하둡(Hadoop) - 주키퍼(Zookeeper)

주키퍼(Zookeeper)

• 주키퍼는 부분실패를 안전하게 처리하는 분산 애플리케이션 개발을 용이하게 한다
• 분산 시스템에 필요한 노드간 정보 공유, 노드 상태 체크, 노드간 공유데이터에 대한 배타적 접근 (Lock, 락) 처리 등을 위한 분산 코디네이션 서비스 시스템이다
• 분산 시스템의 중요한 상태정보, 설정 정보, 메타 데이터 등을 관리하므로 장애로 인한 문제 발생이 일어나지 않도록 해야한다 =>고가용성 보장
• 다수 노드로 ZooKeeper Ensemble 구성
  • 리더와 추종자 역할을 수행하는 노드들의 집합
  • 모든 노드는 동일한 데이터를 가진다
  • 읽기 : 어떤 노드에서 읽어도 동일한 데이터를 읽는다
  • 쓰기 : 어떤 노드가 데이터를 업데이트 하면 리더에 전송하고 이를 추종자노드들에 브로드캐스팅을 한다

 

Zookeeper Ensemble

• 주키퍼 그룹 멤버쉽
  • 계층 구조를 이용하여 서버 노드를 그룹화한다
  • 각 노드에는 호스트명, IP, Port 등 저장한다
  • 각 서버는 HeartBeat를 송신한다
  • 서버 HeartBeat 미 송신시 노드를 변경한다

주키퍼 그룹 멤버쉽

 

 

특징

• 단순함 
  • 핵심기능을 제공하는 간소화된 파일 시스템이다
  • 명령, 알림 기능을 추가 제공한다

 

• 풍부한 기능 제공
  • 분산 큐(queue), 분산 잠금(lock), 피어(peer) 그룹 대표 선출 등의 분산 코디네이션에 필요한 다양한 기능을 제공한다

 

• 고가용성 제공 
  • 다수 노드에서 실행되며 고가용성을 보장하도록 설계된다
  • 분산 시스템에서 발생할 수 있는 단일 장애점(Single Points of Failure : SPOF) 문제 해결을 지원한다

 

• 느슨한 상호작용 지원
  • 노드 또는 노드의 프로세스 들이
  • 미결합 상호작용의 반대
  • 상대방에 대한 정보(IP, Port 등)를 상세히 모르더라도 서로 발견하고 메시지 교환이 가능하다

 

💡  단일장애점?
-  시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 요소

 

 

트랜잭션 처리

• Quorum
  • Leader가 트랜잭션을 수행하기 위해서는 자신을 포함하여 과반수 이상의 노드 합의를 획득해야 한다
  • 과반수의 합의를 위해 필요한 서버들을 Quorum이라고 한다
  • Ensemble을 구성하는 노드의 수 5개이다 (Quorum 노드 3)

 

1. Leader에게 Request 전달 : 새로운 트랜잭션 요청이 Follower에게 도착, Follower는 Leader에게 요청 전달한다
2. Propose : Leader가 Quorum을 구성하는 서버들에게 트랙잭션 수행 가능 여부 확인한다
3. Ack : Quorum 서버는 Leader의 Propose 요청 수신 후 트랙잭션 수행 가능 응답(Ack)을 Leader 에 전송한다
4. Commit
   • 모든 Quorum 서버로 부터 Ack 수신 -> Leader는 트랙잭션 처리(Commit) 명령 브로드캐스트를 한다
   • Commit 명령 전달시 ZAB(ZooKeeper Atomic Broadcast) 알고리즘 사용한다

Zookeeper 트랜잭션 처리

 

 

 

ZAB(ZooKeeper Atomic Broadcast) 알고리즘

• 1단계 : 복구 모드
  • 리더 선출 과정
    1. 모든 ZooKeeper 서버가 선거(election) 과정을 시작하며, 자신이 후보가 된다
    2. 각 서버는 자신의 "선거 에포크 번호"를 증가시키고 이를 다른 서버들에게 전파. 이 번호는 서버가 살아있는 동안 단조 증가한다
    3. 서버는 다른 서버들 로부터 받은 에포크 번호를 비교하며, 가장 높은 에포크 번호를 가진 서버를 리더로 선출. 만약 에포크 번호가 같다면, 가장 많은 데이터를 가진 서버를 리더로 선택한다
  • 클러스터의 동기화 과정
    1. 리더는 클러스터 내의 모든 서버에게 새 에포크를 시작하라는 메시지를 전송한다
    2. 각 서버는 메시지를 수신하고 새 에포크 시작. 서버들은 자신의 로컬 상태를 변경하여 이전 에포크의 모든 업데이트를 무효화하고 새 에포크의 모든 업데이트를 수락할 준비를한다
    3. 리더는 팔로워들에게 이전 에포크의 마지막 상태를 전송. 이를 통해 팔로워들은 리더와 동일한 상태를 유지한다.
• 2단계 : 원자적 브로드캐스트 모드
  1. 클라이언트는 업데이트를 요청하고 이 요청은 리더에게 전송한다
  2. 리더는 이 요청을 받고, 각 요청에 대해 고유한 순서를 부여한다 
  3. 리더는 이 요청을 팔로워들에게 전파. 이 때, 요청은 리더가 부여한 순서대로 전파된다
  4. 팔로워들은 요청을 받고, 그 순서대로 요청을 처리. 팔로워들은 리더로부터 받은 순서대로 요청을 적용하기 때문에, 전체 클러스터는 일관성 유지한다.
  5. 팔로워들은 각 요청을 처리한 후, 리더에게 응답을 전송한다.
  6. 리더는 모든 팔로워로부터 응답을 수신한 후에 클라이언트에게 요청이 성공적으로 처리되었음을 알린다.

ZAB 알고리즘

 

데이터 모델

• 디렉토리 구조, Key-value 모델
  • ZooKeeper의 모든 데이터는 디렉토리 구조 기반으로 znode에 key-value 모델로 저장한다
  • Znode : 파일 시스템의 파일 및 디렉토리

디렉토리 구조

• ZNode
  • 빠른 분산처리를 위해 모든 znode를 메모리에 저장한다
  • ZooKeeper는 분산 코디네이션을 위한 데이터만을 저장하기 때문에 메모리 용량 부담이 적디 (znode는 최대 1MB)
  • 서버가 종료되면 사라지기 때문에 transaction log를 따로 저장 => 데이터 복구 가능
  • Znode 의 종류
    • 영구 노드 (Persistent Node)
      • Persistent znode에 저장된 데이터는 영속된다
    • 임시 노드 (Ephemeral Node)
      • 노드를 생성한 클라이언트와의 세션이 끊어지면 삭제한다
    • 순차 노드 (Sequence Node)
      • 생성 시점에 10자리의 sequence number가 할당 됨. post-fix로 사용
      • Sequence는 atomic하게 증가 => 동일 이름의 znode 이더라도 Seuence Number 는 고유 => 분산 잠금 구현에 활용한다
      • ex) /app1/myapp1 이름의 Sequence Node 2개
        /app1/myapp1-0000000001, /app1/myapp1-0000000002
  • Znode의 stat 구조
    • znode의 메타데이터(metadata)
    • 버전 넘버(version number), ACL(Action control list), 타임 스탬프(Timestamp), 데이터 길이(Data length) 로 구성된다
    • 버전 넘버(version number) : znode의 데이터가 업데이트 될 때마다 증가. 다수의 주키퍼 클라이언트(client)들이 특정한 연산을 같은 znode에 수행할 때 필요하다
    • ACL(Action control list) : znode에 접근하기 위한 권한 획득 메커니즘. Znode의 읽기 쓰기 연산을 통제한다
    • 타임스탬프(Timestamp) : znode가 생성되고 나서 경과된 시간 및 업데이트된 시간
    • 데이터 길이(Data length) : 주키퍼의 데이터 크기. 주키퍼의 데이터들은 최대 1MB까지 저장 가능하다

ZNode의 구조

• Watcher
  • znode 변화 감지, 클라이언트가 설정 가능
  • 자신이 감시하고 있는 znode에 수정이 발생하였을 때, 클라이언트로 callback 호출을 전송하는 알림 기능 제공한다

Watcher

 

Watcher-2