Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- 개발이 취미인 사람
- SWIFT
- component
- Sequelize
- 반복문
- 자바
- javascript
- back-end
- AWS
- node.js
- 코틀린
- props
- 개발자
- react
- It
- 조건문
- file upload
- restful api
- kafka
- vue
- front-end
- 상속
- Producer
- Kotlin
- Nest.js
- java
- spring boot
- swagger
- class
- state
Archives
- Today
- Total
개발이 취미인 사람
[Kafka] - Broker 컨트롤러(Controller) 본문
반응형
개요
안녕하세요. 이번 시간에는 Broker 컨트롤러에 대해 알아보겠습니다.
지난 시간 내용을 학습하고 오지 않으신 분들은 아래 링크를 통해 학습하고 오시는 걸 추천드리겠습니다.
Broker 컨트롤러
카프카 클러스터 환경에서는 리더와 팔로워로 구성되어 있습니다. 그럼 여기서 리더를 지정하는 방법은 무엇일까요?
기본적으로 컨트롤러 선출 방법은 ISR 리스트 목록에서 특정 브로커를 지정합니다. 파티션의 ISR 리스트 정보는 안전한 저장소에 저장되어야 해서 주키퍼에 저장되어 있습니다.
결국 주키퍼 서버가 컨트롤러를 지정합니다. 또는 KRaft 모드에서는 자체 관리하기 때문에 자체적으로 지정합니다.
컨트롤러를 선출하는 과정은 다음과 같습니다.
1. 클러스터 초기 시작 시 리더 선출 과정
Kafka 클러스터가 처음 시작될 때, 각 파티션에 대해 리더 리플리카를 선택해야 합니다. 이 과정은 아래와 같이 진행됩니다.
- 컨트롤러 선출: 처음 클러스터가 시작되면, Zookeeper(KRaft 모드에서는 자체적으로)를 통해 브로커 중 하나가 컨트롤러로 선출됩니다. 이 브로커는 클러스터의 리더 리플리카 선출과 관리 역할을 맡습니다.
- 리더 리플리카 선정:
- 컨트롤러는 Zookeeper(또는 KRaft)를 통해 각 파티션의 리플리카 목록을 가져오고, 해당 파티션에 대해 리더를 선출합니다. 일반적으로 리플리카 목록에서 첫 번째 리플리카가 리더로 지정됩니다.
- 모든 브로커에 걸쳐 파티션 리플리카가 분산되어 있으므로, 각 브로커는 자신이 호스팅하는 파티션의 리더인지 확인한 후 리더 역할을 수행합니다.
- ISR 구성: 각 파티션의 ISR(In-Sync Replica) 목록이 초기화되고, 그 중 첫 번째 리플리카가 리더로 지정됩니다. ISR은 리더 리플리카와 동기화된 리플리카들로 구성됩니다.
2. 장애 발생 시 리더 선출 과정
Kafka 클러스터 운영 중 리더가 장애를 겪으면, 컨트롤러는 새로운 리더 리플리카를 신속하게 선출해야 합니다. 이 과정은 두 가지 유형의 장애로 나눠서 설명할 수 있습니다.
(1) 운영 중 장애 (브로커 실패, 네트워크 문제 등)
- 장애 감지: 브로커가 운영 중에 장애가 발생하면, 컨트롤러는 Zookeeper를 통해 해당 브로커가 실패했음을 감지합니다. 브로커는 정기적으로 Zookeeper에 하트비트를 보내며, 하트비트를 놓치면 장애가 발생한 것으로 간주됩니다.
- 리더 리플리카 재선출:
- 장애가 발생한 브로커가 리더 역할을 맡고 있었다면, 그 파티션의 ISR에서 새로운 리더를 선출합니다.
- ISR에 있는 리플리카들은 리더와 데이터를 동기화하고 있으므로, 컨트롤러는 ISR에 있는 리플리카 중 하나를 새로운 리더로 지정합니다.
- 만약 ISR에 있는 리플리카가 적절하지 않거나 비정상적이라면, 컨트롤러는 해당 파티션에 대해 리더가 없는 상태로 둘 수도 있으며, 데이터 복구 작업을 시작할 수 있습니다.
- 메타데이터 업데이트: 새로운 리더가 선출되면, 컨트롤러는 해당 정보를 Kafka 클러스터의 다른 브로커들과 클라이언트들에게 알립니다. 이후 모든 읽기/쓰기 작업은 새롭게 선출된 리더 리플리카로 전송됩니다.
(2) 관리자에 의한 브로커 재시작
- 브로커 종료: 관리자가 의도적으로 브로커를 재시작할 경우, 컨트롤러는 해당 브로커가 정상적으로 종료되었음을 인식합니다. 이 경우 컨트롤러는 브로커가 재시작될 때까지 일시적으로 리더 역할을 다른 리플리카에게 위임할 수 있습니다.
- 리더 재선출: 관리자가 재시작한 브로커가 리더 리플리카 역할을 맡고 있었다면, 컨트롤러는 위와 동일한 방식으로 ISR에서 새로운 리더를 선출합니다.
- 브로커 재시작 후 동기화: 재시작된 브로커가 다시 정상 상태로 복귀하면, 해당 브로커는 팔로워 리플리카로 복귀하여 리더 리플리카의 데이터를 복제합니다. 이후 상황에 따라 다시 리더 리플리카로 선출될 수 있습니다.
위와 같이 컨트롤러는 중요한 역할을 합니다. 위 내용은 실제 운영중에 고려할 부분일 수 있으니 참고하시면 감사하겠습니다.
'백앤드(Back-End) > Kafka' 카테고리의 다른 글
[Kafka] - Consumer 그룹 코디네이터 (0) | 2024.10.30 |
---|---|
[Kafka] - Producer 메시지 전송 방식 (0) | 2024.10.21 |
[Kafka] - Broker 리플리케이션(Replication) 동작 원리 (0) | 2024.10.15 |
[Kafka] - Broker 메시지 복제와 커밋 ISR(In Sync Replica) (0) | 2024.08.02 |
[Kafka] - Kafka Consumer 메시지 소비 (0) | 2024.08.02 |