리플리케이션

브로커의 장애에도 불구하고 연속으로 안정적인 서비스를 제공하고 데이터 유실을 방지하기 위해서 리플리케이션을 지원

 

kafak-topics.sh --bootstrap-server peter-kafka01.foo.bar:9092 --create --topic peter-test01 --partitions 1 --replication-factor 3

• 카프카는 컨트롤러 브로커를 통해서 클러스터의 상태를 관리하고 있음 - 컨트롤러 브로커는 클러스터에 있는 모든 브로커의 메타데이터를 유지하고 관리하는 역할
• kafka-topics.sh --create 명령을 실행하면, 지정된 브로커(peter-kafka01.foo.bar:9092)로 요청
• 요청을 받은 브로커는 컨트롤러 브로커에게 토픽 생성 요청을 전달
• 컨트롤러 브로커는 현재 클러스터에 등록된 브로커 목록을 조회
• 컨트롤러는 replication-factor=3을 충족할 만큼 활성 브로커 개수가 충분한지 확인
• 만약 브로커 개수가 3개 미만이면 InvalidReplicationFactorException을 반환

 

리더와 팔로워

• 카프카는 동일한 리플리케이션에 대해서 리더와 팔로워로 구분
• 프로듀서와 컨슈머는 모든 리플리케이션에 메시지를 보내는 것이 아니라 리더에게만 메시지를 전송하고 가져옴
• 리더와 팔로워는 ISR(InSyncReplica)라는 논리적인 그룹으로 묶여 있음 - ISR 그룹에 속한 팔로워들만 새로운 리더의 자격을 가질 수 있음
• 리더는 읽고 쓰는 동작은 물론 팔로워가 리플리케이션 동작을 잘 수행하고 있는지를 감시 - 만약 특정 주기 시간만큼 복제 요청을 하지 않는 다면 리더는 해당 팔로워를 ISR에서 추방함
• 프로듀서로부터 받은 메시지를 리더가 팔로워들에게 푸시하는 방식이 아니라 팔로워들이 풀하는 방식으로 구현 - 리더의 부하를 줄이기 위해
• ISR 내에서 모든 팔로워의 복제가 완료되면 리더는 내부적으로 커밋되었다는 표시를 하는데 마지막 커밋 오프셋 위치는 하이워터마크라고 부름
• 모든 브로커는 재시작될 때, 커밋된 메시지를 유지하기 위해 replication-offset-checkpoint라는 파일에 마지막 커밋 오프셋 위치를 저장

 

리더와 팔로워의 리플리케이션 동작 (아래 그림이 좀 틀린건데 알잘딱깔센)

토픽: peter-test01 / 파티션: 1개 (peter-test01-0) / 리플리케이션 팩터: 3개

 

• 리더: 0번 오프셋에 message1

 

 

 

• 팔로워들은 리더에게 0번 오프셋 메시지 가져오기 요청 (리더는 ISR에 있는 팔로워가 요청을 보냈다는 사실을 알고 있음)
• 팔로워들은 message1 레코드를 리플리케이션

 

 

 

• 리플리케이션 동작을 마친 팔로워들은 다음 오프셋인 1번 오프셋 메시지 가져오기 요청
  • 리더는 팔로워들이 1번 오프셋 요청을 했다는 것을 통해서 리플리케이션이 성공했음을 인지
  • 리더는 0번 오프셋을 커밋하고 하이워터마크를 증가시킴
  • 만약 팔로워가 0번 오프셋에 대한 리플리케이션 요청을 보내면 리더는 아직 팔로워가 리플리케이션을 성공하지 못했다고 인지
• 리더는 팔로워들의 1번 오프셋 요청에 대한 응답에 오프셋 0번이 커밋되었다는 내용도 전달

 

 

 

• 팔로워들은 리더의 응답을 통해서 0번 오프셋까지 커밋되었다는 사실을 인지하고 리더와 동일하게 커밋을 표시
• 그리고 오프셋1을 리플리케이션한 뒤에 오프셋2에 대한 요청을 진행 → 위 내용 반복