#Kafka

#1. 핵심 개념

#1.1 구성 요소

#1.2 데이터 흐름

1. Producer는 데이터를 생성하여 카프카 토픽으로 메시지를 발행(Publish)한다.
   • 전송 시 특정 키를 지정하거나, 키가 없으면 파티셔너가 파티션을 결정한다.
   • Kafka 2.4 이상에서는 기본적으로 Sticky Partitioner가 사용되어 배치 효율을 높인다.
2. Broker는 카프카 클러스터의 핵심 서버로, Producer로부터 받은 데이터를 저장하고 Consumer의 요청에 따라 데이터를 전달한다.
3. Partition은 Topic을 논리적으로 나눈 단위다.
   • 각 파티션은 Append-only 로그 형식으로 데이터를 저장하며, 파티션 내에서는 순서가 보장된다.
   • 단, 파티션 간 전역 순서는 보장되지 않는다.
4. Partition을 여러 개 두면 병렬 처리가 가능해져 처리량이 대폭 향상된다.
   • 각 Partition은 클러스터 내 다른 Broker로 복제되어 고가용성을 보장한다.
5. Consumer는 Broker로부터 데이터를 읽어(pull) 처리한다.
6. 같은 Consumer 그룹 내의 Consumer들은 파티션을 나누어 가져 대규모 데이터를 효율적으로 분산 처리한다.

#1.3 활용 사례

• 로그 통합 및 분석
• 실시간 스트림 처리
• 이벤트 기반 아키텍처 (서비스 간 비동기 통신 및 결합도 완화)
• 데이터 파이프라인 구축 (시스템 간 안정적인 고성능 데이터 전송)

#2. 운영 / 트러블슈팅

#2.1 클러스터 복제 / 백업

• 재해복구나 해외 사용자들의 응답속도를 높이기 위해 복제하는 경우가 있다.
• 클러스터 간 복제(MirrorMaker 등)에서 파티션 내부 순서는 보존되지만, 파티션 간 전역 순서는 보장되지 않는다.
• 미러링 과정에서 발생하는 지연 시간인 Replication Latency도 체크가 필요하다.

Replication Latency 대응

• 지연이 길어질 경우 장애 상황일 수 있으니 우선 대역폭 확대를 검토한다.
• 처리량(throughput) 관점: fetch.min.bytes를 키워 한 번에 더 많은 데이터를 가져오면 밀린 데이터를 빠르게 비울 수 있다.
  • 다만 이 값을 키우면 브로커가 데이터가 쌓일 때까지 기다리므로 개별 메시지의 지연(latency)은 오히려 늘어난다.
  • 즉 처리량과 지연은 트레이드오프 관계이며, 지연 자체를 줄이려면 이 값을 낮춰야 한다.
• compression.type도 설정해 볼 수 있다. CPU 사용량은 늘어나지만 네트워크 부하를 줄여 Latency 개선에 도움을 준다.

#2.2 파티셔닝과 키 설계

Data Skew (데이터 쏠림)

• 특정 파티션에 데이터가 몰릴 경우 병목 현상이 발생하는데, 이를 data skew라고 한다.
• 실무에서는 키를 잘 설계하거나 파티셔닝 전략을 적절히 조정해야 한다.

키가 분산되는 원리

• 키에 일정한 해시 연산(예: murmur2 해시 % 파티션 수)을 거쳐 랜덤해 보이는 숫자로 변환한 뒤 골고루 뿌려진다.
• 연산을 했음에도 특정 파티션에만 몰린다면 문제가 되므로, 모니터링 지표를 통해 delay를 감시해야 한다.
• delay는 처리 속도가 유입 속도를 못 따라갈 때 발생한다.

핫 파티션(Hot Partition) 해결

• 주문 ID 외에 타임스탬프를 섞거나 랜덤한 prefix를 붙여 key를 재구성한다. → 솔팅(Salting) 기법
• 다만 이때 데이터의 처리 순서 보장이 어려워질 수 있다.
  • 이럴 때 Consumer에서 메모리 버퍼를 써서 다시 줄을 세워야 하며, OOM 이슈가 발생할 위험이 있다.

키가 없으면?

• 데이터는 균형적으로 퍼지지만, 같은 주문의 생성-결제-배송 순서가 뒤섞여 사고가 생길 수 있다.

파티션을 갑자기 늘리면?

• 키의 해시 분모(파티션 수)가 바뀌므로 같은 키가 이전과 다른 파티션으로 라우팅된다.
• 이미 저장된 데이터가 이동하는 것은 아니지만, 한 키의 메시지가 여러 파티션에 흩어져 순서가 꼬인다.
• 따라서 실무에서는 처음부터 파티션을 넉넉히(보통 예상치의 2~3배) 잡거나, 아예 새로운 토픽으로 데이터를 마이그레이션하기도 한다.

#2.3 Consumer와 리밸런싱

Consumer 수와 파티션 수

• 파티션마다 컨슈머를 1:1로 붙이는 것이 리소스 효율 면에서 가장 깔끔하다.
• 컨슈머 수가 파티션 수보다 많으면 남는 컨슈머는 놀게 된다.

리밸런싱 다운타임 줄이기

• 리밸런싱 중엔 일시적으로 처리가 멈출 수 있다.
• session.timeout.ms나 heartbeat 주기를 조절해 장애 감지를 빠르게 하고, max.poll.interval.ms도 중요하다.
• 다만 session.timeout.ms를 너무 짧게 잡으면 일시적인 GC·네트워크 지연에도 불필요한 리밸런싱(false rebalance)이 발생해 오히려 다운타임이 늘 수 있으니 균형이 필요하다.
• 최신 버전의 **협력적 리밸런싱(Cooperative Rebalancing)**을 쓰면 멈춤을 줄일 수 있다.

{
  "session.timeout.ms": 10000,
  "heartbeat.interval.ms": 3000,
  "max.poll.interval.ms": 300000
}

#3. 모니터링

#3.1 모니터링 도구

Prometheus & Grafana 동작 방식 Prometheus는 Kafka 브로커나 JMX Exporter로부터 메트릭을 주기적으로 Pull 방식으로 수집하고 시계열 데이터베이스(TSDB)에 저장한다. Grafana는 Prometheus를 데이터 소스로 연결하여, 저장된 데이터를 쿼리(PromQL)로 불러와 그래프·차트 형태의 대시보드로 시각화한다. 즉, Prometheus는 데이터의 수집과 보관을, Grafana는 데이터의 표현과 분석 인터페이스를 담당한다.

#3.2 반드시 체크해야 할 핵심 지표

#4. 용어

• 라운드 로빈(Round Robin, RR): 자원 분배나 작업을 공평하게 나누기 위해 '순서대로 돌아가며 일정 시간씩 할당하는 방식'