Kafka 글을 여러 편 정리하다 보니 "기본 개념을 한 번 모아서 짚는 문서"가 빠져 있었다. 이 글은 토픽·파티션·오프셋·복제(Leader/Follower/ISR)에 한해서 입문 수준으로만 정리한다. 파티션 키 전략, 컨슈머 그룹 리밸런싱, 메시지 전달 보장(at-least-once 등) 같은 운영·설계 영역은 별도 문서에서 다룬다. - 파티션 수 결정...
Kafka 글을 여러 편 정리하다 보니 "기본 개념을 한 번 모아서 짚는 문서"가 빠져 있었다. 이 글은 토픽·파티션·오프셋·복제(Leader/Follower/ISR)에 한해서 입문 수준으로만 정리한다. 파티션 키 전략, 컨슈머 그룹 리밸런싱, 메시지 전달 보장(at-least-once 등) 같은 운영·설계 영역은 별도 문서에서 다룬다.
min.insync.replicas 등 정합성 옵션 → Kafka 데이터 정합성 설계파티션 단위로 분산된 append-only 커밋 로그를 여러 브로커에 복제해두고, 발행자(Producer)와 구독자(Consumer)가 같은 로그를 다른 속도로 읽고 쓸 수 있게 해주는 분산 시스템.
이 한 줄에 등장하는 단어들이 곧 Kafka 의 기본 개념이다. 하나씩 풀어 본다.
토픽은 메시지가 담기는 논리적 카테고리 다. RDBMS 의 테이블과 비교하면 가장 가깝다 — 다만 Kafka 토픽은 항상 다음 두 가지 성질을 갖는다.
토픽은 그 자체로 데이터를 저장하지 않는다. 실제 저장은 토픽을 구성하는 파티션 들에서 일어난다.
파티션은 한 토픽을 분할한 하나의 append-only 로그다. 토픽이 8개 파티션으로 구성되어 있다면, 그 토픽으로 발행된 메시지는 어떤 규칙에 따라 8개 로그 중 하나에 들어간다.
파티션을 둔 이유는 두 가지다.
여기서 입문자가 가장 자주 헷갈리는 사실 하나가 결정된다.
순서 보장은 토픽 단위가 아니라 파티션 단위로만 일어난다.
같은 키를 가진 메시지가 같은 파티션에 들어가도록 발행 측에서 보장하지 않으면, "주문 생성 → 결제 → 배송" 이벤트가 서로 다른 파티션에 흩어져 컨슈머가 받는 순서가 뒤집힐 수 있다. 파티션 키 설계는 그래서 입문 단계가 아니라 실전 설계의 핵심 주제로 따로 다룬다 (파티션 키 전략).
파티션은 디스크 위에서 하나의 거대한 파일이 아니다. 세그먼트 라고 부르는 일정 크기의 파일들로 나뉘어 저장된다. 새 메시지는 항상 가장 최근 세그먼트(active segment) 의 끝에 추가되고, 일정 크기·일정 시간이 지나면 새 세그먼트가 만들어진다.
세그먼트로 쪼개 두는 이유는 삭제와 인덱싱이 단순해지기 때문이다. retention 정책에 따라 오래된 메시지를 지울 때 한 메시지씩 삭제하지 않고 통째로 오래된 세그먼트 파일을 unlink 하면 끝이다. 이건 Kafka 가 임의 삭제 / 임의 수정을 지원하지 않는 대신 얻는 단순함이고, append-only 가정이 가능하게 해주는 구조적 근거이기도 하다.
오프셋은 한 파티션 안에서 메시지의 위치를 가리키는 정수다. 파티션 0 의 첫 메시지가 0, 그다음이 1, 그다음이 2 ... 이런 식으로 단조 증가한다. 오프셋은 파티션 내부에서만 의미가 있다 — 파티션 0 의 오프셋 100 과 파티션 1 의 오프셋 100 은 완전히 다른 메시지다.
Kafka 가 다른 메시지 큐와 가장 다른 점이 여기서 드러난다.
브로커는 컨슈머가 어디까지 읽었는지 추적하지 않는다. 컨슈머가 자기 오프셋을 직접 관리한다.
전통적인 큐(예: 일부 RabbitMQ 패턴)는 브로커가 "이 메시지는 컨슈머 A 가 읽었음" 같은 상태를 들고 있다. Kafka 는 그렇지 않다. 컨슈머는 자기가 어디까지 처리했는지 오프셋으로 기록하고, 이 오프셋을 __consumer_offsets 라는 내부 토픽에 커밋한다. 그래서 같은 토픽을 컨슈머 그룹 A 와 B 가 각자 다른 속도로 읽는 게 자연스럽고, 컨슈머가 죽었다 살아나면 마지막 커밋된 오프셋부터 다시 읽으면 된다.
오프셋 커밋 전략(자동 커밋 vs 수동 커밋, 처리 전 커밋 vs 처리 후 커밋) 은 메시지 전달 보장과 직결된다. 이건 Kafka 실전 설계 — 오프셋 커밋 전략에서 자세히 다룬다.
브로커는 Kafka 프로세스를 띄운 한 대의 서버다. 여러 브로커가 모여 클러스터를 이루고, 토픽의 파티션들은 클러스터 내 브로커에 분산되어 저장된다.
브로커가 보통 3대 이상으로 구성되는 이유는 단순하다 — 복제본 3개를 두면 1대가 죽어도 다수결(과반) 을 유지할 수 있고, 컨트롤러 선출이나 ISR 유지에서 분리 뇌 (split-brain) 가 일어날 가능성이 줄어들기 때문이다. 이 부분은 Kafka 실전 설계 — 왜 브로커는 보통 3대인가에 더 짧게 정리되어 있다.
여기서부터가 입문에서 가장 중요한 부분이다. 파티션은 가용성을 위해 여러 복제본(replica) 을 가진다.
토픽을 만들 때 정하는 옵션 중 하나가 replication.factor 다. 값이 3이면 그 토픽의 모든 파티션은 클러스터 안에 3개의 복제본 을 갖는다는 뜻이다. 이 3개는 가능한 한 서로 다른 브로커에 배치된다 (한 브로커에 같은 파티션의 두 복제본이 들어가면 그 브로커가 죽었을 때 가용성이 깨지므로).
즉 replication factor = 리더 1 + 팔로워 N - 1. 총 복제본 수다.
같은 파티션의 N 개 복제본 중 정확히 하나가 리더(leader) 가 된다. 나머지는 팔로워(follower) 다. 둘의 역할은 분명히 다르다.
리더 하나에 모든 트래픽이 몰린다는 사실은 처음 들으면 어색하지만 — 파티션이 충분히 많으면 리더들이 클러스터 전체에 고르게 분산되므로 결과적으로 트래픽도 분산된다.
리더와 팔로워가 있다고 해도, 모든 팔로워가 항상 리더와 같은 위치까지 따라잡고 있는 건 아니다. 어떤 팔로워는 GC 잠깐, 디스크 잠깐, 네트워크 잠깐 늦으면서 뒤처질 수 있다.
Kafka 는 이걸 다루기 위해 ISR(In-Sync Replicas) 이라는 개념을 둔다.
ISR = 현재 리더의 로그를 충분히 따라잡고 있는 복제본들의 집합. 리더 자기 자신도 ISR 의 멤버다.
"충분히 따라잡고 있다" 의 기준은 replica.lag.time.max.ms (기본 30초) 다. 한 팔로워가 이 시간 안에 리더에게 fetch 요청을 보내고 리더의 가장 최근 메시지까지 가져왔다면 ISR 에 포함되고, 이 시간을 넘기면 ISR 에서 제거된다.
이 값이 가지는 트레이드오프가 운영에서 가장 자주 부딪히는 지점이다.
기본값 30초는 대부분의 운영 환경에서 적절히 보수적인 값이라 그대로 두는 경우가 많다.
ISR 이 왜 중요한가는 "커밋된 메시지" 의 정의에서 드러난다. Confluent 공식 문서의 표현을 그대로 빌리면:
"a committed message means that all in-sync replicas for a partition have applied the message"
즉 메시지가 커밋되었다 = ISR 의 모든 복제본이 그 메시지를 적용했다. 컨슈머는 커밋된 메시지만 읽을 수 있다 (high watermark 이후만 노출). 이건 컨슈머 입장에서 "한 번 보였던 메시지가 리더 장애로 사라지는 일은 없다" 는 보장의 근거가 된다.
리더 브로커가 죽으면 컨트롤러는 ISR 에 남아 있는 복제본 중 하나 를 새 리더로 선출한다. 핵심은 "ISR 에 남아 있는" 이다. ISR 에서 빠진 팔로워는 데이터가 뒤처져 있을 수 있으므로 정상 모드에서는 후보가 되지 않는다.
이 정책에 따라오는 트레이드오프가 두 가지 있다.
unclean.leader.election.enable=true 를 켜고 ISR 외부 복제본도 리더로 승격시킨다(availability 우선, 데이터 유실 가능). 기본값이 (a) 인 이유는 명확하다 — 메시지 큐로 쓰이는 시스템에서 침묵의 데이터 유실은 디버깅이 거의 불가능하기 때문이다.acks=all + min.insync.replicas 는 ISR 정의 위에서 동작한다. 프로듀서가 acks=all 로 발행하면 리더는 ISR 의 모든 멤버가 메시지를 적용한 뒤에야 ack 를 돌려준다. min.insync.replicas 는 "최소 이 정도 ISR 이 살아있어야 발행을 받아준다" 는 하한선이다. 둘이 같이 쓰여야 의미가 산다. 자세한 옵션 조합은 Kafka 데이터 정합성 설계 참고.Cluster
└── Broker (서버 노드, 보통 3대 이상)
└── Topic (논리적 카테고리, append-only, 다중 구독자)
└── Partition (분할된 로그, 순서 보장의 단위)
├── Leader Replica (모든 R/W 처리)
├── Follower Replica × (RF-1) (리더에서 fetch)
│ └── ISR 멤버십 = replica.lag.time.max.ms 안에 따라잡았는가
└── Segment (디스크 저장 단위, retention 단위)
└── Message
└── Offset (파티션 내부 위치)이 그림이 머리에 잡히면 그 다음 단계인 파티션 키 설계, 컨슈머 그룹 리밸런싱, 메시지 전달 보장이 자연스럽게 읽힌다 — 모두 이 기본 구조 위에서 트레이드오프를 더하는 이야기이기 때문이다.
acks=all, min.insync.replicas