[Kafka] Apache Kafka란?

Apache Kafka(아파치 카프카)는 LinkedIn에서 개발된 분산 메시징 시스템으로써 2011년에 오픈소스로 공개되었다. 대용량의 실시간 로그처리에 특화된 아키텍처 설계를 통하여 기존 메시징 시스템보다 우수한 TPS를 보여주고 있다.

Kafka란?

• 분산 스트리밍 플랫폼
• 데이터 파이프 라인 구성시, 주로 사용되는 오픈소스 솔루션
• 대용량의 실시간 로그처리에 특화되어 있는 솔루션
• 데이터를 유실없이 안전하게 전달하는 것이 주목적인 메세지 시스템
• 클러스터링이 가능하므로, Fault-Tolerant한 안정적인 아키텍처와 빠른 퍼포먼스로 데이터를 처리
• 수평적으로 서버의 Scale-Out이 가능함
• pub-sub모델의 메세지 큐

* Fault-Tolerant :  시스템내,  Fault (장애)가 발생하더라도 시스템에 지장을 주지 않도록 설계된 컴퓨터 시스템
* Scale-Out : 서버의 대수를 늘려서 성능을 향상시키는 방법

---

1. Pub-Sub 모델 

• Publish - Subscribe (발행/구독) 모델은 메세지를 특정 수신자에게 직접적으로 보내주는 시스템이 아님
• publisher는 메세지를 topic(어떠한 집단을 말함)을 통해서 카테고리화 함
• 분류된 메세지를 받기 원하는 receiver는 그 해당 topic을 구독(subscribe)함으로써 메세지를 읽어 올 수 있음
• 즉, publisher는 topic에 대한 정보만 알고 있고, 마찬가지로 subscriber도 topic만 바라봄
  
• 정리하면, 데이터를 관리하는 Kafka 서버를 사이에 끼고 데이터를 넣는 publisher와 데이터를 읽는 subscriber는 각자의 업무만 kafka 서버를 통해 수행하므로 서로 모르는 상태
• Kafka 클러스터를 중심으로 프로듀서가 데이터를 push하고 컨슈머가 데이터를 pull하는 구조
  (git hub에 push하고 pull하는 과정과 같음)

 

출처: http://kafka.apache.org/081/documentation.html

 

2. 디스크 순차 저장 및 처리

• 메세지를 메모리에 저장하는 기존 메시징 시스템과는 달리 메세지를 파일 시스템에 저장
• 파일 시스템에 메세지를 저장하기 때문에 별도의 설정을 하지 않아도 데이터의 영속성(durability)이 보장됨.
• 디스크가 순차적으로 저장되어 있으므로 디스크 I/O가 줄어들어 속도가 빠름

 

3. Kafka 구조 및 구성요소

출처 : http://blog.mmlac.com/log-transport-with-apache-kafka/

 

• 위의 그림에서 가운데 부분은 Kafka Broker와 Zookeeper로 구성되어 있는데, Kafka Broker가 바로 Kafka 서버이고, Zookeeper는 Kafka Cluster를 구성할 수 있도록 분산 코디네이션 시스템 역할을 한다.
• 위 그림에서는 Kafka Broker와 Zookeeper로 구성되어 있는 것이 3개가 있는데, 이것들을 묶어서 Kafka Cluster라고 부른다. 
• Kafka Broker 와 Zookeeper는 다른 서버에 설치하여 운영하는 것을 추천하는데, 이유는 만약 Zookeeper에서 시스템 오류가 발생한 경우 Kafka Broker에게 영향을 주지 않기 위해서이다.
• Kafka의 topic은 partition이라는 단위로 쪼개어져 Kafka Cluster의 각 서버들에 분산되어 저장된다.
• partition에는 데이터들이 순차적으로 저장되며, Kafka 서버는 해당 데이터를 설정 시간에 따라 보관한다. +) 기본값 7일

출처 : http://kafka.apache.org/081/documentation.html

• 각 partition은 0부터 1씩 증가하는 offset 값을 메세지에 부여하는데, 각 partition의 메세지를 식별하는 ID로 사용된다. +) message_id = offset_no
• offset 값은 partition마다 별도로 관리되므로 topic내에서 메세지를 식별시, partition 번호와 offset 값을 함께 사용한다. ex) 위의 그림에서 방금 쓰여진 메세지들은 (partition_no, offset_no) = (0,12) / (1,9) / (2,12)라고 할 수 있음.
• 이러한 구조로 쓰여진 메세지는 해당 topic을 구독한 consumer가 소비한다. consumer가 가져다가 사용하는 구조이기 때문에 consumer 스스로가 소비하는 속도를 조절할 수 있다.
• consumer들의 묶음을 consumer group이라고하는데, 특정 partition에는 consumer group당 오로지 하나의 consumer만 접근이 가능하다. 즉, 동일한 consumer group에 속하는 consumer끼리는 동일한 partition에 접근할 수 없다. 이때, 특정 partition에 접근하는 consumer를 partition owner라고한다.
• consumer가 message의 offset 번호를 기억하고 있다가, 다음 메세지를 읽어올때 offset 번호를 이용해서 읽어올 수 있다. 여기서 알아둬야할 것은, 한 consumer group 내부의 consumer 끼리는 각자 접근하고 있는 partition의 메세지 offset 값을 공유하고 있어서, 어떤 consumer에서 장애가 발생하면, 다른 consumer가 장애가 발생한 consumer의 offset값을 알고 있기때문에 해당 consumer 대신 메세지를 소비한다.
• 한 번 정해진 partition owner는 Kafka broker나 consumer 구성의 변동이 있지 않는한 계속 유지된다.
• consumer와 partition의 대칭 비율은 1:N이며, consumer가 partition의 수 보다 많은 경우는 사용되지 않는 consumer가 생기고, partition의 수가 consumer의 수보다 많은 경우는 하나의 consumer가 2개 이상의 partition에 접근할 수 있다. 그래서 partition과 consumer의 수를 조절할 필요가 있다.

출처 : http://kafka.apache.org/081/documentation.html

• 위의 그림과 같이 consumer group에 다수의 consumer를 할당하면 각 consumer마다 별도의 partition으로부터 메시지를 받아오기 때문에, (producer가 각 partition에 메시지를 균등하게 분배한다고 가정할 경우) consumer group은 큐 모델로 동작하게 된다.
• 단일 consumer로 이루어진 consumer group을 활용하면 다수의 consumer가 동일한 partition에 동시에 접근하여 동일한 메시지를 액세스하기 때문에 발행-구독 모델을 구성할 수 있다. ex) 하나의 채팅방에 여러명이 접근
  
  • 하나의 consumer에 의하여 독점적으로 partition이 액세스 되기 때문에 동일 partition 내의 메시지는 partition에 저장된 순서대로 처리된다. 만약 특정 키를 지닌 메시지가 발생 시간 순으로 처리되어야 한다면 partition 분배 알고리즘을 적절하게 구현하여 특정 키를 지닌 메시지는 동일한 partition에 할당되어 단일 consumer에 의해 처리되도록 해야한다. ex) 순서가 중요한 증권사 시스템 같은 경우 필요할 것으로 보임
  • 다른 partition에 속한 메시지의 순차적 처리는 보장되지 않기에, 특정 topic의 전체 메시지가 발생 시간 순으로 처리되어야 할 경우 해당 topic이 하나의 partition만을 가지도록 설정해야 한다.
• Kafka는 각각의 Kafka Broker에서 topic들을 관리하는데, 아래의 그림과 같이 하나의 topic을 여러개의 paritition으로 나누어서 각각의 Kafka Broker에 저장할 수 있다. 

각 topic의 parition들이 분산되어 저장된 형태

• Kafka는 여러 상황을 대비하여 partition을 같은 Cluster안에 다른 Broker에 복사하여 저장할 수 있는데, 이때 필요한 것이 replication - factor 설정 값이다.  replication - factor는 간단히 말해, 얼마만큼 partition을 복사할 것인지 설정하는 것이다.
• 위에 그림과 같은 상황에서 replication - factor = 3이면, 총 6개의 partition이 각 서버에 3개씩 생기기 때문에 아래의 그림과 같이 총 18개의 파티션이 생기는 것이다. 
• 여기서 알아둬야할 것은 replicatition - factor는 topic 단위의 설정 값이다. ex) red는 3, blue는 2로 설정 가능

replication-factor의 설정 값에 맞게 partition 복사가 이루어진 상황

• Red topic을 예로 들어 설명하자면, 첫번째 Broker에서 P0-1이 두번째 Broker에 P0-2로 복사되었고, 또 다시 세번째 Broker에 P0-3으로 복사된 것이다. 이때, 각 partition들은 3개의 replica를 가진것이다.
• 이때, 주의깊게 볼것은 검은테두리로 씌워진 partition인데, 이 partition이 바로 leader이고 테두리가 씌워져 있지않은 partition은 follower이다.
• 메세지를 partition에 쓰고 읽는 행위는 leader을 통해서만 수행할 수 있고, follower는 leader의 복사본일 뿐이다. 그렇다고 follower가 해당 용도로만 사용되는 것은 아니다. 여기서, leader와 follower로 구성된 것을 ISR(In Sync Replica)라고 한다.
• 만약 leader에서 장애가 발생하였다면, 해당 partition을 복사한 follower들 중에서 하나가 새로운 leader가 된다.

P0 partition의 기존 리더에서 장애가 발생하여 follwer중 새로운 leader 선출

• 위와같이 새로운 leader가 선출되면 해당 leader를 통해서만 메세지 읽기, 쓰기가 가능한 것이다.

 

Keyword 간단정리

• Kafka Broker = Kafka 서버
• Zookeeper = 분산 코디네이션 시스템(Kafka 서버 구성에 있어, 필수)
• Kafka Cluster = (Kafka Broker + Zookeeper) x N
• Producer(publisher) = 데이터를 Kafka Cluster에 적재하는 주체
• Consumer(subscriber) = Kafka Cluster로 부터 데이터를 읽어오는 주체
• Consumer Group = Consumer의 집합, Consumer x N
• Topic = Kafka Broker에서 사용하는 데이터(메세지)의 카테고리이며, Partition의 집합, Partition x N
• Partition = 메세지의 집합, Topic으로 묶여서 관리됨. Message x N
• Offset = Partition마다 관리되는 메세지의 인덱스
• Leader = 메세지를 읽고 쓰는 것이 가능한 partition
• Follower = Leader의 복제이며, 잠재적 leader

 

참조

[Kafka, 카프카] 아파치 카프카(Apache Kafka) 아키텍처 및 동작방식, 파티션 읽기 쓰기(Partition Read and W

Kafka 이해하기

[Apache Kafka] 1. 소개및 아키텍처 정리

Kafka 운영자가 말하는 Topic Replication | Popit