[OpenSource] Apache Kafka

Table of content

• 1. What is the Apache Kafka
• 2. Benefits of Apache Kafka
• 3. Apache Kafka 아키텍처
  • 3.1. 주체 단위 아키텍처
    • 3.1.1. Producer
    • 3.1.2. Broker
    • 3.1.3. Zookeeper
  • 3.2. 데이터 단위의 아키텍처
    • 3.2.1. Topic
    • 3.2.2. Partition
    • 3.2.3. Offset
• 4. Failover 과정
• 5. 가장 이상적인 Kafka 아키텍처

1. What is the Apache Kafka

Apache Kafka는 대량의 데이터를 처리할 수 있으며, 엔드포인트간 메시지를 전달 할 수 있는 분산 발행-구독 메시징 시스템이다. Kafka 메시지는 스토리지에 유지되고 데이터 복제를 통해 데이터 손실을 방지 할 수 있다. ZooKeeper라는 동기화 서비스 기반의 시스템이며, 실시간 데이터 스트리밍 분석 툴인 Apache Storm과 Spark와 통합되어 자주 사용된다.

 

 

2. Benefits of Apache Kafka

• 신뢰성 : 데이터의 분산, 분할, 복제를 통해 데이터의 신뢰성을 보장한다.

• 확장성 : topic의 발행만으로 down time 없이 쉽게 확장이 가능하다

• 내구성 : 분산된 commit log를 통해 클러스터간 동기화를 하며, failure시 이 로그를 통해 빠른 복구가 가능하다.

• 퍼포먼스 : TB단위의 메시지가 시스템에 저장되어도 안정된 퍼포먼스를 제공한다.

 

 

 

 

 

 

3. Apache Kafka 아키텍처

 

 

 

3.1. 주체 단위 아키텍처

 

3.1.1. Producer

• 하나 이상의 topic으로 메시지를 발행하여 broker로 전송한다.

• 각 메시지는 key, value, timestamp로 이루어져 있다.

• 새로운 메시지를 publish 할 때, 몇개의 파티션으로 나눌 것인지 결정한다. (이미 발행 된 메시지에 대해서 도 가능)

출처 : https://kafka-python.readthedocs.io/ (Kafka-Python API Document Homepage)

 

 

 

3.1.2. Broker

(한 VM 안에 있는 broker 전체집합을 카프카라고 한다.)

• producer에게서 받은 메시지를 세부 설정(파티션, 오프셋 정책…)에 따라서 저장하는 역할

• 저장된 메시지는 정책에 따라 관리되며, consumer의 메시지 pull요청에 의해서만 메시지를 전송할 수 있다.

• 클러스터 내부에 대표 브로커를 선정하여 controller의 역할을 부여한다.

• Controller는 클러스터 내부 모든 브로커에 대해 partition을 관리한다.

• 1.0버전 부터는 offset 정보를 broker에서 관리한다.

 

 

 

3.1.3. Zookeeper

• 클러스터 내부의 브로커 간 통신하기 위해서는 zookeeper를 거쳐야 한다.

• VM 내부의 브로커들이 구동되기 위해서는 zookeeper가 반드시 선행으로 실행되어야 한다.

• 다른 VM의 Zookeeper와 논리적으로 결합되어 있다.

• 외부에서 들어온 요청에 대해서 해당 Leader Partition이 존재하는 브로커로 연결시켜준다.

 

 

 

3.2. 데이터 단위의 아키텍처

 

3.2.1. Topic

• 메시지가 분류되는 키워드.

• 쉽게 말하면 메시지의 주제를 의미한다.

• 하나의 토픽은 여러개의 파티션으로 구성되어 있다.

 

 

 

3.2.2. Partition

• 토픽 발행 시, partitioning factor * replication factor의 수만큼 partition이 생성된다.

• Partition에는 2가지 유형이 있다.

  • Leader Partition : 한 토픽의 구성에 대해 외부와 인터페이스를 담당하는 Partition이다. 데이터 조회시, 이 반드시 leader Partition을 통해 데이터를 얻을 수 있으며, Partition Factor의 수만큼 Leader Partition이 생성된다.

  • Follower Partition : Leader Partition의 failure에 대비한 예비 leader Partition이다. Leader가 failure시, 이들 중 하나가 자동으로 Leader로 승급된다.

  • Follower는 Leader의 변경사항을 pull받는 방식으로 synchronize한다. 이러한 방식을 카프카에서는 ISR(In Sync Replica)라고 명명한다.

  • Follower는 Leader에 대해 pull 방식으로 동기화를 하며, 리더는 이 동기화 요청을 일정시간 받지 못하게 되면 ISR에서 해당 partition을 제외시키게 된다.

• Partitioning 한만큼, 데이터 병렬처리가 이루어지기 때문에 처리속도가 빨라진다.

3개의 공을 한명의 포수가 받는 시간과 3명이 나누어서 받을 때 걸리는 시간을 비교해보자.

 

 

 

3.3.3. Offset

• Kafka의 최소 데이터 단위

• 1 Message publish = 1 Offset

• Producer의 Partitioning Algorithm에 따라 데이터가 위치할 Partition이 결정된다.

• 오프셋별로 commit log가 남아 이를 이용하여 Fail Over를 수행한다.

• 별도의 카프카 데이터 보존 정책에 의해 데이터를 유지한다.

 

 

 

 

 

4. Failover 과정

 

FailOver가 어떻게 이루어지는지에 대해 아키텍처 기반으로 설명하겠다.

다음 그림은 2개의 토픽에 대해 “replication factor = 3, partition factor = 2”의 설정으로 메시지가 발행되어 정상적으로 Broker서버에 저장되어 있는 상태이다.

 

 

 

 

위 아키텍처에서 Broker 0 과 Broker 3에서 장애가 나면 아키텍처는 다음 그림과 같아진다. 이 때, Topic1의 P0 Partition과 Topic2의 P1 Partition의 Leader Partition이 Broker가 장애가 나면서 더이상 Partition에 대해 접근을 할 수 없게 되었다.

 

 

하지만, Kafka에는 다음과 같은 규칙이 있다.

“모든 Partition은 Leader Partition이 될 수 있다.“

 

위 규칙에 의해 Kafka 내부 알고리즘에 의해 기존에 존재하던 Follower Partition이 새로운 Leader로 뽑히게 되어 다음 그림과 같이 장애에 대해 자동으로 Failover가 수행된다.

 

 

 

 

5. 가장 이상적인 Kafka 아키텍처

 

지금까지의 내용을 기억한다면, 데이터에 대한 접근은 오직 “Leader Partition“에 대해서만 접근이 이루어진다는 것을 알 수 있다. 그러므로, Leader Partition이 클러스터 내부의 broker에 골고루 분포가 된다면 한 broker로 트래픽이 몰려 timeout이나 다른 에러가 나는 상황을 방지 할 수 있다.

다시 말해, Leader Partition을 최대한 많은 브로커에 분산시켜 트래픽에 대한 병목 현상을 방지하며, failover에 대해서도 이를 유지할 수 있는 아키텍처가 이상적인 아키텍처이다.

또한 설계하기 나름이지만, offset 설계를 잘하여 데이터의 정합성까지 지켜준다면 가상 이상적인 아키텍처가 될 것이다.