Zookeeper 소개와 작동 프로세스

Zookeeper 란

분산 어플리케이션을 위한 분산 코디네이션 서비스이다. 
분산 어플리케이션을 만들기 위해서 필요한 동기화나 설정 등 다양한 기능의 API 제공해준다.
그리고 무엇보다 높은 수준의 구현이 필요한 coordination 기능을 제공해줘서 더 쉽게 분산 어플리케이션을 구현할 수 있다.

Zookeeper 주요 기능 & 특징

ZNodes

주키퍼는 shared hierachical namespace를 통해 분산 프로세스가 서로 상호작용한다.
이 namespace는 znodes라고 불리는 데이터 레지스터로 구성되어 있다.
이 znode로 메모리에서 데이터를 처리하기 때문에 높은 throughput과 낮은 latency를 제공한다.

• 높은 performance
• 높은 available
• strcitly ordered access - 클라이언트에서 정교한 동기화 기능 구현 가능

zookeeper는 클러스터를 구성하는 서버들은 모두 서로에 대해 알고있다.
disk에 트랜잭션 로그, 스냅샷, 메모리 내 상태 이미지를 유지한다.

클러스터를 구성하는 서버들 중 과반수(Quorum) 이상이 유지되면 부분적으로 장애가 발생해도 안정적으로 zookeeper 서비스를 유지할 수 있다. 

Ordered

zookeeper는 모든 트랜잭션에 대해 순서를 매겨 관리한다.
그래서 synchronization primitives와 같은 더 높은 수준의 추상화를 구현할 수 있다.

Performance

read 위주의 작업이 많은 상황에 적합하다. 적정한 read:write 의 비율은 10:1이다.
write가 들어오면 동기화 작업이 필요하기 때문이다.

요청 처리 process

Replication & Read

요청 프로세스를 제외하면 zookeeper의 각 서버는 각 구성 요소의 자체 복사본을 복제한다.
또한 전체 데이터 트리를 포함하는 in-memory 데이터베이스이다. Update는 복구 가능성을 위해 디스크에 기록되며 Write는 메모리 내 db에 적용되기 전에 디스크에 serialization 된다.

Contract Protocol

모든 zookeeper 서버는 클라이언트에 서비스를 제공한다.
read 요청은 각 서버 db의 로컬 복제본에서 처리되지만, 상태 변경, write 요청은 contract protocol에 의해 처리된다.

클러스터 내 서버는 역할에 따라 Leader, Follower로 나뉜다.

leader : 데이터의 수정 권한을 가진 노드,  write 수행
follower : leader가 아닌 이외의 모든 서버, write 요청은 leader에게 보내고 leader가 보낸 메세지를 전달한다.

Messaging Layer

실패가 발생했을 때 리더를 교체하고 리더와 동기화 하는 작업을 담당한다.
Custom atomic messaging protocol을 사용하기에, 로컬 복제본이 절대 분기되지 않게 보장한다.
leader는 write 요청을 수신하면 변경이 적용될 때 시스템 상태를 계산하고 이를 새로운 상태를 캡처하는 트랜잭션으로 변환한다.

위의 그래프로 read의 요청에 한해서 서버가 적어도 많은 요청을 빠르게 처리할 수 있다는 것을 알 수 있다.

1. Failure and recovery of a follower
2. Failure and recovery of a different follower
3. Failure of the leader
4. Failure and recovery of two followers
5. Failure of another leader

각 상황에 대한 처리량의 변화다.
특히 3번이 발생한 leader 서버에 문제가 생겼을 때 영향을 가장 많이 받는 것을 알 수 있다.

Quorum

quorum이란

클러스터의 앙상블을 이루고 있는 모든 서버 중 과반수 서버로 이루어진 그룹을 말한다.

Quorum의 노드들은 반드시 running 상태여야 하고, 데이터 업데이트가 성공했다면, Quorum을 구성하는 노드들은 이 변경 트랜잭션이 반영되어야 한다.

Quorum이 과반수여야 하는 이유

만약 장애가 발생해도 quorum이 과반수라면, Consistency를 유지할 수 있다.

만약 과반수로 구성하지 않는다면 다음 문제가 생길 수 있다. ( 앙상블 5대, Quorum 2대 일때 )

1. 클라이언트가 주키퍼에게 쓰기 작업을 요청
2. 주키퍼는 쓰기 작업 요청을 Quorum으로 복제 (2대)
3. 5대 중 Quorum 2대에 쓰기 작업 요청이 완료되면 쓰기 작업이 성공
4. Quorum 2대에 장애가 발생하여 쓰기 작업 요청이 유실
5. 주키퍼는 Quorum에 장애가 발생하였으므로 새로운 쿼럼 구성
6. 쿼럼은 2대로 구성 가능하기 때문에 남은 3대의 서버중 2대로 새로운 쿼럼을 구성
7. 클라이언트에서 쓰기 요청했던 내용은 유실되어 확인할 수 없음.

주키퍼 서비스는 안정적으로 돌아가고 있는데 데이터는 없어져 버렸다. consistency를 유지하지 못한다.

만약 과반수로 구성한다면, ( 앙상블 5대, Quorum 3대 일때 )

1. 클라이언트가 주키퍼에게 쓰기 작업을 요청
2. 주키퍼는 쓰기 작업 요청을 Quorum으로 복제 (쿼럼 3대)
3. 5대 중 Quorum 3대에 쓰기 작업 요청이 완료되면 쓰기 작업이 성공
4. Quorum 3대에 장애가 발생하여 쓰기 작업 요청이 유실
5. 주키퍼는 Quorum에 장애가 발생했지만 남아 있는 서버가 과반수가 되지 못해 새로운 Quorum을 구성하지 못함
6. 주키퍼는 이용 불가 상태가 됨

이렇게 이용불가 상태가 된다면, Client 또는 개발자는 장애인 것을 인지하고 대응할 수 있다.

• 이 상황에서 복구를 하려면 장애난 서버 또는 데이터의 하나를 복구해서 quorom을 구성해야한다.