미로

1.Replication

DB에서도 많이 쓰는 개념

Partition을 복제(Replication)하여 다른 Broker상에서 복제물(Replicas)을 만들어서 장애를 미리 대비함

Replicas - Leader Partition, Follower Partition

broker에서 장애 발생시  메세지(데이터) 유실을 방지하기 위해서 쓰는 개념

위 이미지 와 같이  리더와 follower로 이루어짐

producner consumer 모두 리더 broker 에서 IO 발생

Follower는 Broker 장애시 안정성을 제공하기 위해서만 존재

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

아래는 리더 broker 장애시 동작 이다

kafak 클러스터는 리더 broker 장애 발 생시 새로운 leader broker 선출 이후 clinet는 자동으로 새로leader 로 전환

또 partition 리더는 하나의 broker에 몰려 있지 않고 분산되어야함 아래는  kafka 옵션 값 과 예시 이미지

마지막으로 rack 간에도 분산이 필요하다 

2. In-Sync Replicas(ISR)

리더 파티션과 동일한 데이터를 가지고 있는 레플리카를 의미함.

즉, 리더 파티션에 쓰여진 모든 데이터가 인-싱크 레플리카에 정확하게 복제되어 있어야 한다.

In-Sync Replicas(ISR)는 High Water Mark라고 하는 지점까지 동일한 Replicas (Leader와

Follower 모두)의 목록

Leader에 장애가 발생하면, ISR 중에서 새 Leader를 선출

max.messages =4 인 경우 

replica.lag.max.messages 옵션은 Kafka 클러스터에서 리더 복제본(leader replica)과 팔로워 복제본(follower replica) 간의 복제 지연(replication lag)을 제어하는 데 사용됩니다. 이 옵션은 팔로워 복제본이 리더 복제본으로부터 얼마나 많은 메시지 뒤처질 수 있는지를 최대 메시지 수로 지정합니다.

replica.lag.max.messages 로 ISR 판단 시 나타날 수 있는 문제

메시지가 항상 일정한 비율(초당 유입되는 메시지, 3 msg/sec 이하 )로 Kafka로 들어올때, replica.lag.max.messages=5로 하면 5 개 이상으로 지연되는 경우가 없으므로 ISR들이 정상적으로 동작

메시지 유입량이 갑자기 늘어날 경우(예, 초당 10 msg/sec), 지연으로 판단하고 OSR(Out-of-Sync Replica)로 상태를 변경시킴

실제 Follower는 정상적으로 동작하고 단지 잠깐 지연만 발생했을 뿐인데,
replica.lag.max.messages 옵션을 이용하면 OSR로 판단하게 되는 문제가 발생 (운영중에불필요한 error 발생 및 그로 인한 불필요한 retry 유발)

실제로는 위 메세지 수가아닌 ms 로 판단(replica.lag.time.max.ms)이 적합

Follower가 Leader로 Fetch 요청을 보내는 Interval을 체크

예) replica.lag.time.max.ms = 10000 이라면 Follower가 Leader로 Fetch 요청을 10000 ms 내에만 요청하면 정상으로 판단

Confluent 에서는 replica.lag.time.max.ms 옵션만 제공(복잡성 제거)

Follower가 너무 느리면 Leader는 ISR에서 Follower를 제거하고 Zookeeper에 ISR을 유지

Controller는 Partition Metadata에 대한 변경 사항에 대해서 Zookeeper로 수신

2-1 Controller 

Kafka Cluster 내의 Broker중 하나가 Controller가 됨

Controller는 ZooKeeper를 통해 Broker Liveness를 모니터링

Controller는 Leader와 Replica 정보를 Cluster내의 다른 Broker들에게 전달

Controller는 ZooKeeper에 Replicas 정보의 복사본을 유지한 다음 더 빠른 액세스를 위해 클러스터의 모든 Broker들에게 동일한 정보를 캐시함

Controller가 Leader 장애시 Leader Election을 수행

Controller가 장애가 나면 다른 Active Broker들 중에서 재선출됨

2-2 Consumer관련 Position 

Last Committed Offset(Current Offset) : Consumer가 최종 Commit한 Offset

Current Position : Consumer가 읽어간 위치(처리 중, Commit 전)

High Water Mark(Committed) : ISR(Leader-Follower)간에 복제된 Offset

Log End Offset : Producer가 메시지를 보내서 저장된, 로그의 맨 끝 Offset

ISR Fully Committed 의미

2-3High Water Mark

• 가장 최근에 Committed 메시지의 Offset 추적

• replication-offset-checkpoint 파일에 체크포인트를 기록

2-4Leader Epoch

• 새 Leader가 선출된 시점을 Offset으로 표시

• Broker 복구 중에 메시지를 체크포인트로 자른 다음 현재 Leader를 따르기 위해 사용됨

• Controller가 새 Leader를 선택하면 Leader Epoch를 업데이트하고 해당 정보를 ISR 목록의 모든 구성원에게 보냄

• leader-epoch-checkpoint 파일에 체크포인트를 기록

요약 하면 

In-Sync Replicas(ISR)는 High Water Mark라고 하는 지점까지 동일한 Replicas (Leader와 Follower 모두)의 목록

High Water Mark(Committed) : ISR(Leader-Follower)간에 복제된 Offset

Consumer는 Committed 메시지만 읽을 수 있음

Kafka Cluster 내의 Broker중 하나가 Controller가 됨

Controller는 ZooKeeper를 통해 Broker Liveness를 모니터링

1.Producer

Producer - 메시지를 생상(Produce)해서 Kafka의 Topic으로 메시지를 보내는 애플리케이션

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

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

1-1 메세지 구조 

Message 는 Record 혹은 Event 혹은 Data 로 불림

Kafka는 Record(데이터)를 Byte Array로 저장(Producer는 Serializer, Consumer는 Deserializer)

아래 이미지에서 실제로 내가 할것은 send() 호출  호출전에는 옵션 여부 ? 정보 만 하면 이후는 카프카에서 알아서 처리된다.

1-2 Partitioner 

메세지를 Topic의 어떤 Partition으로 보낼지 결정( 지정 가능!)

아래는 default Partiotiner  역할 (Key가Null이 아닐때만 성립되기 때문에 key를 꼭 보내야 한다.)

아래는 key 가 null 일때 Default Partitiner 동작 

2.4 이전은 Round Robin 형식 , 2.4 이후에는 Sticky 형식 으로 

Partitiner는 개발 및 Custom하여 개발해서 교체가 가능하다.

2.Consumer

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

ConsumerGroup

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

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

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

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

2-1. Cousmer Group이 없는 경우 

2-2. Cousmer Group이 있는 경우

동일한 GroupId지정 시  Conusmer들은 하나의 Consumer Group을 형성

4개의 Partition이 있는 Topic을  Conme 하는 4개의 Consumer가 하나의 Consumer Group에 있다면 각 Consumer는 정확히 하나의 Partition에서 Record를 Consumer함

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

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

키가 지정된 메세지 의 경우  partition별로 동일한 key를 가지는 메시지 저장

2-3 Message Ordering (메세지 순서) 

Partition 2개 이상ㅇ인 경우 모든 메세지에 대한 전체 순서 보장 불가

Partition 1개로 구성하면 모든 메세지 전체 순서 보장 가능(처리량은 떨어짐)

이때 아래예시 처럼 Key 를 통해  동일 Partition의 순서를 보장하여 처리 가능

* 운영중에는 Partiton 개수를 변경하면 안된다.( 변경 시 순서 보장 불가) 

2-4.Cardinality(특정 데이터 집합의 유니크(Unique)한 값의 개수)

위 내용 처럼 파티션 전체 데이터를 배포하기위해 키를 만들어  고르게 배포하는게 중요함.

2-5 Consumer Failure (Consumer Rebalancing )

Consumer Group에 4개의 Consumer 가 있고  4개의 파티션이 있다면 각 Consumer 가 각각 하나의 파티션 에서 record를 consume함 

Conusmer는 주어진 Topic 에서 0개 이상의 많은 Partiton 사용 가능

Consumer Group내의 다른 Consumer가 실패한 Consumer 를 대신하여 Partition에서 데이터를 가져와서 처리 

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

총정리

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

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

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

다른 Consumer Group의 Consumer들은 분리되어 독립적으로 작동

동일한 Key를 가진 메시지는 동일한 Partition에만 전달되어 Key 레벨의 순서 보장 가능

Key 선택이 잘 못되면 작업 부하가 고르지 않을 수 있음

Consumer Group 내의 다른 Consumer가

Broker, Zookeeper

1. Broker

Kafka Broker 는 Partition에 대한 Read 및 Write 를 관리하는 소프트웨어 

• kafka Broker는  Kafka Server 라고 부르기도함
• Topic 내의 Partition 들을 분산, 유지 및 관리 
• 각각의 Broker 들은 아이디로 식별됨 (단, ID는 숫자)
• Topic의 일부 Partition들을 포함(multi broker로 흩어져 있기때문에  전체가 아닌 일부만 갖고 있음)
• Kafka Cluster는 여러개의 Broker 로 구성
• Client는 특정 Broker에 연결하면 전체 클러스터에 연결됨
• 최소3대이상의 Broker를 하나의 Cluster 로 구성 (1cluster 안에  4개 Broker 권장) 

Broker ID와 Partition 아이디의 관계

Client

• Kafka Boker는 Bootstrap(부투스트랩) 서버라고 부름
• Client -> Broker 연결 시 Cluster 전체 열결되어 전체 Broker 리스트를 알 수 있다 
• 특정 Broker의 장애를 대비해 전체 Broker List(IP, PORT)를 파라미터로 입력 권장
• 각각의 Broker 는 모든 Broker, Topic, Partition에 대해 알고 있음(Metadata)

2. ZooKeeper

• ZooKeeper는 Broker들을 관리(Broker들의 목록 설정) 하는 소프트웨어이다.
• Zookeeper를 통해  변경사항을 감지하여 Kafka에 알림  -> Topic 생성 제거 , Broker 추가 제거
• Zookeeper 없이 Kafka 동작 불가 했음(4.0 이전 버전)  현재는 없이도 동작 가능
• Zookeeper는 홀수의 서버로 작동하도록 설계되어 최소 3개, 권장5개 이다
• Zookeeper는 Leader(Writes)와 나머지 Follower (reads)로 구성

• Zookeeper는 분산형 Configuration 정보 유지, 분산 동기화 서비스를 제공하고 대용량 분산 시스템을 위한 네이밍 레지스트리를 제공하는 소프트웨어 
• 분산 작업을  제어하기 위해Tree 형태의 데이터 저장소로 이용 -> 멀티 Kafka Broker들 간의 정보(변경 사항 포함) 공유 , 동기화 등을 수행
• Ensemble(앙상블)은 Zookeeper의 서버 클러스터 이다.
• Zookeeper는 Quorum(쿼럼) 알고리즘기반이며, Quorum은 정족수라는 뜻이면 합의체가 의사를 진행시키거나의결을 하는데 필요한 최소한도의 인원수를 뜻함 
• 분산코디네이션 환경에서 예상치 못한 장애가 발생해도 분산 시스템의 ㅇ리관성을 유지시키기 위해서 사용
•  
• Ensemble이 3대로 구성되었다면 Quorum은 2, 즉 Zookeeper 1대가 장애가 발생하더라도 정상 동작
• Ensemble이 5대로 구성되었다면 Quorum은 3, 즉 Zookeeper 2대가 장애가 발생하더라도 정상 동작
• 과반수 합의체를 위해 꼭 홀수로 구성

1.topic 이란?

Topic이란 논리적인 표현이며 메시지 저장소이다.

왼쪽의 producer가 토픽을 발행하면 우측의 consumer가 소비하는 형식이다.

토픽은 데이터베이스의 테이블 혹은 파일시스템의 폴더와 유사한 성질을 갖고 있따. 

또 목적에 따라 각각의 이름을 가질 수 있는데 무슨 데이터를 담는지에 따라 명확하게 명명하는 것을 권장한다. 

2. partition이란?

데이터 처리를 효율적으로 하기위한 핵심 요서. 파티션은 큐를 나눠서 병렬처리를 가능하게 하는 기본 단위, kafka의 토픽은 하나 이상의 파티션으로 나눠져 있다. 이를 통해 메시지가 병렬로 처리될 수 있게 된다.

파티션 개수는 지정 가능 하며 0번부터 오름차순으로 생성된다. 또 topic 내의 파티션들은 서로 독립적이다.

offset 이란 이벤트 메세지의 위치를 나타내는 값. 

이 partition 안에 offset 이 존재하는데 다른 partition 의 offset 과는 다르다.

ex) partion0 offset 1 != partion1 offset 1

같은 partion 안에서는  순서가 보장 되며 데이터는 변경이 불가능(immutable) 하다.

하나의 토픽은 하나이상의 Partition으로 구성

병렬처리(Throughput - 처리율  향상)을 위해서 다수의  Partiotion사용

*CommitLog(추가만 가능하고 변경 불가능한 데이터 스트럭처, 데이터 이벤트는 항상 로그 끝에 추가되고 변경되지 않음)

3. Segment란?

발행된 메시지 데이터가 저장되는 실제 물리 File 

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

파티션당 오직 하나의 Segment가 활성화된다.

segment 들은 Rolling 정책을 쓴다.

log.segment.bytes(default 1 GB), log.roll.hours(default 168 hours)

저도 많이 쓰고 실무에서 많이쓰 는 kafka를 좀 더 정확하게 알 기위해 정리 하고자 작성한다.

카프카(Kafka)는 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 설계된 고성능 분산 이벤트 스트리밍 플랫폼이다.

kafka 의 탄생은 linked In 에서 탄생

kafka의 특징

kafka 사용 되는 곳

카프카 이외에도 rabbitMQ, pulsar 등이 있지만 성능 상 카프카가 가장 좋음(사용량이 적다면 rabbitMQ도 고려할만한다)

아래는 벤치마크 표