Apache Kafka 구조
Apache Kafka 구조
이전에 Apache Kafka 포스팅을 보고 이게 어떻게 가능한가 하는 생각이 들었을 것이다.
이번 포스팅인 Kafka에 대한 구조를 살펴본다면 어떻게 해당 작업이 가능한지 이해할 수 있을 것이다.
1. Overview
기본적으로 Kafka는 아래와 같은 구조를 갖는다.
기본적으로 Producer에서 Topic을 지정해서 데이터를 보내고 Consumer에서 해당 Topic에 대해서 데이터를 가져오는 방식이다.
기본적으로 Kafka는 고성능 TCP 네트워크 프로토콜을 통해 통신하는 서버와 클라이언트로 구성된 분산 시스템으로, 온프레미스와 클라우드를 가리지 않고 배포 가능하며 가상머신이든, 베어메탈 서버든, 컨테이너든 가리지 않고 사용 가능하다.
1) 서버
Kafka는 여러 데이터 센터 또는 클라우드 리전에 걸쳐 있는 하나 이상의 서버로 구성된 클러스터로 실행한다. 이러한 서버 중 일부는 브로커라고 하는 스토리지 계층을 구성한다. 다른 서버는 Kafka Connect를 실행하여 이벤트 스트림으로 데이터를 지속적으로 가져오고 내보내 Kafka를 관계형 데이터베이스 및 다른 Kafka 클러스터와 같은 기존 시스템과 통합되어 작동할 수 있다. Kafka는 클러스터로 운용되는 것이 일반적이며 이를 통해 높은 확장성과 내결함성을 제공한다. 서버에 장애가 발생하더라도 다른 서버가 해당 작업을 인계받아 데이터 손실 없이 지속적인 운영을 보장한다.
a. 브로커
메시지를 저장하고 프로듀서/컨슈머의 요청을 처리하는 서버 프로세스이다. 실제 운영에서는 단일 브로커가 아니라 여러 브로커가 모여 하나의 클러스터(Cluster) 를 이루며, 클러스터 전체가 토픽과 파티션들을 분산 저장·관리한다.
메시지 로그(파티션)를 저장하고, 프로듀서의 쓰기(write)와 컨슈머의 읽기(read)를 처리한다. 각 브로커는 고유한 broker.id 를 가진다.
b. 복제 세트
각 파티션은 하나의 리더를 갖고, 나머지는 팔로워로 복제된다. 프로듀서와 컨슈머는 항상 그 파티션의 리더와 통신한다. 여기서 복제 세트수(Replication Factor)는 가용성과 내결함성을 결정하는데, 만약 복제 세트수가 3이라면 2개까진 고장나도 작동한다. 클러스터링 된 파티션은 각 파티션마다 리더와 팔로워가 있고, 리더를 제외한 팔로워 개수를 ISR(In-Sync Replicas)이라고 한다.
c. ZooKeeper VS KRaft
과거에 kafka는 브로커의 메타데이터(클러스터 상태, 리더 정보 등)를 ZooKeeper가 관리했었다. 이를 통해 ZooKeeper는 클러스터 상태 저장 · 선출 기능을 제공했었는데, 최근에는 Kafka가 자체적으로 메타데이터 로그를 관리하는 KRaft 모드(컨트롤플레인 내장)를 도입하여 ZooKeeper 의존도를 제거할 수 있게 되었다.
2) 클라이언트
네트워크 문제나 머신 장애 발생 시에도 이벤트 스트림을 병렬, 대규모, 내결함성 방식으로 읽고, 쓰고, 처리하는 분산 애플리케이션과 마이크로서비스를 작성할 수 있다. Kafka에는 이러한 클라이언트가 포함되어 있으며, Kafka 커뮤니티에서 제공하는 수십 개의 클라이언트 로 확장된다 . 클라이언트는 Java 및 Scala(고급 Kafka Streams 라이브러리 포함), Go, Python, C/C++ 및 기타 여러 프로그래밍 언어, 그리고 REST API를 지원한다.
2. Partition
토픽(Topic)은 하나 이상의 파티션(Partition) 으로 나뉘어 저장된다. 파티션은 메시지가 순서대로 쌓이는 로그(log) 이며, 각 메시지는 오프셋(offset) 이라는 넘버로 식별된다.
1) 병렬 처리와 스케일링
파티션 수가 많을수록 같은 토픽에 대해 더 많은 컨슈머 인스턴스(컨슈머 그룹)를 병렬로 처리할 수 있다. 하지만 파티션 수는 토픽 생성 시 정해지거나(증가 가능하지만 복잡), 적절히 설계해야 한다.
2) 순서 보장
Kafka는 파티션 단위로(같은 파티션 내에서) 메시지 순서를 보장한다. 토픽 전체에 대한 전역 순서는 보장되지 않는다.
3) 파티션 분배(리더/팔로워, 복제)
각 파티션은 클러스터 내 브로커 중 하나가 리더(leader) 로 선택되고, 다른 브로커들이 팔로워(follower) 로 복제한다. 복제수(replication factor)를 통해 장애 허용성을 얻는다. 리더가 장애가 나면 ISR(In-Sync Replica) 중 하나가 새로운 리더가 된다.
선정된 리더는 모든 데이터의 읽고 쓰기를 담당하며 기본적으로는 follower들은 leader로부터 데이터를 받아서 저장만한다.
단, 특정 설정에 따라 follower에서도 데이터를 읽어 올 수 있다. 이는 Latency를 줄일 수 있지만 실제 세팅이 가능한지는 배포판의 지원 여부를 확인해봐야한다.
4) 오프셋 관리 & 보존(retention)
파티션의 메시지는 오프셋으로 주소화되고 브로커 설정(기간/용량)에 따라 보존된다. 컨슈머는 자신이 처리한 마지막 오프셋을 기록(commit)해 다음에 그 위치부터 읽을 수 있다.
3. Producer
프로듀서는 토픽(또는 파티션)에 메시지를 쓰는 역할을 한다. 프로듀서가 메시지를 어느 파티션에 보낼지는 키 기반 파티셔닝, 라운드로빈, 또는 커스텀 파티셔너를 통해 결정된다.
1) 파티셔닝 방식
- 키가 있으면(keyed) : 키의 해시 → 특정 파티션 (같은 키는 항상 같은 파티션으로 가므로 파티션 내 순서 보장 가능)
- 키가 없으면 : 라운드로빈 등으로 분산
- 아예 특정 파티션으로 직접 지정할 수도 있다.
2) 신뢰성(acks)
- acks=0 : Producer는 ACK를 기다리지 않음 (최고 성능, 데이터 손실 가능)
- acks=1 : Leader가 쓰기 완료하면 ACK (리더가 죽으면 손실 가능)
- acks=all 또는 acks=-1 : ISR에 있는 팔로워들이 복제 완료한 뒤 ACK (가장 안전)
3) 성능 최적화
- 배치(batch) 처리, 압축(compression), linger.ms 설정으로 처리량 향상
- max.in.flight.requests 와 enable.idempotence 설정으로 재전송 시 중복 제어
4) 정확히 한 번(Exactly-once)
- enable.idempotence=true 로 중복 전송을 방지 가능. 트랜잭션 API (transactional.id)를 사용하면 프로듀서-컨슈머 간에 정확히 한 번(일부 조건하) 처리 보장을 제공할 수 있다.
4. Consumer
컨슈머는 토픽의 파티션에서 메시지를 읽어 처리한다. 컨슈머는 컨슈머 그룹(Consumer Group) 에 속하며, 같은 그룹의 각 컨슈머는 파티션의 리더로부터 메시지를 독점적으로 읽는다(즉, 동일 파티션을 같은 시점에 같은 그룹의 두 컨슈머가 동시에 처리하지 않음).
1) 컨슈머 그룹과 병렬성
컨슈머 그룹 내 컨슈머 수 ≤ 파티션 수 이면 각 컨슈머가 하나 이상의 파티션을 할당받아 병렬 처리. 컨슈머 수가 파티션 수보다 많으면 일부 컨슈머는 유휴 상태이다.
2) 오프셋 커밋
- 자동 커밋(auto.commit) : 주기적으로 오프셋을 브로커에 커밋 (간단하지만 실패 시 중복 처리 또는 누락 가능)
- 수동 커밋(manual commit) : 처리가 확실히 끝난 후에 커밋 (정확성 제어)
- 커밋 시점을 잘 설계해야 at-least-once 또는 at-most-once 보장 수준을 맞출 수 있다.
3) 처리 보장
- At-most-once : 읽기 전에 커밋 → 중복 없음, 데이터 손실 가능
- At-least-once : 처리 후 커밋 → 실패 시 중복 처리 가능
- Exactly-once : Kafka 트랜잭션/아이도포텐스 조합으로 일부 워크플로우에서 달성 가능
4) 리밸런스(Rebalance)
그룹 멤버 변경(추가/제거/장애) 시 파티션 재할당이 발생한다. 이 동안 처리 지연/중복이 발생할 수 있으므로 리밸런스 비용을 줄이기 위한 설정(세션 타임아웃, 스티키 어사인 등)과 처리 설계가 필요하다.
5) 오프셋 초기화(earliest/latest)
처음 구독 시 auto.offset.reset 옵션으로 earliest(초기부터) 또는 latest(최신부터) 선택 가능.
6) 모니터링 항목
- Consumer lag (프로듀서 쓰기 속도 대비 컨슈머 읽기 속도)
- 리밸런스 빈도
- 커밋 실패/에러
※ 추가 업데이트 및 검증 예정