1. 개발

링크드인에서 개발되었고 카프카 개발자 3명이 분사하여 콘플루언트를 창업하였다. 현재는 아파치를 통해 제공되고 있다.

2. 소개

분산 메시징 시스템으로 대용량 스트림 정보를 처리하기 위한 오픈 소스 프로젝트이다.

ActiveMQ, RabbitMQ 등의 기술과 비교되지만 대량 처리에 특화되어 있어 기존 MQ에 비해 TPS가 우수하다. 역으로 범용적인 MQ가 제공하는 다양한 기능은 제공되지 않을 수 있다.

또 오버헤드를 줄이기 위해 단순한 메시지 헤더 기반의 TCP 프로토콜을 사용하므로 AMQP, JMS API 등은 지원하지 않는다.

클라우드 단에서는 AWS Kinesis와 비교되기도 한다.

메시지를 기본적으로 메모리에 저장하는 제품들도 있는데 카프카는 메시지를 파일 시스템으로 저장함. 따라서 데이터 영속성을 보장한다.

처리되지 않고 남아있는 메시지가 많으면 기존 제품들은 성능 저하가 발생하지만 카프카는 파일 처리 방식이라 크게 영향 없다. 처리된 메시지를 바로 삭제하는 제품들과 달리 처리된 메시지를 삭제하지 않는다. 단지 설정된 수명이 다하면 삭제된다. 혹시 나중에 다시 메시지를 처리하고자 할 때 (처리 로직 변경 등) 유용하다.

그렇다고 무한정 보관되는 것은 아니기 때문에 카프카에서 소멸되기 전 하둡이나 기타 파일 디비 등으로 아카이브해야 한다.

데이터를 분석하고 시각화하고자 한다면 ELK(Elasticsearch, Logstash, Kibana) 도입이 가능하다.

3. Producer - Consumer

Publish-Subscribe 모델 기반으로Producer, Consumer, Broker로 구성된다.

Producer가 Topic에 메시지 생성하여 Broker에게 전달하고, Broker는 전달받은 메시지를 Topic별로 쌓아놓으면, 해당 Topic을 구독하는 Consumer들이 메시지를 가져간다. Producer가 Broker에게 메시지 전달 시 기존 MQ는 각 메시지를 개별적으로 전달해야 했지만 카프카는 배치 형태로 Broker에게 한번에 전달할 수 있어서 RT 수를 줄일 수 있다.

다른 제품들은 Broker가 Consumer에게 push 하는 방식이지만, 카프카는 Consumer가 Broker로부터 직접 메시지를 가져오는 pull 방식이다.

Consumer 자신의 처리 능력만큼만 메시지를 가져온다. 따라서 Broker가 Consumer가 어떤 메시지를 처리해야 하는지 계산하고 처리 중 메시지를 트래킹할 필요가 없으므로Broker의 부하가 줄어든다. 메시지를 pull 방식으로 처리하기 때문에 Batch Consumer 구현이 가능하다.

메시지를 메모리에 저장하지 않기 때문에 JVM의 부담이 줄어든다. GC도 줄인다.

카프카는 Scale-out과 HA 지원을 위해 Broker들이 클러스터로 동한다.

Broker가 단 1개여도 클러스터로 동작하는데, 클러스터 내 Broker에 대한 분산처리는 주키퍼가 담당한다. 그래서 카프카를 설치할 때는 주키퍼부터 깐다.

카프카 클러스터에서 파티션은 보통 8~20개로 분리하여 사용한다. 파티션은 0번부터 시작하고 카프카의 최소 단위는 offset이다. (offset -> 파티션 -> Topic -> Broker -> 클러스터)