토픽과 파티션 (Topic & Partition)
카프카의 토픽은 큐가 아니라 덧붙이기만 하는 로그입니다. 토픽은 여러 파티션으로 쪼개지고, 레코드는 파티션 끝에 append 되며 그 자리에 오프셋이라는 번호가 붙습니다. 파티션이 여러 개라서 병렬로 쓰고 읽을 수 있지만, 순서가 보장되는 범위는 토픽 전체가 아니라 파티션 하나 안쪽입니다. 같은 키를 가진 레코드가 늘 같은 파티션으로 가는 이유가 여기 있습니다.
01토픽과 파티션 (Topic & Partition)
개념 한눈에 보기쇼핑몰에서 일어나는 사용자 행동을 카프카로 보냅니다. 받는 쪽은 줄 세 개 — 이 줄 하나하나를 파티션이라고 부릅니다.
user-42 가 로그인했습니다. 이 이벤트를 어느 줄에 넣을지는 사용자 아이디(키)를 계산해서 정합니다 — 0번 줄이 나왔습니다.
이벤트는 줄의 맨 끝에 덧붙습니다. 이미 있는 것을 고치거나 중간에 끼워 넣는 일이 없어서, 쓰기가 아주 빠릅니다.
다른 사용자는 다른 줄로 갑니다. user-7 의 상품 조회는 1번 줄에 쌓여, 0번 줄과 나란히 진행됩니다.
user-42 가 장바구니에 담았습니다. 같은 사용자니까 계산 결과도 같고, 반드시 아까와 같은 0번 줄로 갑니다.
여기가 핵심입니다. 같은 사용자의 행동이 늘 같은 줄에 순서대로 쌓이므로, 로그인 → 장바구니 순서가 뒤집히지 않습니다.
user-91 의 검색은 2번 줄로 갑니다. 줄이 여러 개라서 세 사용자의 이벤트가 동시에 쌓이고, 그만큼 많이 받아낼 수 있습니다.
user-42 의 결제까지 0번 줄에 쌓였습니다. 이 줄만 보면 로그인 → 장바구니 → 결제 순서가 언제 읽어도 그대로입니다.
그런데 보장은 줄 안에서만입니다. 1번 줄의 로그아웃이 0번 줄의 결제보다 먼저 일어났는지는 이 그림으로 알 수 없습니다.
그래서 줄 개수는 주고받는 양과 순서 보장을 맞바꾸는 선택입니다. 순서를 지켜야 하는 것끼리 같은 키로 묶고, 그 밖에서는 줄을 늘립니다.
02 쉽게 이해하기
For Everyone토픽은 큐가 아니라 덧붙이기만 하는 로그이고 파티션 여러 개로 쪼개집니다. 순서가 보장되는 범위는 토픽 전체가 아니라 파티션 하나 안이라, 순서를 지켜야 하는 것은 같은 키로 묶어 같은 파티션에 보냅니다.
레코드는 파티션의 끝에만 덧붙고 중간을 수정하지 않습니다.
그래서 쓰기가 순차 디스크 접근이 되어 매우 빠릅니다.
파티션 배정은 키의 해시로 정해지고, 키가 없으면 라운드로빈으로 분산됩니다.
파티션을 늘리면 병렬성이 올라가는 대신 토픽 전체의 전역 순서는 포기하게 됩니다.
읽은 레코드는 사라지지 않고 보존 기간 동안 그대로 남아, 여러 소비자가 같은 데이터를 각자 읽습니다.
- –이벤트 스트리밍 파이프라인 설계
- –파티션 수와 병렬성·순서 보장의 트레이드오프 판단
- –키 설계로 순서가 필요한 단위 묶기
03 자주 묻는 질문
FAQ토픽과 파티션 (Topic & Partition)란 무엇인가요?+
카프카의 토픽은 큐가 아니라 덧붙이기만 하는 로그입니다. 토픽은 여러 파티션으로 쪼개지고, 레코드는 파티션 끝에 append 되며 그 자리에 오프셋이라는 번호가 붙습니다. 파티션이 여러 개라서 병렬로 쓰고 읽을 수 있지만, 순서가 보장되는 범위는 토픽 전체가 아니라 파티션 하나 안쪽입니다. 같은 키를 가진 레코드가 늘 같은 파티션으로 가는 이유가 여기 있습니다.
토픽과 파티션 (Topic & Partition)은(는) 어디에 사용하나요?+
이벤트 스트리밍 파이프라인 설계, 파티션 수와 병렬성·순서 보장의 트레이드오프 판단, 키 설계로 순서가 필요한 단위 묶기
토픽과 파티션 (Topic & Partition)를 쉽게 비유하면?+
토픽은 큐가 아니라 덧붙이기만 하는 로그이고 파티션 여러 개로 쪼개집니다. 순서가 보장되는 범위는 토픽 전체가 아니라 파티션 하나 안이라, 순서를 지켜야 하는 것은 같은 키로 묶어 같은 파티션에 보냅니다.