[개념정리] Kafka 클러스터 구조 이해하기

대용량 처리에 용이한 Kafka의 브로커, 소비자 그룹에 대한 이해를 기반으로 마지막으로 

Kafka 클러스터 구조에 대한 이해를 갖춰 나아가려고 한다.

 

☑️ 단일 브로커 구조는 위험성과 한계가 어떻게 될까?

단일 브로커의 운영방식으로 인한 구조적 문제에 대한 내용들을 살펴보자면 아래와 같다.

 

1. 서버에 문제가 생기면 Kafka 전체에도 문제가 발생한다.
   • 메시지를 저장할 수 없다.
   • 메시지를 소비할 수도 없다.
   • 서비스 전체가 중단되어 심각한 장애를 초래한다.
2. 확장이 불가능하다.
   • 처리량이 늘어나도 단일 서버 한 대가 모든 요청을 감당해야 한다.
   • 특정 Partition에 트래픽이 몰리면 병목이 쉽게 발생한다.
3. 모든 데이터가 한 서버에 쌓여 위험하다.
   • 디스크가 고장나면 메시지 전체가 손실될 위험이 있다.
4. 고가용성(High Availability)이 보장되지 않는다.
   • 일시적인 네트워크 오류, 서버 재부팅으로도 서비스가 멈추게 됨

실 서비스에서는 여러 브로커를 함께 운영하는 클러스터 구조를 기본으로 두고 운영하게 된다.

 

✅ Kafka 클러스터란 무엇인가? 

Kafka 클러스터는 여러 브로커가 하나의 Kafka처럼 동작하는 구조

Kafka는 이처럼 여러 브로커를 하나의 클러스터로 통합하여 다음과 같은 기능을 제공한다.

• Partition을 여러 브로커에 분산해 저장하여 병렬 처리 성능을 확장할 수 있음
• 장애가 발생하면 다른 브로커가 역할을 자동으로 인계 받아 전체 시스템의 고가용성(High Availability)을 확보

✅ Partition 분산 저장 구조

하나의 Topic 내부 Partition은 여러 브로커에 나누어 저장된다.

단일 브로커의 형태

클러스터 구조의 형태

Partition 분산 저장 구조를 통해 3가지의 장점을 가질 수 있게 되는데

 

1. 부하가 분산된다.
   • 한 서버가 모든 메시지를 처리하지 않아도 된다.
2. 병렬 처리(Parellelism)가 자연스럽게 증가한다.
   • Partition 개수가 곧 병렬 처리 상한선이기 때문에 병렬 처리가 자연스럽게 증가한다.
3. 특정 브로커 장애에도 전체 시스템이 멈추지 않는다.
   • Replica 구조 덕분에 특정 브로커 장애에도 시스템이 멈추지 않는다.

✅ Replica(복제본) 구조

Partition은 원본만 존재하는 것이 아니라, Kafka는 각 Partition의 복제본(replica)을 다른 브로커에 저장한다. 

예를 들어 위의 예시를 기반으로 아래와 같은 예시본처럼 복제본이 발생하게 된다.

빨강 → Leader / 청록 → Follower

 

Leader / Follower 역할

Leader

• Producer와 Consumer가 실제로 통신하는 대상으로, Leader와만 통신한다
• 모든 read/write 작업을 Leader가 처리한다.
• 장애가 발생하면 새로운 리더가 자동으로 선출된다.

Follower

• Leader의 데이터를 그대로 복제
• Leader 장애 발생 시 Follower가 자동으로 Leader로 승격된다 (Failover)
• Follower에서 장애가 발생한 경우에는 장애가 복구된 이후부터 Leader의 데이터를 다시 저장하기 시작한다. (동기화)

 

복제의 장점

• Broker 1대가 죽어도 Topic이 사라지지 않는다.
• Producer와 Consumer는 계속 정상적으로 동작한다.
• 데이터 안전성이 크게 증가한다.

✅ Controller 역할

Kafka 클러스터에서는 누가 Leader가 될지, 어떤 브로커가 살아있는지, 파티션을 어디에 저장할지에 대한 총괄 관리자가 필요하다.

 

컨트롤러(Controller)가 하는 일

• 어떤 브로커가 살아 있는지 확인한다.
• 어떤 파티션의 Leader는 누구인지 관리한다.
• Failover 시 새로운 Leader 선출을 진행한다.
• Topic 정보, Partition 정보 등 Metadata를 관리한다.

→ Kafka는 이처럼 Controller를 중앙 두뇌처럼 활용한다. 

장애가 발생하여 새로운 Leader가 선출된 Kafka Cluster

 

✅ KRaft Controller

Kafka 3.x 부터 Kafka는 자체적으로 메타데이터를 관리하는 구조를 도입했다.

이 방식이 KRaft(Kafka Raft Metadata Mode)라고 부름

KRaft의 역할

• Controller의 기능을 Kafka 내부에 직접 포함한다.
• 클러스터 메타데이터를 Metadata Log 형태로 Kafka 내부에 저장한다.
• Raft 합의 알고리즘 기반으로 안정적인 Leader 선출을 지원한다.

쉽게 말해 KRaft는 Kafka Cluster를 안정적으로 운영하기 위한 내부 조율 시스템이라고 할 수 있다.

 

Zookeeper 구조와의 차이

Kafka 2.x 버전까지는 Controller의 역할을 Kafka 가 아닌 Zookeeper가 수행했다.

즉, 메타데이터의 저장과 클러스터 조율 기능이 Zookeeper에 의존하는 구조였다는 것.

Zookeeper의 역할

• Broker 정보 관리
• Topic alc Partition 메타데이터 저장
• Partition Leader 선출
• 브로커 살아있음 체크 (heartbeat)
• 클러스터 전체 상태 관리

즉, Zookeeper는 Kafka 클러스터의 뇌 역할을 수행했다. 

 

하지만 Zookeeper 기반 구조의 문제는

1. 운영해야 하는 시스템이 Kafka와 Zookeeper 2개로 운영 복잡도 증가
2. Zookeeper 장애 시 Kafka도 직접적인 영향을 받음
3. 높은 동시성 환경에서는 Zookeeper가 메타데이터 업데이트 병목이 될 수 있음

이러한 문제점을 해결하기 위해 위에서 서술한 KRaft가 등장하게 된 것