[Kafka] Replication Factor 와 복제 로그

Replication factor

• 개별 topic 에 대해 replication factor (=복제본 갯수) 를 설정한다.

  • 각 topic partition 에 대해 message log 가 plication factor 갯수 만큼 복제된다.
  • ex) topic A 는 replication factor 3, topic B 는 replication factor 5 설정

• replication factor 는 최소 3개 이상을 권장한다.

  • 리더 broker 에 장애가 발생하여도 follower 가 리더로 선출되어 장애 복구

• 기본값은 1. defualt.replication.factor 값으로 수정 가능.

복제본 일관성 유지 방안

쿼럼(quorum) 기반 방식

• 과반수의 복제본이 메시지 수신 ACK 를 갖는 경우에만 리더가 메시지를 commit
• zookeeper 는 리더 선정 방식에 쿼럼 기반 방식을 사용

주 백업(primary backup) 방식

• 모든 follower로부터 ACK를 기다리는 방식
  • 처리 시간, 처리량 부담 발생
  • 메시지와 데이터에 대한 더 나은 일관성을 보장
• 카프카에서 복제본 관리에 사용하는 방식
• 리더 장애 발생시 어떤 follower 라도 리더 대체 가능
  • 각 리더는 ISRIn Sync Replica 세트를 기록
  • -> 각 파티션에 대해 1개의 리더와 주키퍼에 저장된 ISR을 가짐

• 모든 리더와 follower 는 offset 을 유지하며 자신만의 지역로그local log 를 가짐
• 커밋된 최선 메시지 offset 을 high watermark 라 함.

---

Read, Write

message 쓰기 요청 발생시

• partition 에 대한 클라이언트의 쓰기 요청 발생
• zookeeper 로부터 partition 의 리더를 확인, 쓰기 요청 생성
• 리더는 로그를 메시지에 쓰고, ISR 안의 follower의 ACK 를 기다림
• ACK 를 바등면 high watermark 포인터를 증가시키고, 클라이언트로 ACK를 보냄

읽기 작업

• 모든 읽기 작업을 리더를 통해서만 발생한다.
  • 리더에 의해 ACK 확인된 메시지가 클라이언트가 읽을 수 있도록 가용한 상태가 됨

---

장애 발생시

• ISR follower 장애 발생시, 리더는 ISR 에서 follower 를 제외
  • 나머지 follwer 와 작업 진행
• follwer 장애 복구시 로그 동기화 후 리더와 작업 재개
  • 복구된 follwer 를 ISR 로 다시 추가