Kafka 아키텍처

 

 

3. Kafka 소개

Kafka가 무엇인지 소개하는 시간을 가져보자

 

 

 

 

 

 

 

Contents

1. Kafka 역사
2. Kafka 소개
3. Kafka 아키텍처
4. Kafka 중요 개념
5. Kafka 설치
6. Kafka Python 프로그래밍

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처

Kafka 아키텍처를 알아보면서 어떤 컴포넌트들로 구성되는지 알아보자

 

 

 

 

 

 

 

데이터 이벤트 스트림

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

○ Producer는 Topic을 만들고 Consumer는 Topic에서 데이터를 읽어들이는 구조
○ 다수의 Consumer가 같은 Topic을 기반으로 읽어들이는 것이 가능

○ 각 Consumer는 자신이 어디 까지 읽었는지 Off-set을 갖고 있습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

최대 1MB

 

Timestamp는 보통 데이터가 Topic에 추가된 시점

 

Key 자체도 복잡한 구조를 가질 수 있음

○ Key가 나중에 Topic 데이터를 나눠서 저장할 때 사용됨 (Partitioning)

○ Key를 기준으로 다수의 partition의 메시지들이 나눠서 저장

 

Header는 선택적 구성요소로 경량 메타 데이터 정보 (key-value pairs)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처 - Topic과 Partition

 

하나의 Topic은 확장성을 위해 다수의 Partition으로 나뉘어 저장됨

 

메세지가 어느 Partition에 속하는지 결정하는 방식에 키의 유무에 따라 달라짐

○ 키가 있다면 Hashing 값을 Partition의 수로 나눈 나머지로 결정 (권장)
○ 키가 없다면 라운드 로빈으로 결정 (비추천)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처 - Topic과 Partition과 복제본

앞서 설명드렸듯이 Topic은 Partition으로 나누어 저장되고 각 Partition 은 유실을 대비하기 위해 복제본이 존재하는데 이 복제본은 단순히 데이터 유실 방지만이 아닌 소비의 병렬성을 높이기 위해서도 사용이 됩니다.

 

그래서 Partition 같은 경우 Leader와 Follwer로 구성이 됩니다. 모든 Partition 은 하나의 Leader 가 존재하고 하나 혹은 그 이상의 Follwer들이 존재합니다. Partition에 데이터를 쓰는 작업은 Leader를 통해 이루어지고 Partition의 데이터를 읽는 것은 Leader 혹은 Follwer를 통해 이루어집니다. 앞에서 설명드린 Eventual Consistency와 Strong Consistency의 읽기와 쓰기도 Leader과 Follwer가 관여합니다.

 

하나의 Partition은 Fail-over를 위해 Replication Partition을 가짐

 

각 Partition별로 Leader와 Follower가 존재

○ 쓰기는 Leader를 통해 이뤄지고 읽기는 Leader/Follower들을 통해 이뤄짐
○ Partition별로 Consistency Level을 토픽을 만들 때 파라미터로 설정 가능 (in-sync replica - “ack”)

 

 

 

Partition별로 누가 Leader이고 Follower인지 관리가 중요해짐

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처 - Topic 파라미터들

 

이름: “MyTopic”

 

Partition의 수: 3

 

복제본의 수: 3

 

Consistency Level (“acks”): “all” 

 

데이터 보존 기한: 기본 일주일

 

메세지 압축 방식

 

…

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처 - Topic 예

 

3개의 Partition이 있고 Partition별로 3개의 복사본이 있습니다. 하나가 Leader 나머지 2개는 Follower입니다. 만일 Consistency Level이 All이라면 Partition 1에 새로운 메시지가 쓰여진다면 다른 2개의 복제본에 똑같이 다 쓰여질 때까지 쓰기 작업은 완료되지 않습니다. 쓰기 작업이 끝난 뒤에는 어떤 C들이 데이터를 어디서 읽어가건 모두 새로 쓰인 데이터를 읽을 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처 - 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와 Partition

Kafka Broker를 Kafka Server 혹은 Kafka Node라고 부르기도 함

누가 어디에 Broker, Topic에 대한 정보를 관리하는가?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처 - 메타 정보 관리를 어떻게 할 것인가?

 

Broker 리스트 관리 (Broker Membership)

○ 누가 Controller인가? (Controller Election)

 

Topic 리스트 관리 (Topic Configuration)

○ Topic을 구성하는 Partition 관리
○ Partition별 Replica 관리

Partion들을 관리해주는 역할을 하는 것이 Controller (Borker 중의 하나가 이 역할을 수행)

 

Topic별 ACL (Access Control Lists) 관리

 

Quota 관리

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 아키텍처: 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 (1)

 

 

분산 시스템에서 널리 사용되는 Distributed Coordination Service

○ 동기화, 구성 관리, 리더 선출 등 분산 시스템의 관리하고 조율을 위한 중앙 집중 서비스 제공

 

원래 Yahoo! Hadoop 프로젝트의 일부로 자바로 개발됨

○ 이후 Apache 오픈소스 소프트웨어로 변신

 

하지만 다양한 문제 존재

○ 지원하는 데이터 크기가 작고 동기모드로 동작하기에 처리 속도가 느림

    ■ 즉 어느 스케일 이상으로 확장성이 떨어짐
○ 환경설정도 복잡함
○ 그러다보니 Zookeeper를 사용하던 서비스들이 Zookeeper를 대체하기 시작
    ■ ElasticSearch가 또다른 예

 

 

 

 

 

 

 

 

 

 

 

 

 

잠깐! Zookeeper (2)

 

ZooKeeper의 일반적인 사용 사례

○ 메시지 큐를 위한 Apache Kafka
○ 분산 데이터베이스 조정을 위한 Apache HBase
○ 분산 스트림 처리를 위한 Apache Storm
○ …