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

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

Apache Kafka Clients

Producer: 메시지를 생산해서 Kafka의 Topic으로 메시지를 보내는 애플리케이션

Consumer: Topic의 메시지를 가져와서 소비하는 애플리케이션

Consumer Group: Topic의 메시지를 사용하기 위해 협력하는 Consumer들의 집합

. 하나의 Consumer는 하나의 Consumer Group에 포함되며,
  Consumer Group 내의 Consumer들은 협력하여 Topic의 메시지를 분산 병렬 처리함

Producer와 Consumer의 분리(Decoupling)

. Producer와 Consumer는 서로 알지 못하며, 각각 고유의 속도로 Commit Log에 Write 및 Read를 수행

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

Kafka Commit Log

Commit Log

. 추가만 가능하고 변경 불가능한 데이터 스트럭쳐

Offset
. Commit Log에서 Event의 위치

Kafka Offset: Commit Log에서 Event의 위치

Producer가 Write하는 LOG-END-OFFSET과 Consumer Group의 Consumer가 Read하고 처리한 후에 Commit한 CURRENT-OFFSET과의 차이(Consumer Lag)가 발생할 수 있음

Topic, Partition, Segment: Logical View

Topic: Kafka 안에서 메시지가 저장되는 장소, 논리적인 표현

Partition
. Commit Log, 하나의 Topic은 하나 이상의 Partition으로 구성
. 병렬 처리(Throughput 향상)를 위해서 다수의 Partition을 사용

Segment
. 메시지(데이터)가 저장되는 실제 물리 File

. Segment File이 지저된 크기보다 크거나 지정된 기간보다 오래되면 새 파일이 열리고 메시지는 새 파일에 추가됨

Topic, Partition, Segment: Physical View

Topic 생성 시 Partition 개수를 지정하고, 각 Partition은 Broker들에 분산되며 Segment File들로 구성됨
Rolling Strategy: 특정 용량이나 시간에 따라 Segment 파일을 분리 
. log.segment.bytes(default 1GB)
. log.roll.hours(default 168 hours)

Active Segment: Partition당 하나의 Active Segment

Partition당 오직 하나의 Segment가 활성화(Active) 되어 있음
-> 데이터가 계속 쓰여지고 있는 중

Topic, Partition, Segment의 특징

Topic 생성 시 Partition 개수를 지정 - 개수 변경 가능하나 운영 시에는 변경 권장하지 않음

Partition 번호는 0부터 시작하고 오름차순

Topic 내의 Partition들은 서로 독립적임

Event(Message)의 위치를 나타내는 Offset 이 존재

Offset은 하나의 Partition에서만 의미를 가짐 - Partition 0 의 offset 1은 Partition 1의 offset 1과 연관 없음

Offset값은 계속 증가하고 0으로 돌아가지 않음

Event(Message)의 순서는 하나의 Partition 내에서만 보장

Partition에 저장된 데이터(Message)는 변경이 불가능(Immutable)

Partition에 Write되는 데이터는 맨 끝에 추가되어 저장됨

Partition은 Segment File들로 구성됨 - Rolling 정책: log.segment.bytes, log.roll.hours

Kafka 설정

brocker id : 브로커 인스턴스마다 고유한 값을 가짐

linteners : 브로커에서 참조하는 엔드포인트

advertised.listeners
. 컨슈머/프로듀서에서 참조하는 엔드포인트

. 설정하지 않으면 linteners에 설정된 기본값 적용

** linteners/advertised.listeners가 따로 있는 이유? 내부와 외부 트래픽을 나누기 위해
  . 예를 들어 replication 트래픽은 client의 트래픽을 방해해선 안되기 때문에

  . 외부 트래픽은 프록시나 로드밸런서를 타고 올 텐데, 내부 트래픽은 성능 이점 때문에 직접 브로커로 붙어도 괜찮다

  . 외부 트래픽은 SSL을 적용, 내부 트래픽은 SSL을 미적용할 수 있음

num.network.threads

. 서버가 요청을 받거나 응답을 내보내는 스레드

num.io.threads
. 서버가 클라이언트의 Disk I/O같은 요청을 처리하는 스레드

socket.send.buffer.bytes

socket.receive.buffer.bytes

. 소켓 사이즈를 바이트 단위로 설정 가능

===================================================================

log.dirs
. 브로커가 데이터를 저장하는 디렉토리

num.partitions

. 파티션 개수를 지정하지 않았을 때 기본적으로 사용되는 파티션 수===================================================================

log.flush.interval.messages

. 데이터를 디스크에 쓰기 전에 몇 개 까지의 메시지를 가지고 있을 것인지 설정하는 옵션

log.flust.interval.ms

. 플러시를 하기 전에 얼마까지 적재를 할 지 시간으로 설정 (n초마다 flush)
===================================================================

log.flush.interval.ms

. 리텐션 policy에 따라서 삭제할 수 있는지 여부를 확인하기 위해 log segment를 확인하는 간격
===================================================================

auto.create.topics.enable

compression.type
. 프로듀서가 해당 타입으로 메시지를 압축해서 전송, 브로커가 그대로 디스크에 저장하고 컨슈머가 압축한 상태로 consume

delete.topic.enable

. topic을 삭제하는 것을 활성화

message.max.bytes

. 메시지 payloads 제한

replica.lag.time.max.ms

. follower가 leader한테 이 시간동안 fetch request를 보내지 않는다면, 그리고 leader의 log를 다 소모하지 않았다면

  leader는 ISR에서 해당 follower를 제거