Kafka

Kafka

아파치 카프카(Apache Kafka)는 아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트이다. 이 프로젝트는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표이다. 요컨대 분산 트랜잭션 로그로 구성된[2], 상당히 확장 가능한 pub/sub 메시지 큐로 정의할 수 있으며, 스트리밍 데이터를 처리하기 위한 기업 인프라를 위한 고부가 가치 기능이다.

https://ko.wikipedia.org/wiki/%EC%95%84%ED%8C%8C%EC%B9%98_%EC%B9%B4%ED%94%84%EC%B9%B4

 

 

 

위키피디아의 글을 보면 알 수 있듯, 카프카는 pub-sub 모델의 메시지 큐이다.

분산환경에 특화되어 설계되었고, 다른 메시지 큐보다 훨씬 빠르게 처리할 수 있다.

 

 

카프카의 아키텍처는 다음과 같다.

1. Broker : Kafke 서버. 한 클러스터 내에 여러 개가 존재할 수 있다.
2. Topic : 메시지가 생산되고 소비되는 주제
3. Partition : 토픽 내에서 메시지가 분산되어 저장되는 단위
4. Zookeeper : 여러 Broker의 분산 메시지 큐의 정보 관리

 

 

PUB-SUB 모델?

 

Publisher, Subscriber 이다. 즉, 직역하면 발행자와 구독자 모델이다.

 

PUB-SUB 모델은 메시지를 직접 수신자에게 전송하지 않는다.

발행자는 메시지를 카테고리화 시켜 분류한다. 그리고 분류된 메세지를 구독한 수신자만 그 메시지를 읽어올 수 있다.

 

이러한 구조는 발행자와 수신자 모두 직접 통신하지 않고, 오직 메시지의 카테고리만을 확인하게 만든다. 이로 인해 발행자와 구독자 모두 서로의 존재를 알지 못한다.

 

또한 여기에는 Consumer Group이라는 개념이 있다.

Consumer Group은 하나의 토픽을 담당한다. 즉, 토픽 자체는 여러 개의 Consumer Group이 접근할 수 있지만, 하나의 Consumer Group은 하나의 토픽만 접근할 수 있는 1:N의 관계이다.

 

Consumer Group의 존재 이유는 offset의 공유를 위해서이다. 그렇다면 왜 offset을 공유해야 하는가? 

 

각 개별 구독자에 파티션에 대한 접근을 허용했을 때 어느 구독자에서 갑작스럽게 에러가 발생한다면 어느 offset을 소비하고 있었는지 알 수 없게 된다.

 

하지만 Consumer들을 그룹으로 묶어 offset을 공유한다면? 어느 Consumer가 갑작스럽게 에러가 발생하더라도 공유 중인 offset을 이어받아 고가용성을 확보할 수 있게 된다.

 

 

카프카의 파티션

앞서 서술했듯 메시지는 카테고리, 즉 Topic으로 나뉜다. 그리고 Topic은 여러 개의 파티션으로 나눠질 수 있다.

+) 추가로 파티션은 로그라는 단위로 구성된다.

 

데이터는 한 칸의 로그에 순차적으로 추가된다. 여기서도 앞서 언급한 offset이라는 개념이 사용되는데, 그냥 리스트의 인덱스라고 생각하면 된다.

 

그렇다면 왜 굳이 하나의 토픽을 여러 개의 파티션으로 나눠야 하는 것일까? 이는 병렬 처리를 하기 위함이다.

 

하나의 토픽을 하나의 파티션에 몰아서 넣는 것보다, 여러 개의 파티션에 골고루 저장하고 각 파티션을 병렬로 처리하는 것이 시간적으로 당연히 이득이기 때문이다.