Kafka Cluster
여러 브로커가 하나의 Kafka 처럼 동작하는 구조
왜 여러 브로커를 써야하는가?
브로커가 1 대 밖에 없다면
서버가 죽으면 1대 밖에 없으므로 Kafka 전체가 중단됨
확장이 불가함
모든 데이터가 한 군데 모이는 행위
공식 문서에서도 3대 이상의 브로커를 구축할 것을 권장
Kafka Cluster
├─ Broker 1
│ ├─ order 파티션 0 (Leader)
│ ├─ order 파티션 1 (Follower)
│ └─ order 파티션 2 (Follower)
├─ Broker 2
│ ├─ order 파티션 0 (Follower)
│ ├─ order 파티션 1 (Leader)
│ └─ order 파티션 2 (Follower)
└─ Broker 3
├─ order 파티션 0 (Follower)
├─ order 파티션 1 (Follower)
└─ order 파티션 2 (Leader)
Leader, Follower
Leader
Producer, Consumer 의 실제 통신 대상
읽기/쓰기 담당
장애 발생시 Follower 중 Leader 가 선출
Follower
Leader의 데이터를 그대로 복제
장애 복구 후 Leader의 데이터를 다시 저장하기 시작
Controller
브로커가 살아있는지 확인
어떤 파티션의 Leader 가 누구인지 관리
Failover 가 발생시 새로운 Leader 선출
Topic, Partition 등 메타 데이터 관리
KRaft Controller
Kafka 의 자체적인 관리 컨트롤러
Controller 기능이 Kafka 내부에 포함
메타데이터를 로그 형태로 Kafka 내부에 저장
Raft 알고리즘 기반으로 안정적인 Leader 선출
Kafka 3.X 버전 부터 지원
Zookeeper
Kafka 2.X 버전 까지 Controller 의 역할을 수행
다만 Zookeeper와 Kafka Cluster 는 별개의 시스템
복잡도 증가
Zookeeper 의 장애로 Kafka 도 영향을 받음
높은 동시성 환경에서는 병목이 될 수 있음
Share article