[Apache Kafka] 주키퍼(ZooKeeper)

주키퍼(ZooKeeper)란?

분산 코디네이션 서비스를 제공하는 오픈소스 프로젝트
주키퍼는 직접 애플리케이션 작업을 조율하지 않고 조율하는 것을 쉽게 개발할 수 있도록 도와주는 도구이다.  API를 이용해 동기화나 마스터 선출 등의 작업을 쉽게 구현할 수 있게 해준다.
각 애플리케이션의 정보를 중앙 집중화하고 구성관리, 그룹 관리 네이밍, 동기화 등의 서비스를 제공한다.
주키퍼의 데이터는 메모리에 저장되고, 영구 저장소에 스냅샷을 저장한다.

분산 코디네이션 서비스란?

• 분산 시스템에서 시스템 간의 정보 공유, 상태 체크, 서버들 간의 동기화를 위한 락 등을 처리해주는 서비스

Architecture

출처: https://ssup2.github.io/theory_analysis/ZooKeeper/

주키퍼는 분산 시스템의 일부분이기 때문에 동작을 멈춘다면 분산 시스템이 멈출수도 있다. 그래서 안정성을 확보하기 위해 클러스터로 구축한다.
클러스터는 홀수로 구축한다. 어떤 서버에 문제가 생겼을 경우 과반수 이상의 데이터를 기준으로 일관성을 맞추기 때문이다.
살아있는 노드가 과반수 이상이라면 지속적인 서비스를 제공한다.

구성

1. Request Processor: Write 요청 처리

2. Zab(Zookeeper Atomic Broadcast Protocol): Request Processor에서 처리한 요청을 트랜잭션을 생성하여 모든 서버에게 전파한다. Leader-Propose -> Follower-Accept -> leader-Commit 단계로 구성된다.

3. In-memory DB: Znode의 정보가 저장되며, 로컬 파일시스템에 Replication을 구성할 수 있다.

znode란?

출처: https://ssup2.github.io/theory_analysis/ZooKeeper/

주키퍼가 상태 정보를 저장하는 곳

분류1

• Persistent Node: 영구 저장소
• Ephermeral Node: Client가 종료되면 사라진다.

분류2 

• Sequence Node: 생성 시 뒤에 숫자가 붙는다.
• 일반 Node

Watcher

1. 주키퍼를 사용하는 클라이언트 A가 ZooKeeper에게 Watcher 등록을 요청한다.

2. 주키퍼를 사용하는 클라이언트 B가 ZooKeeper에게 ZNode를 수정한다고 말한다.

3. 클라이언트 A에게 변경 이벤트를 전달한다.

주키퍼를 짝수로 구성한 경우 생기는 문제점?
크게 문제는 없으나, 짝수로 구성한 경우 쿼럼을 형성할 때 비례적으로 노드 수가 더 필요하므로 잘 사용되지 않는다.

4대로 구성한 경우

• 쿼럼을 형성하는데에 3대가 필요하다.

5대로 구성한 경우

• 쿼럼을 형성하는데에 3대가 필요하다.

---

6대로 구성한 경우

1. 두 서버에 문제가 생겼으면 4대가 동작하는데 과반수 이상이기 때문에 지속적으로 동작한다.
2. 세 서버에 문제가 생겼으면 3대가 동작하는데 과반수 이상이 아니므로 동작을 멈춘다.

5대로 구성한 경우

1. 두 서버에 문제가 생겼으면 3대가 동작하는데 과반수 이상이기 때문에 지속적으로 동작한다.
2. 세 서버에 문제가 생겼으면 2대가 동작하는데 과반수 이상이 아니므로 동작을 멈춘다.

쿼럼(Quorum)

단어 뜻

• 합의체가 의사를 진행시키거나 의결을 하는 데 필요한 최소한도의 인원수

주키퍼에서의 뜻

• 주키퍼 앙상블을 이루고 있는 모든 서버 중 과반수 서버로 이루어진 그룹을 말한다. 
• 5대의 앙상블일 때 정상적인 서버 3대를 쿼럼이라고 한다.
• 쿼럼은 한 서버에서 일어난 변경이 앙상블 내의 다른 서버로 전파되어 복제될 때, 복제가 이용가능한 수준까지 이루어졌다는 최소 기준이다.

스플릿브레인(Split-brain)

• 시스템의 두 부분 이상이 일관되지 않게 동작하는 것

쿼럼이 5개 중 2개일 때 시나리오

1. 사용자가 주키퍼에게 쓰기 작업을 요청한다. 주키퍼가 쿼럼에게 쓰기 작업을 복제한다.

2. 1번과 2번 서버가 znode의 쓰기 작업을 완료했다고 리더에게 응답한다.

3. 주키퍼 서비스가 클라이언트에게 알린다.

4. 1번과 2번 서버에 문제가 발생했다고 가정한다. 1번과 2번 서버에 적용된 내용이 사라진다. 문제가 발생하더라도 과반수 이상이 살아있기 때문에 계속 동작한다.

5. 아직 살아있는 서버 2개로 새로운 쿼럼을 구성한다.

6. 주키퍼 서비스는 정상적으로 동작하지만 일관성이 깨진다.

쿼럼이 5개 중 3개일 때 시나리오

1. 사용자가 주키퍼에게 쓰기 작업을 요청한다. 주키퍼가 쿼럼에게 쓰기 작업을 복제한다.

2. 쓰기 작업을 3대로 복제한다.

3. 3대에 장애가 발생한 경우 서비스를 중단하고, 2대에 장애가 발생한 경우 지속한다.

4. 쿼럼으로 구성되었던 서버 1대와 쿼럼에 포함되지 않았던 2대로 새로운 쿼럼을 구성한다.

5. 쿼럼으로 구성되었던 서버 1대의 작업을 다른 서버들에게 복제한다.

6. 쓰기 요청을 유실하지 않고 계속 사용할 수 있다.

카프카에서 주키퍼는?

• 서버의 상태를 감지하기 위해 사용되며 새로운 토픽이 생성되었을 때, 토픽의 생성과 소비에 대한 상태를 저장한다.

• 주키퍼와 카프카는대규모 환경에서는 다른 서버에 두는 편이 좋다. 주키퍼 앙상블은 홀수로 구성되어 과반수 이상이 장애가 발생하면 중단되고, 카프카는 그렇지 않아도 되기 때문에 다른 서버에 두는 것을 권장한다.

CAP 정리란?

• 아래의 조건을 모두 충족하는 분산 시스템은 없다는 정리이다.

  • Consistency(일관성): 모든 노드가 같은 데이터를 볼 수 있다.

  • Availability(가용성): 성공, 실패 여부와 상관 없이 요청에 대한 결과를 반환할 수 있다.

  • Partition-tolerance(분할 내성): 메시지 전달이 실패하거나 문제가 발생하더라도 전체 시스템이 원활하게 동작할 수 있다

• 예시

  • 두 개의 ATM기와 한 명의 유저가 있다고 가정한다.

  • ATM기의 기능에는 입금, 인출 기능이 있다. 입금하거나 인출하면 잔액을 업데이트한 후 거래를 완료한다.

  • ATM의 기기 이름을 각각 A, B라고 가정한다.

  • A기기를 사용하려고 하지만 B기기와 통신이 안되는 경우가 발생했다고 생각해본다.

  • 이 문제는 네트워크 문제 때문일 수도 있고 B기기의 문제 때문일 수도 있다.

  • 여기에서 CAP정리를 확인할 수 있다. 일관성과 가용성 중에 하나만 선택할 수 있다.

  • 일관성(Consistency)을 선택한 경우 입금이나 인출을 할 수 없다고 사용자에게 말하고 기다린다.

  • 가용성(Availability)을 선택한 경우 우선 처리를 해주고 B가 치유되면 대화하여 다시 잔금을 동기화한다.

출처: https://data-engineer-tech.tistory.com/4 [데이터 엔지니어 기술 블로그:티스토리]