#5 브로커의 역할
Kafka 브로커의 역할 🏢
Kafka의 브로커는 여러 가지 역할을 수행한다. 단순히 데이터를 저장하는 것뿐만 아니라 컨트롤러 역할, 데이터 삭제, 컨슈머 오프셋 저장, 그룹 코디네이터 등 다양한 기능을 담당한다.
컨트롤러 🖥️
Kafka 클러스터에는 여러 개의 브로커가 존재하지만, 그중 한 대가 컨트롤러 역할을 수행한다. 컨트롤러는 브로커들의 상태를 모니터링하고, 문제가 발생하면 조치를 취한다. 예를 들어, 특정 브로커가 장애로 인해 클러스터에서 빠지게 되면 해당 브로커에 할당된 리더 파티션을 재분배한다.
그런데 "브로커가 클러스터에서 빠진다"는 게 무슨 의미일까? 🤔 브로커가 클러스터에서 빠진다는 것은 네트워크 장애나 하드웨어 장애 등의 이유로 해당 브로커가 정상적으로 동작하지 않는 상태를 의미한다. 이때 Kafka는 장애가 발생한 브로커를 클러스터에서 제외하고, 해당 브로커가 관리하던 리더 파티션을 다른 정상적인 브로커로 이동시킨다.
데이터 삭제 🗑️
Kafka는 일반적인 메시징 시스템과 다르게 컨슈머가 데이터를 가져가더라도 토픽의 데이터가 즉시 삭제되지 않는다.
❌ 컨슈머나 프로듀서가 직접 데이터를 삭제할 수 없다.
✅ 오직 브로커만이 데이터를 삭제할 수 있으며, 삭제는 로그 세그먼트 단위로 이루어진다.
Kafka의 데이터 삭제는 특정 레코드를 선별적으로 삭제하는 방식이 아니라, 로그 세그먼트 단위로 이루어진다. 즉, 데이터가 일정 기간이 지나거나 특정 크기를 초과하면 브로커가 자동으로 해당 세그먼트를 삭제하는 방식이다.
컨슈머 오프셋 저장 📌
Kafka의 컨슈머 그룹은 데이터를 가져오면서 어느 위치까지 가져갔는지를 기록해야 한다. 이를 "오프셋 커밋"이라고 하며, 이 정보는 __consumer_offsets
라는 내부 토픽에 저장된다. 덕분에 컨슈머는 이전에 어디까지 데이터를 처리했는지 알고, 이어서 데이터를 가져갈 수 있다.
그룹 코디네이터 🏗️
Kafka에서 컨슈머 그룹의 상태를 관리하는 역할을 담당하는 것이 바로 그룹 코디네이터다. 컨슈머 그룹 내에서 특정 컨슈머가 연결이 끊어지거나 사라지면, 그룹 코디네이터가 해당 컨슈머가 담당하던 파티션을 다른 컨슈머에게 재할당한다. 이 과정을 리밸런스(Rebalance)라고 한다.
즉, 컨슈머가 갑자기 사라지더라도 Kafka는 자동으로 남아있는 컨슈머들에게 데이터를 나누어 처리할 수 있도록 조정한다.
데이터 저장 📂
Kafka의 데이터 저장 방식도 독특하다. 데이터를 저장하는 기본 경로는 config/server.properties
의 log.dir
옵션에서 설정할 수 있다. 토픽과 파티션 번호를 조합한 디렉토리가 생성되며, 각 파일에는 다음과 같은 정보가 저장된다.
- log 파일: 메시지(레코드)와 메타데이터 저장
- index 파일: 메시지 오프셋을 인덱싱한 정보 저장
- timeindex 파일: 메시지의 타임스탬프 기준 인덱싱 정보 저장
Kafka에서는 데이터를 "메시지(Message)"라고 부르기도 하지만, 공식적으로는 "레코드(Record)"라고 한다.
로그와 세그먼트 📜
Kafka는 데이터를 지속적으로 하나의 파일에 저장하는 것이 아니라, 여러 개의 파일(세그먼트)로 나누어 저장한다. 세그먼트는 두 가지 기준으로 나뉜다.
1. 바이트 기준 📏
log.segment.bytes
설정값에 따라 하나의 세그먼트 파일이 최대 크기에 도달하면 새로운 파일이 생성된다. 기본값은 1GB이다.
📌 예를 들어, 10.log
라는 파일이 있다면, 이 파일은 offset 10번부터 저장된 데이터를 포함하고 있다는 의미다.
2. 시간 기준 ⏳
log.roll.ms
설정값에 따라 일정 시간이 지나면 새로운 세그먼트 파일이 생성된다. 기본값은 7일이며, 시간이 지나면 offset이 다 차지 않더라도 새로운 파일이 생성된다.
❗ 중요한 점: 액티브 세그먼트(active segment)는 삭제 대상이 아니다. 삭제는 리텐션(retention) 기간에 따라 진행되며, 기본적으로 7일 후에 삭제될 수도 있고 설정에 따라 3일 후에 삭제될 수도 있다.
Kafka 데이터 흐름 🔄
아래는 Kafka의 데이터 흐름을 간단히 정리한 구조도다. 계속 공부를 할 때 마다 구조 명칭이 헷갈려서 그려 넣었다
+------------------------+
| Producer | → 데이터를 생성해서 Kafka로 보냄
+------------------------+
|
v
+--------------------------------------------------+
| Kafka Cluster |
| +---------+ +---------+ +---------+ |
| | Broker1 | | Broker2 | | Broker3 | |
| +---------+ +---------+ +---------+ |
| | | | |
| v v v |
| +--------+ +--------+ +--------+ |
| | Topic1 | | Topic2 | | Topic3 | |
| +--------+ +--------+ +--------+ |
| | P1 | P2 | | P1 | P2 | | P1 | P2 | |
| +----+----+ +----+----+ +----+----+ |
+--------------------------------------------------+
|
v
+------------------------+
| Consumer | → 데이터를 가져와 사용
+------------------------+
마무리 🎯
Kafka 브로커는 단순한 저장소 역할을 하는 것이 아니라, 클러스터를 관리하고, 데이터를 삭제하고, 컨슈머 그룹을 조정하는 등 다양한 역할을 수행한다.
💡 오늘 배운 내용 중 궁금한 점:
- 컨트롤러가 다운되었을 때 새로운 컨트롤러는 어떻게 선출될까? 🤔
- 리밸런스 과정이 컨슈머에게 어떤 영향을 미칠까?
이제 Kafka의 내부 동작 방식에 대해 더 깊이 탐구해봐야겠다!