Kafka
LinkedIn에서 개발한 Kafka는 데이터 세계에 새로운 바람을 일으키고 있다.
Kafka가 무엇인지 검색하면 분산형 데이터 스트리밍 플랫폼이라는 다소 어렵게 느껴지는 단어가 나온다.
이는 쉽게 말해 엄청난 양의 데이터를 실시간으로 주고받고 처리할 수 있게 해주는 혁신적인 도구라고 할 수 있다.
Kafka 이전 데이터 시스템의 문제점
과거 데이터 시스템에서는 어떤 문제가 있었을까?
만약, A회사에 수십 개의 애플리케이션이 있고, 각 애플리케이션마다 각각의 DB를 가지고 있으면 어떻게 될까?
복잡함 증가(Complexity)
새로운 서비스가 추가될 때마다 전체 시스템의 복잡도는 눈덩이처럼 불어날 것이다.
데이터가 마치 실타래가 얽혀있는 것처럼 데이터 흐름을 파악하기 어려울 것이고, 이에따라 시스템 관리도 점점 더 어려워졌을 것이다.
만약, 특정 부분에서 장애가 발생하였을 경우, 연결되어있는 애플리케이션들을 모두 확인해야하기 때문에 장애 발생 조치 시간이 점점 더 증가했을 것이다.
데이터 파이프라인 관리
각 애플리케이션이 독립적인 DB를 사용했기 때문에, 데이터를 일관성있게 유지하는 것이 어려웠다.
만약, 한 시스템의 데이터가 변경되면, 이와 연결된 모든 시스템의 데이터를 업데이트 해야했다. 이에 따라 실시간으로 처리가 필요한 환경에서 데이터 관리는 쉽지 않았다.
이러한 문제들을 해결하기 위해 등장한 것이 바로 Kafka다.
Kafka를 통해 데이터를 중앙 집중화 된 스트림으로 관리하게 되면서, 기존의 복잡한 데이터 생태계를 단순화 시키고, 실시간 데이터처리 및 확장이 용이한 시스템을 만들게 된 것.
Kafka의 장점
- 실시간 데이터 처리: Kafka를 통해 대량의 데이터를 실시간으로 처리할 수 있게 되다. 이를 통해 빠른 의사결정과 즉각적인 서비스 제공할 수 있게 되었다.
- 확장성과 안정성: 분산 시스템 구조를 채택함으로써, 데이터 볼륨이 증가해도 쉽게 확장할 수 있으며, 높은 가용성을 보장하게 되었다.
- 데이터 통합의 용이성: 새로운 서비스나 시스템이 추가되더라도 Kafka가 제공하는 표준 포맷으로 연결하면 되기 때문에, 데이터의 일관성 유지와 분석이 훨씬 수월해졌다.
이를 통해 Kafka의 등장으로 기업들은 더 효율적이고 확장 가능한 데이터 아키텍처를 구축할 수 있게 되었다.
Kafka의 동작 방식 및 특징
Kaka는 어떻게 동작할까?
Pub-Sub 모델의 메세지 큐 형태로 동작한다.
이를 이해하기 위해서는 메세지/이벤트 브로커와 메세지 큐에 대한 이해가 필요하다.
메세지 큐(Message Queue, MQ)란?
출처: https://www.cloudamqp.com/blog/what-is-message-queuing.html
메시지 큐는프로그램 간 데이터를 주고받기 위한 통신 방법 중 하나다.
간단히 말해, 프로그램 A가 프로그램 B에게 메시지를 보내고 싶을 때, 직접 전달하는 대신 중간에 있는 큐(대기열)에 메시지를 넣어두면, B가 자신의 처리 속도에 맞춰 큐에서 메시지를 가져가는 방식이다.
메세지 큐 용어
- PRODUCER: 정보 제공자
- CONSUMER: 정보를 제공받아 사용하려는 자
- QUEUE: PRODUCER가 보낸 데이터를 임시 저장 및 CONSUMER에게 제공
메세지 큐의 특징
- 비동기 통신: 송신자와 수신자가 동시에 작업할 필요가 없다.
- 버퍼링: 일시적인 트래픽 급증을 완화할 수 있다.
- 신뢰성: 메시지 전달을 보장한다.
- 보장성: MQ에 들어갈 경우, 결국 모든 메세지가 CONSUMER 서비스에 전달된다.p
가장 중요한 점이 서로 직접 통신하는 것이 아닌, 중간 QUEUE를 통해 중개된다는 점이다.
Pub-Sub 모델이란?
출처: https://www.linkedin.com/pulse/pubsub-architecture-benefits-use-cases-manpreet-singh-sarna/
Pub-Sub(Publisher-Subscriber) 모델은 메시지의 발행자(Publisher)와 구독자(Subscriber) 사이의 결합을 제공하는 메시징 패턴이다.
- Publisher: 특정 주제(Topic)에 대한 메시지를 생성하고 발송한다.
- Subscriber: 관심 있는 주제를 구독하고, 해당 주제에 대한 메시지를 수신한다.
Kafka의 동작 방식
Kafka는 이러한 메시지 큐와 Pub-Sub 모델의 개념을 결합하여 작동한다.
- 토픽(Topic): Kafka에서 메시지는 토픽별로 분류된다. 각 토픽은 여러 개의 파티션으로 나눌 수 있다.
- 프로듀서(Producer): 메시지를 생성하고 특정 토픽으로 발행한다.
- 컨슈머(Consumer): 하나 이상의 토픽을 구독하고 메시지를 소비한다.
- 브로커(Broker): Kafka 서버로, 메시지를 저장하고 관리한다.
Kafka의 독특한 점은 메시지를 디스크에 저장하여 영속성을 제공하고, 분산 시스템을 통해 높은 처리량과 확장성을 보장한다는 것이다.
이로 인해 대용량 실시간 데이터 처리에 특히 적합하다.
Pub-Sub과 kafka의 차이점 ft.메세지 브로커 / 이벤트 브로커
Pub-Sub: 메세지 브로커
메세지 브로커는 마치 패스트푸드 레스토랑과 같다.
👥 고객( Publisher )이 주문을 한다.
🧾 주문이 주방 ( QUEUE ) 으로 전달된다.
🧑🍳 요리사 ( Consumer )가 그 주문서를 보고 음식을 만든다.
🚮 음식이 완성되면 주문서는 버려진다.즉, 메세지 브로커는 Publisher가 생상한 메세지를 메세지 큐에 저장하고, 이 메세지 큐는 저장된 데이터를 Consumer가 가져갈 수 있도록 중간 다리 역할을 하는 브로커 역할을 하게 된다.
이 메세지 브로커들은 Consumer가 큐에서 데이터를 가져가게 되면, 혹은 곧 Queue에서 데이터가 삭제된다.
이러한 이유로 Pub-Sub에는 다음과 같은 특징을 가지고 있다.
- 빠른 처리: 주문이 들어오면 바로 처리한다.
- 일회성: 한 번 처리된 주문은 기록에 남지 않는다.
- 용도: 실시간 주문 처리, 간단한 작업 분배에 적합하다.
대표적인 예: Redis, RabbitMQ, AWS SQS...
Kafka: 이벤트 브로커
이제 Kafka를 포함한 이벤트 브로커는 넷플릭스와 같다.
📋 토픽(Topic): 넷플릭스의 카테고리와 같다. 드라마, 영화, 한국드라마 등 다양한 주제로 영상을 분류한다.
🎬 프로듀서(Producer): 영화 제작사다. 다양한 영상을 만들고 특정 카테고리(토픽)로 넷플릭스에 업로드한다.
👥 컨슈머(Consumer): 넷플릭스 시청자들이다. 자신이 좋아하는 카테고리(토픽)을 선택하고 영상을 시청한다.
💽 브로커(Broker): 넷플릭스의 서버와 같다. 모든 영상을 저장하고 관리한다.이벤트 브로커 역시 메세지 브로커의 QUEUE 기능을 가지고 있기 때문에 메세지 브로커 역할을 할 수 있다.
그러나 여기서 가장 큰 차이는,
이벤트 브로커의 경우, Publisher가 생성한 이벤트를 삭제하지 않고 저장한다는 것이다.
그 이유는, 이벤트의 시점이 저장되어있기 때문에, Consumer가 해당 시점부터 다시 이벤트를 처리할 수 있다.
이를 통해 장애가 발생한다면, 장애가 발생한 그 시점부터 그 이후의 이벤트를 다시 처리할 수 있게 되는 것이다.
또한, 분산 시스템을 통해 엄청난 데이터들도 처리할 수 있다는 장접이 있다.
이로 인해 대규모 실시간 데이터 처리, 시스템 간 데이터 동기화, 로그 수집 등에 매우 유용하다.
정리
데이터 보존:
- 메시지 브로커: 메시지가 소비된 후 삭제된다.
- 이벤트 브로커: 모든 이벤트를 영구적으로 보관한다.
재사용성:
- 메시지 브로커: 메시지가 한 번 처리된 후에는 다시 사용할 수 없다.
- 이벤트 브로커: 이벤트는 여러 번 재처리하거나 다시 볼 수 있다.
대용량 처리:
- 메시지 브로커: 동시에 처리할 수 있는 메시지의 수에 제한이 있다.
- 이벤트 브로커: 대량의 이벤트를 동시에 처리할 수 있다.
