Kafka — 생산·소비·랙의 발생과 해소

파티션 3개짜리 토픽에 키 있는 이벤트를 흘려, 오프셋이 움직이고 랙이 쌓였다가 소비자 증설(리밸런스)로 해소되는 전 과정을 실행한다.

1 / 8Kafka는 우체통이 아니라 장부입니다 — 토픽은 파티션 3개로 나뉜 추가 전용 로그이고, 메시지는 읽혀도 지워지지 않습니다. 소비자는 '어디까지 읽었는지'(오프셋)만 옮깁니다.

파티션 0

파티션 1

파티션 2

소비자 1명 · 랙 0 · 흐린 칸 = 읽음(오프셋 통과), 진한 칸 = 밀림

단계 목록 · 키보드 ←/→ 이동, Space 재생

Kafka는 메시지를 배달하고 지우는 우체통이 아니라 추가 전용 장부다 — 메시지는 남고 소비자의 '어디까지 읽었나'(오프셋)만 움직이며, 랙은 그 거리다.

왜 헷갈리는가

큐(RabbitMQ류)의 감각으로 Kafka를 보면 전부 이상하다 — 읽어도 안 지워지고, 소비자를 늘려도 어느 선에서 더 안 빨라지고, '랙 경보'가 무슨 뜻인지 모호하다. 열쇠는 로그·파티션·오프셋 세 단어다.

애니메이션이 보여주는 것

생산자는 키(사용자 ID)로 파티션을 정한다 — 같은 키는 항상 같은 파티션이라, 사용자 A의 주문 순서는 절대 섞이지 않는다(전역 순서는 없다 — 파티션 안에서만 순서가 있다).

생산 3/틱 vs 소비 2/틱이면 차이가 랙으로 쌓인다. 랙은 장애가 아니라 계기판이다 — '소비가 얼마나 밀렸나'. 소비자를 3명으로 늘리면 리밸런스가 파티션을 1개씩 재배정하고 랙이 빠진다. 여기서 상한이 드러난다: 파티션이 분배 단위라서 소비자는 파티션 수까지만 의미가 있다.

운영 감각

랙 그래프 앞에서 내리는 판단들.

랙이 계단으로 늘기만 함: 소비 처리량 부족 — 소비자 증설(≤ 파티션 수), 또는 소비 로직의 병목(DB 쓰기 등)부터 해소.
소비자 = 파티션 수인데도 밀림: 파티션 증설이 필요하다. 단, 파티션을 늘리면 키→파티션 매핑이 바뀌어 그 경계에서 키 순서가 끊긴다 — 처음부터 여유 있게 잡는 이유.
랙이 톱니로 오르내림: 정상(버스트 흡수 중). Kafka의 존재 이유가 바로 이 완충이다.
리밸런스 폭풍: 소비자가 들락거릴 때마다 그룹 전체가 멈칫한다 — 배포 시 randomized 재시작, cooperative rebalancing으로 완화.
로그는 지워지지 않으므로(보존 기간까지) 다른 그룹이 같은 토픽을 처음부터 읽을 수 있다 — 분석·감사·재처리가 공짜 기능이 되는 이유.

기억할 것

Kafka = 추가 전용 로그. 소비는 삭제가 아니라 오프셋 이동이다.
순서는 파티션 안에서만 — 순서가 필요한 단위를 키로 잡아라.
랙 = 생산-소비의 거리. 경보의 대상은 '증가 추세'다.
소비 병렬성의 상한 = 파티션 수. 파티션 증설은 키 순서 경계를 만든다.
재소비·다중 구독이 공짜 — 로그라는 자료구조의 선물이다.