Kafka에 대해 간략하게 알아보기

 

Kafka의 탄생 배경

Apache Kafka는 2011년 LinkedIn에서 대규모 실시간 데이터 파이프라인 문제를 해결하기 위해 개발되었습니다. 당시 LinkedIn은 수억 명의 사용자 활동 데이터를 다루면서 여러 가지 문제에 직면했습니다.

1. 데이터 규모의 폭발적 증가
   사용자 클릭, 페이지 조회, 추천 시스템 로그, 광고 트래킹 데이터 등이 초당 수십만 건 이상 발생하였고, 이를 기존 메시지 큐나 데이터 처리 시스템으로는 감당하기 어려웠습니다.
2. 다양한 소비자 시스템 요구
   같은 데이터를 실시간 분석 시스템, 배치 처리 시스템, 모니터링 시스템, 추천 엔진 등 여러 서비스에서 동시에 필요로 했습니다. 즉, 하나의 데이터 소스를 다양한 소비자가 독립적으로 안정적으로 처리할 수 있는 구조가 필요했습니다.
3. 기존 시스템의 한계
   당시 사용되던 JMS(Java Message Service) 기반 메시지 큐나 ActiveMQ, RabbitMQ 같은 솔루션은 대량 데이터를 안정적으로 처리하기에는 성능과 확장성이 부족했습니다.
   특히 메시지를 처리한 뒤 삭제하는 방식 때문에, 재처리(replay) 또는 여러 소비자 그룹에 동일 데이터 제공이 쉽지 않았습니다.

이러한 배경에서, LinkedIn은 고성능·확장성·내구성·다중 소비자 지원을 모두 충족하는 새로운 분산 메시징 시스템을 설계했고, 그것이 바로 Apache Kafka입니다. 이후 오픈소스로 공개되어 널리 확산되었습니다.

 

Apache Kafka 통신 방식

 

1. 기본 구조

Kafka는 대규모 데이터 스트리밍 플랫폼으로, 메시지 기반의 분산형 로그 시스템입니다. 핵심 구성 요소는 Producer, Broker(Cluster), Consumer, 그리고 Topic입니다.

• Producer: 데이터를 Kafka로 전송하는 주체
• Broker: 메시지를 저장하고 분산 관리하는 Kafka 서버
• Consumer: 메시지를 구독하고 처리하는 주체
• Topic: 메시지가 저장되는 논리적 공간으로, 데이터 스트림을 구분하는 단위

Kafka는 단순히 메시지를 큐잉하는 것이 아니라, 분산 로그(commit log) 방식으로 메시지를 영구 저장하며 확장성과 내결함성을 제공합니다.

 

 

 

통신 프로토콜

Kafka의 통신은 기본적으로 TCP 기반 바이너리 프로토콜로 동작합니다.
이 프로토콜은 효율적인 **배치 전송(batch transmission)**과 **압축(compression)**을 지원하여 대용량 스트리밍 처리에 최적화되어 있습니다.

• TCP: 안정적인 연결 및 전송 보장
• Request-Response 패턴: Producer와 Consumer는 Broker에 요청을 보내고, Broker가 응답을 반환
• 압축: GZIP, Snappy, LZ4, Zstd 등을 지원하여 네트워크와 저장 효율성 향상

메시지 전송 흐름

1. Producer → Broker
   • Producer는 특정 Topic의 Partition에 메시지를 전송
   • Partition 선택 전략은 Round Robin, Key 기반 해시, 또는 사용자 지정 방식
   • 전송된 메시지는 Leader Replica에 먼저 기록된 후, Follower Replica에 복제되어 고가용성을 보장
2. Broker 내부 처리
   • 메시지는 디스크에 순차적으로 Append 되며, 높은 처리량을 유지
   • 복제(replication)를 통해 장애 발생 시 데이터 유실 방지
   • ISR(In-Sync Replica) 메커니즘으로 Leader와 Follower의 데이터 동기화 상태 관리
3. Consumer ← Broker
   • Consumer는 Consumer Group 단위로 메시지를 가져옴
   • 각 Partition은 Consumer Group 내에서 단 하나의 Consumer에게만 할당되어 병렬성과 부하 분산 확보
   • 메시지 오프셋(offset)을 관리하여, Consumer가 어디까지 읽었는지 추적 가능

 

통신 보장 방식

Kafka는 전송 안정성과 처리 보장을 위해 다양한 수준의 ACK 설정과 전달 보장 모델을 제공합니다.

• ACKs 옵션
  • acks=0: Broker 응답을 기다리지 않음 (가장 빠르지만 데이터 유실 위험)
  • acks=1: Leader Replica에 기록되면 성공 응답
  • acks=all: 모든 ISR에 복제 완료 시 응답 (가장 안전)
• 메시지 전달 보장
  • At most once: 메시지가 손실될 수 있지만 중복 없음
  • At least once: 손실 없이 전달되지만 중복 가능
  • Exactly once: 손실과 중복 모두 방지 (트랜잭션 기능 활용)

 

토픽과 파티션의 상관관계

 

Kafka에서 메시지는 기본적으로 토픽 단위로 그룹화됩니다. 하지만 실제로 데이터의 분산 처리와 성능을 결정짓는 핵심 요소는 **파티션(partition)**입니다. 파티션 개수는 곧 시스템의 처리량, 확장성, 안정성에 직접적인 영향을 주기 때문에 토픽 생성 시 신중하게 결정해야 합니다.

토픽을 설계할 때 고려해야 할 주요 포인트는 크게 세 가지입니다.

---

1. 데이터 처리량 고려

Kafka의 파티션은 컨슈머와 1:1 매핑됩니다.
즉, 파티션 하나에는 컨슈머 그룹 내의 단일 컨슈머만 연결될 수 있습니다.

• 파티션을 늘리면 컨슈머 수도 함께 늘어날 수 있어 병렬 처리 성능이 향상됩니다.
• 반대로 파티션이 적으면 컨슈머가 아무리 많아도 실제 데이터 처리는 병목이 생길 수 있습니다.

예시:

• 프로듀서가 초당 100개의 메시지를 발행
• 컨슈머 1대가 초당 40개 처리 가능
  → 안정적으로 운영하려면 최소 3대 이상의 컨슈머가 필요

일반적으로 컨슈머 전체 처리량 ≥ 프로듀서 발행량을 권장하지만, 반드시 절대적인 규칙은 아닙니다. 운영 환경에 맞게 성능 테스트를 거쳐 조정하면 됩니다.

 

2. 메시지 키와 순서 보장

Kafka는 메시지 키를 기준으로 파티션을 결정합니다.

• 키를 사용하지 않는 경우: 메시지는 라운드 로빈 등으로 분산 → 순서 보장 없음
• 키를 사용하는 경우: 동일한 키는 항상 같은 파티션에 기록 → 해당 파티션 내에서는 순서가 보장됨

따라서 메시지 순서가 중요한 경우:

• 메시지 키를 활용해야 하며,
• 파티션 개수를 임의로 변경하면 기존 순서가 깨질 수 있습니다.

이 문제를 피하려면:

• 커스텀 파티셔너를 개발해 제어하거나,
• 아예 설계 단계에서 순서에 의존하지 않는 데이터 처리 모델을 만드는 것이 이상적입니다.

 

3. 브로커와 시스템 리소스 영향

파티션은 결국 브로커 서버의 파일 시스템에서 관리됩니다. 따라서 파티션 수가 늘어나면 브로커가 처리해야 할 파일 핸들 수와 관리 비용도 증가합니다.

• 운영체제는 프로세스 당 열 수 있는 파일 개수에 제한이 있습니다.
• 브로커 하나가 관리하는 파티션이 과도하게 많아지면 성능 저하나 운영 안정성 문제가 발생할 수 있습니다.

이 경우 단순히 파티션을 늘리기보다, 브로커 자체를 증설(스케일 아웃) 하는 것도 좋은 대안입니다