KU 데이터 엔지니어의 데이터 허브 고도화 2탄:

HDFS

뉴스레터 구독자 여러분 안녕하세요. 디지털정보처 데이터Hub팀 한수연입니다. 지난 호에서 하둡 에코 시스템의 가장 기본인 하둡에 대해서 알아보기 시작했는데요. 하둡의 분산 처리 시스템인 맵리듀스가 무엇인지 관련 논문을 함께 읽어보는 시간을 가졌습니다. 이번에는 하둡의 또 다른 핵심 중 하나인 HDFS의 개념을 Apache Hadoop 공식 문서를 많이 참고해 공부해 보려고 합니다.

하둡(Hadoop)과 HDFS의 관계

HDFS가 하둡에서 어떤 역할을 하는지 말씀드리기 전에 지난 시간에도 언급했던 아파치 하둡의 정의를 다시 적어보도록 하겠습니다. 아파치 하둡은 대용량 데이터를 분산 처리할 수 있는 자바 기반의 오픈소스 프레임워크로 구글이 논문으로 발표한 GFS(Google File System)와 맵리듀스(MapReduce)를 구현한 결과물입니다. 하둡은 분산 파일 시스템인 HDFS(Hadoop Distributed File System)를 통해 데이터를 분산 저장하고, 분산 처리 시스템인 맵리듀스를 이용해 데이터를 처리합니다. 위 개념에서 알 수 있듯이 HDFS는 하둡이 제공하는 분산 파일시스템으로 정의할 수 있습니다.

HDFS

HDFS는 마스터/슬레이브 아키텍처를 가지고 있습니다. HDFS 클러스터는 하나의 네임노드(namenode)와 여러 개의 데이터노드(datanode)로 구성되는데요. 네임노드는 파일 시스템의 네임스페이스(namespace)를 관리하고, 클라이언트에 의한 파일접근을 규제하는 마스터 서버입니다. 네임노드는 하둡의 SPOF(Single Point of Failure)로 하둡2부터 네임노드를 2개가 기본으로 제공되어 네임노드가 다운되는 상황을 방지하려는 노력을 하고 있습니다. HDFS는 파일 시스템 네임스페이스를 노출시키고, 사용자 데이터를 파일에 저장할 수 있도록 합니다. 내부적으로 파일은 하나 이상의 블록으로 분할되고 이러한 블록은 데이터노드 세트에 저장됩니다. 데이터노드는 보통 클러스터에서 노드 하나당 한 개로 구성됩니다. 네임노드는 파일 및 디렉토리 열기, 닫기, 이름 바꾸기와 같은 파일 시스템 네임스페이스 작업을 실행하는데요. 이 뿐만 아니라 데이터노드에 대한 블록 매핑을 결정합니다. 데이터노드는 파일 시스템의 클라이언트로부터의 읽기 및 쓰기 요청을 처리하는 역할을 합니다. 또한, 네임노드의 지시에 따라 블록 생성, 삭제 및 복제를 수행하는 일꾼입니다.

그림1. HDFS Architecture [Apache Hadoop]

네임노드와 데이터노드는 상용 머신에서 실행되도록 설계된 소프트웨어로 일반적으로 GNU/Linux 운영체제(OS)에서 활용됩니다. HDFS는 Java 언어를 사용하여 구축되었는데요. Java를 지원하는 모든 시스템은 네임노드나 데이터노드 소프트웨어를 실행할 수 있습니다. 이식성이 높은 Java 언어를 사용한다는 것은 HDFS가 광범위한 시스템에 배포할 수 있다는 것으로 이해할 수 있습니다. 일반적인 배포에는 네임노드 소프트웨어만 실행하는 전용 시스템이 있습니다. 클러스터의 다른 머신 각각은 데이터노드 소프트웨어의 인스턴스 하나를 실행합니다. 클러스터에 단일 네임노드가 있으면 시스템 아키텍처가 크게 단순화됩니다. 네임노드는 모든 HDFS 메타데이터에 대한 중재자이자 저장소입니다. 시스템은 사용자 데이터가 네임노드를 통해 흐르지 않도록 설계되었습니다.

위의 복잡한 말을 요약해보면 HDFS는 하둡의 스토리지 계층이고, 분산 파일 시스템을 빠르게 처리하는 것에 최적화되어 있는 시스템이며, 마스터/워커 패턴으로 동작하는 네임노드와 데이터노드가 있고, 네임노드의 규제하에 큰 파일을 블록 청크로 분할해서 데이터노드를 통해 클러스터의 여러 머신에 저장하는 시스템입니다. 또한, 네임노드는 모든 HDFS 메타데이터를 저장해 데이터를 관리하지만 실제 사용자 데이터는 네임노드가 아닌 데이터노드를 통하도록 설계되었고 중요한만큼 하둡의 SPOF로 볼 수 있습니다. 

Block

위에서 계속 언급되는 블록에 대해서 조금 더 자세히 얘기해보겠습니다. 물리적인 디스크에서는 블록 크기라는 개념이 있는데요. 이는 한 번에 읽고 쓸 수 있는 데이터의 최대량을 말합니다. 파일시스템 블록의 크기는 보통 수 킬로바이트고, 디스크 블록의 크기는 기본적으로 512바이트입니다. HDFS도 블록의 개념을 가지고 있는데, 하둡3에서 기본 블록 크기는 128MB와 같이 굉장히 큰 단위입니다. HDFS의 파일은 단일 디스크를 위한 파일시스템처럼 특정 블록 크기의 청크로 쪼개지고 각 청크는 독립적으로 저장됩니다. HDFS 블록이 디스크 블록에 비해 그 크기가 큰 이유는 탐색 비용을 최소화하기 위해서 입니다. 디스크에서 데이터를 읽는데 걸리는 총 시간은 파일의 첫 번째 블록을 찾는 seek time과 연속된 데이터 블록을 읽는 데 걸리는 transfer time으로 구성되는데요. 시스템이 수백 테라바이트 또는 페타바이트의 데이터를 처리할 때, 디스크에서 읽는 데 걸리는 시간이 아주 중요합니다. Seek time을 줄이기 위해 블록 크기를 크게 설정하면 seek time을 줄일 수 있고 데이터를 전송하는 데 더 많은 시간을 할애할 수 있습니다.

블록 크기가 작게 설정되면 네임노드에 대해 너무 많은 작업을 생성하는 많은 분할이 발생합니다. 반면에 블록 크기를 크게 설정하면 각 블록은 하나의 mapper에 의해 처리되므로 블록 갯수가 적으면 클러스터의 모든 노드가 사용되지 않을 수 있어서 클러스터가 병렬 처리로 잘 활용되지 못합니다. 128MB가 최적인 것으로 밝혀졌지만 일부 응용 프로그램에는 더 크거나 더 작은 블록 크기가 필요할 수 있습니다. 하지만 Signed 32-bit integer overflow 때문에 블록 사이즈를 2GB보다 크게 설정하는 것은 주의해야 한다고 전문가들은 말합니다.

Data Replication

HDFS는 블록 단위로 데이터를 저장하기 때문에 복제(replication)를 구현하기 적합한 형태인데요. 블록의 손상과 디스크 및 머신의 장애에 대처하기 위해 각 블록은 물리적으로 분리된 다수의 머신에 복제됩니다. HDFS에는 ‘The default replication factor is three’라는 말이 자주 사용되는데요. 이는 일반적으로 HDFS의 블록 복제 계수(replication factor)를 3으로 해서 하나의 블록을 복제해 3개의 머신에 저장한다는 의미입니다.

그림2. Block Replication [Apache Hadoop]

만일 하나의 블록을 이용할 수 없는 상황이 되면 다른 머신에 있는 복사본을 읽도록 클라이언트에 알려주게 됩니다. 네임노드가 블록 복제에 관한 모든 결정을 내리는데, 클러스터의 각 데이터노드에서 주기적으로 Heartbeat와 Blockreport를 수신합니다. 네임노드는 Heartbeat를 통해 데이터노드가 제대로 작동하고 있음을 판단하는데요. Blockrport에는 데이터노드의 모든 블록 목록이 포함되어 있습니다. 블록이 손상되거나 머신의 장애로 특정 블록을 더 이상 이용할 수 없으면 또 다른 복사본을 살아 있는 머신에 복제하여 복제 계수(replication factor)를 정상 수준으로 돌아오게 할 수 있습니다. 또한, 읽기 부하를 클러스터 전체에 분산시키기 위해 특정 블록의 복제 계수를 높게 설정하기도 합니다.

The Persistence of File System Metadata

HDFS 네임스페이스는 네임노드에 저장됩니다. 네임노드는 EditLog라는 트랜잭션 로그를 사용하여 파일 시스템 메타데이터에 발생하는 모든 변경 사항을 지속적으로 기록하는데요. 예를 들어 HDFS에 새 파일을 생성하면 네임노드가 이를 나타내는 레코드를 EditLog에 삽입합니다. 마찬가지로 파일의 복제 요소를 변경하면 새 레코드가 EditLog에 삽입됩니다. 네임노드는 로컬 호스트 OS 파일 시스템의 파일을 사용하여 EditLog를 저장합니다. 파일 및 파일 시스템 속성에 대한 블록 매핑을 포함하여 전체 파일 시스템 네임스페이스는 FsImage라는 파일에 저장됩니다. FsImage는 네임노드의 로컬 파일 시스템에도 파일로 저장됩니다. 일종의 파일 시스템 메타데이터의 시점 스냅샷 이미지로 볼 수 있습니다. 문제가 발생했을 때, 네임노드는 FsImage를 로드한 다음 EditLog의 모든 작업을 재생하여 파일 시스템의 가장 최근 상태를 읽어 복원하는 방식으로 네임노드의 SPOF 문제를 해결하고자 합니다.

데이터 허브 고도화 작업 2탄: HDFS를 마치면서

이번 호에서는 HDFS의 가장 기본적인 개념에 대해 알아보는 시간을 가졌는데요. 처음 접하는 이들에게는 다소 복잡할 수도 있겠습니다. 다음 시리즈에서는 또 다른 하둡의 핵심 중 하나인 YARN에 관한 이야기를 나누고 싶습니다. 읽어주셔서 감사합니다.

참고 자료

“Apache Hadoop”, https://hadoop.apache.org.

톰 화이트, 하둡 완벽 가이드, 한빛미디어, 2017.