개요

Kafka는 큐가 아니라 읽어도 사라지지 않는 로그다 — 소비자가 각자 책갈피를 들고 읽는다

온프렘 쿠버네티스에서 서비스를 구성하며 Kafka를 도입하는 환경을 전제로 한다. “메시지 보내는 법”이 아니라 도입하는 사람이 알아야 하는 것 — 왜 서비스 사이에 로그를 놓는지, 유실·중복·순서는 어떻게 다루는지, 온프렘 k8s 배포(Strimzi)와 운영 — 을 다룬다.

쿠버네티스 기초는 CKA 덱 수준을 전제하고, 여기서 다시 설명하지 않는다.

2026년 8월 기준으로 쓰였다 — Kafka 4.3 (KRaft 전용) · Strimzi 0.51 · Kubernetes 1.34.

첫 장부터 읽기

구성

1. 0~1장왜 Kafka인가

   범위 · 목적과 자리

   서비스끼리 직접 부르면 되는데 왜 가운데 로그를 놓는가

2. 2~3장핵심 모델

   토픽 · 파티션 · 오프셋 · 복제

   데이터는 어떤 모양으로 쌓이고, 브로커가 죽으면 어떻게 되는가

3. 4~6장읽고 쓰기

   프로듀서 · 컨슈머 · 전달 보장

   유실·중복·순서는 각각 어느 나사로 조이는가

4. 7~8장설계

   토픽 설계 · 생태계

   파티션 수·보존은 어떻게 정하고, Connect·스키마는 언제 얹는가

5. 9~11장온프렘 쿠버네티스

   배포(Strimzi) · 운영 · 트러블슈팅

   온프렘 k8s에서 Kafka 자체를 어떻게 돌리는가

6. 12~13장마무리

   용어 사전 · 마무리

전체를 관통하는 두 문장

읽어도 사라지지 않는다. Kafka의 데이터는 큐처럼 “꺼내면 없어지는” 것이 아니라 로그에 정해진 기간 동안 그대로 남고, 소비자마다 자기 위치(오프셋)를 따로 들고 읽는다. 다중 구독·재처리·장애 복구 — Kafka가 큐와 다르게 할 수 있는 일은 전부 이 성질에서 나온다 (2장).

순서·병렬성·확장의 단위는 파티션이다. 순서는 파티션 안에서만 보장되고, 컨슈머는 파티션 수까지만 병렬로 붙는다. 키를 무엇으로 잡을지(4장), 파티션을 몇 개로 할지(7장)가 설계의 절반인 이유다.

0. 시작하기 전에이 덱의 대상과 범위, 미리 잡아두면 좋은 멘탈 모델 세 가지.