HDFS (r1)

네임노드는 HDFS 클러스터의 마스터 서버 역할을 하는 핵심 구성 요소이다. 이는 파일 시스템의 네임스페이스와 메타데이터를 중앙에서 관리하며, 클라이언트가 파일에 접근할 수 있도록 전체 시스템의 디렉터리 트리와 파일의 위치 정보를 제공한다.

네임노드가 관리하는 주요 메타데이터에는 파일 및 디렉터리의 이름, 권한, 소유자 정보와 각 파일이 어떤 데이터노드의 어떤 블록들로 구성되어 있는지에 대한 매핑 정보가 포함된다. 이 메타데이터는 주로 시스템 메모리(RAM)에 상주하여 빠른 접근이 가능하지만, 영속성을 위해 FsImage 파일과 EditLog 파일로 디스크에도 저장된다. FsImage는 파일 시스템 네임스페이스의 체크포인트 이미지이고, EditLog는 최신 체크포인트 이후의 모든 트랜잭션 기록이다.

네임노드는 클라이언트의 읽기 요청을 처리할 때, 요청된 파일의 블록 위치 정보를 데이터노드 목록과 함께 반환한다. 쓰기 작업 시에는 새 블록을 할당하고 해당 블록의 복제본을 저장할 데이터노드들을 선택하는 책임을 진다. 또한, 데이터노드로부터 정기적으로 하트비트와 블록 리포트를 수신하여 클러스터의 상태와 데이터 블록의 무결성을 지속적으로 모니터링한다.

네임노드는 단일 장애점이 될 수 있는 구조적 특성을 가진다. 이를 완화하기 위해 고가용성 구성을 위해 액티브-스탠바이 형태의 네임노드 쌍을 운영하거나, 메타데이터의 백업 및 복구를 위해 보조 네임노드를 활용한다. 네임노드의 성능과 확장성은 사용 가능한 메모리 용량에 직접적으로 의존한다.

데이터노드는 HDFS 클러스터의 각 서버에 배포되는 데이터 저장 및 처리 구성 요소이다. 데이터노드는 실제 데이터 블록을 로컬 디스크에 저장하고, 네임노드의 지시에 따라 데이터 블록의 생성, 삭제, 복제 작업을 수행한다. 또한 클라이언트의 데이터 읽기/쓰기 요청을 직접 처리하는 역할을 담당한다.

각 데이터노드는 주기적으로 네임노드에게 하트비트와 블록 리포트를 전송한다. 하트비트는 데이터노드의 활성 상태를 확인하는 신호이며, 블록 리포트는 해당 데이터노드에 저장된 모든 블록의 목록과 상태 정보를 포함한다. 이를 통해 네임노드는 클러스터 전체의 데이터 블록 맵과 데이터노드의 건강 상태를 실시간으로 파악한다.

데이터노드는 데이터 블록을 기본적으로 세 개의 복제본으로 저장한다[2]. 네임노드의 지시에 따라 다른 데이터노드로부터 블록 데이터를 수신하여 저장하거나, 자신이 가진 블록을 다른 데이터노드로 전송하는 파이프라인 복제 작업을 수행한다. 데이터의 무결성을 보장하기 위해 저장된 블록에 대한 체크섬을 계산하고 주기적으로 검증한다.

데이터노드의 주요 구성 요소와 역할은 다음과 같다.

보조 네임노드는 네임노드의 보조 역할을 수행하는 서버 컴포넌트이다. 주된 목적은 네임스페이스의 체크포인트를 생성하여 네임노드의 메타데이터 손실 위험을 줄이고, 장애 복구 시간을 단축하는 것이다. 보조 네임노드는 네임노드의 실시간 장애 조치를 위한 대기 노드가 아니며, 따라서 네임노드가 다운되었을 때 자동으로 서비스를 이어받지 않는다.

보조 네임노드의 핵심 작업은 주기적으로 네임노드의 FsImage 파일과 EditLog를 병합하여 새로운 FsImage 체크포인트를 생성하는 것이다. 이 과정은 다음과 같이 진행된다.

1. 네임노드는 현재의 FsImage와 새로운 트랜잭션을 기록하기 위한 새 EditLog 파일을 생성한다.

2. 보조 네임노드는 이전 FsImage와 기존 EditLog를 네임노드로부터 가져온다.

3. 보조 네임노드는 메모리에서 두 파일을 병합하여 새로운 통합 FsImage를 생성한다.

4. 생성된 새로운 FsImage는 다시 네임노드로 전송되어 적용된다.

이러한 정기적인 체크포인트 생성은 시스템 운영에 중요한 이점을 제공한다. EditLog 파일이 무한정 커지는 것을 방지하여 네임노드의 재시작 시간을 크게 단축시킨다. 또한 최신의 FsImage 체크포인트를 별도로 보관함으로써, 네임노드에 장애가 발생했을 때 이 백업 이미지를 기반으로 시스템을 더 빠르게 복구할 수 있는 기반을 마련한다. 일부 배포판에서는 보조 네임노드의 기능이 체크포인트 노드 또는 백업 노드라는 명칭으로 구현되기도 한다.

HDFS의 기본 데이터 저장 단위는 블록이다. 파일 시스템의 파일은 하나 이상의 블록으로 나뉘어 데이터노드에 분산 저장된다. 기본 블록 크기는 128 메비바이트로 설정되어 있으며, 이는 대용량 파일을 효율적으로 처리하기 위한 설계이다. 블록 크기를 크게 설정함으로써 메타데이터의 양을 줄이고, 네트워크 오버헤드를 최소화하여 대규모 데이터 처리 성능을 향상시킨다.

각 블록은 독립적인 저장 단위로 취급되며, 네임노드는 파일과 이를 구성하는 블록들의 매핑 정보를 관리한다. 파일이 블록으로 분할되면, 각 블록은 고유한 식별자를 부여받고 별도의 저장 단위로 다루어진다. 이 방식은 파일의 크기와 무관하게 일관된 방식으로 데이터를 관리할 수 있게 한다.

블록은 물리적으로 데이터노드의 로컬 파일 시스템에 일반 파일 형태로 저장된다. 각 데이터노드는 할당받은 블록 데이터를 관리하고, 클라이언트의 읽기 요청이 있을 때 해당 블록 데이터를 제공한다. 블록의 크기와 복제 정책은 HDFS의 핵심 설정 항목으로, 클러스터의 성능과 내구성에 직접적인 영향을 미친다.

HDFS는 데이터의 안정성과 가용성을 보장하기 위해 블록 복제 전략을 핵심 메커니즘으로 채택한다. 모든 파일은 여러 개의 복제본으로 구성된 블록 시퀀스로 저장되며, 기본 복제 계수는 3으로 설정되어 있다[4]. 이는 데이터를 여러 데이터노드에 분산 저장함으로써, 단일 디스크나 서버의 장애가 발생하더라도 데이터 손실 없이 서비스를 계속할 수 있도록 설계되었다.

복제본의 배치는 네트워크 대역폭과 장애 도메인을 고려한 정책에 따라 결정된다. 일반적인 배치 전략은 첫 번째 복제본을 클라이언트가 위치한 동일한 데이터노드에, 두 번째 복제본은 다른 랙의 노드에, 세 번째 복제본은 두 번째 복제본과 같은 랙 내의 다른 노드에 저장하는 방식이다. 이 전략은 랙 간 네트워크 트래픽을 최소화하면서도, 전체 랙이 손상되는 장애에 대비할 수 있도록 한다.

네임노드는 모든 블록과 그 복제본의 위치 정보를 메타데이터로 관리하며, 정기적인 하트비트와 블록 리포트를 통해 데이터노드의 상태와 복제본의 무결성을 모니터링한다. 만약 특정 데이터노드가 응답하지 않거나 블록이 손상된 것으로 감지되면, 네임노드는 다른 정상 노드에 새로운 복제본을 생성하도록 복제 명령을 내려, 전체 클러스터의 복제 계수를 항상 유지하도록 한다.

클라이언트가 HDFS에 파일을 쓰려면 먼저 네임노드에 파일 생성 요청을 보낸다. 네임노드는 파일의 메타데이터를 생성하고, 파일 데이터를 저장할 적절한 데이터노드 목록을 클라이언트에게 반환한다. 클라이언트는 첫 번째 데이터노드에 데이터 블록을 직접 쓰기 시작하며, 이 데이터노드는 블록을 복제본 수만큼 지정된 다음 데이터노드로 파이프라인 방식으로 전달한다. 모든 데이터노드로부터 쓰기 완료 확인을 받으면 클라이언트는 네임노드에 완료를 알린다.

읽기 작업은 쓰기보다 단순하다. 클라이언트가 네임노드에 파일의 블록 위치를 요청하면, 네임노드는 각 블록의 복제본을 보유한 데이터노드 목록을 반환한다. 클라이언트는 목록에서 가장 가까운 데이터노드에 접속하여 데이터를 직접 읽는다. 첫 번째 블록 읽기가 끝나면 클라이언트는 다음 블록의 위치를 네임노드에 다시 요청하고, 이 과정을 파일 끝까지 반복한다.

이러한 읽기/쓰기 모델은 몇 가지 중요한 특징을 가진다. 첫째, 데이터 이동은 네임노드를 거치지 않고 클라이언트와 데이터노드 사이에서 직접 이루어진다. 이는 네임노드의 병목 현상을 방지하고 전체 처리량을 높인다. 둘째, 데이터 일관성 모델은 "한 번 쓰고, 여러 번 읽기"에 최적화되어 있다. 파일은 생성되고 닫힌 후에는 수정할 수 없으며, 오직 추가만 가능하다. 이는 데이터 무결성을 보장하고 고성능의 순차적 읽기를 가능하게 한다.

HDFS는 시스템 구성 요소의 고장을 자동으로 감지하고 복구하는 장애 허용 설계를 핵심 원리로 삼는다. 이는 저가의 상용 하드웨어를 대규모로 사용하는 환경에서 필수적인 특성이다. 장애 허용의 핵심은 데이터의 다중 복제본 정책과 구성 요소의 모니터링 및 자동 복구 메커니즘에 있다.

데이터 수준의 장애 허용은 블록 복제를 통해 구현된다. 클라이언트가 파일을 HDFS에 쓰면, 시스템은 기본적으로 각 데이터 블록을 서로 다른 데이터노드에 3개의 복제본으로 생성한다[5]. 하나의 데이터노드가 고장나거나 디스크에 배드 섹터가 생겨 특정 블록에 접근할 수 없게 되어도, 클라이언트는 다른 데이터노드에 저장된 동일 블록의 복제본을 통해 데이터를 정상적으로 읽을 수 있다. 네임노드는 주기적으로 각 데이터노드로부터 하트비트와 블록 리포트를 수신하여 블록 복제본의 상태와 위치를 지속적으로 추적한다. 특정 데이터노드로부터 하트비트가 중단되면 네임노드는 해당 노드를 장애 상태로 표시하고, 그 노드가 보유했던 블록들의 복제본이 설정된 복제 계수 미만으로 떨어졌음을 인지한다. 이후 네임노드는 다른 정상 데이터노드에 부족한 복제본을 새로 생성하도록 복제 명령을 내려 복제 계수를 유지한다.

네임노드 자체의 장애는 더 심각한 문제를 일으킬 수 있으며, 이를 위한 메커니즘도 마련되어 있다. 네임노드의 메타데이터는 지속성을 위해 로컬 디스크와 NFS 같은 원격 저장소에 이중으로 기록된다. 또한, 보조 네임노드는 주기적으로 체크포인트를 생성하여 메타데이터의 스냅샷을 유지함으로써 복구 시간을 단축하는 역할을 한다. 고가용성(HA) 구성을 위해 Active-Standby 방식의 네임노드 쌍을 설정할 수도 있다. 이 경우 Active 네임노드에 장애가 발생하면 Standby 네임노드가 즉시 인계받아 서비스를 계속하며, 저널 노드를 통해 메타데이터 변경 사항이 공유되어 상태의 일관성을 보장한다.

네임스페이스는 HDFS에서 파일 시스템의 계층적 디렉터리 구조와 파일의 메타데이터를 의미한다. 이 네임스페이스는 네임노드에 의해 중앙 집중적으로 관리된다. 네임노드는 파일과 디렉터리의 이름, 소유권, 권한, 생성 및 수정 시간 등의 속성 정보와 함께, 각 파일의 데이터 블록이 어떤 데이터노드에 저장되어 있는지에 대한 매핑 정보를 메모리에 유지한다. 이러한 메타데이터는 파일 시스템의 전체 구조를 정의한다.

네임스페이스의 모든 변경 사항은 네임노드에 기록된다. 예를 들어, 새 파일 생성, 디렉터리 삭제, 파일 이름 변경 등의 작업은 네임노드에 의해 처리되고, 그 트랜잭션 로그인 FsImage와 EditLog에 기록된다. 네임노드는 이러한 메타데이터를 기반으로 클라이언트의 파일 시스템 조작 요청을 처리하고, 실제 데이터 입출력 위치를 안내하는 역할을 한다. 네임스페이스 자체는 데이터노드의 실제 데이터 블록 저장과는 독립적으로 관리된다.

네임스페이스 관리는 HDFS의 확장성과 성능에 직접적인 영향을 미친다. 네임노드의 메모리 용량은 관리 가능한 파일과 디렉터리의 총 개수를 제한하는 주요 요소이다. 매우 많은 수의 소규모 파일을 저장하는 경우, 각 파일에 대한 메타데이터가 네임노드 메모리를 과도하게 소비하여 확장성 문제를 일으킬 수 있다. 이러한 한계를 극복하기 위해, Hadoop 2.0 이후에는 HDFS 페더레이션 아키텍처가 도입되어, 여러 독립적인 네임스페이스를 여러 네임노드가 분산하여 관리할 수 있게 되었다.

HDFS는 사용자가 파일 시스템을 조작할 수 있도록 Hadoop 분산 파일 시스템 쉘을 제공합니다. 이 쉘은 hadoop fs 또는 hdfs dfs 명령어로 접근할 수 있으며, 두 명령어는 기능상 동일합니다. 이 명령어들은 리눅스의 표준 파일 시스템 명령어와 유사한 구문을 따릅니다.

주요 명령어는 다음과 같이 분류할 수 있습니다.

명령어 사용 시, 경로는 HDFS의 루트를 기준으로 지정하며, hdfs://<네임노드호스트>:포트/경로 형식의 전체 URI를 사용하거나 기본 설정을 사용하는 경우 간단히 /경로로 지정할 수 있습니다. 예를 들어, /user/hadoop 디렉토리를 생성하려면 hdfs dfs -mkdir /user/hadoop 명령을 실행합니다. 로컬 파일 data.txt를 HDFS의 해당 디렉토리로 업로드하려면 hdfs dfs -put ./data.txt /user/hadoop/을 사용합니다.

이 쉘 명령어들은 스크립트에서 배치 작업을 자동화하거나, 시스템 관리자가 HDFS 클러스터를 운영하고 모니터링하는 데 필수적인 도구입니다. 또한 -help 옵션을 사용하면 특정 명령어의 상세 사용법을 확인할 수 있습니다.

HDFS는 하둡 생태계의 핵심 구성 요소로서, Java 언어를 통해 애플리케이션에서 직접 파일 시스템에 접근하고 조작할 수 있는 풍부한 API를 제공한다. 이 API는 org.apache.hadoop.fs 패키지에 정의되어 있으며, 파일과 디렉터리의 생성, 삭제, 읽기, 쓰기, 상태 확인 등 기본적인 파일 시스템 연산을 수행하는 데 사용된다. 모든 작업의 시작점은 FileSystem 객체를 얻는 것이며, 이는 주로 FileSystem.get() 정적 메서드에 Configuration 객체를 전달하여 획득한다.

핵심 클래스와 주요 메서드는 다음과 같다.

* FileSystem: HDFS와 상호작용하는 주요 인터페이스이다. open(), create(), mkdirs(), delete(), listStatus() 등의 메서드를 제공한다.

* Path: HDFS 내 파일이나 디렉터리의 위치를 나타내는 불변 객체이다.

* FSDataInputStream: 파일을 읽기 위한 입력 스트림으로, FileSystem.open() 메서드를 통해 얻는다. 임의 접근을 지원하는 seek() 메서드가 특징이다.

* FSDataOutputStream: 파일에 쓰기 위한 출력 스트림으로, FileSystem.create() 메서드를 통해 얻는다. 버퍼링된 스트림을 제공한다.

아래는 HDFS에 파일을 쓰고 읽는 기본적인 Java API 사용 예시이다.

```java

import org.apache.hadoop.conf.Configuration;

import org.apache.hadoop.fs.*;

public class HDFSExample {

public static void main(String[] args) throws Exception {

Configuration conf = new Configuration();

conf.set("fs.defaultFS", "hdfs://namenode:9000");

FileSystem fs = FileSystem.get(conf);

// 파일 쓰기

Path writePath = new Path("/user/test/output.txt");

FSDataOutputStream out = fs.create(writePath);

out.writeUTF("Hello HDFS\n");

out.close();

// 파일 읽기

Path readPath = new Path("/user/test/output.txt");

FSDataInputStream in = fs.open(readPath);

String content = in.readUTF();

System.out.print(content);

in.close();

fs.close();

}

}

```

Java API는 고수준의 편의성을 제공하지만, RPC 호출과 데이터 전송의 오버헤드로 인해 작은 파일을 매우 많이 처리할 때는 성능 저하가 발생할 수 있다. 또한, 스트림 기반의 API이므로 복잡한 파일 시스템 트랜잭션을 구현하기에는 제한적이다. 이러한 고수준 API 외에도, HDFS는 네임노드와 데이터노드 간의 저수준 통신 프로토콜을 정의하며, 이는 주로 HDFS 클라이언트나 특수 목적의 도구 개발에 사용된다.

HDFS의 동작은 여러 설정 파일을 통해 제어된다. 주요 설정 파일은 XML 형식으로 작성되며, 하둡 설치 디렉토리의 etc/hadoop/ 하위에 위치한다.

핵심 설정 파일은 다음과 같다.

hdfs-site.xml 파일은 가장 중요한 HDFS 전용 설정을 담고 있다. dfs.replication 파라미터는 데이터 블록의 기본 복제 계수를 결정하며, 일반적으로 3으로 설정된다. dfs.blocksize는 HDFS가 파일을 나누는 기본 블록 크기를 지정하며, 기본값은 128MB이다. 또한, dfs.namenode.name.dir은 네임노드의 메타데이터(예: fsimage와 에디트 로그)가 저장되는 로컬 디렉토리 목록을, dfs.datanode.data.dir은 데이터노드가 실제 데이터 블록을 저장하는 로컬 디렉토리 목록을 정의한다.

설정 변경 후에는 영향을 받는 HDFS 데몬을 재시작해야 적용된다. 또한, 고가용성(HA) 구성이나 Kerberos 보안 설정과 같은 고급 기능을 사용할 경우에는 추가적인 설정 파일(hdfs-site.xml 내 상세 파라미터)이 필요하다. 모든 설정은 클러스터 내 모든 노드의 설정 파일에 일관되게 적용되어야 정상적인 동작을 보장한다.

HDFS 클러스터의 상태와 성능을 지속적으로 추적하는 것은 안정적인 운영에 필수적이다. 모니터링은 주로 네임노드와 데이터노드의 상태, 클러스터 용량, 블록 상태, 입출력 작업 등을 확인하는 것을 포함한다.

주요 모니터링 수단은 네임노드의 웹 UI(기본 포트 9870)와 데이터노드의 웹 UI(기본 포트 9864)이다. 네임노드 웹 UI는 클러스터의 전반적인 상태를 한눈에 보여주며, 다음 정보를 제공한다.

또한, HDFS는 JMX(Java Management Extensions) 메트릭을 노출시켜 Ganglia, Prometheus와 같은 외부 모니터링 시스템과의 통합을 지원한다. 이를 통해 네임노드의 RPC 처리 시간, 데이터노드의 디스크 사용률, 블록 복제 상태와 같은 상세한 성능 지표를 수집하고 시각화할 수 있다. 정기적인 로그 파일(hadoop-hdfs-namenode.log, hadoop-hfs-datanode.log) 점검도 장애 조기 발견에 도움이 된다.

HDFS의 인증은 클라이언트와 서버 컴포넌트가 서로의 신원을 확인하는 과정이다. 초기 HDFS는 단순한 신뢰 기반 모델을 사용했으나, 보안 요구사항이 증가하면서 Kerberos 프로토콜을 기반으로 한 강력한 인증 체계가 도입되었다. Kerberos 인증이 활성화된 환경에서는 사용자나 서비스가 티켓 부여 티켓을 획득한 후 서비스 티켓을 받아야만 HDFS 클러스터에 접근할 수 있다. 이는 무단 접근을 방지하는 핵심 메커니즘이다.

인증 방식은 크게 두 가지로 구분된다. 첫째는 위에서 설명한 Kerberos 기반의 강력한 인증이다. 둘째는 단순 인증으로, 클라이언트의 호스트 운영체제 사용자 ID를 신뢰하는 방식이다. 후자는 보안 수준이 낮아 개발 환경이나 폐쇄된 네트워크에서 주로 사용된다. 인증 모드는 hadoop.security.authentication 속성을 통해 simple 또는 kerberos로 설정한다.

인증이 완료되면, HDFS는 인가 단계에서 해당 사용자에게 권한을 부여한다. 또한 Hadoop 에코시스템 내에서 Delegation Token이나 Block Access Token과 같은 위임 토큰 메�니즘을 사용해 인증 성능을 최적화하기도 한다.

HDFS의 권한 모델은 유닉스 파일 시스템의 권한 체계를 크게 본떠서 설계되었다. 파일과 디렉터리에 대해 소유자, 그룹, 기타 사용자별로 읽기(r), 쓰기(w), 실행(x) 권한을 부여하는 방식이다. 그러나 HDFS의 실행 권한은 파일이 아닌 디렉터리에 대해서만 의미를 가지며, 디렉터리 내부의 파일 및 서브디렉터리 목록에 접근할 수 있는지 여부를 결정한다.

권한 검사는 클라이언트가 네임노드에 요청을 보낼 때 수행된다. 네임노드는 요청을 보낸 사용자(클라이언트 프로세스의 사용자 ID)와 파일/디렉터리의 소유자 및 그룹 정보를 비교하여 접근을 허용할지 판단한다. 기본적으로 권한 검사는 활성화되어 있지만, 설정을 통해 비활성화할 수도 있다[7]. 이는 신뢰할 수 있는 환경에서의 운영 편의를 위한 것이다.

권한 관리를 위한 주요 HDFS 쉘 명령어는 다음과 같다.

초기 버전의 HDFS 권한 모델은 상대적으로 단순했으나, Kerberos 기반의 강력한 인증이 도입되고, HDFS ACL (Access Control List)이 지원되면서 세분화된 접근 제어가 가능해졌다. ACL은 기존의 유닉스 스타일 권한을 보완하여, 특정 명명된 사용자나 그룹에게 추가적인 권한을 부여할 수 있게 한다.