대규모 Kafka 수집 및 처리 | Rajamohan Jabbala

Source: Dev.to

대부분의 Kafka 장애는 Kafka가 확장되지 못해서가 아니라, 팀이 수치를 계산하지 않았기 때문에 발생합니다.

“좋은” 상태는 어떤 모습인가 (SLO 먼저)

운영 중인 Kafka 파이프라인은 다음을 만족해야 합니다:

• 토픽당 N msgs/sec 를 낮은 지연 시간으로 처리
• 파티션, 컨슈머, 브로커를 통해 선형적으로 확장
• 최소 1 회(at‑least‑once) 혹은 정확히 1 회(exactly‑once) 전송 보장
• 컨슈머 그룹을 통한 fan‑out 지원
• 명확한 지연, 처리량, 내구성 SLO 내 유지

예시 SLO

• 프로듀스 지연 p99 ≤ X ms
• 컨슈머 지연 ≤ Y sec (안정 상태)
• 2배 스파이크 발생 후 복구 ≤ Z min
• 가용성 ≥ 99.9 %

이러한 기준을 정의하지 않으면 Kafka 튜닝은 미신이 됩니다.

Kafka 메커니즘 (실제로 중요한 부분)

• 토픽은 파티션을 통해 확장됩니다.
• 하나의 파티션 → 하나의 컨슈머(그룹당)
• 여러 컨슈머 그룹 = 독립적인 재읽기(fan‑out)

규칙:
하나의 그룹에서 유용한 최대 컨슈머 수 = 파티션 수.
파티션보다 많은 컨슈머를 추가해도 처리량이 늘어나지 않습니다.

논리 아키텍처

Producers → orders topic (P partitions, RF=3)

Kafka cluster distributes:
  • One leader per partition
  • Replicas across brokers

Downstream consumer groups:
  • Fraud consumer group
  • Analytics consumer group
  • ML feature consumer group

Each group owns its own offsets and scales independently.

용량 계획 (절대 빼먹으면 안 되는 단계)

입력값

핵심 공식

• 파티션 수: P = ceil((T / C) × H)
• 인그레스: Ingress = T × S × R
• 이그레스 (그룹당): Egress = T × S
• 일일 저장량 (리더 기준): T × S × 86,400
  전체 저장량은 R과 보관 일수를 곱해 계산합니다.

예시 (1 M msgs/sec)

결과

• 파티션 수: 60
• 인그레스: 약 572 MB/sec
• 그룹당 이그레스: 약 191 MB/sec
• 3일 보관 (복제 포함) 저장량: 약 155 TB

이것이 “브로커만 추가하면 된다”는 전략이 통하지 않는 이유입니다.

뒤통수 치지 않는 파티셔닝

• order_id처럼 고유도가 높은 키 사용, country처럼 낮은 키는 피함.
• 스키를 적극적으로 모니터링.
• 나중에 재샤딩 비용을 줄이기 위해 초기 단계에서 약간 과도하게 파티션을 늘림.

컨슈머 그룹 확장

• 컨슈머 수를 파티션 수(P)까지 확장.
• 파이프라인마다 별도 그룹 사용.
• 지연이 증가할 때 자동 확장, 절대 지연값에 기반하지 않음.

신뢰성 기본 설정

acks=all
min.insync.replicas=2   # RF=3일 때
enable.idempotence=true
unclean.leader.election.enable=false
# Rack/AZ‑aware replica placement

• 비즈니스 로직이 정확히 한 번 전송을 요구하는 경우에만 exactly‑once semantics 적용.

관측 > 튜닝

관찰할 항목

• 파티션별 지연 증가
• p95/p99 프로듀스·컨슈머 지연
• 복제 부족 파티션
• 디스크, NIC, 컨트롤러 상태

확장 시점

• 컨슈머 → 지연이 상승할 때
• 파티션 → 컨슈머가 포화될 때
• 브로커 → 디스크·NIC 부하가 증가할 때

최종 정리

Kafka가 확장되지 않는 이유는 Kafka 자체가 그렇기 때문이 아니라, 설계가 부족하기 때문입니다.

• 수학이 희망을 이긴다.
• 측정이 신화를 이긴다.