Kafka는 대용량 메시지를 안정적으로 처리하기 위한 분산 메시징 시스템입니다. 이 글에서는 파티션이 3개인 Kafka 클러스터에서 메시지가 어떻게 저장되고 처리되는지, 장애 발생 시 어떻게 동작하는지 단계별로 알아보겠습니다.
Kafka 클러스터 다중 파티션 구성 이해: 고가용성과 장애복구
목차
1. Kafka 클러스터 기본 구성
Kafka는 하나의 토픽을 여러 개의 파티션으로 나누고, 이를 여러 브로커에 분산 저장해 병렬성과 안정성을 높입니다.
이 글의 예시는 다음과 같은 구성입니다:
- 브로커 수: 3개 (Broker-1, Broker-2, Broker-3)
- 토픽 수: 1개 (topic-1)
- 파티션 수: 3개 (Partition 0, Partition 1, Partition 2)
- Replication Factor: 3 (각 파티션마다 리더 1개, 팔로워 2개)
Kafka는 항상 과반수(majority)의 복제본이 정상이어야 작동하므로, 최소 3개의 브로커를 권장합니다.
2. 파티션과 리더-팔로워 구조
Kafka는 각 파티션을 하나의 리더(Leader)와 여러 개의 팔로워(Follower)로 구성합니다.
- 리더: 메시지를 저장하고, Producer와 Consumer가 직접 접근합니다.
- 팔로워: 리더의 데이터를 복제하며, 리더가 장애 날 경우 리더로 승격될 수 있습니다.
| Partition | Leader 브로커 | Follower 브로커 |
| 0 | Broker-1 | Broker-2, Broker-3 |
| 1 | Broker-2 | Broker-1, Broker-3 |
| 2 | Broker-3 | Broker-1, Broker-2 |
이 배치는 모든 브로커에 고르게 리더와 팔로워 역할을 분산시켜, 리소스 효율성을 높입니다.
3. 메시지 저장과 처리 흐름
1. 메시지 전송: Producer
- Producer는 Kafka 클러스터에 메시지를 보낼 때, 내부적으로 파티션 결정 로직을 사용합니다.
- 일반적으로 메시지 키(key)를 해싱하거나 라운드 로빈 방식으로 파티션을 선택합니다.
- 예를 들어, 메시지가 Partition 1으로 지정되었다면, 해당 파티션의 리더인 Broker-2가 메시지를 받게 됩니다.
Producer → Broker-2 (Partition 1의 리더)
2. 메시지 저장: Leader Broker
- 선택된 리더 브로커(Broker-2)는 메시지를 로그 세그먼트(Log Segment)라는 파일에 기록합니다.
- 이 파일은 Kafka의 영속적인 저장소로, 디스크에 저장됩니다.
- 메시지는 먼저 리더에만 저장되며, 이후 복제 단계로 넘어갑니다.
- Kafka는 높은 처리 성능을 위해 디스크에 순차적으로 데이터를 기록합니다.
3. 데이터 복제(Replication) : Follower Broker
- 리더 브로커에 저장된 메시지는 해당 파티션의 팔로워 브로커로 자동 복제됩니다.
- 복제는 비동기 또는 준동기 방식으로 진행되며,
- 복제 상태가 리더와 동일한 브로커는 ISR (In-Sync Replica) 리스트에 등록됩니다.
- ISR에 포함된 팔로워만 리더 장애 시 새로운 리더가 될 수 있습니다.
Broker-2 (리더) → Broker-1, Broker-3 (팔로워)
4. 메시지 소비 : Consumer
- Consumer는 파티션의 리더에게서만 데이터를 읽습니다.
- Partition 1의 리더가 Broker-2라면, Consumer는 Broker-2에 직접 연결하여 데이터를 가져옵니다.
Consumer ← Broker-2 (Partition 1의 리더)
4. Replication Factor에 따른 구조 변화
Replication Factor(복제 계수)는 하나의 파티션 데이터를 몇 개의 브로커에 복제할지를 결정합니다.
복제본 수가 많을수록 데이터 손실에 강하고, 장애 발생 시 복구 가능성이 높아집니다.
◆ Replication Factor = 1 (복제 없음)
- 각 파티션은 리더 1개만 존재하고, 복제본이 없습니다.
- 리더 브로커가 장애 발생 시 데이터 손실 위험이 큽니다.
- 운영 환경에서는 권장하지 않습니다.
| 브로커 | 파티션 역할 |
| Broker-1 | Partition 0 (Leader) |
| Broker-2 | Partition 1 (Leader) |
| Broker-3 | Partition 2 (Leader) |
◆ Replication Factor = 2 (리더 + 복제본 1개)
- 각 파티션은 리더 1개 + 팔로워 1개(복제본)으로 구성됩니다.
- 브로커 1대가 장애 나도 작동은 가능하지만, 2대가 장애 나면 데이터 손실 가능성이 있습니다.
| 브로커 | 파티션 역할 |
| Broker-1 | Partition 0 (Leader), Partition 1 (Follower) |
| Broker-2 | Partition 1 (Leader), Partition 2 (Follower) |
| Broker-3 | Partition 2 (Leader), Partition 0 (Follower) |
◆ Replication Factor = 3 (리더 + 복제본 3개) : 권장 구성
- 각 파티션은 리더 1개 + 팔로워 2개로 구성됩니다.
- 브로커가 1대 장애 나도 정상 동작하며 데이터 손실도 없습니다.
- Kafka 운영 환경에서는 가장 안정적인 구성으로 권장됩니다.
| 브로커 | 파티션 역할 |
| Broker-1 | Partition 0 (Leader), Partition 1 (Follower), Partition 2 (Follower) |
| Broker-2 | Partition 1 (Leader), Partition 2 (Follower), Partition 0 (Follower) |
| Broker-3 | Partition 2 (Leader), Partition 0 (Follower), Partition 1 (Follower) |
◆ Replication Factor = 4 (불가능)
- 브로커가 3개인 상태에서 Replication Factor = 4는 설정할 수 없습니다.
- 이유는 복제본은 서로 다른 브로커에만 배치할 수 있기 때문입니다.
- Replication Factor는 브로커 수를 초과할 수 없습니다.
5. 장애 발생시 리더 전환(Failover) 동작
Kafka는 고가용성을 위해 복제본(Replicas) 중 하나가 장애가 발생하면 자동으로 리더(Leader)를 다른 브로커로 전환합니다.
이 과정을 통해 메시지 유실 없이 서비스를 지속할 수 있습니다.
장애 시나리오: Broker-1 다운
Kafka 클러스터의 Controller(자동으로 선출된 브로커)가 Broker-1의 장애를 인지합니다. 이때, Partition 0의 리더가 사라지므로 리더 교체가 필요합니다.
◆ 장애 발생 전 상태
| 파티션 | 리더 브로커 |
| Partition 0 | Broker-1 |
| Partition 1 | Broker-2 |
| Partition 2 | Broker-3 |
1. Controller가 장애 감지
- Kafka 클러스터에는 Controller 역할을 수행하는 브로커가 하나 있습니다.
- Controller는 주기적으로 모든 브로커의 상태를 감시하며, Broker-1의 다운을 감지합니다.
- 이로 인해 Partition 0의 리더가 사라졌음을 인식하게 됩니다.
2. ISR에서 새로운 리더 자동 선출
- Kafka는 Partition 0의 ISR(In-Sync Replica, 동기화된 복제본) 목록을 확인합니다.
- 이 중 가장 최신 데이터를 가진 팔로워(예: Broker-2 또는 Broker-3)를 새로운 리더로 자동 승격합니다.
- ISR은 리더와 지속적으로 데이터를 동기화하고 있던 복제본만 포함됩니다.
Partition 0: Broker-1 (기존 리더) 장애 → Broker-2 또는 Broker-3 (새 리더)
3. 클라이언트의 트래픽 전환
- Kafka의 Producer와 Consumer는 클러스터의 메타데이터를 기반으로 리더 정보를 자동으로 갱신합니다.
- 새로운 리더가 선출되면, 클라이언트는 새 리더에게 메시지를 쓰고 읽도록 자동으로 전환됩니다.
Producer → 새 리더 (Broker-2 또는 Broker-3)
Consumer ← 새 리더 (Broker-2 또는 Broker-3)
4. 장애 브로커 복구 후 클러스터 재 합류
- Broker-1이 복구되어 다시 클러스터에 연결되면, Kafka는 해당 브로커를 다시 정상 브로커로 인식합니다.
- Partition 0의 복제본도 다시 Broker-1에 생성되며, ISR에 재합류합니다.
- 단, ISR 합류 전까지는 리더로 승격될 수 없습니다.
| 파티션 | 리더 | 복구 후 Broker 1 역할 |
| Partition 0 | Broker-2 (리더) | 팔로워로 복제 진행 |
◆ 장애 발생 전 후 비교
| 상태 | Partition 0 리더 | Partition 1 리더 | Partition 2 리더 |
| 장애 전 | Broker-1 | Broker-2 | Broker-3 |
| 장애 후 | Broker-2 (새 리더) | Broker-2 | Broker-3 |
| 복구 후 | Broker-1 (팔로워) | Broker-2 | Broker-3 |
Kafka 클러스터에서 파티션을 여러 개 구성하면 처리 속도와 확장성이 크게 향상됩니다.
Replication Factor를 3으로 설정하면 데이터 손실 없이 고가용성을 유지할 수 있습니다.
Kafka의 리더-팔로워 구조와 장애 복구 메커니즘을 이해하면, 안정적인 운영 환경을 구축할 수 있습니다.
관련 글 링크
'1.시스템&인프라 > Apache Kafka' 카테고리의 다른 글
| 6. Kafka 프로듀서 파티션 할당 방식(Round Robin vs Sticky 비교) (0) | 2025.03.28 |
|---|---|
| 5. Kafka 리더 장애 발생 시 Failover를 위한 Producer와 Consumer 설정 (0) | 2025.03.28 |
| 3. Kafka 단일 파티션 기반 리더-팔로워 동작 원리: 장애복구 (0) | 2025.03.28 |
| 2. Kafka 단일 노드 동작 원리: 파티션 분배부터 Consumer 전략까지 (0) | 2025.03.28 |
| 1. 실시간 데이터 처리 플랫폼 Apache Kafka 이해하기 (0) | 2025.03.28 |