Kafka는 데이터를 여러 브로커에 복제해 장애에 대비한다.
그렇다면 실제로 브로커 한 대를 중지했을 때, 파티션과 복제본에는 어떤 변화가 발생하는지에 대해 실습을 해보기로 했다.
브로커 3대로 구성한 Kafka 환경에서 kafka-1을 중지하고, Kafka UI에 표시되는 order 토픽의 상태를 비교했다.
먼저 이번에 중지한 대상은 브로커 1이다.
브로커는 파티션의 복제본을 저장하는 서버이며, 하나의 브로커에 여러 파티션의 복제본이 함께 존재한다.
이번 환경에서도 브로커 1은 파티션 0·1·2의 복제본을 모두 가지고 있었다. 따라서 브로커 하나를 중지했지만 세 파티션 모두 영향을 받았다.
1. 중지 전: 모든 복제본이 정상적으로 동기화된 상태
order 토픽은 다음과 같이 구성되어 있었다.
- Number of Partitions : 총 몇개의 파티션을 만들 것인지?
- Replication Factor : 1개의 파티션을 몇개 유지할 것인지? Leader + Follower 의 수
| 항목 | 중지 전 상태 |
| 파티션 수 | 3개 |
| 복제 계수 | 3 |
| 동기화된 복제본 | 9 / 9 |
| URP | 0 |
| 메시지 수 | 총 3개, 파티션마다 1개 |
복제 계수가 3이라는 것은 파티션마다 리더를 포함해 총 3개의 복제본이 존재한다는 의미다.
따라서 파티션 3개의 복제본을 모두 합하면 9개가 된다.
화면에서 초록색으로 표시된 리더를 기준으로 브로커별 역할을 정리하면 다음과 같다.
| 파티션 | 브로커 1 | 브로커 2 | 브로커 3 |
| 파티션 0 | 팔로워 | 팔로워 | 리더 |
| 파티션 1 | 리더 | 팔로워 | 팔로워 |
| 파티션 2 | 팔로워 | 리더 | 팔로워 |
각 브로커가 파티션 하나씩의 리더를 맡고 있었고, 나머지 브로커가 해당 파티션의 데이터를 복제하고 있었다.
In Sync Replicas가 9 of 9라는 것은 전체 복제본 9개가 모두 ISR에 포함되어 있었다는 뜻이다.
ISR은 리더와 동기화 상태를 유지하는 복제본 집합이며, 리더 자신도 포함된다.
2. 브로커 1 중지: 세 파티션에서 복제본 하나씩 이탈
브로커 1이 가지고 있던 복제본은 다음 세 개다.
- 파티션 0의 팔로워 복제본
- 파티션 1의 리더 복제본
- 파티션 2의 팔로워 복제본
브로커 1의 중지로 이 세 복제본이 모두 동기화에 참여할 수 없게 되었다.
그 결과 In Sync Replicas는 9 / 9에서 6 / 9로 감소했다.
파티션마다 브로커 2와 3의 복제본 두 개씩이 남았으므로, 동기화된 복제본의 총합은 6개가 된 것이다.
이때 복제 계수는 여전히 3이다. 복제 계수는 설정된 복제본 수이고, ISR은 현재 동기화에 참여하는 복제본 집합이기 때문이다.
브로커가 중지되었다고 복제 계수나 기존 배치 정보가 자동으로 2로 바뀌지는 않는다.
3. 파티션 1의 리더가 브로커 2로 변경
이번 실습에서 가장 눈에 띄는 변화는 파티션 1의 리더 전환이다.
중지 전에는 파티션 1의 브로커 1이 초록색이었지만, 중지 후에는 브로커 1이 빨간색으로 바뀌고 브로커 2가 초록색으로 표시되었다.
| 파티션 | 중지 전 리더 | 중지 후 리더 | 변화 |
| 파티션 0 | 브로커 3 | 브로커 3 | 리더 유지 |
| 파티션 1 | 브로커 1 | 브로커 2 | 리더 전환 |
| 파티션 2 | 브로커 2 | 브로커 2 | 리더 유지 |
파티션 0과 2는 팔로워 하나를 잃었지만 기존 리더가 살아 있었으므로 리더를 유지했다.
반면 파티션 1은 리더가 중지되었기 때문에 다른 복제본이 리더 역할을 이어받아야 했다.
화면에서는 기존에 동기화되어 있던 브로커 2의 복제본이 새로운 리더가 된 것을 확인할 수 있다.
이는 Kafka의 복제와 리더 전환 구조에 부합하는 결과다.
파티션 1 자체가 다른 서버로 새롭게 이동한 것이 아니라, 브로커 2에 이미 존재하던 파티션 1의 복제본이 리더 역할을 이어받은 것이다.
또한 파티션 1의 Replicas 목록은 여전히 1, 2, 3이다. 이 목록의 첫 번째 브로커는 우선 리더인 preferred leader를 의미하며, 장애 이후의 실제 리더와는 다를 수 있다. 이번 화면에서는 목록의 두 번째인 브로커 2가 현재 리더다.
URP가 0에서 3으로 증가한 이유
브로커 중지 후 URP는 0에서 3으로 증가했다.
URP는 Under-Replicated Partitions, 즉 동기화된 복제본 수가 설정된 복제 계수보다 적은 파티션의 수를 의미한다.
이번에는 세 파티션 모두 다음 상태가 되었다.
| 파티션 | 설정된 복제 계수 | 남은 ISR 수 | 복제 부족 여부 |
| 파티션 0 | 3 | 2 | 해당 |
| 파티션 1 | 3 | 2 | 해당 |
| 파티션 2 | 3 | 2 | 해당 |
따라서 복제가 부족한 파티션은 총 3개다.
URP 3은 파티션 3개가 모두 중단되었다는 뜻이 아니라 세 파티션 모두 리더는 존재하지만, 목표로 설정한 복제 수준을 충족하지 못하고 있다는 뜻이다.
현재 동작을 이어갈 기반은 남아 있지만, 추가 장애에 대비할 여유가 줄어든 상태로 해석해야 한다.
조금 더 쉽게 이해해보기
1. 파티션 리더와 활성 컨트롤러
리더는 두 종류로 나누어 생각하면 이해하기 쉽다. ‘파티션의 리더’와 ‘클러스터를 관리하는 컨트롤러’이다.
회사에 비유하면 다음과 같다.
- 브로커 1·2·3 → 직원 3명
- 파티션 0·1·2 → 업무 3개
- 파티션 리더 → 각 업무의 담당자
- 활성 컨트롤러(Active Controller) → 담당자를 배정하고 장애를 관리하는 관리자
파티션 리더는 업무별 담당자이다
처음에는 업무를 다음과 같이 나누어 맡고 있었다.
| 업무 | 담당자 |
| 파티션 0 | 브로커 3 |
| 파티션 1 | 브로커 1 |
| 파티션 2 | 브로커 2 |
여기서 브로커 1은 ‘브로커들의 리더’가 아니라 ‘파티션 1의 리더를 맡은 브로커’이다.
한 직원이 여러 업무를 맡을 수 있듯이, 브로커 한 대가 여러 파티션의 리더를 맡을 수도 있다. 실제로 브로커 1을 중지한 후에는 다음과 같이 변경되었다.
| 업무 | 담당자 |
| 파티션 0 | 브로커 3 |
| 파티션 1 | 브로커 2 |
| 파티션 2 | 브로커 2 |
브로커 2가 파티션 두 개의 리더를 맡게 된 것이다.
컨트롤러는 담당자 배정과 장애를 관리하는 관리자이다
파티션 리더가 메시지 저장 요청을 처리한다면, 컨트롤러는 다음과 같은 일을 담당한다.
“브로커 1이 사용할 수 없는 상태이다. 파티션 1의 리더를 맡을 다른 복제본을 정해야 한다.”
즉, 컨트롤러는 클러스터의 관리 담당자이다. 모든 메시지를 먼저 받아서 각 브로커로 전달하는 총괄 서버는 아니다.
현재 설정에서는 서버 3대가 두 역할을 함께 맡는다
실습에 앞서 생성해둔 도커 컴포즈에는 다음과 같은 설정을 작성해놓았다.
KAFKA_PROCESS_ROLES: broker,controller
이는 각 서버가 데이터를 저장하는 브로커 역할과 클러스터를 관리하는 컨트롤러 역할을 겸한다는 뜻이다.
컨트롤러 3개 중 하나가 활성 컨트롤러로 관리 업무를 주도하고, 나머지는 메타데이터를 복제하며 활성 컨트롤러 장애에 대비한다.
| 구분 | 파티션 리더 | 활성 컨트롤러 |
| 담당 범위 | 해당 파티션 | 클러스터 관리 |
| 주요 역할 | 해당 파티션의 메시지 쓰기·복제 주도 | 브로커 상태 관리·파티션 리더 선출 |
| 개수 | 파티션마다 하나 | 컨트롤러 집합에서 하나 |
‘주문 업무 담당자’와 ‘회사 관리자’가 별개의 역할인 것처럼, 파티션 리더와 컨트롤러도 별개의 역할이다.
현재 환경에서는 같은 서버가 두 역할을 함께 수행할 수 있다.
앞서 확인한 토픽 화면의 초록색 숫자는 파티션 리더를 나타낸다. 그 화면만으로는 어느 서버가 활성 컨트롤러인지 알 수 없다.
2. 리더 전환은 파티션별로 보면 이해하기 쉽다
이번 리더 전환을 이해하려면 파티션별로 보는 것이 더 직관적이다.
‘파티션 하나가 브로커 3대에 복제되어 있고, 그중 하나가 리더이다’라는 관점을 기준으로 보면 된다.
| 파티션 | 중지 전 | 중지 후 |
| 파티션 0 | 브로커 3이 리더, 1·2가 팔로워 | 리더 3 유지, 팔로워 1 중지 |
| 파티션 1 | 브로커 1이 리더, 2·3이 팔로워 | 2가 새 리더, 1 중지, 3은 팔로워 |
| 파티션 2 | 브로커 2가 리더, 3·1이 팔로워 | 리더 2 유지, 팔로워 1 중지 |
이렇게 보면 파티션 1만 리더가 바뀐 이유가 드러난다. 중지한 브로커 1이 파티션 1에서는 리더였고, 나머지 파티션에서는 팔로워였기 때문이다.
또한 파티션마다 복제본 하나씩을 잃었으므로 다음과 같은 변화가 발생했다.
- 각 파티션의 ISR: 3개 → 2개
- 전체 ISR 합계: 9개 → 6개
- 복제가 부족한 파티션: 0개 → 3개, 즉 URP 3
리더와 복제 관계를 이해할 때는 파티션별로 보고, 서버 한 대가 중지되었을 때 영향 범위를 확인할 때는 브로커별로 보면 된다.
실습 결과
브로커 1을 중지한 결과, 파티션 1의 리더는 브로커 2로 전환되었고 파티션 0과 2의 리더는 유지되었다. 세 파티션에서 복제본 하나씩이 ISR에서 이탈하면서 동기화된 복제본은 9개에서 6개로 감소했고, URP는 0에서 3으로 증가했다.
이번 실험을 통해 Kafka의 복제는 데이터를 여러 곳에 저장하는 역할뿐 아니라, 기존 리더가 중지되었을 때 다른 복제본이 리더 역할을 이어받도록 하는 기반이라는 점을 확인했다.
'개발공부 > Kafka' 카테고리의 다른 글
| Kafka가 필요한 이유와 핵심 개념 정리 (0) | 2026.09.24 |
|---|