토픽과 파티션

카프카에서 데이터는 토픽(topic) 이라는 논리적인 단위로 저장돼요. 토픽은 마치 파일 시스템의 폴더처럼, 그 안에 쌓이는 이벤트(event) 들이 파일 하나하나에 해당한다고 보면 돼요. 그런데 이 토픽은 하나의 저장소에 몰아두지 않고 여러 조각으로 쪼개서 다양한 브로커에 나눠 담게 되는데, 그 조각 하나하나가 바로 파티션(partition) 이에요.

출처: https://kafka.apache.org/intro#main-concepts-and-terminology

본문

카프카에서 이벤트를 읽고 쓸 때는 항상 이벤트 단위로 작업해요. 이벤트는 키(key), 값(value), 타임스탬프(timestamp), 그리고 선택적인 메타데이터 헤더(header)로 구성되어 있어요. 예를 들어 손님의 결제 이벤트라면 이벤트 키가 "Alice", 이벤트 값이 "Bob에게 200달러 결제", 타임스탬프가 "2020년 6월 25일 오후 2시 6분"처럼 기록되지요.

이벤트들은 토픽 안에 영속적으로 정리되어 저장돼요. 토픽 이름은 "payments"처럼 사람이 알아보기 쉽게 지을 수 있고요. 토픽은 항상 다중 프로듀서·다중 구독자를 지원해요. 즉 하나의 토픽에 이벤트를 쓰는 프로듀서가 0개, 1개, 여러 개가 될 수도 있고, 이를 구독하는 컨슈머도 마찬가지로 여럿이 될 수 있어요.

토픽은 파티셔닝(partitioning) 되어 있어요. 쉽게 말해 토픽이 여러 브로커에 나뉘어 존재하는 여러 "버킷(bucket)"에 걸쳐 퍼져 있는 구조지요. 이렇게 데이터를 분산 배치하면 여러 클라이언트가 동시에 여러 브로커에서 데이터를 읽고 쓸 수 있기 때문에 확장성(scalability)에 굉장히 중요해요. 새 이벤트가 토픽에 발행되면 실제로는 그 토픽의 파티션 하나에 append(추가)되지요.

같은 이벤트 키(예를 들어 고객 ID나 차량 ID)를 가진 이벤트들은 항상 같은 파티션으로 쓰여져요. 그리고 카프카는 특정 토픽-파티션을 읽는 어떤 컨슈머든 그 파티션의 이벤트를 정확히 쓰여진 순서대로 읽는다는 것을 보장해줘요. 즉 파티션 안에서는 순서가 지켜지고, 전체 토픽 수준에서는 순서가 보장되지 않는다는 점을 꼭 기억해야 해요.

데이터를 내결함성(fault-tolerant) 있고 고가용성(high-availability) 있게 만들려면 모든 토픽을 복제(replicate) 할 수 있어요. 반복 팩터(replication factor)를 3으로 설정하면 데이터의 복사본이 항상 세 개 존재하게 되는 식이에요. 이 복제는 토픽 단위가 아니라 토픽-파티션 단위로 이뤄져요.

전통적인 메시징 시스템과 달리, 카프카에서 토픽의 이벤트는 소비된 뒤 삭제되지 않아요. 대신 토픽별 설정으로 이벤트를 얼마나 오래 보관할지를 정하면, 그 보존 기간이 지난 옛 이벤트만 버려지지요. 그래서 이벤트는 필요할 때마다 몇 번이든 다시 읽을 수 있어요.

더 알아보기

오프셋이 어떻게 파티션 안의 위치를 나타내는지는 [오프셋과 커밋 관리] 문서를 보면 돼요.
파티션이 여러 브로커에 복제되는 원리는 [복제와 ISR] 문서에서 다뤄요.
토픽별 보존·복제 옵션을 다루는 실제 설정값은 topic-config 문서를 참고해요.