분산 시스템의 요구 사항
- 증가하는 데이터 크기를 처리하는 방법은 무엇일까?
- 방대한 양의 데이터 처리는 CPU와 RAM 등 컴퓨팅 리소스 능력에 크게 의존하는데, 더 많은 처리 능력이 필요할 때 마다 자원들을 업그레이드 할 수 있는 수직적 확장성 문제는 어떻게 다룰 것인가?
- 수직적 확장성 문제를 해결하기 위해 여러 머신을 사용할 수 있는 분산 시스템을 사용할 수 있지만, 일반적인 분산 처리 시스템에서 '머신 간 데이터 동기화', '하나의 구성 오류로 인한 전체 시스템의 오류', '스토리지 노드에서 연산 노드로 데이터 전송을 위한 더 많은 대역폭 필요' 등의 한계는 어떻게 극복할 것인가?
모든 복잡성을 처리하고 앞에서 설명한 요구 사항을 해결하려면 분산 컴퓨팅을 위한 새로운 아키텍처가 필요하다.
분산 컴퓨팅을 위한 새로운 모델
수평적 확장성
오류 없이 시스템을 확장하기 위해 새로운 노드를 동적으로 추가할 수 있어야 하고, 더 많은 노드를 추가한다는 것은 수평적 확장성을 의미한다.
전체 시스템 오류 대신 부분 오류
아키텍처는 클러스터에서 하나 이상의 노드 장애를 처리할 수 있어야 하고, 이는 전체 시스템의 기능을 감소시키지만 전체 시스템의 오류를 초래하지 말아야 한다는 것을 의미한다.
데이터 복구
시스템의 노드 장애로 인해 데이터가 손실되어서는 안된다. 즉, 아키텍처는 부분적인 시스템 오류가 발생한 경우 데이터를 복제하고 복구할 수 있어야 한다. 동시에 연산이 진행되는 동안 오류가 발생하는 경우 런타임에서 죽은 노드의 연산을 살아있는 노드로 전환할 수 있어야 한다.
노드 복구
노드가 실패하고 일정 시간이 지나면 복구되는 경우, 전체 시스템을 다시 시작하지 않고도 복구된 구성 요소를 추가할 수 있어야 한다.
일관성
작업의 출력은 정상적인 실행과 부분적인 시스템 오류의 경우에도 일관되어야 한다.
위와 같은 배경으로 귀여운 노랑 코끼리, 하둡이 등장하게 되었다.
Hadoop?
- 하둡은 2006년 야후의 더그 커팅이 '넛치'라는 검색엔진을 개발하는 과정에서 대용량의 비정형 데이터를 기존의 RDB 기술로는 처리가 힘들다는 것을 깨닫고, 새로운 기술을 찾는 중 구글에서 발표한 GFS와 MapReduce 관련 논문을 참고하여 개발하였다.
- 이후 아파치 재단의 오픈 소스로 공개 되었으며, 하둡은 하나의 성능 좋은 컴퓨터를 이용하여 데이터를 처리하는 대신, 적당한 성능의 범용 컴퓨터 여러 대를 클러스터화하고, 큰 크기의 데이터를 클러스터에서 병렬로 동시에 처리하여 처리 속도를 높이는 것을 목적으로 하는 분산처리를 위한 오픈소스 프레임워크라고 할 수 있다.
현재 대부분의 Hadoop은 Hadoop 3.x Architecture 사용하고 있기 때문에 Hadoop 1.x Architecture와 Hadoop 2.x Architecture는 역사가 되었다. 하지만 Hadoop에 대한 이해를 높이기 위해 어떻게 발전했는지에 대해서 알아보자
Hadoop 1.x Architecture
Core Components
Hadoop은 아래와 같이 크게 2가지 핵심 구성 요소가 존재한다.
- HDFS : Hadoop 분산 파일 시스템
- MapReduce : 분산 컴퓨팅
HDFS (Hadoop Distributed File System)
NameNode
- Master Node에 존재
- 클러스터 전체에 분산된 파일에 대한 메타데이터 관리를 담당
- 클러스터 전체의 파일 블록 위치 및 권한과 같은 정보를 관리
- FsImage(파일 시스템 이미지)는 메타데이터(네임스페이스를 포함한 데이터의 모든 정보)를 읽고 메모리에 보관
- EditLog는 DataNode에서 발생한 변경 사항 기록
Secondary NameNode
- 클러스터의 크기에 따라 Master Node 또는 별도의 노드에서 실행할 수 있음
- NameNode의 Standby 역할이 아닌, FsImage와 EditLog를 주기적으로 병합하는 Check Point 역할을 수행
DataNode
- Worker Node(or Slave Node)에 존재
- Hadoop 클러스터의 Worker Node에 개별 파일 블록을 저장하는 역할을 수행
- Replication Factor를 기반으로 하나의 블록을 여러 Worker Node에 복제하여 데이터 손실 방지
- 필요할 때 마다 NameNode와 통신하여 데이터 블록에 대한 액세스(쓰기/읽기) 처리
- Worker Node가 실행 중임을 NameNode가 인식하도록 주기적으로 NameNode에 하트 비트를 전송
MapReduce
JobTracker
- NameNode와 동일한 Master Node에서 실행
- 모든 MapReduce 작업은 먼저 JobTracker에 제출되고, JobTracker는 MapReduce 처리에 사용되는 다양한 파일 블록의 위치를 확인
- TaskTracker와 통신하여 파일 블록이 존재하는 여러 DataNode에 작업을 분배
TaskTracker
- 일반적으로 DataNode가 실행되는 WorkerNode에서 실행
- JobTracker로부터 작업 정보를 수신하고 해당 WorkerNode에서 작업 시작
- 대부분의 경우, TaskTracker는 물리적 데이터 블록이 있는 동일한 노드에서 작업 시작
- DataNode와 동일하기 JobTracker에게 하트 비트를 주기적으로 전송하여, JobTracker에게 WorkerNode가 실행 중임을 인식하도록 함
Hadoop 1.x Architecture 문제점
- 백업 NameNode가 없기 때문에, 단일 장애 지점 존재하므로 해당 프로세스 또는 시스템이 다운되면 전체 클러스터가 다운
- JobTracker가 Hadoop 클러스터 전체 리소스 관리, 작업 스케줄링 및 모니터링을 수행하기 때문에 부하 발생
- Hadoop 클러스터를 최대 4000개 노드까지 확장할 수 있지만, 그 이상의 확장성은 성능 저하 및 작업 실패율 증가 발생
Hadoop 2.x Architecture
Hadoop 2.x Architecture에 대한 내용은 Hadoop 1.x Architecture의 문제점을 어떻게 보완했는지를 아래 내용과 함께 다음 포스팅에서 살펴보자.
- HDFS 고가용성(High Availability)와 HDFS Federation
- YARN Architecture
Reference
