Kafka란?
- 실시간 데이터를 처리하기 위해 설계된 오픈소스 분산 스트리밍 플랫폼
- 데이터 재생이 가능한 분산 커밋 로그 (Distributed Commit Log)
- 한번 기록되면 영구적임
- Scalability와 Fault Tolerance를 제공하는 Publish-Subscription 메시징 시스템
- Producer-Consumer (Publish-Subscription)
- High Throughput과 Low Latency 실시간 데이터 처리에 맞게 구현됨
- 분산 아키텍처를 따르기 때문에 Scale out 이란 형태로 스케일 가능
- 서버 추가를 통해 Scalability 작성 (서버=Broker)
- 정해진 보유기한 (default=일주일) 동안만 메시지를 저장
Eventual Consistency
- 100대 서버로 구성된 분산 시스템에 레코드를 하나 쓴다면 그 레코드를 바로 읽을 수 있을까?
- 내가 쓴 레코드가 리턴이 될까?
- 보통 하나의 데이터 블록은 여러 서버에 나눠 저장됨 (Replication Factor)
- 따라서 데이터를 새로 쓰거나 수정하면 전파되는데 시간이 걸림
- 보통 읽기는 다수의 데이터 카피 중에 하나를 대상으로 일어나기 때문에 앞서 전파 시간에 따라 데이터가 있을 수도 있고 없을 수도 있음
- Strong Consistency vs. Eventual Consistency
- Strong Consistency: 데이터를 쓴 후 복제가 완료될 때까지 기다리는 구조
- Eventual Consistency: 그게 아닌 바로 리턴
데이터 특성에 따라 어떻게 구현할지 선택하면 된다. 대부분의 데이터는 Eventual 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)
Kafka 아키텍처 - Topic과 Partition
- 하나의 Topic은 확장성을 위해 다수의 Partition으로 나뉘어 저장됨
- 메시지가 어느 Partition에 속하는지 결정하는 방식에 키의 유무에 따라 달라짐
- 키가 있다면 Hashing 값을 Partition의 수로 나눈 나머지로 결정
- 키가 없으면 라운드 로빈으로 결정 (비추)
Kafka 아키텍처 - Topic과 Partition과 복제본
- 하나의 Partition은 Fail-over를 위해 Replication Partition을 가짐
- 각 Partition별로 Leader와 Follower가 존재
- 쓰기는 Leader를 통해 이뤄지고 읽기는 Leader/Follower들을 통해 이뤄짐
- Partition별로 Consistency Level을 설정 가능 (in-sync replica - "ack")
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)
메타 정보 관리를 어떻게 할 것인가?
- Broker 리스트 관리 (Broker Membership)
- 누가 Controller인가? (Controller Election)
- Topic 리스트 관리 (Topic Configuration)
- Topic을 구성하는 Partition 관리
- Partition 별 Replica 관리
- Topic별 ACL (Access Control Lists) 관리
- Quota 관리
반응형
