[kafka] Kafka의 주요 구성 요소 (Broker, Zookeeper)

Broker와 Zookeeper

https://wiki.terzeron.com/ko/OS_%EC%9D%BC%EB%B0%98_%EC%8B%9C%EC%8A%A4%ED%85%9C/Kafka/Kafka_%EC%86%8C%EA%B0%9C

 

Kafka의 주요 구성 요소중 Broker, Zookeeper는 카프카 클러스터를 구성하는 것들이다. Apache Zookeeper는 카프카 클러스터 윗 단에서 역할을 하고 Broker는 카프카 클러스터 내에서 역할을 한다.

 

 

1. Broker(Kafka Server)

카프카의 Broker는 Topic과 Partition을 유지 및 관리한다. 즉, Topic과 Partition에 데이터가 Read 및 Write 되도록 관리하는 소프트웨어이다. 카프카 서버라고도 부르며 Topic 내 partition들을 분산(배치)하고 유지 및 관리한다. 

 

- 각 Broker들은 숫자로 구성된 ID로 구분되며 카프카 클러스터는 여러 개의 Broker로 구성된다.

- Topic 데이터의 일부분(Partition)을 갖으며 데이터 전체를 갖는 것은 아니다. Topic을 Patition으로 나눠서 여러 Broker에 분산시키면 Partition이 '병렬'적으로'분산'되어처리되기 때문에 하나의 Broker는 Topic의 일부분인 Partition을 갖는다. (멀티브로커) 이러한 Topic의 형태는 장애가 발생했을 때 보다 적은 손실이 가능하다.

- 클라이언트(Producer/Consumer)가 특정 Broker에 연결하면 전체 클러스터에 연결할 수 있다.

- 안정성측면에서 카프카 클러스터를 구성할 때 최소 4대 이상의 Broker를 포함하는 것을 권장한다. 

- Partition ID와 Broker ID는 전혀 관련이 없다. Topic을 만들 때 Partition 개수를 지정하면 카프카 클러스터가 자동으로 Partition을 적절한 Broker에 할당한다. 즉, Topic을 구성하는 Partition들은 여러 Broker에 최대한 겹치지 않도록 '분산'된다.

 

 

 

cf. 부트스트랩(Bootstrap) 서버 (Broker Server)

클라이언트(Producer/Consumer)가 Broker에 접속할 때에는 부트스트랩 서버를 통해 접근하며 부트스트랩 서버는 카프카 클러스터 내의 모든 Broke들을 총칭하기도 한다.

 

[클라이언트가 브로커에 연결하는 과정]

- 클라이언트가 최초로 특정 Broker에 연결하면, 해당 Broker는 카프카 클러스터 내의 모든 Broker의 리스트를 응답해준다. 각각의 Broker들은 모든 Broker, Topic, Partition의 정보(Metadata)에 대해 알고 있다.

- 클라이언트는 응답 받은 Broker 리스트를 통해 클라이언트(Producer/Consumer)가 메시지를 전달하거나 받아가야 할 Topic(Partition)의 위치를 알게 되고 해당 Partition이 있는 Broker로 연결한다.

- 하지만 해당 Broker에 문제가 발생했을 경우를 대비해 모든 Broker들에 대해 연결을 시도하는 방식이 일반적이다.

 

 

2. Zookeeper

Zookeeper는 분산형 Configuration 정보를 유지하고 '분산 시스템에서 동기화 서비스를 제공하는 소프트웨어'이다. 카프카에서 Zookeeper를 사용하는데, 여기서는 분산된 Broker들을 관리하는 용도로 사용된다. 즉, Broker들의 목록이나 설정 정보를 관리하며 Zookeeper는 변경사항(Topic 생성 및 제거, Broker 생성 및 제거 등)이 발생하면 모든 Broker들에게 알린다.

 

Zookeeper는 카프카의 Broker, Topic, Partition의 개수 등에 대한 정보를 가지고 있다. 이러한 정보들은 Zookeeper의 리더가 가지고 있고 팔로워가 읽어가 Broker들에 동기화를 해 주는 작업을 진행한다. Zookeeper는 분산 시스템의 정보를 제어하기 위해 Tree 형태로 데이터를 관리하며 동기화 작업을 수행한다.

 

Zookeeper의 아키텍처

 

- Zookeeper 없이는 카프카가 동작할 수 없다. 하지만 최근 Zookeeper를 제거하는 방식을 개발 중에 있다.

- Zookeeper 서버는 홀수로 구성해야 한다. 보통 Zookeeper 서버 3개를 구성한다. (1개는 불가능)

- Zookeeper에는 리더가 있고 나머지 서버에는 팔로워로 구성된다. 리더는 write를하고 팔로워는 read를 한다. 위 Zookeeper 아키텍처 그림에서 보면, 하나의 리더에서 팔로워들이 데이터를 가져가서 클라이언트(여기서는 Broker)에 동기화하는 작업을 진행한다.

- 위와 같이 홀수로 구성된 Zookeeper 클러스터 형태를 Zookeeper Ensemble(주키퍼 앙상블)이라고 한다.

 

 

Zookeeper를 홀수의 서버로 구성해야 하는 이유 - Quorum 알고리즘 기반

Quorum(쿼럼)은 특정 합의체에서 의결을 하는데 필요한 '일정 구성원의 수'를 의미한다. 즉, Zookeeper 앙상블에서 무언가를 의결하기 위해서는 과반수 이상의 Zookeeper서버가 필요하다는 것이다. 이러한 방식으로 Zookeeper가 동작하는 이유는 분산 환경에서 예상치 못한 장애가 발생해도 분산 시스템의 일관성을 유지할 수 있기 때문이다.

 

앙상블이 5대로 구성되어있다고 가정하면 Quorum은 3이 되어야 하며 Zookeeper노드 2대가 장애가 발생해도 Zookeeper 전체적으로는 정상적으로 동작한다. 이렇듯 과반 이상의 수를 넘어야 한다는 이유 때문에 Zookeeper 노드를 홀수로 구성해야 한다.