[Kafka] - 7. In sync Replicas

Replication of Partition

장애를 대비하기 위해 Partition을 Replicate하여 다른 Broker에 Replicas(복제본)을 만들어 두어 장애를 대비한다.

 

실제로 어떻게 복제하는가?를 알아보자

 

1. ISR

---

In Sync Replicas 로 '얼마나 잘 복제하고 있는가'에 대한 지표

• ISR은 High Water Mark라고 하는 지점까지 동일한 Replicas이다.
• Leader Partition은 가진 Broker와 이를 따르는 Follower (102,103)이 있다.
• replica.lag.max.messages 값이 4에 따라, ISR과 OSR이 나누어진다.

 

High Water Mark

LOG-END-OFFSET과 ISR의 Last-Committed offset의 차이가 replica.lag.max.messages 값보다 작으면 마지막 offset을 High water mark라고 부른다.

• High Water Mark는복제본 중 가장 많이 복사한 곳(Fully-replicated-committed) 라고도 하며, 이 때의 commit은 앞서 배운 consumer의 commit과는 다른 개념이다. ( 복제한 것을 알려주는 의미이다. )
• 결국, ISR의 High Water Mark는 복제의 기준이 되며 Leader Broker가 장애가 발생하게 되면, ISR 중에서 새롭게 Leader를 뽑아 대체하면 된다.

 

2. Replica.lag.time.max.ms

---

Replica.lag.max.messages

ISR을 판단하는 지표로 사용되지만, 큰 문제점이 있다.

Message(data)가 항상 일정 비율(초당 3)로 Kafka Produce된다고 생각해보자

Replica.lag.max.messages 값이 5로 하면, 5개 이상 지연되는 경우가 없어 제대로 동작한다.

 

1. Message(data)가 급격하게 유입이 늘어난다면(초당10 가정)

2. 지연으로 판단하여 Follower를 OSR로 state를 변경하여 버린다.

실제 Follower는 정상적으로 동작 중이고, 잠깐의 Delay로 OSR로 판단되어 버리는 문제가 발생한다.

운영 중에 불필요한 Error가 발생하며, Retry도 유발한다.

 

Replica.lag.time.max.ms

Follower가 Leader로 Fetch 요청을 보내는 interval로 Check

• Replica.lag.time.max.ms =10000 이라면 Follower가 10000ms 이내에 요청하면 정상 그렇지 않으면 OSR로 처리한다.

 

ISR에 대한 정보는 Leader가 존재하는 Broker가 관리한다.

아래 그림과 같이 하나의 Leader(102)와 2개의 ISR Follower(101,103)가 존재한다고 가정해보자

1. Broker 103은 max.ms 이내에 fetch하지 못하였다고 해보자

2. ISR을 관리하는 Broker 102 는 Zookeeper에게 변경된 ISR[101,102] 값을 전달하여 준다

3. Zookeeper는 Controller Broker에게 Partition metadata(변경 사항)에 대해 보내준다.

4. Controller는 다른 Broker들에게 갱신된 정보를 알려준다(Sync)

 

 

Controller

---

• Broker들 중 하나로 Kafka Cluster(zookeeper)가 Active Broker들 중 하나를 지정
• Controller는 Zookeeper를 통해 ISR,Broker liveness 등을 Monitoring 한다.
• Controller는 Leader와 Replica 정보를 Cluster 내에 다른 Broker들에게 전달한다.
• Controller는 Zookeeper에게 Replicas 정보 복사본을 유지한 뒤, 더 빠른 Access를 위해 모든 Broker들에게 동일한 정보를 캐시한다. ( 캐시하여 접근 속도를 높이기 위함 )
• Controller는 Leader Broker가 장애 발생 시, Leader Election을 수행한다.
• Conroller가 장애가 나면, zookeeper가 재선출한다.

Consumer Position

---

1. Last-committed Offset(current offset) : Consumer가 최종 Commit한 offset

2. Current Position : Consumer가 읽은 위치(batch로 처리되어 여러 칸을 이동 가능) , Commit 되기 전

3. High WaterMark : ISR간에 복제된 offset으로 Committed

4. Log-End Offset : Producer가 Message를 보내 저장된 맨 마지막 offset

topic-partition(Consumer-lag)

 

ISR Commit

---

ISR의 목록의 모든 Replica가 Message를 받으면 'Committed'

• Consumer는 Commit된 Message만 가져갈 수 있다.
• Leader는 Message를 Commit할 시기를 결정
• Committed Message는 모든 follower에서 동일한 offset을 가지도록 보장( 시간이 흐르면, OSR도 commit된 곳까지 온다)
• 어떤 Replica가 Leader인지 관계없이(장애 발생 포함) 모든 Consumer들은 해당 offset에서 같은 Data를 보장 받는다.
• Broker가 다시 시작될 떄, Committed Message 목록을 유지하기 위해 Broker의 모든 Partition에 대한 마지막 Committed-offset은 Replication-offset-checkpoint 라는 File에 저장된다.

 

 

Replicas 동기화

1. High Water Mark

• 가장 최근의 Commited message offset 추적
• Replication-offset-checkpoint 라는 File에 checkpoint 기록

 

2. Leader Epoch

• 새로운 Leader가 선출 된 경우 0->1 로 Epoch.
• 새로운 Leader가 선출된 지점을 Offset으로 표시
• Broker 복구 중에 Message를 Checkpoint로 자른 뒤 현재 Leader를 따르게 한다.
• Controller가 새로운 Leader를 선택, Leader epoch update 처리, 모든 정보를 ISR 목록의 구성원에게 전송한다.
• Replication-epoch-checkpoint file에 checkpoint 기록

 

Fetcher Thread

---

Follwer에서 Leader를 Fetch를 수행

Leader Broker도 다른 Partition의 Follower임으로 fetcher-thread가 존재

 

Message Commit 과정

1.Leader 및 Follwer는 offset=5 까지 복제가 된 상태

2. Producer가 새로운 Message를 send하여, offset 6에 message를 저장

3. Broker의 fecther thread가 독립적으로 돌면서 가져온 Message를 Write

4. fecther thread가 Leader에게 요청하지만, Null 값을 되돌려줌과 동시에 Leader는 High water Mark를 6으로 이동시킨다.

5. fecther thread가 재요청, High water Mark = 6 값을 받고 갱신시킨다.

 

step1

step2

step3

step4

step5