Gidhub BE Developer

Kafka ISR(In Sync Replica)

2019-12-03
goodGid

이 글의 코드 및 정보들은 을 바탕으로 작성하였습니다.

리더와 팔로워

  • 리더는 모든 데이터의

  • Read / Write 요청을 처리 및 데이터를 저장한다.

  • 팔로워는 리더를 주기적으로 체크하면서

  • 없는 데이터를 리더로부터 받아와 리플리케이션을 유지한다.


정합성 문제

  • 만약 팔로워에 문제가 있어

  • 리더로부터 데이터를 가져오지 못한다면 어떻게 될까?

  • 리더가 다운되는 경우

  • 팔로워가 새로운 리더로 승격되어야한다.

  • 그런데 데이터가 일치하지 않으면 큰 문제가 발생할 수 있다.

  • 카프카에서는 이러한 현상을 방지하고자

  • ISR(In Sync Replica)라는 개념을 도입했다.


ISR

  • ISR은 현재 리플리케이션이 되고 있는 그룹을 뜻한다.

  • ISR에는 중요한 규칙이 있다.

  • ISR에 속해 있는 구성원만이 리더의 자격을 가질 수 있다.


  • 예를 들어

  • peter 토픽의 리플리케이션 팩터 : 2

  • 리더 : 1번 브로커

  • 팔로워 : 2번 브로커

  • ISR 구성원 : 1,2번 브로커


  • 이 상황에서 1번 브로커가 다운이 되면

  • ISR의 구성원인 2번 브로커가

  • 새로운 리더로 승격할 수 있다.


  • 즉 ISR이라는 그룹을 만들어

  • 리플리케이션의 신뢰성을 높힌다.


Example

  • 위 예제의 상황은 다음과 같다.

  • 1개의 리더

  • 2개의 팔로워

  • 리플리케이션 팩터 : 3

  • 리더와 팔로워 모두 ISR의 구성원


  • 그림의 동작 Flow에 대해 알아보자.

  • 프로듀서는 A메세지를 토픽의 리더에게 보낸다.

  • 리더만 토픽을 Write를 한다. (리더의 조건)


  • 팔로워들은 매우 짧은 주기로 리더와의 데이터를 동기화한다.

  • 그런데 팔로워2가 동작하지 않는다.

  • 리더는 팔로워들이 주기적으로 데이터를 확인하고 있는지를 체크하여

  • 만약 설정된 일정 주기(replica.lag.time.max.ms)만큼

  • 확인 요청이 오지 않는다면

  • 리더는 해당 팔로워의 문제가 발생했음을 인지하고

  • 해당 팔로워는 리더의 역할을 대신할 수 없다고 판단해

  • ISR 그룹에서 추방시킨다.

  • (= ISR 그룹에서의 리더 자격도 박탈당한다.)


  • ISR의 최종 구성원은

  • 리더와 팔로워1이며

  • 만약 이상황에서 리더가 다운된다면

  • ISR의 구성원인 팔로워1이 리더로 승격되고

  • 프로듀서와 컨슈머들의 요청들을 이어서 처리한다.


참고


Similar Posts

Comments