Kafka 기본 요소들에 대한 추가 이해 - 1
이 페이지에서는 Kafka 를 공부하기 위해 주로 사용되는 용어들에 대해서 이전 게시글에 이어 추가 이해를 위하여 추가한다.
[+] 2025.05.12 - [Kafka, MSK, Kinesis/아키텍처 및 내부 구조] - Kafka 를 공부하기 위해 필요한 기본 용어들
또한, 이 게시글은 도서 O'REILLY 의 '카프카 핵심 가이드' 의 내용들을 심화 이해하기 위하여 작성하는 글이다.
이 페이지는 perplexity 를 통해 필자가 어떤 prompt 를 작성하여 공부하는지를 공유한다. ([] 로 표기)
또한, 검색이외에 추가로 덧붙일 내용은 ※ 로 추가한다.
[Kafka 의 publish/subscribe messaging 구조 및 broker 의 필요성을 설명해 줘]
- Kafka의 Publish/Subscribe 메시징 구조
Kafka의 Publish/Subscribe(발행/구독) 메시징 구조는 발행자(Producer)가 메시지를 특정 토픽(Topic)에 발행(publish)하면, 구독자(Consumer)가 관심 있는 토픽을 구독(subscribe)하여 해당 토픽의 메시지를 받아가는 방식이다. 이 구조는 발행자와 구독자가 서로 직접 연결되지 않고, 토픽이라는 중간 매개체를 통해 데이터를 주고받는 느슨한 결합(loosely coupled) 아키텍처를 제공한다.
주요 구성 요소와 동작 방식
- Producer(발행자):
메시지를 특정 토픽에 발행한다. 발행자는 구독자의 존재나 수에 대해 알 필요가 없다. - Topic(토픽):
메시지의 분류 기준이 되는 논리적 채널이다. 여러 Producer가 동일한 토픽에 메시지를 발행할 수 있고, 여러 Consumer가 동일한 토픽을 구독할 수 있다. - Consumer(구독자):
관심 있는 토픽을 구독하여, 그 토픽에 발행된 메시지를 가져간다. 구독자는 발행자가 누구인지 알 필요 없이 오직 토픽에만 관심을 가진다. - Broker(브로커):
Producer로부터 메시지를 받아 토픽별로 저장하고, Consumer가 요청할 때 메시지를 제공하는 중개자 역할을 한다.
구조의 특징 및 장점
- 확장성:
Producer와 Consumer의 수에 상관없이 시스템을 유연하게 확장할 수 있다. - 유연성:
새로운 Producer나 Consumer를 추가하거나 제거해도 기존 시스템에 영향을 주지 않는다. - 실시간 처리:
메시지가 토픽에 저장되면, Consumer는 실시간으로 메시지를 받아 처리할 수 있다. - 독립성:
Producer와 Consumer가 서로를 몰라도 되기 때문에, 시스템 간 종속성이 낮다.
-Kafka에서 Broker의 필요성
Broker는 Kafka에서 핵심적인 역할을 담당하는 서버(프로세스)로, 메시지의 저장, 관리, 분배를 책임진다.
브로커의 주요 역할
- 메시지 저장:
Producer가 발행한 메시지를 토픽별로 받아 저장한다. 메시지는 파티션 단위로 분산 저장되어, 대용량 데이터도 효율적으로 처리할 수 있다. - 데이터 분산 및 복제:
여러 브로커가 클러스터를 구성해 데이터를 분산 저장하고, 복제(Replication) 설정을 통해 장애 발생 시 데이터 손실을 방지한다. - 메시지 전달:
Consumer가 토픽을 구독하면, 해당 토픽의 메시지를 Consumer에게 제공한다. Kafka에서는 Consumer가 브로커에 메시지를 직접 요청(pull)하는 구조이다. - 확장성과 고가용성:
여러 브로커가 함께 동작함으로써, 시스템의 확장성과 장애 대응 능력이 향상된다. 브로커를 추가하면 데이터 처리량을 쉽게 늘릴 수 있다. - 중개자(Decoupler) 역할:
Producer와 Consumer가 직접 통신하지 않고, 브로커를 통해 메시지를 주고받음으로써 느슨한 결합 구조를 실현한다. 이를 통해 시스템의 독립성과 유연성이 높아진다.
요약
- Kafka의 Publish/Subscribe 구조는 Producer가 토픽에 메시지를 발행하고, Consumer가 토픽을 구독해 메시지를 받아가는 방식이다.
- 이 구조에서 **브로커(Broker)**는 메시지의 저장, 분산, 전달을 담당하는 중추적인 역할을 하며, 시스템의 확장성, 안정성, 유연성을 보장한다.
- 브로커가 존재하기 때문에 Producer와 Consumer가 서로를 몰라도 데이터 교환이 가능하고, 대용량 데이터 처리와 장애 복구도 용이하다.
※ 아래 예시 사진이 Kafka 를 이해하는데 도움이 된다.
(출처 : https://learn.conduktor.io/kafka/what-is-apache-kafka/)
- Kafka 를 도입하기 전에는 Source 들이 여러 Target 에 데이터를 분산시키므로 관리가 어렵다.
(이는 이후 해결하기 위해서 소요되는 개선 비용, 즉, 기술 부채와도 연관된다.)
- 위의 문제는 Producer / Consumer 구조의 Kafka 를 사용하면 해결 할 수 있다.
[Kafka 의 message, key, batch 에 대해서 알려줘]
Kafka에서 message, key, batch는 각각 다음과 같은 역할과 특징을 가진다.
- message
Kafka에서 message는 데이터의 기본 단위로, 일반적으로 byte 배열(byte[]) 형태로 저장된다. 각 message는 topic의 특정 partition에 저장되며, 메시지에는 value뿐 아니라 key와 같은 메타데이터가 포함될 수 있다. message는 Kafka의 pub/sub 시스템에서 생산자(Producer)가 생성해 전송하고, 소비자(Consumer)가 읽어가는 데이터 단위다.
※ RDBMS 의 row, record 에 대응 된다.
- key
Kafka의 message key는 메시지의 종류를 식별하거나, 데이터의 처리 순서와 밀접한 관련이 있다. 가장 중요한 역할은 동일한 key를 가진 메시지를 항상 동일한 partition으로 보내는 것이다. 이를 통해 특정 key(예: 사용자 ID, 주문 번호 등)를 기준으로 메시지의 순서를 partition 단위로 보장할 수 있다. 만약 key를 지정하지 않으면 Kafka는 round robin 방식 등으로 파티션을 자동 할당한다. 하지만 key를 지정하면 해당 key의 해시값을 이용해 partition이 결정되므로, 같은 key는 항상 같은 partition에 저장되어 순서가 유지된다. 단, key를 잘못 사용할 경우 특정 partition에 트래픽이 몰릴 수 있으니 주의해야 한다.
※ RDBMS 의 Partition Table 개념 및 이를 필요로 하는 이유를 연상하면 이해하기 쉽다.
- batch
Kafka에서 batch는 여러 개의 message를 모아 한 번에 전송하거나 저장하는 단위다. Producer가 message를 하나씩 전송하지 않고 일정량이 쌓이거나, 일정 시간이 경과하면 batch 단위로 묶어서 Broker로 전송한다. batch를 사용하면 네트워크 요청 횟수를 줄여 처리량(throughput)을 높이고, 시스템 효율성을 개선할 수 있다. batch의 크기(batch.size)와 대기 시간(linger.ms) 등은 설정할 수 있으며, batch가 클수록 throughput은 증가하지만 개별 message의 지연(latency)은 늘어날 수 있다. 효율성과 지연 시간의 균형을 고려해 batch 관련 옵션을 조정하는 것이 중요하다.
정리하면,
Kafka의 message는 데이터의 기본 단위이고, key는 메시지의 순서와 파티션 분배에 중요한 역할을 하며, batch는 여러 메시지를 묶어 효율적으로 처리하는 단위다. 이 세 가지 개념은 Kafka의 분산 메시징 시스템에서 데이터 처리의 효율성과 일관성을 높이는 핵심 요소다.
[Kafka 의 schema 개념과 이의 필요성을 알려줘]
Kafka의 schema는 Kafka를 통해 주고받는 메시지의 데이터 구조와 타입을 명확하게 정의한 명세를 의미한다. Kafka 자체는 메시지를 단순한 바이트 배열로 취급하므로, 데이터가 어떤 구조인지, 어떤 타입으로 이루어졌는지 알지 못한다. 이로 인해 Producer와 Consumer 간 데이터 구조 불일치, 데이터 해석 오류, 호환성 문제 등이 발생할 수 있다. 이러한 문제를 해결하기 위해 Kafka에서는 Schema Registry라는 별도의 컴포넌트를 도입해 메시지의 스키마를 중앙에서 관리하고 검증한다.
Kafka의 schema 개념
- schema는 메시지의 필드, 데이터 타입, 구조 등을 정의한 명세다.
- 주로 Avro, JSON, Protobuf 포맷으로 작성하며, 각 스키마는 고유한 Schema ID를 가진다.
- Producer는 메시지를 직렬화할 때 해당 스키마의 ID를 메시지에 포함하고, Consumer는 이 ID를 이용해 스키마를 조회해 역직렬화한다.
- Schema Registry는 스키마를 등록·조회·버전 관리하며, 스키마 호환성(Backward, Forward, Full 등) 정책을 통해 데이터 진화(evolution)도 관리한다.
Kafka에서 schema의 필요성
- 데이터 일관성 및 유효성 보장
스키마를 사용하면 Producer가 잘못된 데이터나 구조가 다른 메시지를 전송하는 것을 방지할 수 있다. 스키마와 일치하지 않는 메시지는 등록되지 않으므로, 데이터 품질과 일관성이 유지된다. - 서비스 간 결합도 감소 및 명세 관리 용이
여러 Producer와 Consumer가 다양한 언어와 환경에서 데이터를 주고받을 때, 스키마를 통해 데이터 구조를 명확히 공유할 수 있다. 스키마가 중앙에서 관리되므로 데이터 명세 관리가 쉬워지고, 담당자가 바뀌거나 시스템이 확장되어도 데이터 구조를 쉽게 파악할 수 있다. - 스키마 진화 및 호환성 관리
데이터 구조가 변경될 때, 스키마의 버전을 관리하고 호환성 정책을 적용해 과거 데이터와의 호환성을 유지할 수 있다. 예를 들어, 필드 추가/삭제, 타입 변경 등이 발생해도 기존 데이터와 신규 데이터가 함께 처리될 수 있다. - 불필요한 커뮤니케이션 및 작업 감소
스키마가 명확히 정의되어 있으면, 데이터 파싱이나 메시지 구조 문의, 변경 논의 등 불필요한 커뮤니케이션이 줄어들어 개발자는 본연의 업무에 집중할 수 있다. - 데이터 직렬화/역직렬화 효율성
Avro와 같은 포맷을 사용할 경우, 메시지에 스키마 전체가 아닌 스키마 ID만 포함되어 데이터 전송량이 줄고, 직렬화/역직렬화가 효율적으로 이루어진다.
결론
Kafka에서 schema는 메시지 구조와 타입을 명확히 정의하고, 데이터 일관성, 호환성, 효율적인 데이터 처리, 시스템 확장성 등 다양한 측면에서 필수적인 역할을 한다. Schema Registry를 통해 스키마를 중앙에서 관리함으로써 데이터 품질과 시스템 안정성을 높일 수 있다.
※ 일반적인 RDBMS 의 table 과는 다르게 Kafka 에서는 메시지를 table 의 지정된 포맷으로 받지 않으므로 이에 대해서 table 과 같은 메시지 규정을 만드는 것이다. 이는 MongoDB 의 Collection 분리와 의미상통한다. 물론, RDBMS 는 table 이라는 형상과 포맷설정이 필수 연결관계이므로, 이를 동시에 설정해줘야 하지만, Kafka 의 형상 관리는 아래의 Topic 으로, 포맷 설정은 schema 로 따로 분리된다.
[Kafka 의 topic, partition 에 대해서 알려줘]
Kafka에서 topic, partition, stream은 데이터 저장과 실시간 처리의 핵심 개념이다.
- topic
topic은 Kafka에서 데이터를 논리적으로 구분하고 저장하는 단위다. 데이터베이스의 테이블이나 파일 시스템의 폴더와 비슷한 개념으로, Producer가 데이터를 특정 topic에 저장하면 Consumer가 해당 topic을 구독해 데이터를 가져간다. 하나의 Kafka 클러스터에는 여러 개의 topic을 만들 수 있고, 목적에 따라 topic 이름을 자유롭게 지정할 수 있다.
- partition
partition은 topic을 물리적으로 나누는 단위다. 하나의 topic은 1개 이상의 partition으로 구성되고, 각 partition은 독립적인 데이터 스트림(큐) 역할을 한다. 메시지는 partition 끝에 순차적으로 저장되며, 각 메시지는 오프셋(offset)이라는 고유 번호를 가진다. 여러 partition이 있을 경우 Producer가 보낸 데이터는 분산되어 저장되고, 여러 Consumer가 각 partition을 병렬로 처리할 수 있다. partition은 클러스터 내 여러 브로커에 분산 저장되어 장애 대응과 데이터 내구성도 높아진다. partition 내부에서는 메시지의 순서가 보장되지만, 전체 topic 차원에서는 partition 간 순서 보장은 되지 않는다.
※ Multi Write, raid 1 과 같은 다중 쓰기를 통한 가용성을 높이는 작업을 연상하면 이해하기 쉽다.
- stream
stream은 Kafka에서 연속적으로 발생하는 데이터 흐름, 즉 실시간 데이터 스트림을 의미한다. Kafka의 기본 기능은 메시지의 저장과 전달에 초점을 맞추지만, Kafka Streams는 Kafka의 데이터를 실시간으로 처리하고 분석할 수 있도록 제공되는 라이브러리다. Kafka Streams를 사용하면 topic에 저장된 데이터를 실시간으로 읽어와 필터링, 변환, 집계, 조인 등 다양한 처리를 수행할 수 있고, 처리 결과를 다시 다른 topic에 저장할 수도 있다.
Kafka Streams는 다음과 같은 특징을 가진다.
- 분산 환경에서 확장성과 장애 복원력을 갖춘 실시간 데이터 처리 애플리케이션을 만들 수 있다.
- filter(), map(), groupBy() 등 다양한 연산을 지원하며, 집계 결과나 상태 정보를 내부 상태 저장소에 저장할 수 있다.
- Consumer API를 내부적으로 사용하므로, Consumer Group과 마찬가지로 partition별 병렬 처리가 가능하다.
- 복잡한 데이터 파이프라인이나 실시간 대시보드, 이벤트 감지, 데이터 변환 등 다양한 실시간 데이터 처리에 활용된다.
요약
- topic은 데이터를 논리적으로 구분하는 단위이고, 여러 개의 partition으로 구성된다.
- partition은 데이터를 물리적으로 분산 저장하고, 병렬 처리와 확장성을 가능하게 하는 단위다.
- stream은 Kafka를 통해 연속적으로 흐르는 데이터 자체이자, Kafka Streams와 같은 라이브러리를 통해 실시간으로 데이터를 처리하는 개념이다.
- Kafka Streams를 활용하면 topic에 저장된 데이터를 실시간으로 가공·분석하고, 결과를 다시 topic에 저장하는 복잡한 데이터 파이프라인을 쉽게 구축할 수 있다.