[Hadoop/기록] 5. Hadoop Architectures 훑기

[HDFS v1.x ~ v3.x Architecture]

HDFS ver 1.0

HDFS ver1.0 이던 시절, 당시의 HDFS의 구조는 위와 같다. Dataflow를 간단히 설명하자면 다음과 같다.

1. 요청이 HDFS Client로 들어온다 -> 2. HDFS Client는 namenode에서 파일에 대한 메타데이터를 불러온다. 이때 메타데이터는 namespace, filename을 의미한다. -> 3. HDFS는 이 정보를 바탕으로 데이터 노드에서 읽어내고자 하는 데이터를 읽어낸다. -> 4. 만약 namenode가 수정되면 secondary node의 edit file을 수정한다.

모든 시스템은, 발생한 문제를 해결하고 고도화 하는 과정에서 발전하기 마련이다. HDFS 1.0버전에서 발생한 주된 문제중 하나는 Single-Point of Faliure 였다. 이는 namenode server에 만약 문제가 발생하면, HDFS 시스템 전체에 문제가 생기는 것을 뜻한다. 그래서 Hadoop 은 이를 보완하고자, 뒤따르는 Hadoop2.x에 두가지 기능을 추가하였다.

1. HDFS High-Availability
2. HDFS Federation

먼저 HDFS High-Availability, 즉 고가용성을 어떤식으로 보완했는지 보자. 아래 그림은 HDFS HA Architecture를 나타내고 있다. 제일 먼저 눈에 띄는 것은 NameNode를 Active/Standby 두개로 나눠서 메타데이터를 관리한다는 점이다. 이렇게 하면 Active 상태의 NameNode 서버에 문제가 생기더라고 곧바로 Standby 서버로 교체가 가능하다. 그림에는 나와있지 않지만, 이 두개의 NameNode들은 항상 Synchronized 되어 있어서 어느 한쪽이 변화가 생기면 다른쪽도 이를 감지해서 반영하게 된다.

더불어 DataNode들은 Rack으로 묶여져 있는데, 이 Rack들의 replication을 관리함으로서 데이터의 고가용성 또한 보완하고 있다.

다음은 HDFS Federation이다. Federation은 NameNode의 연합을 의미하는 것으로, HA에 비해 조금 생소한 개념이였다. 결론적으로는, 수평적으로 여러개의 NameNode를 사용한다는 것. 이유는 다음과 같다.
하나의 네임노드에서 관리하는 파일, 블록 개수가 많아지면 물리적 한계가 있다. 만약 네임노드의 디스크가 512Gb인데 클러스터의 파일 및 블록의 메타정보가 700Gb라면 문제가 발생한다. 이를 해결하기 위해 HDFS Federation을 하둡 2.0 이상에서 지원, 복수의 네임노드를 갖게한다. 이를 이용하면 File, dir 정보를 가지는 namespace와 블록의 정보를 보관하는 block pool을 각 NameNode가 독립적으로 관리하게 된다. 따라서 하나의 NameNode에 문제가 생겨도 다른 NameNode에 영향을 주지 않는다.

 

여기까지가 Hadoop 1.x ~ Hadoop 2.x였다. 현재 내 vmware에 설치되어 있는 Hadoop은 3.2.2 version이다. 그렇다면 Hadoop 2.x에서 Hadoop 3.x로 넘어오면서 생긴 변화점 들을 살펴보자.

[Hadoop 2.x vs Hadoop 3.x]

• 사용하는 java version
  Hadoop 3.x로 넘어오면서 사용하는 java -version이 변경되었다. 2.x에서는 java7, 3.x에서는 java8이 베이스 언어이다.
• Fault Tolerance
  Fault Tolerance, 즉 장애 허용은 시스템 측면에서 어떤 결함이 발생한다고 하더라도 이를 허용하는 개념이다. 2.x version에서는 Replication을 이용했다. 3.x부터는 Erasure-Coding기법을 사용한다. 이는 데이터를 잘개 쪼개서 Grid 내에 서로다 른 디스크 사이로 균형을 맞추어 흩어지는 방식으로 중복 허용 기술을 빅데이터 적으로 발전시키게 된다.
• Data-Balancing
  Hadoop 2.x의 경우 HDFS Balancer를 사용했다고 하면, Hadoop 3.x의 경우에는 Intra-data node balancer를 사용하게 된다. 
• Strorage-Scheme
  3x Replication Scheme -> user eraser encoding
• Storage-Overhead
  기존의 replication 방식은 200%의 오버헤드를 각오해야 하지만, 3.x에서는 50%의 오버헤드만 각오하면 된다.
• Yarn-timeline-service
  2.x에서의 timeline-service -> 3.x에서는 timeline-service2
• Scalability
  10000개 이상으로 발전
• Default Port Range
  임시포트 범위를 리눅스 임시포트 범위에서 충돌문제로 인해 이동
• Compatible File System
  지원하는 파일 시스템이, 2.x대 에서는 HDFS, FTP, Amazon S3, Azure만 지원했던 것에 비해, 모든 파일 시스템으로 확장되었다.
• NameNode Recovery
  NameNode의 장애복구가 자동으로 이루어짐 -> Automatic - Failover

 

[Master-Slave Architecture]

다시 아키텍쳐의 구조를 가져왔다. 하둡은 결국 데이터들을 multiple-rack형태로 가져간다. 그리고 이 데이터들을 실질적으로 가지고 있는 Slave-Node와, 이들의 메타데이터를 가지고 있는 Master-Node로 나위어진다. 곧, DataNode(Slave-Node), NameNode(Master-Node) 라 할 수 있다.

• Master Node 는 file-system 내에 namespace를 관리하는 역할을 한다. 곧, NameNode는 고가용성의 Master Node이다.
• Slave Node는 Master Node, 즉 NameNode 로 부터 작업을 부여받아 주어진 작업을 수행하게 된다. 

HDFS ver 1.0

 

[Replication management]

    아래 이미지는 HDFS의 Block Replication을 보여준다. 하나의 파일을 Block 1~5라고 쪼개었다고 생각해보자. 그러면 이를 여러개의 노드들에 분산해서 저장해야 한다. 최소 3개의 replication을 만들었다 치면, 4개의 노드에는 다음과 같이 나누어 저장할 수 있다. 이제 이 상황에서 하나의 노드가 깨지거나 다운되었다고 생각해 보면, 남은 3개의 노드중 어떤 2개의 노드를 합치더라도 원래 상태의 노드를 복구해 낼 수 있다.

 

[Rack Awareness]

Rack이란 ? -> Physical collections of nodes in hadoop Cluster(하둡 클러스터 내의 물리적 노드 집합)

하둡의 클러스터는 여러개의 Rack들로 이루어져 있다. 아래 그림에서 볼 수 있듯이 하나의 Rack에는 여러 데이터노드가 포함되어 있다.

그러면 하둡 입장에서 어떻게 노드의 위치를 알 수 있을까? 
여기에 대한 대답이 바로 Rack Awareness이다. 이 Rack Awareness 설정을 통해 노드의 위치를 파악하는 것이다. 

정확히는 Rack Awareness policies(렉 인지 정책)에 따라 움직인다. 그 과정은 다음과 같다.

1. 먼저 저장하고자 하는 파일을 적당히 여러 블럭으로 나눈다. -> 2. 나눠진 블럭들은 3개의 replica(default가 3개이다)로 복제되어 각각의 Rack으로 나눠진다. -> 3. 여기서 주의할 점은, 하나의 데이터노드에는 최대 하나의 replica만 들어갈 수 있다는 점이다. (이것이 policy중 1번, There should not be more than 1 replica ) -> 4. 더불어 하나의 Rack에는 최대 하나의 replica 만 들어갈 수 있다. (이것이 2번, More than 2 replica's of a single block is not allowed on the same Rack) -> 5. 마지막으로, 하둡 클러스터 내에서 사용중인 Rack의 수는 replica의 수보다 작아야 한다. (3번, The number of racks used inside a Hadoop Cluster must be smaller than the number of replicas)