Kafka와 Spark Streaming_(2, 3)

Kafka란?

• 실시간 데이터를 처리하기 위한 오픈소스 분산 스트리밍 플랫폼
  • 데이터 재생이 가능한 분산 커밋 로그 (Distributed Commit Log)
• Scalability와 Fault Tolerance를 제공하는 Publish-Subscription 메시징 시스템
  • Producer-Consumer
• High Throughput과 Low Latency를 실시간 데이터 처리에 맞게 구현
• 분산 아키텍처를 따르기 때문에 Scale Out이란 형태로 스케일 가능
  • 서버 추가를 통해 Scalability 달성 (서버 = Broker)
• 정해진 보유기한 (retention period) 동안 메시지를 저장

---

기존 메시징 시스템 및 DB와의 비교

• kafka는 메시지를 보유 기간 동안 저장
  • 소비자가 오프라인 상태일 때에도 내구성과 내결함성을 보장
  • 기본 보유 기간은 일주일
• kafka는 메시지 생산과 소비를 분리
  • 생산자와 소비자가 각자의 속도에 맞춰 독립적으로 작업이 가능하도록 함
  • 시스템 안정성을 높일 수 있음
• kafka는 높은 처리량과 저지연 데이터 스트리밍 제공
  • Scale-Out 아키텍처
• 한 파티션 내에서는 메세지 순서를 보장
  • 다수의 파티션에 걸쳐서는 'Eventually Consistent' - 페이먼츠 시스템에서 주로 사용
  • 토픽을 생성할 때 지정 가능 (Eventual Consistency vs Strong Consistency)
    • Eventually Consistency - 데이터의 복제를 기다리지 않고 바로바로 리턴하는 구조
    • Strong Consistency - 데이터를 쓸 때 복제가 완료될 때까지 기다리는 구조
• 데이터 처리량이 크고 다수의 소비자를 지원할 수 있어 사내 내부 데이터 버스로 사용

---

Kafka의 기능과 이점

• 스트림 처리
  • kafka는 실시간 스트림 처리를 목표로 만들어진 서비스
  • ksqlDB를 통해 SQL로도 실시간 이벤트 데이터 처리 가능
• High Throughput (높은 처리량)
  • kafka는 초당 수백만 개의 메시지 처리 가능
• Fault Tolerance (내결함성)
  • kafka는 데이터 복제 및 분산 커밋 로그 기능을 제공하여 장애 대응이 용이
• Scalability (확장성)
  • kafka의 분산 아키텍처는 클러스터에 브로커를 추가하여 쉽게 수평 확장 가능
• 풍부한 생태계의 존재
  • kafka는 커넥터와 통합 도구로 구성된 풍부한 에코시스템을 갖추고 있어 다른 데이터 시스템 또는 프레임워크와 쉽게 연동이 가능
  • Kafka Connect, Kafka Schema Registry

---

Kafka 아키텍처

데이터 이벤트 스트림

• 데이터 이벤트 스트림을 Topic이라고 부름
  
  • Producer는 Topic을 만들고 Consumer는 Topic에서 데이터를 읽어드리는 구조
  • 다수의 Consumer가 같은 Topic을 기반으로 읽어들이는 것이 가능

---

Message (Event) 구조 : Key, Value, Timestamp

• 최대 1MB
• Timestamp는 보통 데이터가 Topic에 추가된 시점
• Key 자체도 복잡한 구조를 가질 수 있음
  • Key가 나중에 Topic 데이터를 나눠서 저장할 때 사용 (Partitioning)
• Header는 선택적 구성요소로 경량 메타 데이터 정보 (key-value pairs)

---

Topic과 Partition

• 하나의 Topic은 확장성을 위해 다수의 Partition으로 나뉘어 저장
• 메세지가 어느 Partition에 속하는지 결정하는 방식에 키의 유무에 따라 달라짐
  • key가 없다면 Hashing 값을 Partition의 수로 나눈 나머지로 결정
  • key가 없다면 라운드 로빈으로 결정 (첫 번째 partition 부터 순차적으로 결정 - 비추천)

Topic과 Partition과 복제

• 하나의 Partition은 Fail-over를 위해 Replication Partition을 가짐
• 하나의 Topic은 다수의 Partition으로 구성 (Scalability)
• 각 Parttion 별로 Leader와 Follower가 존재
  • 쓰기는 Leader를 통해 이뤄지고 읽기는 Leader/Follwer들을 통해 이뤄짐
  • Partition 별로 Consistincy Level을 설정 가능 (in-sync relica - 'ack')

---

Broker (실제 데이터를 저장하는 서버)

• kafka 클러스터는 기본적으로 다수의 Broker로 구성
  • 여기에 원활한 관리와 부가 기능을 위한 다른 서비스들이 추가 (Zookeeper가 대표)
  • 한 클러스터는 최대 20만개까지 partition을 관리 가능
  • Broker들이 실제로 Producer/Consumer들과 통신 수행
• 위의 Topic의 Partition들을 실제로 관리해주는 것이 Broker
  • 하나의 Broker는 최대 4000개의 partition을 처리 가능
• Broker는 물리서버 혹은 VM 위에서 동작
  • 해당 서버의 디스크에 Partition 데이터들을 기록
• Broker의 수를 늘림으로써 클러스터 용량을 늘림 (Scale Out)
• 20만개의 partition과 4000개의 제약은 Zookeeper를 사용하는 경우
  • 해당 문제를 해결하기 위해 더 많은 partition을 대체하는 KRaft도 존재

Broker와 Partition

• Kafka Broker를 Kafka Server 혹은 Kafka Node 라고 부르기도 함
• 메타 정보 관리 방법
  • Broker 리스트 관리 (Broker Membership)
    • Controller = Controller Election
  • Topic 리스트 관리 (Topic Configuration)
    • Topic을 구성하는 Partition 관리
    • Partition 별 Replica 관리
  • Topic 별 ACL (Access Control Lists) 관리
  • Quota 관리

Partition과 Segment

• 하나의 Partition은 다수의 Segment로 구성
  • Segment는 변경되지 않는 추가만 되는 로그 파일이라고 볼 수 있음 (Immutable, Append-Only_
    • Commit Log
       - Sequential, Immutable, Append-only
       - WAL (Write Ahead Logging)
       - Replication과 Fault Tolerance의 최소 단위
       - Data Recovery나 Replay에 사용 가능
• 각 Segment는 디스크상에 존재하는 하나의 파일
• Segment는 최대 크기가 있어서 이를 넘어가면 새로 Segment 파일을 만들어냄
  • 각 Segment는 데이터 오프셋 범위를 가짐
• 로그 파일의 특성 (Partition의 특성 -> 정확히는 Segment의 특성)
  • 항상 뒤에 데이터 (Message)가 쓰여짐 : Append Only
  • 한 번 쓰여진 데이터는 불변 (Immutable)
  • Retention period에 따라 데이터를 제거하기도 함
  • 데이터에는 번호(offset)가 주어짐

---

Zookeeper

• 분산 시스템에서 널리 사용되는 Distributed Coordination Service
  • 동기화, 구성 관리, 리더 선출 등 분산 시스템을 관리하고 조율을 위한 중앙 집중 서비스 제공
• 다양한 문제들이 존재
  • 지원하는 데이터 크기가 작고 동기모드로 동작하기에 처리 속도가 느림
  • 환경 설정 복잡
  • Zookeeper를 사용하던 서비스들이 다른 서비스를 사용
• 사용 사례
  • 메시지 큐를 위한 Apache Kafka
  • 분산 데이터베이스 조정을 위한 Apache HBase
  • 분산 스트림 처리를 위한 Apache Storm