Kafka - In-Sync-Replicas

In-Sync-Replicas

ISR(In-Sync-Replicas)이란?

 

 - In-Sync-Replicas(ISR)은 Follower가 잘 복사해 가고 있는지 판단하는 지표이다.

 - ISR은 High Water Mark라고 하는 지점까지 동일한 Replicas(Leader와 Follwer)의 목록이다.

 - Leader에 장애가 발생하면, ISR 중에서 새로운 Leader를 선출한다.

 - replica.lag.max.messages 옵션을 통해서 ISR을 판단하여 ISR 중에서 Leader를 선정한다.

 

replica.lag.max.messages란?

 - replica.lag.max.messages는 Follower와 Leader 간의 지연된 메시지의 개수를 판단하는 기준이 된다.

 - 예를 들어서, replica.lag.max.messages=4인 경우, Leader에 8개의 메시지가 저장되고, Follower에 4개의 메시지가 저장되었다면, 이를 지연(OSR) 상태로 판단한다.

 - 즉, replica.lag.max.messages의 값 보다 작아야 ISR의 조건이 만족하는 것이다.

 

replica.lag.max.messages 사용 시 문제점

1. replica.lag.max.messages의 문제점

 - 메시지가 항상 일정한 비율로 Kafka에 들어올 때, 지연되는 경우가 거의 없기 때문에 ISR들이 정상적으로 동작한다.

 - 하지만, 메시지 유입량이 갑자기 늘어날 경우, 지연으로 판단하고 OSR로 상태를 변경시키는 상황이 발생할 수 있다.

 - 실제로 Follower는 정상적으로 동작하고 단지 잠깐 지연만 발생했을 뿐인데, replica.lag.max.messages 옵션을 이용하면 OSR로 판단하게 되는 문제가 발생한다.

 

2. replica.lag.time.max.ms의 사용

 - Follower가 Leader로 Fetch 요청을 보내는 간격을 체크하는 옵션이다.

 - 예를 들어, replica.lag.time.max.ms=10000이라면, Follower가 Leader로 Fetch 요청을 10000ms 내에만 하면 정상으로 판단한다.

 

ISR의 관리

 

 - ISR은 Leader가 속해있는 Broker가 관리한다.

 - 만약, Follower가 너무 느리면, Leader는 ISR에서 Follower를 제거하고 Zookeeper에 ISR을 유지한다.

 - 그리고 Controller는 Partition Metadata에 대한 변경 사항을 Zookeeper로부터 수신한다.

 

Controller란?

 - Kafka Cluster 내 여러 개의 Broker 중 하나가 Controller가 된다.

 - Controller는 Zookeeper를 통해 Broker Liveness를 모니터링하고, ISR의 대한 정보를 수신한다.

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

 - Controller는 Zookeeper에 Replicas 정보의 복사본을 유지한 후, 더 빠른 액세스를 위해 Cluster 내 모든 Broker 들에게 동일한 정보를 캐시 한다.

 - Leader에 장애가 발생하면, Controller가 Leader Election을 수행한다.

 - Controller에 장애가 발생하면, 활성화된 Broker 등 중에서 Controller가 재선출된다.

 

Consumer와 관련된 Position

 

 - Last Committed Offset(Current Offset) : Consumer가 최종 Commit 한 Offset이다.

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

 - High Water Mark(Committed) : ISR 간에 복제된 Offset이다.

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

 

Committed의 의미

 

 - ISR 목록의 모든 Replicas가 메시지를 성공적으로 가져오면 Committed라고 한다.

 - Consumer는 Committed 메시지만 읽을 수 있다.

 - Committed 메시지는 모든 Follower에서 동일한 Offset을 갖도록 보장한다.

 - 즉, 어떤 Replica가 Leader인지에 관계없이 모든 Consumer는 해당 Offset에서 동일한 데이터를 볼 수 있다.

 - Broker가 다시 시작할 때 Committed 메시지 목록을 유지하도록 하기 위해, Broker의 모든 Partition에 대한 마지막 Committed Offset은 replication-offset-checkpoint라는 파일에 기록된다.

 

Message Commit 과정

 

1. Offset 5까지 복제가 완료되어 있는 상황에서, Producer가 메시지를 보내면 Leader가 Offset 6에 새 메시지를 추가한다.

 

 

2. 각 Follower들의 Fetcher Thread가 독립적으로 Fetch를 수행하고, 가져온 메시지를 Offset 6에 메시지를 Write 한다.

 

 

3. 각 Follower들의 Fetcher Tread가 독립적으로 가시 Fetch를 수행하고 null을 받아온다. 그 후 Leader는 High Water Mark를 이동시킨다.

 

 

4. 각 Follower들의 Fetcher Thread가 독립적으로 다시 Fetch를 수행하고 High Water Mark를 받는다.

 

최종 정리

 - ISR은 High Water Mark라고 하는 지점까지 동일한 Replicas의 목록이다.

 - High Water Mark는 ISR 간에 복제된 Offset이다.

 - Consumer는 Committed 메시지만 읽을 수 있다.

 - Kafka Cluster 내의 여러 Broker 중 하나가 Controller가 된다.

 - Controller는 Zookeeper를 통해 Broker Liveness를 모니터링하는 역할을 수행한다.

---

출처

ㆍ https://fastcampus.co.kr/dev_online_kafka