서론
안녕하세요. 본 게시물에서는 빅데이터 플랫폼인 Hadoop을 공부하면서, HDFS Federation이 어떤 역할을 위해 탄생했고 활용되는지를 알아보고자 글을 작성합니다. 최근 회사에 입사한 후 어떤 개념을 먼저 공부해볼 까 고민하던 중, 동료분께서 HDFS Federation의 개념에 대해서 말씀해주셨고, 이를 한 번 공부하며 기록해보고자 합니다.
이번 게시물은 HDFS Federation 배경 및 환경 구축에 필요한 개념들을 먼저 알아가 볼 것이며, 다음 게시물에서는 실제 Local Docker 환경에서 HA / Federation이 적용된 Multi Node Cluster를 구축하는 실습 관련하여 게시물을 작성해볼 예정입니다.
한 번 시작해볼까요?
HDFS Federation
정의
우선, HDFS는 NameNode와 DataNode로 분리되어 있습니다. 이 두 핵심 구성 요소가 어떤 역할을 수행하는 지 먼저 알아보겠습니다.
NameNode는 HDFS에서의 "두뇌 / 관리자" 역할을 수행하는 중요한 구성 요소이며, 파일 시스템의 NameSpace 및 실제 파일이 어느 위치에 존재하는 지에 대한 Metadata를 저장하는 역할을 수행합니다. 실제로 사용자 / 클라이언트가 작업 요청했을 때 NameNode가 전달받아 내부에 저장된 Metadata 정보를 통해 원하는 정보가 어느 위치에 있는 지를 찾아내고, 이를 DataNode에 접근하여 제공하는 역할을 수행합니다.
만약, 단일 Cluster에서 NameNode에 장애가 발생할 경우 실제 파일이 위치한 Metadata에 대한 정보를 받아올 수 없습니다. 이 때, 클라이언트 요청을 처리할 수 없으며, 이는 곧 치명적인 문제로 연결될 수 있는 것이죠. 그렇기 때문에, 저는 NameNode를 "두뇌"라고 표현해봤습니다.
DataNode는 HDFS에서의 "일꾼" 역할을 수행하는 요소이며, 실제 데이터를 작은 크기의 블록 단위로 저장하고 사용자의 요청에 따라 데이터를 읽기/쓰기 하는 작업을 수행합니다. DataNode를 많이 생성할수록 더 많은 데이터를 저장할 수 있으며. 실제 데이터를 저장하고 작업을 수행하는 역할을 담당하기 때문에 저는 DataNode를 "일꾼"으로 표현해봤습니다.
"두뇌"의 크기가 일정한데, "일꾼"이 마구마구 늘어나면, 당연히... 두뇌가 아파하겠죠?
(마치 제가 코딩할 때 저의 두뇌와 동일한 것 같네요 ㅎㅎ)
이 정도의 개념을 숙지한 상태에서, HDFS Federation에 대해서 한 번 알아가보겠습니다.
HDFS Federation이란 하나의 Hadoop Cluster 내에서 여러 개의 독립적인 NameSpace를 지원하는 기능입니다. 각 NameSpace는 자체적인 NameNode에 의해 관리가 되며, 이를 통해 단일 HDFS Cluster에서 여러 파일시스템을 운영할 수 있게 됩니다. NameSpace는 자체적인 NameNode에 의해 관리가 되며, 이를 통해 단일 HDFS Cluster에서 여러 파일시스템을 운영할 수 있게 됩니다.
HDFS의 초기 버전 (1.xx)에서는 단일 NameNode가 전체 Cluster의 Metadata(어떤 DataNode에 데이터가 들어있는 지에 대한 정보)를 관리했습니다. 이로 인해, FaceBook과 같은 대규모 Cluster를 운영하는 서비스에서 메모리 관리 및 성능 병목 현상을 경험하게 됬죠. 이러한 문제를 해결하기 위해서 Hadoop Cluster에 도입한 것이 바로 HDFS Federation입니다.
장점
우선, 하나의 NameNode가 파일 시스템 내 모든 NameSpace를 관리하는 것이 아닌, 각 NameNode가 각 NameSpace를 독립적으로 관리합니다. 즉, 여러 NameNode로 부하를 분산시킬 수 있기에 더 많은 파일과 더 큰 Cluster를 안정적으로 운영할 수 있습니다.
또한, 독립적으로 NameSpace를 관리하기 때문에, 수평적으로 확장이 가능하다는 큰 장점이 있습니다. 이러한 개념을 잘 생각해보면, 뭔가 Hadoop의 큰 특징 중 하나인 "Commodity Hardware"와 연관이 있다는 생각이 듭니다. 시스템 확장을 진행하고 싶을 때, 적절한 크기의 Hardware를 추가할 수 있다는 것과 연결될 수 있는 것이죠.
좀 더 확실하게 이해를 돕고자, 간단한 예시를 들어보겠습니다.
한 스타트업에서 "운영팀 / 개발팀 / 홍보팀" 총 3개의 팀이 생성하는 데이터를 관리해야 한다고 생각해봅시다. 하나의 NameNode로 관리하는 것 또한, 규모가 크지 않은 스타트업의 입장에서는 적절한 Hadoop Cluster 구조가 될 수 있습니다. 그러나, 만약에 회사가 많이 커져 NameNode의 부하가 커지는 상황이 온다면, 각 팀에서 발생하는 데이터를 따로 관리하는 것이 보다 적절할 수 있겠죠. 즉, 하나의 NameNode가 각 팀이 생성하고 관리하는 실제 데이터에 대한 Metadata를 각각 관리하도록 Hadoop Cluster 구조를 변경시킴으로서 NameNode의 부하를 줄일 수 있습니다.
추가로, "디자인팀"을 위한 시스템이 추가되어야 한다면, 하나의 NameNode일 때는 부하가 점점 더 커지게 됩니다. 그렇지만, HDFS Federation을 활용하게 된다면, 수평적으로 확장이 유연하게 가능하기 때문에 Hadoop Cluster 운영을 보다 손쉽게 할 수 있습니다.
이러한 특징으로 인해 HDFS Federation은 대규모 Hadoop Cluster에서 엄청 중요한 역할을 하며, 시스템의 전반적인 성능과 관리 효율성을 크게 향상시키는 장점이 있습니다.
High Availability
High Availability는 HDFS의 치명적인 단점 중 하나인 SPOF(Single Point Of Failure)를 예방하고 해결하고자 도입되었습니다. SPOF라는 의미는 시스템 중 한 부분의 실패로 인해 시스템 장애가 발생한다는 것을 의미합니다. 즉, NameNode가 SPOF가 되며, 위에서도 설명했던 것과 동일하게 NameNode 장애는 큰 문제를 일으킬 수 있습니다. 안정적인 대규모 Hadoop Cluster를 도입하기 위해서는 HA가 결국에는 필수적으로 요구됩니다.
High Availability를 적용하기 위해서는 NameNode를 최소 2개 이상 운영해야하며, 활성화(Active) / 보조(Standby) 구조를 통해 HA를 구현합니다. 평소에는 실제 Active Node가 사용자 / 클라이언트 요청을 처리하는 역할을 수행하다가, Active Node에서 장애가 발생했을 때 StandBy Node가 Active 역할을 대신합니다.
Active와 Standby Node 간의 동기화는 High Availability의 핵심 기능 역할이 됩니다.
동기화 과정을 설명해보면...
- 편집 로그 공유: Active Node는 모든 NameSpace에서의 수정 사항을 편집 로그에 기록합니다. 이 로그는 이후 설명 할 QJM이나 공유 Storage 시스템에 저장하여 관리합니다.
- 실시간 동기화: StandBy Node는 지속적으로 공유된 편집 로그를 모니터링하고 변경 사항을 자신의 NameSpace에 적용합니다. 이를 통해 거의 실시간으로 동기화 상태를 지속할 수 있게 됩니다.
- 블록 위치 정보 갱신: DataNode들은 Active / StandBy Node 모두에게 블록 위치 정보와 하트비트(정상적으로 운영되고 있다는 신호)를 전송합니다. 이를 통해, StandBy Node 또한 최신 블록 위치 정보를 유지할 수 있게 됩니다. (위 사진에서 Block Pool을 의미합니다.)
- 체크포인트: 주기적으로 StandBy Node는 체크포인트를 생성해서 Metadata의 스냅샷을 기록합니다. 이를 통해 실제 서비스 장애가 발생했을 때, 해당 체크포인트를 활용하여 빠르게 복구할 수 있습니다.
Active Node가 StandBy Node로 대체되는 과정은 아래와 같습니다.
- Hadoop Cluster 내 Jookeeper가 Active Node의 장애를 감지합니다.
- 장애가 감지되면, StandBy Node에게 "Active가 장애 상태니까, 너가 Active 대체 해"라는 신호를 보냅니다.
- StandBy Node는 Active로의 전환을 진행하기 전, QJM에서 미처리 된 편집 로그를 읽고 적용함으로써 최신 정보를 유지합니다.
- 펜싱 매커니즘을 실행함으로써, 기존의 Active Node가 더 이상 Active 역할을 수행하지 못하도록 합니다.
- StandBy Node가 Active 상태로 전환하며, 이후로부터 클라이언트 요청 처리는 StandBy Node가 대신 수행합니다
** 펜싱 메커니즘이란 확실하게 Active Node를 죽이는 (Down 시키는) 과정이라 생각하면 됨.
이러한 High Availability 덕분에, 대규모 Hadoop Cluster에서 Active Node에 장애가 발생하더라도 무중단 서비스를 제공할 수 있습니다.
QJM (Quorum Journal Manager)
QJM은 HDFS에서 High Availability 구현을 위해 선호되는 방법이며, Active와 StandBy Node 간 편집 로그를 공유하는 역할을 수행합니다. Cluster를 구축할 때 JournalNode에서 작동하며, Active에서 편집한 로그를 기록하고, 이를 StandBy가 읽어 동기화를 유지할 수 있도록 도와줍니다.
일반적으로 3개 이상의 JournalNode로 구성된다고 하는데, 이 부분에 대해서는 정확하게 왜 그러는지는 잘 모르겟습니다. 추후에 한 번 찾아보는 시간을 가져보겠습니다..!!
Jookeeper
Jookeeper는 보편적으로 여러 서버 간 동기화, 구성 관리 등을 수행하기 위해 개발되었으며, HDFS에서는 HA구성을 위해 아래와 같은 핵심 역할을 수행합니다.
- Active Node를 선출하는 작업을 수행함으로써, Hadoop Cluster에서 단 하나의 Active Node만 존재하도록 보장하는 역할을 수행합니다. 또한, 클라이언트에게 현재 Active Node의 정보를 제공하며, 항상 Active Node에 연결할 수 있도록 합니다.
- Active Node 장애 시, StandBy Node로의 자동 전환을 진행합니다.
- 분산 락 메커니즘을 통해 두 NameNode가 동시에 Active 상태가 되는 것을 방지합니다.
이러한 Jookeeper의 도입을 통해 HDFS의 High Availability를 크게 향상시킬 수 있으며, SPOF 문제를 해결하는 데 핵심 역할을 수행합니다.
마무리하며
여기까지 HDFS Federation 및 HA가 적용된 Cluster 구축에 필요한 개념들에 대해 알아봤습니다. 해당 포스팅을 읽으면서 "왜 HDFS Federation을 쓸까?", "왜 HA를 적용해야 할까?" 등에 대한 궁금증이 해소되었길 바랍니다. 다음 게시물은 Docker 환경에서 어떻게 구축해나아가는지 한 번 알아가보는 시간을 가져보겠습니다.
긴 글 읽어주셔서 감사합니다. :)
(쓰다보니 글이 많이 길어졌네요..!!)
References
[1]. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/Federation.html