[Hadoop_기초] 3. Hadoop 분산파일시스템 이해(1)

hadoop 유튜브 영상 참고하여 정리한 내용입니다.

 

HDFS의 원리 - Google File System

the google file system을 참고하여 만들어 진 것이 hadoop distributed file system이다. 

GFS아키텍쳐를 포함한 분산환경 아키텍쳐는 여러대의 서버가 클러스터처럼 동작하는 것이다.

분산 환경 아키텍쳐는 master-slave 구조와 no-master 구조로 크게 나뉠 수 있다.

master-slave 구조에서 slave 서버가 확장해 나가는 식으로 scale out 해나간다. 대부분의 분산환경 서버가 이러한 구조이다. 

no - master 구조는 모든 노드들이 동일하게 데이터를 공유하고 있다. GFS는 master-slave 구조이다. 

아래에서 chunkserver가 slave 서버라고 볼 수 있다. 

master에 부하가 가지 않는 상황을 만들어 주는 것이 해당 구조의 핵심이다. 

따라서 어플리케이션과 chunkserver가 direct로 연결되어서, 트래픽을 주고 받지만 master하고는 데이터를 주고받지는 않는다. 

master-slave 구조는 master의 안정성이 가장 보장되어야 하며 master에서 에러가 발생하면 전체적으로 문제가 생긴다.

기존에는 서버의 스펙을 높임으로써 scale up에 집중했다면 이제는 어느정도 한계가 온 상태에서 데이터의 양은 점점 더 많아지므로

scale out 에 집중하고 있다. 

이러한 구글 플랫폼의 철학을 바탕으로 만들어진 것이 HDFS이다.

병렬처리(parallel) : 보다 CPU 중심적인 연산, CPU를 병렬적으로 두어 처리하는 것에 집중. 데이터를 공유 스토리지에 공유해놓고, CPU코어수나 메모리수를 여러개를 두어 처리하는 것.

분산처리(distributed) : 데이터에 집중되어 있는 방식, 데이터를 분산하여 그 분산된 데이터를 처리 하는 것. 

데이터를 분산하고 자동화하는 것에 집중

자동화 : 장애가 나도 소프트웨어가 알아서 자동으로 복구되는 것. 

 

HDFS - hadoop distributed file system (분산파일시스템)

• 수천대 이상의 리눅스 기반 범용 서버들을 하나의 클러스터로 사용
  -> 온프레미스에 물리적인 서버로 구축할 수도 있고, 클라우드에 가상서버로 구동할 수도 있다.
• 마스터 - 슬레이브 구조
• 파일은 블록 단위로 저장
• 블록 데이터의 복제본 유지로 인한 신뢰성 보장(기본 3개 복제본)
  -> 100메가 데이터를 저장하려면 복제본 때문에 300메가를 사용하게 된다. (자체적으로)
• 높은 내고장성(fault-tolerance)
• 데이터 처리의 지역성 보장

하둡은 기본적으로  위와 같은 구조로 수백대의 클러스터를 구성한다. 

• namenode가 마스터서버의 역할을 한다. 하둡 분산파일 시스템에 대한 마스터 데몬이다.
• DN - data node(데이터를 저장관리) / TT - test tracker(실제 어플리케이션 업무 실행)
  이 두개는 하나의 쌍으로 데몬을 띄운다. 하둡 플랫폼의 슬레이브 데몬을 구성한다.
• 분산 파일 시스템에 저장된 어플리케이션 연산을 처리하기 위해 어플리케이션 관리하는 마스터 데몬은 job tracker. 별도의 서버를 띄운다. 이 또한 최소한의 부하가 가도록 관리를 해야한다. 

 

1. HDFS - Block

-> 하둡에 어떠한 612메가 파일을 복사하려는 작업을 하려 할때, 아래와 같이 128메가로 하둡이 용량을 쪼개서 분산 파일시스템에 저장한다. 

-> 블록은 하나의 큰 파일을 하둡이 쪼개는 기준을 블록이라 한다. 

-> 왜 128메가? 원래 디폴트는 64메가였는데, 업그레이드되면서 128메가가 됨. 

 

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

• HDFS의 블록은 128메가오 같이 매우 큰 단위이다.
  -> 설정에 따라서 용량을 더 적게 설정할 수 있다.
• 이러한 이유는 탐색 비용을 최소화할 수 있기 때문이다.
• 블록이 크면 하드디스크에서 블록의 시작점을 탐색하는데 걸리는 시간을 줄일 수있고 네트워크를 통해 데이터를 전송하는데 더 많은 시간을 할당할 수 있다.
• 데이터 처리를 빨리 할 수 있다.

예시)

1분에 24기가바이트의 데이터를 생성하는 경우가 있다고 하자. 일종의 로그성 데이터인 것. 

1. 이 데이터를 하둡 클러스터에 저장한다면 (이 방식은 다양. 하둡 커맨드/ kafka 연계 등등)
2. 하둡 내부적으로 알아서 128메가의 블록으로 쪼갠다. 
3. 그리고 서버내에 분산하여 저장한다.(슬레이브 DN에) / 이때 데이터를 복사하여 여러개를 저장한다. 
4. 즉 128메가로 쪼개서 만들어진 블록의 X3만큼의 복제본이 만들어지는 것이다. 

만약 특정 노드에 장애가 발생한다면? DFS 마스터노드(name node)는 각 노드와 통신하며 관리하는데, 이때 DN의 장애를 탐지할 수 있게 된다. 통신이 특정 시간 이후에도 오지 않는 다면 장애로 인지하게 된다. 

namenode는 실제로 데이터가 복제돼서 저장될 때, 각 데이터의 노드 위치와 형식을 보관한다. 따라서 각 블락들이 어디에 저장되어 있는지 다아는 것이고 주기적으로 리포트를 받는다. 

장애가 발생한 노드가 가지고 있던 데이터 복제본의 노드가 실행되도록 마스터가 명령을 전송한다. 그러면서 장애가 발생한 노드에 있던 데이터에 대한 새로운 복제가 발생하게 되고, 이때 데이터 노드 간에 통신이 발생한다. 

즉 장애가 발생하더라도 하둡에서는 항상 세개의 복제본을 유지한다.

이 때도 작업자가 수기로 작업하는 경우는 없다. 하둡 내에서 자동으로 발생되는 과정들이다. 

이 때 over replicated가 발생하지 않도록도 namenode가 관리한다. 

 

하둡이 데이터 유실이 발생할 경우?

- 세개의 복제본 데이터 노드가 거의 동시에 장애가 발생한 경우

이 말인 즉슨, 세 개의 복제본이 저장된 데이터 노드가 동시적으로 장애가 발생하지 않는 다면 데이터 유실은 거의 일어나지 않는다.

 

일반적인 서버의 스펙은?

보통 연산을 메모리 상에서 많이 하므로 데이터 노드 하나에 메모리를 많이 할당한다. 
최근 ETL 처리를 spark 엔진으로 많이 활용한다. spark이 메모리 베이스로 데이터를 처리하기 때문이다. 
노드 하나에 메모리를 128기가에서 일반적으로 256기가를 할당한다. 

CPU는 오히려 그렇게 비싸고 좋은 것을 사용하지 않는다. 가장 저가이면서 효율적인 CPU모델을 사용한다.

core수는 hyper threading을 지원하는 것을 기본으로 사용한다. 보통 virtual core 포함해서 16~32개 정도

데이터 디스크는 여러개를 구성한다. 최근에는 과거처럼 너무 큰 디스크를 사용하지는 않는다.(성능적인 문제로 인해)
하나당 2~3테라 정도의 크기를 사용한다. 

하둡 클러스터를 운영하다보면 scale out을 해야하는 경우가 오는데, 이 때 온프레미스로 운영하다보면 도입 시기에 따라서 클러스터 스펙들이 달라진다. (운영상의 문제 발생)

 

블록의 지역성(locality)

- 맵리듀스와 관련된 개념

저장된 데이터들에 대해 연산을 처리하고 싶다면? 맵리듀스 프로그램을 짜서 실행하게 된다. 

이 때 슬레이브 노드 하나에 DN과 TT를 같이 띄우게 된다.  namenode가 데이터를 가지고 있는 슬레이브 서버에 연산을 할당하게 된다. 그리고 test tracker가 자기 자신이 가지고 있는 데이터를 실행한다. 즉 local 데이터를 읽고 연산하게 된다는 것이다. 실제 데이터가 있는 곳에 가서 연산을 수행하는 것이 지역성의 기본 특성이다.

 

=> 따라서 장기적으로 본다면 마스터 노드의 스펙도 중요하다. 

 

블록 캐싱

• 데이터 노드에 저장된 데이터 중 자주 읽는 블록은 블록 캐시라는 데이터 노드의 메모리에 캐싱
• 파일 단위로 캐싱할수있어서 조인에 사용되는 데이터들을 등록하여 읽기 성능을 높일 수 있다. 
• 여기서 용량이 크지 않은(상대적이지만 보통 수십메가바이트) 데이터의 경우

네임노드의 역할

• 전제 HDFS에 대한 name, space 관리
• data node로부터 block 리포트를 받음
• data에 대한 복제 유지를 위한 커맨더 역할 수행
• 파일 시스템 이미지 파일 관리
• 파일 시스템에 대한 edit log 관리

보조네임노드(SNN)

• 네임노드의 메모리에는 항상 최신상태를 유지해야한다. 네임노드가 fs이미지를 읽을 때 변경 사항을 적용하게 된다. 이 때 edits log 등 변경 사항이 점점 늘어나게 된다. 이때 이러한 변경 사항을 SNN에 저장해서 머지한 다음에, 네임 노드의 fs이미지를 최신화해주게 된다. 
• 즉 fsimage와 edits 파일을 주기적으로 병합
• 보조네임노드가 장애가 나면 edits 파일이 무한히 증가하게 된다. 

데이터 노드의 역할

• 마스터 서버에 본인이 가지고 있는 데이터를 주기적으로 리포팅
• 물리적으로 HDFS 데이터를 저장
• 레이드(RAID) 구성을 하지 않는다. 
  -> os가 설치되고 하둡 플랫폼이 설치되는 영역의 디스크는 빠르고 작은 디스크를 사용하고 RAID0로 구성한다. 그러나 실제 데이터를 저장하는 데이터 디스크는 구성하지 않는다.
  -> 이를 구성하게 되면 실질적으로 데이터를 저장할 수 있는 물리적인 용량 디스크가 줄기 때문이다. 

RAID란?(참고)

레이드란 Redundant Array of Independent Disk의 약자로, 2개 이상의 디스크를 병렬로 처리하여 성능 및 안정성을 향상시키는 방식입니다. 과거에는 주로 용량이 작은 디스크들을 연결하여 디스크 용량을 높이기 위해 사용

요즘에는 디스크 성능 향상에서 나아가 디스크 오류나 데이터 손실 등 장애에 대비하기 위한 용도로 사용
한 번 손실되거나 삭제된 데이터를 복구하기에 시간과 노력이 많이 소요되는 만큼, 데이트 손실을 방지하기 위한 일종의 대비책

한 개의 디스크에 데이터를 저장하는 방식이 아닌, 데이터 저장의 성능 및 안정성 확보를 위해 복수의 디스크를 구성하는 방식을 레이드(RAID)