[Kafka] 9. Zookeeper

 

 

Apache ZooKeeper™는 분산 작업의 중앙 집중식 조정 서비스입니다. 

주 서버 선출, 그룹 구성원 관리, 구성 정보 제공, 네이밍 및 대규모 동기화와 같은 일반적인 조정 작업을 수행합니다. 

ZooKeeper의 주요 목표는 분산 시스템의 운영을 보다 간단하게 하고, 시스템 내 복제본 간에 개선되고 더 신뢰할 수 있는 변경 전파를 공급하는 것입니다.

Apache Kafka는 여러 서버(브로커)에서 실행되는 분산 퍼브-섭(pub-sub) 메시징 시스템입니다.

브로커들은 서로 조정해야 하며, 카프카의 초기 몇 년 동안은 ZooKeeper가 이러한 조정을 제공했습니다.

그러나 최근에는 KRaft라는 또 다른 소프트웨어 구성 요소로 대체되었습니다.

이 장에서는 카프카 ZooKeeper, 그 한계 및 관련 대안에 대해 탐구합니다.

 

 

1. Role of ZooKeeper in Kafka

카프카는 생산자로부터 메시지를 수신하고 소비자에게 전달하는 여러 브로커로 구성된 분산 시스템으로 설계되었습니다. 

브로커는 일반적으로 더 높은 장애 허용성과 가용성을 위해 클러스터 내에서 운영됩니다.

초기에는 ZooKeeper가 클러스터 내의 브로커들이 서로 조정하는 데 도움을 주었습니다. 

예를 들어, ZooKeeper는 브로커의 가용성 상태를 추적하고 클러스터 내의 주요 브로커 또는 컨트롤러를 결정했습니다.

주요 기능은 다음과 같습니다:

 

 

구성 관리 Configuration management

ZooKeeper는 클러스터 전반에 걸쳐 구성을 관리하기 위한 중앙 집중식 저장소 또는 결정적인 출처 역할을 했습니다. 

이는 구성 매개변수에 대한 단일 진실의 출처를 제공하여 클러스터의 모든 브로커가 지정된 구성을 따르도록 보장했습니다. 

여기에는 주제 생성 또는 삭제와 같은 구성 변경이 포함되며, 이러한 변경은 ZooKeeper를 통해 클러스터 전반에 전파되었습니다.

 

 

리더 선출 Leader election

브로커 클러스터에서 리더 브로커는 모든 읽기 및 쓰기를 처리하며, 팔로워들은 리더의 데이터를 복제합니다. 

리더 노드가 오프라인 상태가 될 때마다 리더 선출이 발생하며, 새로운 리더는 즉시 업데이트됩니다. 

ZooKeeper는 리더의 세부 정보를 유지하기 위한 단일 지점 역할을 했습니다. 

카프카는 또한 ZooKeeper를 통해 작업 조정을 지원했습니다.

 

액세스 제어 목록 Access control lists

카프카는 모든 주제에 대한 액세스 제어 목록(ACL)을 ZooKeeper에 저장하여 각 주제에 대한 읽기 및 쓰기 권한을 정의했습니다.

또한 서버 목록과 같은 데이터도 유지했습니다.

 

락 관리 Lock management

락 관리는 카프카와 같은 분산 환경에서 데이터 손실이나 손상을 초래할 수 있는 동시 수정이 발생하지 않도록 방지하는 데 필수적입니다. 

락은 시스템이 분산 동기화를 위해 공유 리소스에 상호 배타적인 방식으로 작업할 수 있도록 유지됩니다. 

ZooKeeper는 클러스터 전반에 걸쳐 락을 관리하고 이를 사용하여 카프카의 클러스터 구성 및 주제 구성이 클러스터 내의 모든 카프카 브로커에서 동일하게 유지되도록 보장합니다.

 

구성원 관리 Membership management

ZooKeeper는 브로커가 클러스터를 떠나거나 가입할 경우 이를 감지하고 업데이트했습니다. 

또한 클러스터의 구조와 상태에 대한 포괄적인 정보를 저장했습니다.

 

 

2. ZooKeeper concepts

ZooKeeper의 데이터 모델은 파일 시스템과 유사합니다. 이는 znodes로 알려진 작은 데이터 노드로 작동하며, 트리와 같은 구조 내에서 계층적으로 배열됩니다.

 

2.1. Znode

Znode는 데이터를 저장할 수 있기 때문에 종종 데이터 레지스터(data registers)라고 불립니다. 

파일 시스템의 디렉토리 내의 파일처럼, znode는 자식 노드와 연결된 데이터를 포함합니다. 

ZooKeeper 트리 내의 각 znode는 경로에 의해 고유하게 식별되며, 경로 구성 요소는 "/"로 구분됩니다.

 

2.2. Ensemble

ZooKeeper에서 앙상블(ensemble)은 분산 애플리케이션을 공동으로 조정하고 관리하는 ZooKeeper 서버의 모음을 의미합니다(최소 3개). 

이러한 서버는 동일한 데이터를 복제하고 협력하여 장애 허용성과 높은 가용성을 제공합니다. 

앙상블은 ZooKeeper 배포의 중추를 형성합니다. 

이들은 개별 서버 중 하나가 실패하거나 접근할 수 없게 되더라도 ZooKeeper 서비스가 정상적으로 운영되도록 보장합니다.

 

2.3. Session

세션은 클라이언트와 서버 간에 유지되는 연결을 나타냅니다. 

여기서 카프카 노드는 클라이언트로 작용하여 ZooKeeper 서버 앙상블과 연결을 설정합니다. 

ZooKeeper 서버는 클라이언트의 요청을 선입선출(FIFO) 방식으로 처리합니다.

세션이 설정되면 서버는 카프카 클라이언트에 고유한 세션 ID를 부여합니다. 

세션의 유효성을 유지하기 위해 클라이언트는 주기적으로 하트비트를 전송합니다. 

일반적으로 세션 타임아웃 값은 밀리초로 표시되며, 클라이언트로부터의 통신이 없을 때 세션이 만료되는 기간을 정의합니다.

 

2.4. Watches

와치는 카프카가 시스템 내의 변경 사항에 대한 알림을 받는 메커니즘 역할을 합니다. 

클라이언트는 특정 znode를 읽을 때 와치를 설정합니다. 

이러한 와치는 znode 데이터 수정 또는 znode의 자식 변경에 응답하여 활성화됩니다. 

와치는 관련 변경 사항이 발생할 때 한 번만 트리거됩니다. 

세션이 만료되는 경우, 해당 세션과 연결된 와치는 자동으로 제거된다는 점에 유의해야 합니다.

 

2.5. ZooKeeper Quorum

실제 운영에서 쿼럼(quorum)은 투표가 진행되기 위해 필요한 최소한의 주키퍼 노드 수를 나타냅니다.

ZooKeeper의 맥락에서 쿼럼은 ZooKeeper가 제대로 작동하기 위해 운영되고 접근 가능한 최소 ZooKeeper 서버 노드 수를 나타냅니다.

이 수치는 또한 카프카 요청을 저장하기 위해 최소한의 ZooKeeper 노드가 저장을 확인해야 한다는 것을 의미합니다.

ZooKeeper 클러스터에서 데이터는 하나의 ZooKeeper 노드에 기록되고 앙상블 내의 모든 노드에 복제됩니다. 

그러나 카프카가 모든 ZooKeeper 노드가 데이터를 저장할 때까지 기다리면 과정에서 지연이 발생합니다. 

이 문제를 해결하기 위해 시스템은 최소한의 ZooKeeper 노드 쿼럼이 데이터를 복제하면 진행됩니다.

쿼럼의 크기는 Q = 2N+1 공식을 통해 정의됩니다. 

여기서 Q는 앙상블을 형성하는 데 필요한 ZooKeeper 서버 노드 수를 정의하며, N은 실패할 수 있는 노드 수를 나타냅니다.

예를 들어, 두 개의 ZooKeeper 서버 노드가 충돌하더라도 효율적으로 작동할 수 있는 ZooKeeper 클러스터를 설정하고자 한다면, N은 2가 됩니다. 

따라서 앙상블 크기는 5가 되어야 합니다. 

이처럼 5개 중 3개의 ZooKeeper 서버가 데이터를 저장하면, 카프카 요청은 진행될 수 있으며 나머지 2개 서버는 데이터를 저장하는 데 따라잡을 수 있습니다.

쿼럼은 시스템 지연 및 오류가 발생하더라도 ZooKeeper가 인정한 업데이트는 다른 요청이 이를 대체할 때까지 손실되거나 수정되지 않도록 보장합니다.

 

3. Limitations of Kafka ZooKeeper

단일 실패 지점
ZooKeeper에서 장애 허용성을 달성하고 지속적인 가용성을 보장하는 것은 까다롭습니다. 

최소 쿼럼을 위해 동일한 클러스터로 여러 ZooKeeper 서버 노드를 실행해야 하기 때문입니다. 

모든 가능한 중단 시나리오에서 ZooKeeper 앙상블이 올바르게 작동하도록 보장하는 것은 비용이 많이 듭니다. 

이러한 비용에도 불구하고 대부분의 노드가 동시에 실패할 경우 단일 실패 지점이 여전히 발생할 수 있습니다.

추가 오버헤드
ZooKeeper 클러스터는 카프카 클러스터를 실행하기 위한 전제 조건입니다. 

ZooKeeper 클러스터를 관리하는 것은 운영 복잡성을 크게 증가시킵니다. 

관리자는 앙상블을 설정하고 유지해야 하기 때문입니다. 매개변수 구성, 성능 모니터링, 장애 처리 및 보안 보장을 포함하여 복잡성이 증가합니다. 

카프카 개발자는 두 시스템의 건강 및 성능을 유지하기 위해 지속적으로 모니터링해야 합니다.

보안
ZooKeeper의 보안 모델과 업그레이드를 카프카와 동기화하는 것은 복잡한 작업입니다. 

ZooKeeper와 카프카가 연결을 보안하기 위해 동일한 보안 프로토콜을 지원해야 하므로 신중한 계획과 조정이 필요합니다. 

ZooKeeper를 제거하면 카프카의 보안 모델이 간소화되어 관리가 용이해지고 전체 시스템 효율성이 향상됩니다.

 

 

4. KRaft—The Kafka ZooKeeper alternative

KRaft는 카프카의 ZooKeeper 의존성을 제거한 합의 프로토콜인 카프카 Raft를 의미합니다. 

ZooKeeper에서는 카프카 클러스터의 하나의 컨트롤러가 리더와 통신합니다. 

만약 컨트롤러가 다운되면 재선거가 발생하는 데 시간이 걸려 카프카 성능에 영향을 미칩니다. 

KRaft에서는 브로커 클러스터 내의 단일 컨트롤러가 요청을 처리하기 위해 쿼럼으로 대체됩니다. 

어떤 컨트롤러가 사용할 수 없게 되면, 다른 컨트롤러가 요청을 처리하고 작업을 관리할 수 있습니다. 

이는 카프카의 갑작스러운 장애에 대한 내성을 향상시킵니다.

KRaft 쿼럼 컨트롤러는 메타데이터가 쿼럼 전반에 걸쳐 정확하게 복제되도록 보장합니다. 

이벤트 소스 저장 모델을 사용하여 복제 시 상태를 정확하게 유지합니다. 

상태는 메타데이터 주제라는 이벤트 로그에 저장됩니다. 

로그가 무한정 커지는 것을 방지하기 위해 주기적으로 스냅샷으로 정리됩니다.

쿼럼의 다른 컨트롤러들은 활성 컨트롤러가 로그에 기록한 이벤트를 처리하여 활성 컨트롤러를 따릅니다. 

만약 어떤 노드가 일시적으로 멈춘 경우, 재가입 시 로그에서 놓친 이벤트를 신속하게 따라잡을 수 있어 다운타임을 크게 줄이고 시스템 복구 시간을 개선할 수 있습니다. 

ZooKeeper의 장애와 달리, KRaft에서는 누락되거나 지연된 이벤트만 복사됩니다.

 

4.1. KRaft benefits

KRaft는 운영 오버헤드가 적고, 카프카의 데이터 플레인과 동일한 구성 매개변수, 보안 메커니즘 및 실패 시나리오를 사용하기 때문에 급격한 학습 곡선이 없습니다.

간소함
ZooKeeper에서는 ZooKeeper 클러스터와 카프카 클러스터 각각에 대해 다른 구성 파일을 유지해야 합니다. 

KRaft에서는 단일 구성 파일로 모든 것을 관리합니다.

확장성
KRaft에서는 컨트롤러 쿼럼만 메타데이터에 접근할 수 있으며, 모든 다른 서버는 컨트롤러 쿼럼과 통신합니다. 

이는 메타데이터 저장소에 대한 추가 요청을 줄여주며, 카프카가 더 많은 서버와 주제를 처리할 수 있도록 합니다.

성능
KRaft에서는 추가 ZooKeeper 클러스터를 관리할 필요가 없기 때문에 운영 복잡성이 줄어듭니다. 

이는 카프카 배포 및 유지 관리를 간소화하여 오버헤드 및 잠재적 장애 지점을 줄임으로써 전체 시스템 성능을 향상시킵니다.