Apache Kafka는 아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트로 pub/sub 모델의 메시지 큐를 지원한다.
마이크로서비스 아키텍처에서 메시지 브러커는 Message Backing Service로써 동작하며, 메시지의 처리를 통해 비동기 애플리케이션, DB 동기화, 보상트랜잭션 구현, PUB/SUB 구현 등 다양한 형태의 애플리케이션으로 응용될 수 있다.
Kafka는 대표적인 메시지 브로커로써, RabbitMQ와 많이 비교된다.
일반적으로 RabbitMQ는 대표적인 신뢰성 높은 메시지 브로커로써 각광받는다. 장애 발생 시에도 데이터 복원이 쉽고, 반드시 한번의 전송을 보장한다. 다만 성능면에서 Kafka 보다 떨어진다.
Kafka는 대용량 실시간 처리에 특화되어 있다. 특히 대량의 Batch Job을 일괄 처리하는데 적합하다.
지금부터는 Kafka 아키텍처와 구축 단계, Kafka를 이용한 메시지 브로커 애플리케이션 개발 과정에 대해 살펴보도록 하자.
기존 JMS로 대표되는 Message Backing Service 모델은 Queue, Pub/Sub 구조로 구분된다. 이 중 Kafka는 Pub/Sub 구조를 구현하였으며, 강력한 대용량 처리 성능과 실시간 처리을 위한 스트리밍 데이터를 전송할 수 있도록 구조를 설계하였다. Kafka는 Queue, Pub/Sub의 기본 컨셉을 그대로 구현하면서 각 모델의 단점을 극복하고 동시에 두 가지 방법론을 모두 통합 할 수 있는 유연성을 제공한다.
Queues 방식은 단일 송신자가 단일 수신자에게 데이터를 전송하는 방식이다. 큐에 저장된 메시지는 한명의 수신자에 의해 한번만 읽을 수 있으며, 읽혀진 메시지를 큐에서 제거한다. Queue 방식은 한번 읽고 지워지는 Event-Driven 방식에 적합하다.
Pub/Sub 구조는 여러 송신자가 메시지를 발행하고 여러 수신자가 구독하는 방식이다. 모든 메시지는 Tipic을 구독하는 모든 수신자들에게 전송이 가능하도록 되어있다. 사실 전송이 아닌 수신자가 Polling하는 방식으로 구성되어 있다고 볼 수 있다.
이와 같이 Message Backing Service는 생산자와 소비자 간의 결합도를 낮추지만, 확장성은 한계가 있다. 또한 Pub/Sub 구조의 낮은 결합도는 메시지의 신뢰도를 낮추는 영향을 주기도 한다. 모든 메시지가 모든 수신자에게 전송되도록 하기 위한 메커니즘이 설계되어야 하고, 이는 메시지를 제공하는 Broker에 따라 다른 기능으로 존재하게 된다.
Kafka는 앞서 살펴본 Queue와 Pub/Sub의 장점을 가지고 만들어졌다. 일반적인 구조는 Pub/Sub을 구현하지만, Queue 구조를 동시에 표현할 수 있다.먼저 여러 소비자가 Consumer Group에 소속되고 topic을 구독할 때 오직 하나의 소비자만 그룹내에서 토픽의 메시지를 읽는다. 그리고 메시지는 broker 내부 토픽에서 사라지지 않고 보유되는데 이는 일반적인 Queue와 다른점이다.
이와 같은 특징은 Queue와 Pub/Sub의 구조를 동시에 구현할 수 있게 한다. 일반적인 Queue 방식을 구현하고 싶을 경우 하나의 Consumer Group에 모든 소비자가 들어있도록 구성하면 된다. 이렇게 구성하면 메시지는 하나의 소비자에게만 발행되기 때문이다.
즉 다음과 같은 구분점으로 Kafka를 설계할 수 있다.