Programmers TIL

[Kafka] Kafka 아키텍처 _TIL

PTJ 2023. 7. 12. 12:06

데이터 이벤트 스트림

- 데이터 이벤트 스트림을 Topic이라고 부름

  • Producer는 Topic을 만들고 Consumer는 Topic에서 데이터를 읽어들이는 구조
  • 다수의 Consumer가 같은 Topic을 기반으로 읽어들이는 것이 가능
  • Topic마다 데이터 보존 기한 및 정책이 있음 (default. 7day)

 

- 이벤트 스트림을 구성하는 요소 (Message) : Key, Value, Timestamp

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

 

- Topic과 Partition

  • 하나의 Topic은 확장성을 위해 다수의 Partition으로 나뉘어 저장됨
  • 메세지가 어느 Partition에 속하는지 결정하는 방식에 키의 유무에 따라 달라짐
    • 키가 있다면 Hashing 값을 Partition의 수로 나눈 나머지로 결정
    • 키가 없다면 라운드 로빈으로 결정 (비추)
  • 하나의 Partition은 Fail-over를 위해 Replication Partion을 가짐
  • 각 Partition별로 Leader와 Follower가 존재
    • 쓰기는 Leader를 통해 이뤄지고 읽기는 Leader/Follower들을 통해 이뤄짐
    • Partition별로 Consistency Level을 설정 가능 (in-sync replica - "ack")

 

- Topic 파라미터들 (ref. https://kafka.apache.org/documentation/#topicconfigs)

  1. 이름: "MyTopic"
  2. Partitiond의 수: 3
  3. 복제본의 수: 3
  4. Consistency Level("acks"): "all"
  5. 데이터 보존 기한: 기본 일주일
  6. 메세지 압축 방식
  7. ...

 

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

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

 

- 메타 정보 관리를 어떻게 할 것인가?

  • Broker 리스트 관리 (Broker Membership)
    • 누가 Controller인가? (Controller Election)
  • Topic 리스트 관리 (Topic Configuration)
    • Topic을 구성하는 Partition 관리
    • Partition별 Replica관리
  • Topic별 ACL(Access Control Lists)관리
  • Quota 관리

 

- Zookeeper와 Controller

  • Kafka 0.8.2 (2015년)부터 Controller가 도입됨
    • Controller는 Broker이면서 Partition관리
  • 장기적으로 Zookeeper의 사용을 최소화하거나 사용 자체를 없애려는 것이 목표
  • 현재로는 두가지 모드가 존재
    • Zookeeper 모드
      • 3, 5, 7대의 서버를 Zookeeper Ensemble을 구성하기 위해 사용
      • Controller가 Zookeeper를 통해 메타데이터 관리와 리더 선출 담당
      • 하나의 Controller가 존재
    • KRaft 모드
      • Zookeeper를 완전히 배제 Controller가 역할을 대신 수행
      • 다수의 Controller들이 Zookeeper역할을 대신 수행
        • Controller들은 보통 Broker들이기도 함
더보기

* Zookeeper란?

  • 분산 시스템에서 널리 사용되는 Distributed Coordination Service
    • 동기화, 구성 관리, 리더 선출 등 분산 시스템의 관리하고 조율을 위한 중앙 집중 서비스 제공
  • 원래 Yahoo! Hadoop 프로젝트이 일부로 자바로 개발됨
    • 이후 Apache 오픈소스 소프트웨어로 변신
  • 하지만 다양한 문제 존재
    • 지원하는 데이터 크기가 작고 동기모드로 동작하기에 처리 속도가 느림
      • 즉 어느 스케일 이상으로 확장성이 떨어짐
    • 환경설정도 복잡함
    • 그러다보니 Zookeeper를 사용하던 서비스들이 Zookeeper를 대체하기 시작
      • ElasticSearch가 또 다른 예
  • Zookeeper의 일반적인 사용 사례
    • 메세지 큐를 위한 Apache Kafka
    • 분산 데이터베이스 조정을 위한 Apache HBase
    • 분산 스트림 처리를 위한 Apache Storm
    • ...