0. 들어가기 전
이전에 MSA 프로젝트를 진행할 때, Kafka를 사용해본 적이 있습니다.
하지만 그때는 먼저 구현을 했어야 했기에 제대로 된 Kafka의 이론은 모른채 구현만 쫓아갔던 기억이 있습니다.
현재는 실무에서도 Kafka를 사용하고 있는 시점이고 개인적으로도 어떤 기술이고 어떤 원리인지 궁금하기 때문에 자세히 알아보려 합니다.
물론 하나의 기술을 알아볼 때, 실전 -> 이론으로 배우는 것이 빠를 수 있지만
당장은 시간이 좀 있어서 이론 -> 실전 순으로 알아보려고 합니다 😀 (처음엔 시간 많았는데 다시 글 쓰려고 보니 이젠 없네요...)
기술을 공부할 때 저는 무조건 기술의 공식문서가 1순위라고 생각하기 때문에 공식문서를 저만의 언어로 풀어서 포스팅해보겠습니다!
(거의 번역본일수도.. ㅎㅎ;;)
Apache Kafka 기술의 공식문서 링크는 아래와 같습니다.
https://kafka.apache.org/documentation/
Apache Kafka
Apache Kafka: A Distributed Streaming Platform.
kafka.apache.org
1. What is Apache Kafka?
공식문서에서 설명하는 Apache Kafka는 다음과 같습니다.
Apache Kafka is an open-source distributed event streaming platform.
- 카프카는 ‘분산 이벤트 스트리밍 플랫폼’이다.
1-1. What is event streaming?
그렇다면, 'event streaming'이란 뭘까요?
event streaming is the practice of capturing data in real-time from event sources.
- 이벤트 스트리밍은 실시간으로 'event source'에서 발생하는 데이터를 캡쳐하는 것이다.
- event source는 'event'가 발생하는 곳으로 DB, Software Application, mobile device 등이 있습니다.
Event Streaming이란, 실시간으로 발생하는 'event'를 'event stream' 형태로 저장하여 처리하고 필요한 곳에 전달하는 것을 말합니다.
이를 통해 다음과 같은 효과를 보장합니다.
- 실시간 데이터를 연속적으로 수집, 처리하는 데이터 흐름 보장
- 단순히 데이터를 전달 뿐만이 아닌 데이터를 분석하고 해석하는 구조 제공 (데이터 처리)
- 처리 지연 없이 적절한 시점에 적절한 위치로 데이터 전달
1-2. What is event stream? (event? stream?)
그렇다면, 'event stream'이란 무엇일까요?
'event stream'은 말 그대로, 'event'와 'stream'의 개념을 합친 것입니다.
- event : 어떤 일이 발생했다는 사실 (ex : 회원 탈퇴, 주문 취소, 로그인 성공, ...)
- stream : 시간에 따라 연속적으로 발행하는 데이터의 흐름
따라서, 'event stream'은 연속적으로 발생하는 Event의 흐름을 의미합니다.
Kafka는 Event를 연속적으로 발생하는 stream으로 저장하여 이를 가공 및 처리할 수 있도록 합니다.
1-3. What is Kafka 'event streaming platform' meaning?
그렇다면 Kafka는 어떠한 원리로 'Event Streaming Platform'을 구성할까요?
Kafka는 다음과 같은 3가지 Core Concept을 사용해서 'Event Streaming Platform'을 구성합니다.
1. To publish (write) and subscribe to (read) streams of events.
2. To store streams of events durably and reliably for as long as you want.
3. To process streams of events as they occur or retrospectively.
- Event Stream을 Publish/Subscribe한다. (Pub/Sub 구조)
- 원하는 시간만큼 Event Stream을 안전하게 저장한다.
- 실시간 Event Stream, 과거의 Event Stream을 처리할 수 있다. (실시간 처리, 재처리)
2. How does Kafka Work? (Internals, Server-Client)
이번 챕터에서는 Kafka는 어떻게 동작하는지 내부 구조(Internal)를 살펴봅시다.
Kafka is a distributed system consisting of servers and clients that communicate via a high-performance TCP network protocol.
- Kafka는 높은 성능의 TCP Protocol로 통신하는 여러 Server, Client로 구성된 분산 시스템
2-1. Servers
Kafka is run as a cluster of one or more servers that can span multiple datacenters or cloud regions.
- Kafka는 확장 가능한 하나 이상의 서버로 이루어진 'Cluster' 형태로 동작한다.
여기서 Kafka Cluster 내의 서버는 Broker를 의미한다.
- Broker : Event Stream을 저장하는 Storage Layer 역할의 Server
또 다른 서버로는, Kafka Connect Server가 존재한다.
- Kafka Connect Server : Kafka Connector를 실행시키는 Server
- Kafka Connect란, 지속적으로 Event Stream을 Import/Export해서 외부 시스템(DB)나 다른 Kafka Cluster를 통합하는 것
a Kafka cluster is highly scalable and fault-tolerant.
- Kafka Cluster는 높은 확장성과 실패 시에도 정상적으로 동작할 수 있다.
- 1개의 서버에 장애가 발생하더라도 다른 서버에서 작업을 이어받아서 데이터의 손실 없이 작업을 처리할 수 있다.
2-2. Clients
- Kafka Client를 통해 Kafka Cluster와 상호작용하면서 Event를 Pub/Sub 할 수 있다.
- 이를 통해 Event Stream을 Pub/Sub하고 가공 및 처리할 수 있는 분산 애플리케이션과 마이크로서비스를 구축할 수 있다.
Kafka의 Server-Client 구조를 간략하게 표현해보면 다음과 같습니다.
(Kafka Connect는 생략)
3. Components & Terms
이번 챕터에서는 본격적으로 Kafka에서 사용되는 구성 요소 및 사용되는 용어에 대해서 간략하게 알아보도록 합시다.
3-1. Event
Event는 앞서 잠깐 살펴봤지만, 좀 더 구체적인 예시로 설명해보겠습니다.
An event records the fact that "something happened" in the world or in your business.
- Event는 서비스에서 '어떤 일이 발생했다는 사실'을 나타낸다.
- Event는 다음과 같은 요소로 구성된다.
- Key
- Value
- Timestamp
- Optional Metadata Headers
* Bank Application
* Event : 'Alice가 Bob에게 200$를 송금했다.' (2020년 6월 25일 오후 2시 6분)
Event key: "Alice"
Event value: "Made a payment of $200 to Bob"
Event timestamp: "Jun. 25, 2020 at 2:06 p.m."
이처럼, Event는 서비스의 비즈니스에 따라 다양한 내용으로 나타날 수 있다.
3-2. Producer & Consumers
Producers are those client applications that publish (write) events to Kafka,
and consumers are those that subscribe to (read and process) these events.
- Producer와 Consumer는 모두 Kafka의 Client Application이다.
- Producer : Event를 Publish(Write)하는 Client Application
- Consumer : Event를 Subscribe(Read)하는 Client Application
- Kafka는 높은 확장성을 위해 Producer와 Consumer가 분리되어서 결합을 가지지 않는다.
- 따라서, Producer는 Consumer 컨디션과 상관없이 Event를 Publish 할 수 있다.
3-3. Topics
Events are organized and durably stored in topics.
- Event는 Topic 내에 저장된다.
- Event : File System의 file과 유사
- Topic : File System의 Folder와 유사
- Topic들은 항상 여러 Producer와 여러 Consumer를 가질 수 있다.
- 하나의 토픽은 Producer, Consumer가 없을 수도 있고 여러 개일 수도 있다.
- Topic 내에 저장된 Event들은 전통적인 Message System과 달리, 사용자가 원하는 만큼 재소비 할 수 있다. (이벤트를 소비 후 버리지 않을 수도 있다.)
3-4. Partitions
Topics are partitioned, meaning a topic is spread over a number of "buckets" located on different Kafka brokers.
- Topic은 파티셔닝되어 각 파티션에 각각 다른 Broker가 할당된다.
- Partition 1개당 1개의 Kafka Broker 할당 (정확히는 Leader Broker 1개 할당, 뒤에 챕터에서 설명)
- 따라서, 같은 Topic이라도 다른 Partition이라면 서로 다른 Kafka Broker를 사용한다.
- 하나의 Topic 내에 여러 Partition이 존재한다고 이해하면 이해하기 쉽다.
- 새로운 Event가 하나의 Topic에 Publish 되면 Topic 내의 하나의 Partition에 적재되는 것이다.
이렇게 Topic을 파티셔닝하는 'Partition' 개념을 도입한 이유는 이러한 '데이터 분산 적재'가 확장성에 매우 중요하기 때문입니다.
- Topic 내의 여러 파티션이 존재하고, 파티션별로 Broker가 여러 개 할당되어 있다.
- 이를 통해 Client Application은 하나의 Topic 내의 Event를 사용하고자 할 때, 여러 Broker를 사용하여 동시에 여러 데이터를 읽고 쓸 수 있다.
- 만약, 하나의 Topic 내에 파티션 없이 하나의 Broker가 할당되었다면 병렬 처리가 힘들고 하나의 Broker에 부하가 집중될 수 있다.
- Kafka는 여러 파티션에 Broker를 1개씩 할당하여 데이터를 분산하면서 병렬 처리 및 부하 분산, 높은 확장성을 가진다.
Event가 Publish되어 Kafka 내부에 저장되는 구조를 표현하면 다음과 같습니다.
- 각 Event는 Topic 내부 Partition에 저장됩니다.
- Partition에 저장되는 순서는 기본적으로 라운드로빈 방식으로 저장됩니다.
- Partition 1 -> 2 -> 3 -> 4 순서
※ Event Consume 순서 불일치 문제
기본적으로 하나의 Topic 내의 Event가 여러 Partition에 라운드로빈 방식으로 저장됨에 따라,
Client Application에서 해당 Event를 Consume 시 저장된 Event 순서와 Consume한 Event 순서가 불일치하는 문제가 발생할 수 있습니다.
이해를 돕기 위해, 예시 상황을 가정해보겠습니다.
- 1개의 토픽에 3개의 파티션 존재 (Partition 0, Partition 1, Partition 2)
- Event 1 ~ Event 6 순서로 6개가 들어왔다고 가정
해당 경우에 각 파티션에 적재되는 Event는 다음과 같을 것입니다.
- Partition 0 : Event 1, Event 4
- Partition 1 : Event 2, Event 5
- Partition 2 : Event 3, Event 6
일반적으로 Event를 소비하는 Consumer는 여러 개로 구성하여 Event 처리 성능을 높입니다.
이때, 여러 Consumer가 Event를 처리하는 속도나 네트워크 지연과 같은 변수 상황에 의해 Event 소비 순서가 달라질 수 있습니다.
Partition 1을 담당하는 Consumer에 문제가 생겨 지연이 발생했다고 가정해보면 다음과 같이 소비됩니다.
- Event 적재 순서 : Event 1 -> Event 2 -> Event 3 -> Event 4 -> Event 5 -> Event 6
- 실제 Event 소비 순서 : Event 1 -> Event 3 -> Event 4 -> Event 6 -> Event 2 -> Event 5
해당 상황은 비즈니스에 따라 치명적일 수 있습니다.
예를 들어, 간단하게 주문 상태 관련 Topic에서 사용자가 주문 후에 주문 취소를 했다고 가정해봅시다.
- Event 적재 순서 : '주문 완료' -> '주문 취소'
- 실제 Event 소비 순서 : '주문 취소' -> '주문 완료'
이런 식으로 Event가 소비되면, 실제 주문이 이루어지기 때문에 서비스에 심각한 문제를 초래할 수 있습니다.
※ Event Consume 순서 불일치 문제 해결 - Event Key 설정
해당 문제는 Event를 Produce할 때 Event Key를 설정해서 보내면, 해당 Event는 정해진 Partition에만 적재됩니다.
(Key를 해싱하여 적재할 Partition을 정한다.)
따라서, 해당 Event는 Partition 1개에만 적재되어 1개의 Consumer에서만 소비되기 때문에 이벤트 순서가 보장됩니다.
실제 구현은 이론을 다루는 글이다보니 생략하도록 하겠습니다.
4. Main Concepts
이번 챕터에서는 간략하게 각 구성 요소들의 Main Concept에 대해서 소개해보도록 하겠습니다.
4-1. Event를 필요한 만큼 소비 가능
Events in a topic can be read as often as needed—unlike traditional messaging systems, events are not deleted after consumption.
- Topic 내의 Event들은 전통적인 다른 메시징 시스템과 달리, 소비 후에 사라지지 않기 때문에 필요한 만큼 여러 번 읽을 수 있다.
- Topic당 Event 유지 기간을 설정하여 그 기간만큼 Event를 보관할 수 있다.
4-2. 동일 Event Key는 동일 Partition 저장 보장 & 파티션 내 이벤트 Consume 순서 보장
기본적으로 하나의 Topic 내의 Event가 여러 Partition에 라운드로빈 방식으로 저장됨에 따라,
Client Application에서 해당 Event를 Consume 시
저장된 Event 순서와 Consume한 Event 순서가 불일치하는 문제가 발생할 수 있습니다.
이해를 돕기 위해, 예시 상황을 가정해보겠습니다.
- 1개의 토픽에 3개의 파티션 존재 (Partition 0, Partition 1, Partition 2)
- Event 1 ~ Event 6 순서로 6개가 들어왔다고 가정
해당 경우에 각 파티션에 적재되는 Event는 다음과 같을 것입니다.
- Partition 0 : Event 1, Event 4
- Partition 1 : Event 2, Event 5
- Partition 2 : Event 3, Event 6
일반적으로 Event를 소비하는 Consumer는 여러 개로 구성하여 Event 처리 성능을 높입니다.
이때, 여러 Consumer가 Event를 처리하는 속도나 네트워크 지연과 같은 변수 상황에 의해 Event 소비 순서가 달라질 수 있습니다.
Partition 1을 담당하는 Consumer에 문제가 생겨 지연이 발생했다고 가정해보면 다음과 같이 소비됩니다.
- Event 적재 순서 : Event 1 -> Event 2 -> Event 3 -> Event 4 -> Event 5 -> Event 6
- 실제 Event 소비 순서 : Event 1 -> Event 3 -> Event 4 -> Event 6 -> Event 2 -> Event 5
해당 상황은 비즈니스에 따라 치명적일 수 있습니다.
예를 들어, 간단하게 주문 상태 관련 Topic에서 사용자가 주문 후에 주문 취소를 했다고 가정해봅시다.
- Event 적재 순서 : '주문 완료' -> '주문 취소'
- 실제 Event 소비 순서 : '주문 취소' -> '주문 완료'
이런 식으로 Event가 소비되면, 실제 주문이 이루어지기 때문에 서비스에 심각한 문제를 초래할 수 있습니다.
이러한 문제를 Kafka는 'Event Key'를 설정하여 해결합니다.
Events with the same event key (e.g., a customer or vehicle ID) are written to the same partition, and Kafka
guarantees that any consumer of a given topic-partition will always read that partition's events in exactly the same order as they were written.
- 같은 Event Key를 가진 Event는 동일한 Partition에 적재된다.
- 즉, Event Key는 이벤트를 특정 Partition에 할당하는 데 사용된다.
- Kafka는 Partition 내 Event가 기록된 순서를 보장한다.
4-3. Topic 복제 기능
To make your data fault-tolerant and highly-available, every topic can be replicated.
- 장애 시 안정성과 높은 가용성을 위해서 모든 토픽은 복제될 수 있다.
이렇게 해서 Kafka 공식문서에 나와 있는 기본적인 Kafka의 개념들을 알아보았습니다.
이후에는 좀 더 심화적인 내부 원리, 설계에 관해서 다뤄보도록 하겠습니다! :)
'Kafka' 카테고리의 다른 글
| Transactional Outbox Pattern을 통해 Event Message 발행 보장하기 (0) | 2025.03.03 |
|---|---|
| [Kafka] Apache Kafka 공식문서 살펴보기 (Design, 심화 이론) (2) | 2024.12.21 |
0. 들어가기 전
이전에 MSA 프로젝트를 진행할 때, Kafka를 사용해본 적이 있습니다.
하지만 그때는 먼저 구현을 했어야 했기에 제대로 된 Kafka의 이론은 모른채 구현만 쫓아갔던 기억이 있습니다.
현재는 실무에서도 Kafka를 사용하고 있는 시점이고 개인적으로도 어떤 기술이고 어떤 원리인지 궁금하기 때문에 자세히 알아보려 합니다.
물론 하나의 기술을 알아볼 때, 실전 -> 이론으로 배우는 것이 빠를 수 있지만
당장은 시간이 좀 있어서 이론 -> 실전 순으로 알아보려고 합니다 😀 (처음엔 시간 많았는데 다시 글 쓰려고 보니 이젠 없네요...)
기술을 공부할 때 저는 무조건 기술의 공식문서가 1순위라고 생각하기 때문에 공식문서를 저만의 언어로 풀어서 포스팅해보겠습니다!
(거의 번역본일수도.. ㅎㅎ;;)
Apache Kafka 기술의 공식문서 링크는 아래와 같습니다.
https://kafka.apache.org/documentation/
Apache Kafka
Apache Kafka: A Distributed Streaming Platform.
kafka.apache.org
1. What is Apache Kafka?
공식문서에서 설명하는 Apache Kafka는 다음과 같습니다.
Apache Kafka is an open-source distributed event streaming platform.
- 카프카는 ‘분산 이벤트 스트리밍 플랫폼’이다.
1-1. What is event streaming?
그렇다면, 'event streaming'이란 뭘까요?
event streaming is the practice of capturing data in real-time from event sources.
- 이벤트 스트리밍은 실시간으로 'event source'에서 발생하는 데이터를 캡쳐하는 것이다.
- event source는 'event'가 발생하는 곳으로 DB, Software Application, mobile device 등이 있습니다.
Event Streaming이란, 실시간으로 발생하는 'event'를 'event stream' 형태로 저장하여 처리하고 필요한 곳에 전달하는 것을 말합니다.
이를 통해 다음과 같은 효과를 보장합니다.
- 실시간 데이터를 연속적으로 수집, 처리하는 데이터 흐름 보장
- 단순히 데이터를 전달 뿐만이 아닌 데이터를 분석하고 해석하는 구조 제공 (데이터 처리)
- 처리 지연 없이 적절한 시점에 적절한 위치로 데이터 전달
1-2. What is event stream? (event? stream?)
그렇다면, 'event stream'이란 무엇일까요?
'event stream'은 말 그대로, 'event'와 'stream'의 개념을 합친 것입니다.
- event : 어떤 일이 발생했다는 사실 (ex : 회원 탈퇴, 주문 취소, 로그인 성공, ...)
- stream : 시간에 따라 연속적으로 발행하는 데이터의 흐름
따라서, 'event stream'은 연속적으로 발생하는 Event의 흐름을 의미합니다.
Kafka는 Event를 연속적으로 발생하는 stream으로 저장하여 이를 가공 및 처리할 수 있도록 합니다.
1-3. What is Kafka 'event streaming platform' meaning?
그렇다면 Kafka는 어떠한 원리로 'Event Streaming Platform'을 구성할까요?
Kafka는 다음과 같은 3가지 Core Concept을 사용해서 'Event Streaming Platform'을 구성합니다.
1. To publish (write) and subscribe to (read) streams of events.
2. To store streams of events durably and reliably for as long as you want.
3. To process streams of events as they occur or retrospectively.
- Event Stream을 Publish/Subscribe한다. (Pub/Sub 구조)
- 원하는 시간만큼 Event Stream을 안전하게 저장한다.
- 실시간 Event Stream, 과거의 Event Stream을 처리할 수 있다. (실시간 처리, 재처리)
2. How does Kafka Work? (Internals, Server-Client)
이번 챕터에서는 Kafka는 어떻게 동작하는지 내부 구조(Internal)를 살펴봅시다.
Kafka is a distributed system consisting of servers and clients that communicate via a high-performance TCP network protocol.
- Kafka는 높은 성능의 TCP Protocol로 통신하는 여러 Server, Client로 구성된 분산 시스템
2-1. Servers
Kafka is run as a cluster of one or more servers that can span multiple datacenters or cloud regions.
- Kafka는 확장 가능한 하나 이상의 서버로 이루어진 'Cluster' 형태로 동작한다.
여기서 Kafka Cluster 내의 서버는 Broker를 의미한다.
- Broker : Event Stream을 저장하는 Storage Layer 역할의 Server
또 다른 서버로는, Kafka Connect Server가 존재한다.
- Kafka Connect Server : Kafka Connector를 실행시키는 Server
- Kafka Connect란, 지속적으로 Event Stream을 Import/Export해서 외부 시스템(DB)나 다른 Kafka Cluster를 통합하는 것
a Kafka cluster is highly scalable and fault-tolerant.
- Kafka Cluster는 높은 확장성과 실패 시에도 정상적으로 동작할 수 있다.
- 1개의 서버에 장애가 발생하더라도 다른 서버에서 작업을 이어받아서 데이터의 손실 없이 작업을 처리할 수 있다.
2-2. Clients
- Kafka Client를 통해 Kafka Cluster와 상호작용하면서 Event를 Pub/Sub 할 수 있다.
- 이를 통해 Event Stream을 Pub/Sub하고 가공 및 처리할 수 있는 분산 애플리케이션과 마이크로서비스를 구축할 수 있다.
Kafka의 Server-Client 구조를 간략하게 표현해보면 다음과 같습니다.
(Kafka Connect는 생략)
3. Components & Terms
이번 챕터에서는 본격적으로 Kafka에서 사용되는 구성 요소 및 사용되는 용어에 대해서 간략하게 알아보도록 합시다.
3-1. Event
Event는 앞서 잠깐 살펴봤지만, 좀 더 구체적인 예시로 설명해보겠습니다.
An event records the fact that "something happened" in the world or in your business.
- Event는 서비스에서 '어떤 일이 발생했다는 사실'을 나타낸다.
- Event는 다음과 같은 요소로 구성된다.
- Key
- Value
- Timestamp
- Optional Metadata Headers
* Bank Application
* Event : 'Alice가 Bob에게 200$를 송금했다.' (2020년 6월 25일 오후 2시 6분)
Event key: "Alice"
Event value: "Made a payment of $200 to Bob"
Event timestamp: "Jun. 25, 2020 at 2:06 p.m."
이처럼, Event는 서비스의 비즈니스에 따라 다양한 내용으로 나타날 수 있다.
3-2. Producer & Consumers
Producers are those client applications that publish (write) events to Kafka,
and consumers are those that subscribe to (read and process) these events.
- Producer와 Consumer는 모두 Kafka의 Client Application이다.
- Producer : Event를 Publish(Write)하는 Client Application
- Consumer : Event를 Subscribe(Read)하는 Client Application
- Kafka는 높은 확장성을 위해 Producer와 Consumer가 분리되어서 결합을 가지지 않는다.
- 따라서, Producer는 Consumer 컨디션과 상관없이 Event를 Publish 할 수 있다.
3-3. Topics
Events are organized and durably stored in topics.
- Event는 Topic 내에 저장된다.
- Event : File System의 file과 유사
- Topic : File System의 Folder와 유사
- Topic들은 항상 여러 Producer와 여러 Consumer를 가질 수 있다.
- 하나의 토픽은 Producer, Consumer가 없을 수도 있고 여러 개일 수도 있다.
- Topic 내에 저장된 Event들은 전통적인 Message System과 달리, 사용자가 원하는 만큼 재소비 할 수 있다. (이벤트를 소비 후 버리지 않을 수도 있다.)
3-4. Partitions
Topics are partitioned, meaning a topic is spread over a number of "buckets" located on different Kafka brokers.
- Topic은 파티셔닝되어 각 파티션에 각각 다른 Broker가 할당된다.
- Partition 1개당 1개의 Kafka Broker 할당 (정확히는 Leader Broker 1개 할당, 뒤에 챕터에서 설명)
- 따라서, 같은 Topic이라도 다른 Partition이라면 서로 다른 Kafka Broker를 사용한다.
- 하나의 Topic 내에 여러 Partition이 존재한다고 이해하면 이해하기 쉽다.
- 새로운 Event가 하나의 Topic에 Publish 되면 Topic 내의 하나의 Partition에 적재되는 것이다.
이렇게 Topic을 파티셔닝하는 'Partition' 개념을 도입한 이유는 이러한 '데이터 분산 적재'가 확장성에 매우 중요하기 때문입니다.
- Topic 내의 여러 파티션이 존재하고, 파티션별로 Broker가 여러 개 할당되어 있다.
- 이를 통해 Client Application은 하나의 Topic 내의 Event를 사용하고자 할 때, 여러 Broker를 사용하여 동시에 여러 데이터를 읽고 쓸 수 있다.
- 만약, 하나의 Topic 내에 파티션 없이 하나의 Broker가 할당되었다면 병렬 처리가 힘들고 하나의 Broker에 부하가 집중될 수 있다.
- Kafka는 여러 파티션에 Broker를 1개씩 할당하여 데이터를 분산하면서 병렬 처리 및 부하 분산, 높은 확장성을 가진다.
Event가 Publish되어 Kafka 내부에 저장되는 구조를 표현하면 다음과 같습니다.
- 각 Event는 Topic 내부 Partition에 저장됩니다.
- Partition에 저장되는 순서는 기본적으로 라운드로빈 방식으로 저장됩니다.
- Partition 1 -> 2 -> 3 -> 4 순서
※ Event Consume 순서 불일치 문제
기본적으로 하나의 Topic 내의 Event가 여러 Partition에 라운드로빈 방식으로 저장됨에 따라,
Client Application에서 해당 Event를 Consume 시 저장된 Event 순서와 Consume한 Event 순서가 불일치하는 문제가 발생할 수 있습니다.
이해를 돕기 위해, 예시 상황을 가정해보겠습니다.
- 1개의 토픽에 3개의 파티션 존재 (Partition 0, Partition 1, Partition 2)
- Event 1 ~ Event 6 순서로 6개가 들어왔다고 가정
해당 경우에 각 파티션에 적재되는 Event는 다음과 같을 것입니다.
- Partition 0 : Event 1, Event 4
- Partition 1 : Event 2, Event 5
- Partition 2 : Event 3, Event 6
일반적으로 Event를 소비하는 Consumer는 여러 개로 구성하여 Event 처리 성능을 높입니다.
이때, 여러 Consumer가 Event를 처리하는 속도나 네트워크 지연과 같은 변수 상황에 의해 Event 소비 순서가 달라질 수 있습니다.
Partition 1을 담당하는 Consumer에 문제가 생겨 지연이 발생했다고 가정해보면 다음과 같이 소비됩니다.
- Event 적재 순서 : Event 1 -> Event 2 -> Event 3 -> Event 4 -> Event 5 -> Event 6
- 실제 Event 소비 순서 : Event 1 -> Event 3 -> Event 4 -> Event 6 -> Event 2 -> Event 5
해당 상황은 비즈니스에 따라 치명적일 수 있습니다.
예를 들어, 간단하게 주문 상태 관련 Topic에서 사용자가 주문 후에 주문 취소를 했다고 가정해봅시다.
- Event 적재 순서 : '주문 완료' -> '주문 취소'
- 실제 Event 소비 순서 : '주문 취소' -> '주문 완료'
이런 식으로 Event가 소비되면, 실제 주문이 이루어지기 때문에 서비스에 심각한 문제를 초래할 수 있습니다.
※ Event Consume 순서 불일치 문제 해결 - Event Key 설정
해당 문제는 Event를 Produce할 때 Event Key를 설정해서 보내면, 해당 Event는 정해진 Partition에만 적재됩니다.
(Key를 해싱하여 적재할 Partition을 정한다.)
따라서, 해당 Event는 Partition 1개에만 적재되어 1개의 Consumer에서만 소비되기 때문에 이벤트 순서가 보장됩니다.
실제 구현은 이론을 다루는 글이다보니 생략하도록 하겠습니다.
4. Main Concepts
이번 챕터에서는 간략하게 각 구성 요소들의 Main Concept에 대해서 소개해보도록 하겠습니다.
4-1. Event를 필요한 만큼 소비 가능
Events in a topic can be read as often as needed—unlike traditional messaging systems, events are not deleted after consumption.
- Topic 내의 Event들은 전통적인 다른 메시징 시스템과 달리, 소비 후에 사라지지 않기 때문에 필요한 만큼 여러 번 읽을 수 있다.
- Topic당 Event 유지 기간을 설정하여 그 기간만큼 Event를 보관할 수 있다.
4-2. 동일 Event Key는 동일 Partition 저장 보장 & 파티션 내 이벤트 Consume 순서 보장
기본적으로 하나의 Topic 내의 Event가 여러 Partition에 라운드로빈 방식으로 저장됨에 따라,
Client Application에서 해당 Event를 Consume 시
저장된 Event 순서와 Consume한 Event 순서가 불일치하는 문제가 발생할 수 있습니다.
이해를 돕기 위해, 예시 상황을 가정해보겠습니다.
- 1개의 토픽에 3개의 파티션 존재 (Partition 0, Partition 1, Partition 2)
- Event 1 ~ Event 6 순서로 6개가 들어왔다고 가정
해당 경우에 각 파티션에 적재되는 Event는 다음과 같을 것입니다.
- Partition 0 : Event 1, Event 4
- Partition 1 : Event 2, Event 5
- Partition 2 : Event 3, Event 6
일반적으로 Event를 소비하는 Consumer는 여러 개로 구성하여 Event 처리 성능을 높입니다.
이때, 여러 Consumer가 Event를 처리하는 속도나 네트워크 지연과 같은 변수 상황에 의해 Event 소비 순서가 달라질 수 있습니다.
Partition 1을 담당하는 Consumer에 문제가 생겨 지연이 발생했다고 가정해보면 다음과 같이 소비됩니다.
- Event 적재 순서 : Event 1 -> Event 2 -> Event 3 -> Event 4 -> Event 5 -> Event 6
- 실제 Event 소비 순서 : Event 1 -> Event 3 -> Event 4 -> Event 6 -> Event 2 -> Event 5
해당 상황은 비즈니스에 따라 치명적일 수 있습니다.
예를 들어, 간단하게 주문 상태 관련 Topic에서 사용자가 주문 후에 주문 취소를 했다고 가정해봅시다.
- Event 적재 순서 : '주문 완료' -> '주문 취소'
- 실제 Event 소비 순서 : '주문 취소' -> '주문 완료'
이런 식으로 Event가 소비되면, 실제 주문이 이루어지기 때문에 서비스에 심각한 문제를 초래할 수 있습니다.
이러한 문제를 Kafka는 'Event Key'를 설정하여 해결합니다.
Events with the same event key (e.g., a customer or vehicle ID) are written to the same partition, and Kafka
guarantees that any consumer of a given topic-partition will always read that partition's events in exactly the same order as they were written.
- 같은 Event Key를 가진 Event는 동일한 Partition에 적재된다.
- 즉, Event Key는 이벤트를 특정 Partition에 할당하는 데 사용된다.
- Kafka는 Partition 내 Event가 기록된 순서를 보장한다.
4-3. Topic 복제 기능
To make your data fault-tolerant and highly-available, every topic can be replicated.
- 장애 시 안정성과 높은 가용성을 위해서 모든 토픽은 복제될 수 있다.
이렇게 해서 Kafka 공식문서에 나와 있는 기본적인 Kafka의 개념들을 알아보았습니다.
이후에는 좀 더 심화적인 내부 원리, 설계에 관해서 다뤄보도록 하겠습니다! :)
'Kafka' 카테고리의 다른 글
| Transactional Outbox Pattern을 통해 Event Message 발행 보장하기 (0) | 2025.03.03 |
|---|---|
| [Kafka] Apache Kafka 공식문서 살펴보기 (Design, 심화 이론) (2) | 2024.12.21 |
