Home (Hadoop) Abstract of Zookeeper and ZKFC
Post
Cancel

(Hadoop) Abstract of Zookeeper and ZKFC

By woobni
Posted Feb 24, 2023 Updated Jun 30, 2023 13 min read

0. 개요

1) Raft Consensus Algorithm

Untitled

  • 분산 시스템에서 전체 노드의 최신화 및 동기화, 그리고 장애를 복구할 수 있는 능력인 내결함성(False Tolerance)을 동시에 구현하기 위해 만들어진 합의 알고리즘
  • 리더 선출 프로세스, 로그 엔트리 복제 등의 메커니즘을 사용
  • 합의 알고리즘을 채택한 분산 시스템에서는 전체 노드 수를 가급적 3개 이상의 홀수로 유지하는 것이 권장
    1. 전체 노드 수가 3개 이상이어야 허용 가능한 장애 노드가 생긴다. 그 미만으로는 내결함성을 갖출 수 없음
    2. 전체 노드 수가 홀수일 때 허용 가능한 장애 노드 수의 비율이 좀 더 높다.
      • 분할 투표(split votes)로 인한 리더 선출(Leader Election)의 불필요한 반복과 명령 처리 지연 가능성을 줄이기 위해서라도 홀수 개의 노드 운영이 더욱 권장

2) Hadoop HA Architecture

Untitled

  • Active Name Node와 Standby Name Node는 데이터 노드로부터 블록 리포트와 하트비트를 받아서 동일한 메타데이터를 유지하고, Journal Node 를 이용하여 edit log 공유
  • Active Name Node에 문제가 발생하면 Standby Name Node가 Active Name Node로 동작
  • Active Name Node에 문제가 발생하는 것을 자동으로 확인하는 것이 어렵기 때문에 보통 Zookeeper를 이용하여 장애 발생시 자동으로 변경될 수 있도록 함

Zookeeper

  • Zookeeper는 어떤 Name Node가 Active 인지, Standby 인지를 저장함으로써 Name Node들을 관리
  • 클러스터의 각 Name Node는 Zookeeper에서 영구 세션을 유지함. 시스템이 문제가 생기면 Zookeeper 세션이 만료되어 장애 조치가 트리거 되어야 함을 다른 Name Node에 알림

ZKFC (ZooKeeper Failover Controller)

  • zkfc는 Hadoop 클러스터의 Name Node 장애 복구를 관리하는 데몬
  • Zookeepr Client 로써 동작
  • Name Node가 동작하는 서버에 zkfc 도 같이 동작하면서 상태 확인 명령을 통해 Name Node 상태를 모니터링
  • Zookeeper를 기반으로 Name Node를 활성화

Zookeeper와 ZKFC

Untitled

  1. zkfc는 평소(Name Node 가 정상 동작할 때)에 Zookeeper 와 zkfc 간 세션을 유지
  2. zkfc는 Active Name Node의 상태가 비정상이 되면 이를 감지하여 zkfc 와 Zookeeper 간 세션을 종료시킴
  3. Zookeeper는 Active 가 반응이 없으면 (세션이 끊기면) 바로 Standby Name Node 에게 Active 가 장애가 났음을 알림
  4. zkfc는 로컬 Name Node가 정상이고 현재 lock znode를 보유하고 있는 다른 노드가 없음을 확인하면 자체적으로 lock 획득을 시도함
  5. Zookeeper는 여러 Standby Name Node 가 있다면 어떤 것을 Active 로 선출할지 정함
  6. zkfc는 Zookeeper를 기반으로 다음 Name Node를 활성화(다른 노드는 차단. fencing method)

1. Zookeeper 소개

  • 분산 시스템을 설계할 때의 문제점
    • 분산된 시스템간의 정보 공유
    • 클러스터에 있는 서버들의 상태 체크
    • 분산된 서버들간에 동기화를 위한 락(lock) 처리
  • 이러한 문제를 해결하는 시스템을 코디네이션 서비스 시스템 (coordination service) 이라고 하며, Apache Zookeeper가 대표적임

2. Zookeeper 구성

1) Zookeeper 데이터 모델

Untitled

  • Zookeeper는 디렉토리 구조 기반으로 된 key-value 자료구조. 사실상 Zookeeper는 여기에 데이터를 넣고 빼는 기능이 가장 큰 핵심. 나머지는 분산 시스템의 문제를 이로 구현할 것일 뿐임
  • znode는 ZooKeeper 서버에 등록한 노드 또는 경로
    • 크기가 작은 data를 저장할 것이라고 가정하고 구현되어 있기 때문에 각 znode의 크기는 1MB로 제한
  • znode 종류
    • Persistent Node
      • znode에 데이터를 저장하는 순간 영구 저장되는 노드 (단, 강제 삭제시엔 삭제됨)
    • Ephemeral Node
      • znode를 생성한 클라이언트의 세션이 연결되어 있을 때만 유효한 노드 (연결이 끊어질 시 자동 삭제)
      • 이를 통해서 클라이언트가 연결이 되어 있는지 아닌지를 판단하는데 사용할 수 있다. (클러스터를 구성할때 클러스터내에 서버가 들어오면, 이 Ephemeral Node로 등록하면 된다.)
    • Sequence Node
      • znode를 생성할때 자동으로 sequence 번호가 붙는 노드 (분산락 구현에 이용)

  • znode 예) [ Hadoop DataNode Zookeeper zkCli.sh ]

    Untitled

2) Zookeeper Watcher

  • ZooKeeper 클라이언트에서 발생하는 이벤트를 처리하기 위해 사용되는 콜백 인터페이스
  • Watch 기능은 ZooKeeper 클라이언트가 특정 znode에 watch를 걸어놓으면, 해당 znode가 변경이 되었을때, 클라이언트로 callback 호출을 날려서 클라이언트에 해당 znode가 변경이 되었음을 알려준다. 그리고 해당 watcher는 삭제 된다.

3. ZooKeeper 활용 시나리오

ZooKeeper 클라이언트 쉘, 또는 ZooKeeper API로 구현 (보통 ZooKeeper 클라이언트 쉘은 주로 간단한 테스트 및 디버깅 용도로 사용)

1) 큐

  • Watcher와 Sequence node를 이용
  • Queue 라는 Node를 만든 후에, 이 노드의 Child node를 sequence node로 구성하면 새롭게 생성되는 메세지들은 이 sequence node 순차적으로 생성
  • 이 큐를 읽는 클라이언트가 이 큐 node를 watch 하도록 설정하면, 이 클라이언트는 새로운 메세지가 들어올 때 마다 call back을 받아서, 마치 메세지 Queue의 pub/sub 과 같은 형태의 효과를 낼 수 있다.

2) 서버 설정 정보 저장

  • 가장 일반적인 용도로는 클러스터 내의 각 서버들의 설정 정보(Configuration)를 저장하는 저장소로 쓸 수 있다.
  • 정보가 안정적으로 저장이 될 뿐 아니라. Watch 기능을 이용하면, 설정 정보가 저장될 경우, 각 서버로 알려서 바로 반영을 할 수 있다.

3) 클러스터 정보 유지

  • 현재 클러스터에서 기동중인 서버 목록을 유지할 수 있다.
  • Ephemeral Node는 Zookeeper 클라이언트가 살아 있을 경우에만 유효하기 때문에, 클러스터내의 각 서버가 Ephemeral Node를 등록하도록 하면, 해당 서버가 죽으면 Ephemeral Node 가 삭제 되기 때문에 클러스터 내의 살아 있는 Node 리스트만 유지할 수 있다.

4) 글로벌 락

  • Zookeeper를 이용하여 많이 사용되는 시나리오 중의 하나로, 여러개의 서버로 구성된 분산 서버가 공유 자원을 접근하려고 했을 때, 동시에 하나의 작업만이 발생해야 한다고 할 때, 그 작업에 Lock을 걸고 작업을 할 수 있는 기능을 구현할때 사용한다.
  • 자바 멀티 쓰레드 프로그램에서 synchronized를 생각하면 쉽게 이해가 가능할 것

4. ZooKeeper 응용 사례

Zookeeper는 보통 Hadoop Eco System과 같이 사용됨

1) Spark with Zookeeper

  • Zookeeper는 스케줄링 Cluster Manager(Master)의 장애에 대비하여 고가용성 기능을 제공

Untitled

2) Kafka Cluster with ZooKeeper

  • Kafka의 Zookeeper 클라이언트는 Kafka 의 브로커를 관리하고 조정하는 데 사용
  • Kafka도 분산 처리 플랫폼이지만 메시지를 주고 받는 Pub/Sub 외에는 아무것도 하지 않음
    • → 브로커 상태를 저장하지 않기 때문에 상태 관리를 위해 Zookeeper를 사용

  • 클러스터 아키텍처

    Untitled

    • Producer와 Consumer는 kafka의 브로커 정보를 가지고 있음. 만약 동적으로 브로커의 상태가 변경(스케일 아웃되는 등) 되는 경우 Zookeeper가 이를 알려줌
    • 브로커로 메시지 생산 실패 시 Zookeeper가 다른 정상 서버로 Producer와 Consumer에게 브로커를 알림

3) Redis Cluster with Zookeeper

  • ZooKeeper의 기능(디렉터리 구조, Watcher)을 이용하여 Redis Cluster의 Health check, Server failover, Sharding rule 관리를 담당하는 서비스(Redis Cluster Manager)를 설계

  • 클러스터 아키텍처

    Untitled

  • ZooKeeper 디렉터리 구조

    • 아래와 같이 ZooKeeper의 분산 저장소 기능을 사용해 디렉터리 구조를 설계하고, Watch 기능을 이용하여 애플리케이션 서버에서 해당 디렉터리 정보를 이용

      Untitled

4) Apache Storm, HBase, Solr, Flume, Ambari, Nutch, etc.

5. 결론

  1. 제품의 앱 스택이 대부분 컨테이너로 구축되어 있다면 k8s로 장애 대응 가능. Zookeeper를 쓴다면 컨테이너로 구축되지 않은 앱을 HA 구성할 때 사용할 수 있을 것 같음
    • Hive, Spark, etc.
  2. Hadoop을 Docker로 구축하면 Zookeeper-ZKFC를 안쓰고 쿠버네티스를 통해 고가용성을 챙길 수 있을 것 같음
  3. 만약 zkfc가 문제가 발생한다면 네임 노드가 정상이어도 다른 네임 노드로 Active 변경 필요
    1. 네임노드 간의 fencing 설정이 중요(아래는 설정이 제대로 안되어 있는 예시)

    2. [ hdfs-site.xml ]

      Untitled

    3. fencing 설정이 안되어 있으면 둘 다 Active가 되어 충돌 발생할 수 있음(다른 하나의 네임 노드가 완전히 죽었을 경우 만을 고려할 수 있음)
  4. Hadoop Eco 클러스터 내 앱 간에는 소켓 통신이(SSH) 필수

Reference

  1. https://seongjin.me/raft-consensus-algorithm/
  2. https://sencia.tistory.com/38
  3. https://bcho.tistory.com/1016
  4. https://zookeeper.apache.org/doc/r3.4.6/recipes.html#ch_recipes
  5. https://d2.naver.com/helloworld/294797
  6. https://docs.cloudera.com/HDPDocuments/HDP3/HDP-3.0.0/fault-tolerance/content/configure_and_deploy_automatic_failover.html
  7. https://github.com/apache/zookeeper
  8. https://spark.apache.org/docs/latest/spark-standalone.html#high-availability
Hadoop
Hadoop
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents

© 2024 woobni. Some rights reserved.