Apache Kafka

Apache Kafka(이하 Kafka)는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합, mission-critical application(?)을 구축하기 위해 사용하는 오픈소스 분산 이벤트 스트리밍 플랫폼입니다. 저같은 경우엔 팀에서 데이터 파이프라인을 새로 구축하기 위해 사용하고 있습니다.

 

Kafka는 아래와 같은 특징을 가지고 있습니다.

• 높은 처리량
  • 2ms 이내로 메시지 전달
• 확장성
  • 1000 개 이상의 브로커
  • 하루에 수 조 개의 메시지 전달
  • 수 Petabyte의 데이터
  • 수십만 개의 파티션
• 영구 스토리지
  • 분산 클러스터
  • 지속성
  • Fault-Tolerant
• 고가용성
  • 클러스터를 효율적으로 확장하거나 지리적으로 분리된 클러스터들을 연결 가능
• 신뢰성
  • 순서 보장
  • 메시지 소실 없음
  • 효율적인 exactly-once processing
• 많은 커뮤니티 / 레퍼런스

주요 개념 및 용어

Event는 것은 무언가 발생했다는 것을 기록합니다. 이것은 record 또는 message라고도 불립니다. Kafka에서의 Event들은 기존의 다른 전통적인 메시징 시스템과 달리, 메시지들이 소비된 후 삭제되지 않고 유지됩니다. 대신 밑에 나올 Topic의 설정을 통해 얼마동안, 얼마나 저장하고 있을지 설정할 수 있습니다.

 

개념적으로, Event는 Key, Value, Headers(Optional metadata)로 구성됩니다.

ex)

• Event key: "Alice"
• Event value: "Made a payment of $200 to Bob"
• Event timestamp: "Jun. 25, 2020 at 2:06 p.m."

Producer는 Kafka에게 Event를 발행(publish)하는 클라이언트이고, Consumer는 이런 Event를 구독(subscribe)하는 클라이언트입니다. Producer와 Consumer는 완전히 디커플링되어있고, 서로에 대해 알지 못합니다. 이는 Kafka가 높은 Scalability를 달성하기 위한 핵심 설계입니다. 

ex) Producer는 Event를 발행하기 위해 Consumer를 기다릴 필요 없음

 

Event는 Topic에 조직화되고(organized) 영구적으로 저장(durably stored)됩니다. 'Topic: 폴더 - Event: 폴더 내의 파일들'이라고 생각하면 쉽습니다. Topic 내의 Event들은 언제든 필요하면 소비할 수 있습니다.

 

Topic들은 분할됩니다(partitoned). 즉, Topic은 서로 다른 Broker에 존재하는 여러 "bucket"에 분산됩니다. 이러한 데이터 분산배치는 클라이언트들로 하여금 한 번에 여러 Broker로부터 Read/Write할 수 있도록 하므로 확장성(scalability)에 매우 중요합니다. 새로운 Event가 특정 Topic에 발행되면, 이 Topic의 Partition 중 하나(또는 설정에 따라 여러 개)에 추가됩니다.

Figure: 이 예제의 Topic은 4개의 Partiton(P1–P4)을 가지고 있고, 두 개의 다른 Producer Client가 각각 독립적으로 네트워크를 통해 해당 Topic의 Partition들에 작성함으로써 새로운 Event들을 해당 Topic에 발행하고 있습니다. 같은 key(여기선 같은 색상으로 표현)를 가진 Event들은 같은 Partition에 추가되고 있습니다.  (Note: 두 Producer들은 특정 조건에서 같은 Partition에 Event를 추가할 수 있습니다)

이 때 같은 event key(e.g. 고객 ID, 차량 ID)를 가진 Event들은 같은 Partiton에 추가되며, Kafka는 해당 Topic-Partition의 Consumer로 하여금 Event 발생 순서에 맞게 수신하도록 보장합니다. 

 

데이터를 Fault-Tolerant하고 고가용성으로 구성하기 위해 모든 Topic들은 복제(Replication)될 수 있습니다 (심지어 지역 또는 데이터센터 전반에 걸쳐). 문제가 발생할 경우에 대비하여 데이터 복사본을 가지고 있는 여러 Broker를 유지합니다. 보통의 설정은 replication factor가 3입니다. (=Event가 항상 세 개 존재. 복제는 Topic-Partion 레벨에서 이루어짐) 

 

설계에 관한 부분은 Apache Kafka Design 섹션을 참고하면 좋습니다.

참고 문서

• https://kafka.apache.org/intro#intro_concepts_and_terms