주키퍼의 필요성
주키퍼는 개발자들이 동기화를 비롯한 부수적인 요소 대신, 서비스가 제공하는 기능과 그 구현 방법에 더 집중하도록 도와준다. 개발자가 주키퍼에 저장해야하는 정보는 제어 또는 조율을 위한 데이터이다. (서버들의 설정 정보, 클러스터의 마스터 서버, 각각 작업에 할당되어 있는 서버 정보)
주키퍼가 직접 스스로 조율하는 것이 아닌, 개발자가 주키퍼 API를 사용해서 동기화나 마스터 선출 등 골치아픈 작업을 쉽게 구현할 수 있도록 도와준다.
CAP 정리
CAP는 일관성(Consistency), 가용성(Availability), 분할 내성(Partition-tolerance)을 의미하며, 이 세가지 조건을 모두 만족하는 분산 시스템의 존재는 없음을 증명하는 정리이다.
일관성: 모든 노드가 같은 순간, 같은 데이터를 볼 수 있다.
가용성: 성공, 실패와 관계 없이 요청에 대한 결과를 반환
분할 내성: 메시지 전달이 실패해도, 일부 시스템에 문제가 일어나도 전체 시스템은 원활히 동작
주키퍼를 사용해도 조건을 모두 만족 시키는 분할 시스템은 구성할 수 없다. 하지만 시스템의 일관성, 가용성을 극대화 하고 분할이 발생해도 데이터를 읽는 연산이 가능하도록 구현할 수 있다.
주키퍼의 장점
- 일관성, 순서, 지속성 보장
- 동기화를 위한 프리미티프(primitive, 기초적인 요소)를 구현 가능.
- 분산 시스템에서 동시성으로 인해 생기는 잘못된 동작 차단.
주키퍼가 사용되는 서비스
HBase: Hadoop에서 사용되는 HBase는 Cluster Master를 선출하기 위해 Zookeeper 사용
Kafka: 카프카 서버의 Crash를 감지하기 위해 사용. 새로운 topic이 생성되었을 때, topic의 생성과 소비에 대한 상태를 저장하기 위해 도입
주키퍼 API
주키퍼는 데이터를 트리로 관리한다. 트리의 노드는 데이터를 저장할 수 있는 노드이며, 주키퍼가 트리내에서 관리된다고 하여 znode라 불린다.
create
/path data:path라는 이름의znode를 생성, znode에data저장
delete/path:/path라는 이름의znode삭제
exists/path:/path라는 이름의znode가 있는지 확인.
getData/path data:/path라는 이름의znode에data를 설정한다.
getData/path:/path라는 이름의znode의data를 얻는다.
getChildren/path:/path라는 이름의znode의 자식 node들의 리스트를 얻는다.
znode의 모드
- persistent: delete를 통한 명시적으로 지우지 않는 한 없어지지 않음
- Ephemeral: 생성한 Client가 Crash가 발생하거나 주키퍼와 연결이 끊어질 경우에도 삭제
- Sequential: 생성될 때, znode의 이름에 정수가 순차적으로 더해진다.
ex) /task/task-1, /task/task-2/, /task/task-3/ 과 같이 새로운 노드 생성
znode는 사용성에 따라 모드를 반드시 지정해서 create를 호출해야 한다.
- persistent모드로 znode 생성: 생성한 세션이 시스템에 존재하지 않더라도 연속적으로 보관해야 할 데이터
- Ephemeral모드로 znode 생성: 생성한 세션이 주키퍼 서비스와 연결이 유효할 경우에만 쓰일 정보 저장 -> Ephemeral 모드는 자식모드를 가지지 않는 특징이 있다.
버전(Version)
znode에는 데이터가 변경될 때마다 증가하는 Version이 있다. 버전 관리는 똑같은 znode를 여러 클라이언트가 사용할 경우에 유용하다.
만약 C1이 /config를 설정하고(버전2) 이후에 C2가 /config를 바꿧을 경우(버전3), C1 이 다음 setData를 호출하면서 버전2를 넣어주면 실패한다.
주키퍼 구조
주키퍼 서버
| 스탠드어론(standalone) | 쿼럼(quorum) |
|---|---|
| 하나의 주키퍼 서버 | 여러대의 앙상블 |
| 주키퍼 서버 상태 복제 필요 x | 각각의 주키퍼가 가진 상태 복제하여 일관성 유지 |
쿼럼모드 장점
- 주키퍼 앙상블은 Client 요청을 각기 다른 서버가 받을 수 있고 자연스럽게 요청 수가 증가 한다. 서버 한대로 주키퍼 트래픽 감당이 어려우면 쿼럼모드를 사용
- 어떤 이유로 Client와 연결이 끊기면, 앙상블 내에 다른 서버와 자동으로 연결해 주는 유연성을 가지고 있어 따로 예외처리를 할 필요가 없다.
쿼럼(Quorum)
주키퍼에서 쿼럼은 주키퍼가 동작하는데 필요한 최소한의 서버 개수. 또한 Client가 Data를 안전하게 저장했음을 의미한다.
예를들어 주키퍼 앙상블의 5대 서버가 있으면 쿼럼은 3이며, 세 대의 서버가 Client의 요청을 반영한 znode tree를 가지고 있으면 client는 요청에 성공했다는 응답을 받는다. 나머지 두대는 Client에 응답을 보낸 이후에 Data 복제를 한다.
하지만, 만약 쿼럼이 2이면, 2대에 서버에 요청을 보내고 성공했다는 응답을 받는다. 그런데 복제가 일어나기 전에 파티션이 발생하여 최신 데이터를 가진 2대에 서버 연결이 끊기면? 그래도 서버에 3대가 남아있고 쿼럼이 2이기 때문에 정상이라고 판단하여 정상 작동된다. 하지만 /z znode는 어떤 서버에도 존재하지 않는다.
이러한 문제를 해결하기 위해 쿠럼은 n/2 + 1(n = odd number)로 정해진다.
Reference
https://brunch.co.kr/@timevoyage/77 - Zookeeper Distributed Process Coordination by TOMO
