[개념 정리] 2. 하둡 분산 파일 시스템(HDFS) 이해(1)

Keyword : HDFS, 구글 플랫폼의 철학, 하둡 특성, 하둡 클러스터 네트워크 및 데몬 구성, 블록, 네임노드, 데이터노드

개인적인 공부를 위해 강의를 정리한 내용입니다. 이번 글에 포함되어 있는 많은 이미지 또한 해당 강의에서 발췌했습니다.
하둡을 처음 공부하시는 분들은 강의 시청을 추천드립니다.

 

하둡 분산 파일 시스템(HDFS) 이해

분산환경은 물리적으로 여러 대의 서버가 하나의 클러스터처럼 동작하는 환경을 뜻합니다. 그런 분산 플랫폼의 구조를 크게 두 개로 나누면 마스터-슬레이브 구조와 마스터가 없는 구조로 나눌 수 있습니다. 마스터-슬레이브 구조는 최종 마스터 역할을 하는 부분이 있고 그 마스터의 관리를 받는 슬레이브들이 있는 구조를 뜻합니다. 슬레이브 서버들은 n대의 서버로 확장할 수 있는 아키텍처를 가져갑니다. 마스터 자체가 없는 구조는 마스터가 가지고 있어야 하는 정보들을 모든 노드가 공유를 하는 유형입니다.

 

구글 파일 시스템 논문에 나와있는 기본 구조

 

GFS는 마스터-슬레이브 구조로, 위의 그림에서 GFS master 부분이 마스터이고 GFS chunkserver 부분들이 슬레이브 입니다. 이 chunkserver는 여러 대로 계속 확장될 수 있는 구조입니다. 그림 왼쪽의 Application(GFS client)가 GFS에 어떤 job을 실행할 수 있는 클라이언트입니다. 하둡이 이 아키텍처를 기반으로 소프트웨어 플랫폼을 구현한 것이기 때문에 구조가 거의 동일합니다. 마스터-슬레이브 구조에서 중요한 부분은 마스터에 부하가 가지 않는 상황을 유지해줘야 한다는 것입니다. 왼쪽 아래 굵은 선을 보면 GFS chunkserver와 GFS client가 직접적으로 연결된 것을 확인할 수 있습니다. 이는 이 두 파트가 실제 트래픽(data)을 주고 받는 것을 뜻하며, 마스터는 데이터를 주고 받는 연산이 전혀 없도록 설계가 되어 있습니다. 마스터에서 데이터를 처리하거나 주고받는 과정은 포함하지 않게 설계하는데, 이는 마스터 부분에서 장애가 발생하면 전체 클러스터의 역할을 못하게 되기 때문입니다. 마스터의 안정성을 보장할 수 있는 구조로 구성하고, 서비스를 운영할 때도 그 부분에 신경을 많이 써야 합니다. 

 

---

 

구글 플랫폼 철학

1. 한 대의 고가 장비보다 여러 대의 저가 장비가 낫다 (Scale-up / Scale-out)

데이터가 페타 단위로 늘어나다 보니, 하드웨어(cpu, 메모리 등)의 스펙 자체를 높이는 것은 물리적으로 한계가 있기 때문에 여러 대의 저가 장비를 하나의 클러스터처럼 확장하는 scale-out 방식을 기본적인 철학으로 가지고 있습니다. 이 철학을 따라 만든 것이 하둡 에코시스템이기 때문에 중요한 철학입니다.

2. 데이터는 분산 저장한다.

분산과 병렬의 차이 : '병렬'은 cpu 중심적인 용어로 많이 사용되어 cpu를 병렬로 처리하는 것의 의미를 강조한 용어고, 분산은 데이터에 좀 더 포커싱을 맞춘 용어입니다. 그래서 데이터를 분산하고 분산된 데이터를 처리하면 보통 distributed computing이라고 하고, 데이터를 공유 스토리지에 공유한 뒤, cpu 코어 수나 메모리를 여러 개로 늘려 가면서 처리하는 것은 보통 parallel computing이라고 합니다. 

3. 시스템(H/W)은 언제든 죽을 수 있다. (Smart S/W)

스마트한 소프트웨어를 만들어서 하드웨어 장애가 나타났을 때 잘 대처해야 한다는 철학을 갖고 있습니다. 하드웨어와 소프트웨어 플랫폼이 서로 잘 연계가 되고 유기적으로 동작하게 구성되어 있습니다. 따라서 소프트웨어만 잘 안다고 해서 플랫폼을 완벽하게 이해했다고 말하기는 힘듭니다. 

4. 시스템 확장이 쉬워야 한다

데이터가 늘어나 처리해야 하는 양이 늘어났을 때 아키텍처 전체를 바꾸고 장비의 스펙을 올려서 개발을 하는 것이 아니라, 클러스터 노드 수를 올리면 작동이 원활히 이루어져야 한다는 뜻입니다.

핵심 키워드는 '분산'과 '자동화'로, 장애 이슈가 생겨도 소프트웨어가 자동으로 복구하고 관리자는 장애가 일어난 부분을 파악해 처리해주면 빠르게 정상 작동하는 것이 구글 플랫폼의 철학입니다.

 

---

 

하둡 특성

수천 대 이상의 리눅스 기반 범용 서버들을 하나의 클러스터로 사용

이때 on-premise(자체적인 전산 서버 구축 및 운용)의 물리적인 클러스터로 구성할 수 있고, 클라우드에 virtual machine(가상 머신)에 뜨는 instance로 구성할 수도 있습니다. 

마스터-슬레이브 구조

하둡도 마스터 역할을 하는 부분이 있고 슬레이브 역할을 하는 부분으로 나누어진 구조로 이루어집니다. 마스터에 대한 관리가 하둡 플랫폼 이용시 굉장히 중요합니다.

파일을 블록(block) 단위로 저장

뒤에서 자세히 설명하겠습니다.

블록 데이터의 복제본 유지로 인한 신뢰성 보장(기본 3개의 복제본)

하둡은 100메가 짜리 데이터를 보관하면 실제로는 300메가 정도의 공간을 차지합니다. 왜냐하면 백업 명령을 내리지 않아도 플랫폼 자체적으로 원본 포함 3개의 복제본을 유지하기 때문입니다. 그렇기 때문에 특정 서버에 장애가 일어났다고 해서 전체 데이터가 손실되는 경우는 없습니다. 

높은 내고장성(Fault-Tolerance) & 데이터 처리의 지역성 보장(locality)

뒤에서 자세히 설명하겠습니다.

 

---

 

하둡 클러스터 네트워크 및 데몬 구성

 

데몬(daemon) : 서비스의 요청에 대해 응답하기 위해 오랫동안 실행 중인 백그라운드(background) 프로세스

하둡은 보통 최소 몇 십대, 수 백대 이상의 서버를 하나의 클러스터로 구성해서 운영합니다. 하둡은 여러 대의 서버를 하나의 클러스터로 구성하다 보니 실제 물리적으로 센터에 들어가는 Rack형 클러스터를 사용하게 되고, 그 안에 렉 switch가 있고 그 안에 여러 대의 노드들이 들어갑니다.

하둡 1.0을 기준으로, Name Node는 하둡 분산파일시스템(HDFS)에 대한 마스터 데몬으로 마스터 서버 역할을 합니다. 슬레이브에 해당하는 DN(Data Node-데이터 저장, 관리하는 노드), TT(Task Tracker-애플리케이션 업무를 수행) 데몬은 보통 하나의 쌍으로 이루어져 있습니다.

분산파일시스템에 저장되어 있는 데이터에 대한 어떤 job의 애플리케이션 연산 처리를 관리하는 마스터 데몬은 Job Tracker입니다. Job Tracker 마스터가 다운되면 전체 job이 관리가 되지 않는 문제가 발생할 수 있기 때문에 최소한의 로드가 걸리게끔 DN, TT와 다른 서버에 띄우는 경우가 많습니다. 하둡 1.0에서 2.0으로 업그레이드 되며 가장 주요하게 변한 부분은 마스터 노드의 이중화입니다. 마스터 노드가 고장났을 경우를 대비하기 위해서 이중화가 추가되었습니다. 

 

---

 

하둡에서 블록(Block)이란?

출처 : https://data-flair.training/blogs/hadoop-hdfs-architecture/

하둡에서는 데이터를 블록이라는 단위로 나눠 저장합니다. 위의 그림과 같이 612MB짜리 Example.txt 파일을 하둡에 복사하면, 128MB짜리 파일들로 A, B,..로 하둡이 스스로 나눈 뒤 저장합니다. 이와 같이 하나의 파일을 여러 개로 나누는 단위를 블록이라고 하고, 하둡 1.0의 디폴트 설정 값은 64MB였고 최근에 업데이트되어 128MB로 나눕니다. 128MB로 나누고 남은 블록은 128MB이 아닌 실제 남은 크기 100MB로 저장이 됩니다.

 

하둡에서 블록 하나의 크기가 큰 이유는?

HDFS의 블록은 128MB와 같이 매우 큰 단위로 되어 있으며 설정으로 64MB, 256MB 등으로 변경 가능합니다. 블록의 사이즈가 큰 이유는 HDFS의 NameNode, DataNode 등이 블럭을 탐색할 때 블록이 크면 하드 디스크에서 시작점을 탐색하는 데 걸리는 시간을 줄일 수 있습니다. 또한 네트워크를 통해 데이터를 전송할 때 파일 위치를 찾는 데 사용하는 리소스를 전송 자체에 더 많은 시간을 할당할 수 있다는 장점이 있습니다. 즉 탐색 비용을 최소화해 데이터를 빠르게 처리할 수 있기 때문에 블록의 사이즈가 큰 것입니다.

 

블록 크기 분할과 추상화에 따른 이점

블록 단위로 나누어 저장하기 때문에 디스크 사이즈보다 더 큰 파일을 보관할 수 있습니다. 또한 파일 단위보다 블록 단위로 추상화를 하면 스토리지의 서브 시스템을 단순하게 만들 수 있으며, 파일 탐색 지점이나 메타정보를 저장할 때 사이즈가 고정되어 있으므로 구현이 용이합니다. 내고장성을 제공하는데 필요한 복제(replication)를 구현할 때 매우 적합합니다. 예를 들어 하나의 서버가 고장났을 때 그 서버에 있던 블록들이 다른 서버들에 2개씩 이미 복제되어 있기 때문에 그 블록들만 추가적으로 다시 복제해주면 됩니다. 즉 같은 노드에 같은 블록이 존재하지 않도록 복제하여 노드가 고장일 경우 다른 노드의 블록으로 복구할 수 있습니다. 중요한 이점 중 하나는 같은 파일을 분산 처리하여 데이터 처리 성능을 개선할 수 있다는 것입니다. 

 

블록의 지역성(Locality)

저장된 데이터에 대해 어떤 연산을 할 때, 데이터 처리는 TaskTracker 데몬에서 이루어지게 되는데 이때 실제 데이터를 갖고 있는 노드(테스크 트래커 포함된 노드)에 먼저 job이 할당 되는 것이 블록의 지역성입니다. 하지만 노드 내에 테스크 트래커가 포함되어 있지 않을 수 있는데 이때는 같은 Rack에 있는 테스크 트래커에 job을 먼저 할당합니다. 그 이유는 같은 Rack의 경우 통신 switch가 모두 연결되어 있어 데이터를 전송하는 시간이 감소하기 때문입니다. 이처럼 블록의 지역성을 활용하면 데이터 전송 시간을 절약하고, 대용량 데이터 확인을 위한 디스크 탐색 시간을 감소할 수 있습니다. 

 

블록 캐싱

저장된 데이터 중 자주 읽는 블록은 블록 캐시(block cache)라는 데이터 노드의 메모리에 명시적으로 캐싱할 수 있습니다. 파일 단위로 캐싱할 수도 있어서 조인(다른 메타 데이터와 함께 사용)에 사용되는 데이터들을 등록해 읽기 성능을 높일 수 있습니다.

 

---

 

네임노드 역할

 

네임노드는 전체 HDFS에 대한 Name Space를 관리합니다. 또한 DataNode로부터 블록 리포트를 받고, 데이터에 대한 복제(Replication)을 유지하기 위한 커맨더 역할을 수행합니다. 그리고 파일시스템 이미지 파일(fsimage)을 관리하는데 fsimage는 파일시스템 데이터의 영속적인 체크포인트(스냅샷) 파일입니다. (fsimage는 파일 시스템에 존재하는 모든 디렉토리와 파일 아이노드(inode) 정보를 바이트로 직렬화 하고, 각 아이노드는 파일의 복제 단위, 변경 및 접근시간, 접근 권한, 블록 크기와 파일을 구성하는 블록 조합들과 같은 정보를 가집니다. 디렉토리는 변경 시간, 권한 할당, 크기 등 메타데이터가 저장됩니다. 출처, 손상 시 많은 데이터 손실) 네임노드는 스냅샷 이후에 변경되는 사항들을 Edit Log에 남기고 이를 관리합니다. 

 

보조 네임노드(Secondary NameNode)

 

네임노드가 처음에 데몬을 구동시키면 fsimage를 읽은 후 메모리에 그 스냅샷을 구성합니다. 전체 하둡 클러스터에 있는 파일 메타정보들을 구성하고, 그 뒤 edit log를 읽어가며 변경 사항을 메모리에 반영을 하게 됩니다. 이러한 과정이 끝나서 네임노드 구성이 끝난 뒤 서비스가 시작되는 것입니다. 그런데 그 이후로 운영하는 중에 파일시스템에 변경이 일어나면 모두 edit log에 남습니다. 그런 변경 사항은 계속 늘어나고, 이를 지속해서 fsimage에 병합을 해줘야 하는데, 네임노드에서 이를 직접 하지 않고, 위의 그림에서 오른쪽과 같이 edit log와 fsimage를 보조 네임노드에 보내서 병합을 한 뒤, 실제 fsimage를 바꿔주는 작업을 주기적으로 해주어 네임노드 메모리는 항상 최신 상태를 유지하게 됩니다. 사실 보조(세컨더리) 네임노드에 장애가 일어나면 그 자체로 하둡 클러스터 운영 관점에서 문제가 발생하지는 않지만, edit log가 너무 커지면 네임 노드를 리스타트 하는 경우에 edig log 파일을 읽지를 못해 out of memory exception이 발생할 수 있습니다. 따라서 보조 네임노드가 잘 병합되고 있는지 관리하는 것도 중요합니다.

 

---

 

데이터노드(DataNode) 역할

 

실제로 데이터는 데이터 노드의 물리적 로컬 파일시스템에 저장되어 있습니다. (네임노드는 데이터를 갖고 있지 않음) 일반적으로 데이터노드는 레이드 구성(RAID, Redundant Array of Independent Disks - HDFS는 노드 간 복제하는 기능이 있어 RAID가 제공하는 중복성은 필요하지 않음, 성능 측면에서도 모든 디스크에 블록을 연속적으로 배열하는 JBOD(Just a Bunch of Disks) 방식보다 느려 레이드의 큰 이득이 없다, 출처)을 하지 않습니다. 또한 데이터노드의 중요한 역할은 마스터 서버에 갖고 있는 데이터를 계속 리포트하는 것입니다. 네임노드가 시작될 때, 그리고 (주기적으로) 로컬 파일시스템에 있는 모든 HDFS 블록들을 검사 후 정상적인 블록의 목록을 만들어 네임노드에 전송합니다. 디스크가 깨지는 등 고장이 발생하는 일은 꽤나 잦은 일입니다.