Apache Kafka

Overview

Event를 Topic Partition에 Append하고 Consumer가 Offset을 기준으로 읽는 분산 Log다.

핵심 원리

순서는 Partition 안에서 보장되며 Consumer Group의 한 Partition은 한 Consumer가 담당한다.

flowchart LR; P[Producer] --> T{Topic}; T --> P0[Partition 0]; T --> P1[Partition 1]; P0 --> C1[Consumer A]; P1 --> C2[Consumer B]

Partition

Partition은 Topic을 나눈 병렬 처리 단위다. 같은 Partition 안에서는 append 순서가 유지되지만, Topic 전체의 전역 순서는 기본적으로 보장되지 않는다.

Key를 기준으로 Partition을 고르면 같은 Key의 Event를 같은 Partition에 모아 순서를 지킬 수 있다. 대신 특정 Key가 몰리면 hot partition이 생겨 병렬성이 떨어질 수 있다.

Partition 수는 처리량의 상한, Consumer 확장 폭, 순서 보장 범위를 함께 결정한다. 너무 적으면 병렬성이 부족하고, 너무 많으면 Rebalance 비용과 운영 복잡도가 올라간다.

Broker와 Cluster

Broker는 Partition의 데이터를 저장하고 읽는 Kafka Server다. Kafka Cluster는 여러 Broker가 모여 Partition과 Replica를 분산 보관하는 구조다.

Cluster는 단순히 Broker를 여러 대 두는 것이 아니라, 리더와 팔로워 Replica를 나누고 장애 시 다른 Replica가 역할을 이어받도록 설계한다. 이 때문에 Disk 여유, 네트워크 대역폭, Replica 배치 전략이 함께 중요하다.

ISR과 Replication

각 Partition은 여러 Replica를 둘 수 있고, 그중 실제 쓰기와 읽기를 책임지는 Replica가 Leader다. Leader를 따라잡은 Replica 집합을 ISR(In-Sync Replicas)이라고 한다.

ISR이 충분히 유지되면 장애가 나도 Leader를 빠르게 교체할 수 있다. 반대로 Replica 지연이 커져 ISR에서 빠지면 내구성과 가용성의 균형이 흔들린다. 그래서 Under-Replicated Partition과 ISR shrink를 운영 지표로 본다.

Consumer Group

Consumer Group은 같은 Topic을 여러 Consumer가 나눠 읽기 위한 협업 단위다. Group 안에서는 Partition 하나가 같은 시점에 하나의 Consumer에만 할당되므로, 병렬성은 Partition 수와 Consumer 수의 관계에 의해 결정된다.

Consumer Group의 장점은 확장성과 독립성이다. 같은 Topic을 여러 Group이 각각 다른 목적, 예를 들어 주문 처리, 검색 인덱싱, 감사 로그 적재처럼 독립적으로 소비할 수 있다.

Offset Commit

Offset은 Consumer가 어디까지 읽었는지 나타내는 위치 값이다. Commit은 이 위치를 저장해서 재시작 후 이어 읽을 수 있게 한다.

Auto commit은 단순하지만 처리 완료 전에 Offset이 앞서 기록될 수 있어 유실 위험이 있다. 수동 commit은 처리 성공 이후에 Commit할 수 있어 더 안전하지만, 중복 처리 가능성을 대비한 멱등성이 필요하다.

중요한 기준은 “읽음”과 “완료”를 분리하는 것이다. DB 반영이 끝난 뒤 Commit해야 장애 복구 시 재처리가 가능하고, Commit 전에 장애가 나면 같은 메시지를 다시 보게 될 수 있다.

Consumer Lag

Consumer Lag은 Producer가 기록한 최신 Offset과 Consumer가 Commit한 Offset의 차이다. Lag이 커지면 Consumer가 따라가지 못하고 있다는 뜻이다.

Lag은 단순히 “느리다”가 아니라, 처리량 부족, 외부 시스템 지연, Rebalance 반복, Partition 편중, GC, 장애 복구 같은 원인을 드러내는 신호다. 따라서 Lag 자체보다 추세와 원인을 같이 본다.

Retry와 재처리

Kafka에서는 Retry가 자동으로 안전성을 보장하지 않는다. 실패한 메시지를 즉시 같은 흐름에서 다시 처리하면 중복과 폭주가 커질 수 있다.

짧은 지연 재시도는 일시적 네트워크 오류나 다운스트림 일시 실패에 유용하지만, 반복 실패 메시지는 별도 Retry Topic이나 DLQ로 분리하는 편이 낫다. 재시도 정책은 지수 백오프, 최대 시도 횟수, Poison Message 격리를 함께 설계해야 한다.

Consumer 재시도는 Offset Commit과 분리해서 생각해야 한다. 처리 실패 시 Commit하지 않으면 재처리되지만, 같은 메시지를 여러 번 볼 수 있으므로 Event ID 기반 멱등성이나 Unique Constraint가 필요하다.

실무에서 발생하는 문제

Partition 편중, Consumer Lag, 잦은 Rebalance, 잘못된 Retry로 처리 지연과 중복이 발생한다. 메시지 크기와 보존 기간은 Broker Disk와 Network 비용에도 직접 영향을 준다.

Trade-off

Partition은 병렬성과 순서 범위를 결정한다. 수를 늘리면 처리량을 키울 수 있지만 운영 비용과 순서·재분배 복잡성이 증가한다.

흔한 오해

Kafka의 내구성이 업무의 exactly-once를 자동 보장하지 않는다. Producer의 DB 변경과 발행 사이 Dual Write는 Transactional Outbox로 줄이고, Consumer의 외부 DB 변경과 재전달은 멱등성·중복·순서의 Inbox·Unique Constraint로 보호한다.

또한 Broker Cluster가 있다는 사실만으로 데이터가 자동으로 안전해지는 것은 아니다. Replica 수, ISR 유지, Commit 전략, Retry 정책, Lag 감시가 함께 맞물려야 운영 가능한 시스템이 된다.

Interview Questions

• 이 기술이 해결하는 핵심 문제는 무엇인가?
• 내부에서는 어떤 순서로 동작하는가?
• 운영 환경에서 어떤 지표와 실패 모드를 확인해야 하는가?

왜 필요한가

생산자와 소비자를 시간적으로 분리하고 Event를 보존해 여러 Consumer Group이 각자의 속도로 재생할 수 있게 한다. 높은 처리량과 Partition 단위 순서가 필요한 Stream에 적합하다.

내부 동작

Producer는 Key를 기준으로 Partition을 선택하고 Leader Broker에 Batch 전송한다. Consumer Group에서는 한 Partition을 같은 시점에 한 Consumer가 처리하며 Coordinator가 Assignment를 관리한다. Offset은 “어디까지 처리했다고 간주하는가”를 기록한다.

Example

주문 ID를 Key로 사용하면 같은 주문 Event가 같은 Partition에 배치되어 순서를 유지할 수 있다. Consumer는 DB 반영 성공 후 Offset을 Commit하고, 재처리돼도 결과가 같도록 Event ID Unique 제약을 둔다.

Production Considerations

Produce/Fetch Latency, Under-replicated Partition, ISR, Disk, Consumer Lag, Rebalance 시간을 본다. Retention과 Partition 수, Replication Factor, acks, Retry를 업무 RPO와 처리량에 맞추고 장애 복구 시 재처리량을 시험한다.

실무에서는 다음 질문에 답할 수 있어야 한다.

• Partition 수가 현재 트래픽과 2배 성장에도 충분한가?
• ISR이 줄어들 때 알림이 울리는가?
• Offset Commit은 성공 이후에만 일어나는가?
• Lag이 커졌을 때 원인이 처리량 부족인지, Rebalance인지, 다운스트림 실패인지 구분되는가?
• Retry가 무한 증폭되지 않도록 DLQ나 별도 Retry 흐름이 있는가?

Related Topics

비동기 처리 설계, ActiveMQ와 JMS, Message Broker 비교, AWS RDS·MSK와 선택 기준을 비교한다.