Maru's Study Memo

Replication of Partition: 장애를 대비하기 위한 기술

Producer/Consumer는 Leader와만 통신: follower는 복제만

Producer는 Leader만 Write하고 Consumer는 Leader로부터만 Read함
Follower는 Broker 장애시 안정성을 제공하기 위해서만 존재

Follower는 Leader의 Commit Log에서 데이터를 가져오기 위해 요청(Fetch Request)으로 복제

Leader 장애 -> 새로운 Leader를 선출

Kafka 클러스터는 Follower 중에서 새로운 Leader를 선출
Client(Producer/Consumer)는 자동으로 새 Leader로 전환

Partition Leader에 대한 자동 분산: Hot Spot 방지

auto.leader.rebalance.enable: 기본값 enable
leader.imbalance.check.interval.seconds: 기본값 300 sec
. 300초마다 leader 분산에 불균형 여부 check
leader.imbalnce.per.broker.percentage: 기본값 10
. 다른 브로커보다 10% 이상 더 많이 가져가면 불균형으로 판단

Rack Awareness: Rack간 분산하여 Rack 장애를 대비

동일한 Rack 혹은 Available Zone상의 Broker들에 동일한 "rack name" 지정
복제본(Replica-Leader/Follower)은 최대한 Rack 간에 균형을 유지하여 Rack 장애 대비
Topic 생성시 또는 Auto Data Balancer/Self Balancing Cluster 동작 때만 실행

Consuming from Kafka: Partition으로부터 Record를 가져옴(Poll)

Consumer는 각각 고유의 속도로 Commit Log로부터 순서대로 Read(Poll)를 수행

다른 Consumer Group에 속한 Consumer들은 서로 관련이 없으며, Commit Log에 있는 Event(Message)를 동시에 다른 위치에서 Read할 수 있음

Consumer Offset: Consumer Group이 읽은 위치를 표시

Consumer가 자동이나 수동으로 데이터를 읽은 위치를 commit하여 다시 읽음을 방지

__consumer_offsets라는 Internal Topic에서 Consumer Offset을 저장하여 관리

Consuming as a Group: 동일한 group.id로 구성된 모든 Consumer들은 하나의 Consumer Group을 형성

Partition응 항상 Consumer Group 내의 하나의 Consumer에 의해서만 사용됨

Consumer는 주어진 Topic에서 0개 이상의 많은 Partition을 사용할 수 있음

Consumer Group의 Consumer들은 작업량을 어느 정도 균등하게 분할함

동일한 Topic에서 consume하는 여러 Consumer Group이 있을 수 있음

Message Ordering(순서): Key를 사용하여 Partition별 메시지 순서 보장

동일한 Key를 가진 메시지는 동일한 Partition에만 전달되어 Key 레벨의 순서 보장 가능
. 멀티 Partition 사용 -> 처리량 증가

. 운영 중에 Partition 개수를 변경하면? 순서 보장 불가

Record(Message) 구조: Header, Key, Value

Key와 Value는 Avro, Json 등 다양한 형태가 가능

Serializer/Deserializer

Kafka는 Record(데이터)를 Byte Array로 저장

Key와 Value용 Serializer를 각각 설정

Producing to Kafka: High-Level Architecture

Partitioner의 역할: 메시지를 Topic의 어떤 Partition으로 보낼지 결정

Kafka Broker: Topic과 Partition을 유지 및 관리

Kafka Broker는 Partition에 대한 Read 및 Write를 관리하는 소프트웨어
. Kafka Server라고 부르기도 함
. Topic 내의 Partition들을 분산, 유지 및 관리
. 각각의 Broker들은 ID로 식별됨(ID는 숫자)
. Topic의 일부 Partition들을 포함 -> Topic 데이터의 일부분(Partition)을 갖을 뿐 데이터 전체를 갖고 있지 않음
. Kafka Cluster: 여러 대의 Broker들로 구성됨
. Client는 특정  Broker에 연결하면 전체 클러스터에 연결됨
. 최소 3대 이상의 Broker를 하나의 Cluster로 구성해야 함 -> 4대 이상을 권장함

Zookeeper: Broker를 관리

Zookeeper는 Broker를 관리 (Broker 들의 목록/설정을 관리)하는 소프트웨어

. 변경사항에 대해 Kafka에게 알림: 토픽 생성/제거, Broker 추가/제거 등

. Zookeeper는 홀수의 서버로 작동하게 설계되어 있음(최소 3, 권장 5)

. Zookeeper에는 Leader(writes)가 있고 나머지 서버는 Follower(reads)

Zookeeper 아키텍쳐: Leader/Follower 기반 Mater/Slave 아키텍쳐

Zookeeper는 분산형 Configuration 정보 유지, 분산 동기화 서비스를 제공하고 
대용량 분산 시스템을 위한 네이밍 레지스트리를 제공하는 소프트웨어

분산 작업을 제어하기 위한 Tree 형태의 저장소
-> Zookeeper를 사용하여 멀티 Kafka Broker들 간의 정보(변경 사항 포함) 공유, 동기화 등을 수행

. 변경사항에 대해 Kafka에게 알림: 토픽 생성/제거, Broker 추가/제거 등

. Zookeeper는 홀수의 서버로 작동하게 설계되어 있음(최소 3, 권장 5)

. Zookeeper에는 Leader(writes)가 있고 나머지 서버는 Follower(reads)

Zookeeper Failover: Quorum 알고리즘 기반

Quorum(쿼럼)은 "정족수"이며, 합의체가 의사를 진행시키거나 의결을 하는데 필요한 최소 인원을 뜻함

분산 코디네이션 환경에서 예상치 못한 장애가 발생해도 분산 시스템의 일관성을 유지시키기 위해서 사용