Hadoop Ecosystem 컴포넌트들의 서버 구성

라이크나우 2023. 6. 22. 13:09

이번 글에서는 Hadoop Ecosystem을 구성할때 각 컴포넌트의 서버 종류가 무엇인지, 보통 어떻게 구성하는지(HA 등등)에 대해서 공부해보고자한다.

물론, 데이터의 양, 쿼리 복잡성등의 요구사항에 따라 구성은 다르게 설정되어야 하지만 우선은 일반적인 내용을 기준으로 서버 구성 방법을 정리하는 게 이번 목표이다.

이번에는 Hadoop Ecosystem 의 가장 기본이 되는 컴포넌트인 HDFS, YARN, Hive, Impala, Zookeeper를 먼저 다룰예정이다.

먼저 혼란을 방지하기 위해 MasterNode/WorkerNode와 NameNode/DataNode의 차이부터 짚고 넘어가야겠다.

MasterNode/WorkerNode : 관리자 역할을 하는 서비스를 설치해놓은 서버를 주로 MasterNode라고 하며 실제 job을 수행하는 서비스를 설치한 서버는 보통 WorkerNode라고 한다. 서버 자체의 alias라고 생각하면 좋다. 이 외에 Utility, gateway 서버도 지정한다.

NameNode/DataNod : HDFS 상에서의 서버 구별이다. 아래에서 자세히 설명한다.

HDFS

NameNode : HDFS의 메타데이터를 저장하고 관리한다. 기본적으로 하나의 Active NameNode와 하나의 Standby NameNode를 사용하는 High Availability(HA) 모드를 지원한다. Active NameNode가 다운되면 Standby NameNode가 Active 상태로 전환되어 서비스를 계속 제공할 수 있다. NameNode는 보통 고성능 서버에 설치되며, 충분한 메모리를 갖추어야 한다. 일반적으론 MasterNode에 설치한다.

DataNode : 실제 데이터 블록을 저장한다. 클라이언트는 NameNode에게 데이터 블록의 위치 정보를 받아 DataNode에 직접 접근한다. 일반적으로 여러 개의 서버에 구성하며 각각의 서버는 여러 하드디스크에 대용량 데이터를 저장하고 기본적으로 3벌복제를 해두어서 데이터 유실을 막는다. 일반적으론 WorkerNode에 설치한다.

+) 만일 NameNode의 IP(or domain) 을 사용하는 경우가 있다면 현재 Active인 상태의 NameNode의 ip를 하드코딩한다면 서버가 스위치될때 당연히 에러를 내뿜을 것이다. 이 문제를 해결하기 위해 Zookeeper가 NameNode의 상태를 추적한다. 결론적으로 사용자는 Zookeeper의 서비스주소를 통해 설정해야 중단없이 NameNode를 사용할 수 있다.

YARN

ResourceManager : 클러스터 전체의 리소스를 관리하고 Application의 요청에 따라 리소스를 할당한다. HA 모드를 지원해서 Active RM 과 Standby RM 으로 구성될 수 있다. ResourceManager는 리소스 사용이 적기 때문에 NameNode와 동일한 서버에 설치되곤 한다.

NodeManager : 리소스 사용을 모니터링하고 Applicatoin 실행을관리한다. 지난 YARN글에서 언급했듯이 NodeManager는 HDFS의 DataNode와 동일한 서버에서 구성하는 것이 일반적이며 좋다. YARN이 작업을 수행할 때에 Disk I/O를 줄일 수 있기 때문이다.

Hive

Hive는 Hadoop 위에서 동작하는 컴포넌트로 데이터에 SQL과 같은 질의를 제공한다. HiveServer2, Hive Metastore로 구성된다.

HiveServer2 : 클라이언트와 Hive 간의 인터페이스이다. JDBC, ODBC 및 Thrift를 통해 클라이언트의 연결을 수락하고, SQL 질의를 실행하며, 결과를 클라이언트에 반환한다. 또한 병렬로 여러 클라이언트 세션을 처리할 수 있다. GatewayNode에 설치하는걸 권장한다.

HiveMetastore : Hive Metastore는 Hive의 메타데이터를 저장하는 서비스이다. 메타데이터에는 테이블, 컬럼, 파티션 등에 대한 정보가 포함된다. Metastore는 메타데이터에 대한 질의를 처리하며, HiveServer2가 클라이언트의 SQL 질의를 처리하는 데 필요한 메타데이터를 제공한다. Metastore는 일반적으로 관계형 데이터베이스에 저장되며 Derby(Hive 설치와 함께 제공되는 내장형 DB), MySQL, PostgreSQL 등 다양한 데이터베이스를 지원한다. HiveServer2와 HiveMetastore는 서로 다른 서버에 설치되는게 좋다. 각자 CPU, 메모리 사용, 디스크 네트워크I/O가 많은 작업을 수행하기 때문이다. 자원이 풍부하다면 UtiltyNode에 추가하는걸 권장한다.

Hadoop 클러스터 : Hadoop 클러스터는 Hive의 데이터를 저장하고 처리한다. Hive는 HDFS에 테이블 데이터를 저장하며, YARN/MapReduce를 통해 SQL 질의를 병렬 처리한다. Hive는 데이터를 읽고 쓰기 위해 HDFS를 직접 사용하며, SQL 질의를 MapReduce 작업으로 변환하여 실행한다. DataNode에 대한 연결은 HiveServer2가 담당하고 있다.

Impala

Impala는 실시간 대화형 쿼리를 할 수 있게 하는 컴포넌트이며 Impala Daemon(impalad), Statestore, Catalog Service로 구성된다.

Impala Daemon(impalad) : 일반적으로 각 worker node에서 실제 쿼리를 실행하며 YARN과 마찬가지로 각 DataNode에 데몬이 하나씩 뜬다.

Statestore (satestored) : 클러스터의 상태 정보를 추적하고 관리하는 역할을 한다. Daemon들의 가용성을 모니터링하고 이 정보를 다른 Daemon에 전파한다. 일반적으로 UtilityServer에 설치하는걸 권장한다.

Catalog Service (catalogd) : 테이블과 메타데이터를 관리한다. 메타데이터 자체는 Hive Metastore에 저장되지만 Impala는 이 정보들을 캐시로 가지고 있고 catalogd가 해당 역할을 한다. 일반적으로 Statestore와 같은 서버에 설치한다.

Zookeeper

Zookeeper는 분산 코디네이션 서비스로, 주로 하둡 클러스터의 상태 정보를 저장하고 관리한다. Zookeeper 서버는 보통 홀수 개의 노드 (예: 3, 5, 7)에서 구성되어 높은 가용성을 제공한다. 홀수로 구성하는건 과반수 서버의 동의를 얻기 위함인데, 합의(consensus) 과정에서 모든 서버가 동일한 서비스 상태를 공유할 때 사용된다. 자세한 예시를 들어보자면

클라이언트가 ZooKeeper에 데이터를 쓰는 과정을 단계 별로 살펴보자.

1. 클라이언트는 데이터를 쓰는 요청을 ZooKeeper 앙상블에 전송한다.
2. 이 요청은 앙상블의 리더(Leader)에게 먼저 도달하게 된다. 리더는 이 요청을 자신의 로그에 기록하고, 다른 팔로워(Follower) 서버에게 이 요청을 전파한다.
3. 팔로워 서버들은 이 요청을 받아 자신의 로그에 기록하고, 리더에게 이를 확인하는 메시지를 전송한다.
4. 리더는 과반수의 팔로워로부터 확인 메시지를 받으면, 이 요청을 적용하라는 메시지를 팔로워들에게 전송한다. 이 메시지를 받은 팔로워들은 요청을 자신의 상태에 적용한다.
5. 모든 서버가 요청을 적용한 후, 리더는 클라이언트에게 요청이 성공적으로 처리되었다는 메시지를 전송한다.

이런 과정을 통해 ZooKeeper는 모든 서버가 동일한 순서로 요청을 적용하도록 보장하며, 이를 통해 서비스의 일관성을 유지한다!
예를 들어, 여러 클라이언트가 동시에 같은 데이터를 변경하려고 할 경우, ZooKeeper는 합의 알고리즘을 통해 이들 요청을 일정한 순서로 처리하고 결과적으로 모든 클라이언트가 동일한 결과를 보게 되어 분산 시스템의 일관성을 유지할 수 있게 된다. 또, Leader-Follower 구성은 리더가 다운되더라도 다른 팔로워를 리더로 선출하여 Zookeeper가 멈추지 않게 해준다.

홀수인 이유를 설명하다보니 Zookeeper의 글이 길어졌지만 보통 앙상블은 MasterNode에 설치된다. 만일 MasterNode가 짝수개라면 UtilityServer에까지 설치하는 케이스를 본 적이있다. (일반적인지는 모르겠지만..)

이렇게 주요 서비스의 서버 별 역할 및 구성 방법을 살펴보았다. 다음번엔 다른 서비스(Kafka, Sqoop 등)에 대해서도 알아볼 예정이다.

참고자료

https://docs.cloudera.com/documentation/enterprise/latest/topics/cm_ig_host_allocations.html