[Kafka] 1. Apache Kafka 개념 및 소개

Apache Kafka 개념 및 소개

• Apache Kafka는 LinkedIn에서 개발된 분산 메시징 시스템으로, 대용량 실시간 로그처리에 특화된 아키텍처 설계를 통해 기존 메시징 시스템보다 우수한 TPS를 보여주고 있다.
• Kafka는 RabbitMQ와 메시지 큐와의 성능에서 차이가 나며, 클러스터 fail-over, replication과 같은 여러가지 특징을 가지고 있다.

Kafka의 기본 구성요소 및 동작

Kafka의 구조

• Kafka는 발행-구독(publish-subscribe)모델을 기반으로 동작
• 크게 producer, consumer, broker로 구성
• topic을 생성하고 producer가 topic 메시지를 전달한다 > Broker는 Zookeeper를 통해 Topic별로 적재(파티션 별로 쪼개어 각 서버에 분산) -> topic을 구독하는 Consumer는 메시지를 받아서 처리한다.
• Topic에서 모든 메시지는 바이트의 집합이다. 이 집합은 배열로 표현되고, Producer는 Kafka Queue에 정보를 저장한다.
• 모든 Topic은 Partition으로 나뉜다.

• Kafka의 broker(중개인)는 topic을 기준을 메시지를 관리하고 Producer는 특정 topic의 메시지를 생성하고 해당 메시지를 broker에게 전달한다.
• broker가 전달받은 메시지를 topic별로 분류하여 쌓아놓으면 해당 topic을 구독하는 consumer들이 메시지를 가져가서 처리한다
• kafka cluster는 Multi broker로 구성되고, 클러스터에 대한 메시지 읽기와 쓰기 작업의 부하분산(Load-Balancing)을 돕는다.
• 각 Broker는 상태를 저장하지 않지만(stateless) Zookeeper를 이용하여 상태정보를 유지한다.

Kafka는 확장성(scale-out)과 고가용성(high availablility)를 위해 broker들이 클러스터로 동작하게 설계되었다. broker가 한 개밖에 없어도 클러스터로 동작하고 broker에 대한 분산처리는 Apache ZooKeeper가 담당한다.

기존 Messing System과 차이점

• 대용량 실시간 처리 로그에 특화되어 TPS가 우수
• 범용 메시지 시스템에서 제공하는 다양한 기능들은 제공되지 않는다.
• 분산 및 복제 구성을 손쉽게 할 수 있다.
• AMQP 프로토콜이나 JMS API를 사용하지 않고 단순한 헤더 메시지를 지닌 TCP 기반 프로토콜을 사용하여 프로토콜에 의한 오버헤드를 감소.
• Producer가 broker에게 다수의 메시지를 전송할 때 다수의 메시지를 batch형태로 broker에게 한 번에 전달 할 수 있어 TCP/IP Round trip 횟수를 줄일 수 있다.
• 메시지를 메모리에 저장하지 않고 파일 시스템에 저장한다.
  • 파일 시스템에 저장하기 때문에 데이터의 영속성(durability)이 보장
  • 기존 메시징 시스템에서 처리되지 않고 남아있는 메시지의 수가 많을 수록 시스템의 성능이 크게 감소하였으나, Kafka에서는 메시지를 파일 시스템에 저장하기 때문에 메시지를 쌓아두어도 성능이 크게 감소하지 않는다.
  • 많은 메시지를 쌓을 수 있어서 실시간 처리 및 주기적인 batch 작업에 사용할 데이터를 쌓아두는 용도로 사용할 수 잇다.
  • consumer에 의해 처리된 메시지(acknowledged message)를 곧바로 삭제하는 기존 메시징 시스템과 달리 처리된 메시지를 삭제하지 않고 파일시스템에 그대로 두엇다.
• 기존 메시징 시스템에서는 broker가 consumer에게 메시지를 push해 주지만, Kafka는 consumer가 broker로부터 직접 메시지를 가지고 pull 방식으로 동작한다. 따라서 consumer는 자신의 처리 능력만큼의 메시지만 broker로부터 가져오기 때문에 최적의 성능을 낼 수 있다.
  • Kafka는 consumer가 직접 필요한 메시지를 broker로부터 pull하므로 broker의 consumer와 메시지 관리에 대한 부담이 적다.
  • 메시지를 pull방식으로 가져오므로, 메시지를 샇아두었다가 주기적으로 처리하는 batch consumer의 구현이 가능하다.

Kafka의 4가지 Core APIs

• Producer API(메시지 송신 API) : 하나 이상의 Kafka topics에 대한 recoard 스트림을 발행 할 수 있다.
• Consumer API(메시지 수신 API) : 응용프로그램에서 하나 이상의 topics을 구독하고 record 스트림을 처리할 수 있다.
• Streams API(스트림 API) : 어떤 어플리케이션을 스트림 프로세서로 작동할 수 있고, 하나 이상의 topics을 스트림에 소비하여 하나 이상의 출력 스트릠에 생성하며, input stream과 output stream을 효율적으로 변환한다.
• Connector API : Kafka topics에 기존 어플리케이션 또는 데이터 시스템들을 연결하여, 재사용할 수 있는 생산자들 또는 소비자들이 구축하고 실행할 수 있다. 예를들면 RDBMS에 커넥터는 테이블에 대한 모든 변경사항을 점유(capture)할 수 있다.

Kafka는 client와 server간의 통신을 간단하게하며, 고성능이며, 언어에 구애받지않는 TCP protocol로 수행한다.
Protocol은 하위 버전과의 호환성을 유지하며 관리된다.

• Broker : topic을 기준으로 메시지를 관리하며 클러스터를 구성(분산처리는 zookeeper가 담당)한다. broker는 Producer와 Consumer가 서로 통신할 수 있도록 중개하고 메시지를 관리하는 서버 클러스터로 Producer가 받은 메시지를 Topic별로 분류하여 Consumer는 토픽별로 메시지를 가져다 쓸 수 있다.

Topic과 Partition

Kafka의 topic은 partition 단위로 쪼개어 클러스터의 각 서버에 분산되어 저장되고, 고가용성을 위하여 복제(replication) 설정을 할 경우 Partition 단위로 각 서버들에 분산되어 복제한다. 장애가 발생하면 partition 단위로 fail over가 수행된다.

Partition의 분산

• Producer가 메시지를 실제 어떤 partition으로 전송할지는 사용자가 구현한 partition분배 알고리즘에 의해 결정된다. Round-Robin(RR) 방식의 Partition분배 알고리즘을 구현하여 각 partition에 메시지를 균등하게 분배하도록 하거나 메시지 키를 활용하여 알파벳 A로 시작하는 키를 가진 메시지는 P0에만 전송하고 B로 시작하는 키를 가진 메시지는 P1에만 전송하는 형태도 가능하다.
  • Kafka는 고가용성을 위해 각 Partition을 복제하여 클러스터에 분산시킬 수 있다.
• Partition의 복제

Consumer와 Consumer Group

메시지 모델은 크게 Queue(큐)모델과 publish-subscribe(발행-구독)로 분류한다.

• Queue모델은 메시지가 쌓여 있는 Queue로부터 메시지를 가져와서 consumer pool에 있는 consumer중 한개의 메시지를 할당하는 방식이다.
• publish-subscribe 모델은 topic을 구독하는 모든 consumer에게 메시지를 broadcasting 하는 방식이다.

Kafka에서는 consumer group이라는 개념을 적용하여 두 가지 모델을 publish-subscribe모델로 일반화 했다.
kafka의 partition은 consumer group당 오로지 하나의 consumer의 접근만을 허용하며, 해당 consumer를 partition owner라고 부른다. 따라서 동일한 consumer group에 속하는 consumer끼리는 동일한 partition에 접근할 수 없다.

 

참조

 

https://kafka.apache.org/documentation/