Kafka의 구조: Topic, Partition, Broker, Offset - 핵심 구성 요소 정리
Kafka를 학습할 때 가장 먼저 마주하는 개념들이 있다.
Topic, Partition, Offset, 그리고 Broker.
도대체 이 단어들이 서로 어떤 관계를 맺고 있고,
실제 메시지가 어떤 과정을 거쳐 Kafka에 저장되고,
소비자(Consumer)가 어떻게 그 메시지를 읽어가는지 흐름이 잘 보이지 않을 때가 많다.
Kafka는 단순한 큐 시스템이 아니다.
대용량 메시지를 분산 환경에서 안전하게 저장하고, 빠르게 전송하며,
다양한 방식으로 소비할 수 있도록 설계된 데이터 스트리밍 플랫폼이다.
이 글에서는 Kafka의 핵심 구조를 하나씩 뜯어보며, 기능과 동작 원리, 그리고 실제 운영 시 고려해야 할 포인트들까지 정리해보려 한다.
Kafka 메시지 전달의 흐름
Kafka를 처음 접할 때 가장 먼저 이해해야 할 것은 메시지가 Kafka 내부에서 어떻게 이동하는가다.
- Producer가 메시지를 전송하면,
- Kafka의 특정 Topic 내 Partition에 저장되고,
- Consumer는 해당 Partition으로부터 메시지를 Offset 기준으로 읽어간다.
이 단순한 흐름 속에 Kafka의 고성능, 확장성, 신뢰성을 가능하게 만든 구조들이 숨어 있다.
Topic – 메시지의 분류 단위
Kafka에서 메시지는 Topic이라는 단위로 분류된다.
쉽게 말하면, 특정한 주제별로 메시지를 저장하는 논리적 저장소다.
예를 들어 "user-signup", "payment-request", "log-event" 같은 다양한 Topic이 있을 수 있다.
Producer는 메시지를 보낼 때 Topic을 지정하고,
Consumer는 자신이 관심 있는 Topic을 구독(subscribe)해서 메시지를 받아간다.
Topic은 단순한 분류용 컨테이너가 아니다.
내부적으로는 Partition이라는 단위로 물리적으로 나뉘어 있고,
Kafka의 성능과 확장성을 결정짓는 중요한 단위다.
Partition – Kafka의 확장성과 병렬 처리의 핵심
Kafka Topic은 내부적으로 하나 이상의 Partition으로 나뉜다.
각 Partition은 독립된 로그 파일처럼 동작하며, 메시지를 순차적으로 저장한다.
이 구조가 중요한 이유는 다음과 같다.
병렬 처리(Parallelism)
- 여러 Partition이 있으면, 여러 Consumer가 각 Partition을 나눠서 읽을 수 있다.
- 즉, Topic의 처리 속도는 Partition 수에 따라 병렬화가 가능하다.
수평 확장(Scalability)
- Partition은 물리적으로 서로 다른 Broker에 분산될 수 있다.
- 이는 Kafka 클러스터가 수천 TPS 이상을 안정적으로 처리할 수 있게 만드는 핵심 구조다.
메시지 순서 보장
- Kafka는 Partition 내에서는 메시지 순서를 보장한다.
- 하지만 Topic 전체 범위에서는 보장되지 않는다.
- 따라서 특정 키를 기준으로 Partition을 지정하는 것이 중요하다.
(예: userId를 Partition Key로 지정하면, 같은 유저의 메시지는 항상 같은 Partition에 들어가므로 순서 유지 가능)
Broker – Kafka 클러스터를 구성하는 노드
Kafka는 분산 시스템이다.
여러 대의 서버가 하나의 Kafka 클러스터를 구성하고,
각 서버를 Broker라고 부른다.
- 하나의 Broker는 여러 Partition을 저장할 수 있다.
- Topic의 Partition은 여러 Broker에 분산되어 저장된다.
- Kafka의 확장성과 장애 허용성은 이 구조에서 비롯된다.
Kafka에서는 특정 Partition마다 Leader Broker가 존재한다.
모든 읽기/쓰기는 Leader에서만 이루어지고,
다른 Broker에 있는 Follower Partition은 Leader의 데이터를 복제한다.
이 구조는 이후 다룰 Replication과 장애 복구 메커니즘의 핵심이 된다.
Offset – 메시지를 식별하는 고유한 번호
Kafka는 메시지를 Queue처럼 꺼내가면 사라지는 구조가 아니다.
대신, 메시지를 디스크에 저장해두고,
Consumer는 자신이 읽은 메시지의 위치(Offset)를 기준으로
다음 메시지를 읽는다.
- 각 Partition에 저장된 메시지는 0번부터 시작하는 Offset으로 저장된다.
- Consumer는 자신이 마지막으로 읽은 Offset 정보를 별도로 관리해야 한다.
- Kafka는 메시지를 자동으로 삭제하지 않는다. Retention 기간 내에서는 같은 메시지를 여러 번 읽는 것도 가능하다.
Offset을 직접 관리할지(Auto commit 여부), 어떻게 저장할지(Kafka 내부 topic에 저장 vs 외부 DB 사용)는
Consumer 애플리케이션 설계 시 반드시 고려해야 하는 요소다.
Partition 개수는 어떻게 결정해야 할까?
Partition 개수는 Kafka 설계에서 가장 민감한 선택 중 하나다.
- Partition이 많을수록 병렬 처리 성능은 좋아지지만,
- 메시지 순서 보장은 어려워지고,
- 브로커 간 네트워크 비용, 리소스 사용량도 증가한다.
일반적으로는 예상하는 Consumer Group 수와 메시지 처리량,
그리고 순서를 보장해야 하는 단위(예: 사용자 단위, 거래 단위)를 고려해 결정한다.
초기 설계 시 Partition을 너무 적게 잡으면 나중에 재파티셔닝이 어려워지므로,
처리량이 클수록 여유 있게 잡는 편이 좋다.
정리하며
Kafka의 구조는 단순한 큐 시스템과는 다르다.
Producer가 Topic으로 메시지를 전송하면, 내부적으로는 여러 Partition에 분산 저장되고,
각 Partition은 Broker들 사이에 나뉘어 저장된다.
Consumer는 Offset 기준으로 메시지를 읽어가며, 필요한 경우 같은 메시지를 여러 번 처리할 수도 있다.
이 구조는 Kafka가 고성능, 고확장성을 가지면서도
데이터 재처리와 장애 복구에 강한 이유가 된다.
다음 편에서는 Kafka에서 메시지를 전송하는 주체인 Producer를 다룰 예정이다.
메시지를 어떤 기준으로 Partition에 분배하는지,
어떻게 하면 중복 없이 안전하게 메시지를 전송할 수 있는지,
실무에서 고려해야 할 설정과 튜닝 포인트를 함께 정리해보겠다.