3) kafka min.insync.replicas / replication / ISR / producer ACKs

kafka 기본개념

3) kafka min.insync.replicas / replication / ISR / producer ACKs

saay-hi 2024. 6. 24. 14:18

장애로 인해 leader partition 의 브로커가 중단되었을 때는 다른 follwer 파티션이 리더로 선정된다. 이 때 리더로 승격되는 follwer 파티션은 대부분 ISR(In Sync Replication) 에 속한 파티션에서 선출이 된다

ISR(In Sync Replication) 은 정상적으로 복제를 보장하는 replication group 을 뜻한다.

ISR은 브로커 config인 min.insync.replicas라는 옵션을 통해 결정되며, producer의 config은 asks와 연관이 깊다.

옵션 정리)

replication-factor : topic 의 partition 복제본이 몇 개 생성하는 지에 대한 옵션
min.insync.replicas : 최소한의 리더 파티션의 동기화를 보장하는 레플리카 수를 지정하는 옵션 (리더 파티션도 해당 수에 포함된다는 것을 명심하자.)
acks=<all(-1), 0, 1> : producer 에서 보낸 메시지가 정상적으로 파티션에 작성되었는가 에 대한 설정
- 이 때 all 인 경우 프로듀서는 min.insync.replicas 설정 개수만큼의 파티션에 대한 write 응답을 대기해야함.

ISR 간 동기화는 Pull 방식으로 동작하며, Follwer 에서 leader 에게 fetch 요청을 보내고, Leader 에서 응답으로 follwer 에게 메시지를 전송한다.

이 때, Fetch 요청에 Follwer들이 다음 메시지의 offset 이 포함되며, 항상 수신 순서로 처리

브로커(노드) 중단의 경우 ISR 에 속하는 Follwer 파티션이 선출되는데,
Follwer replica 가 일정 시간 이상 Fetch 요청을 하지 않거나, 시간 내에 Leader 파티션의 마지막 offset 메시지 복제를 실패한다면, 동기화 실패로 Follwer 파티션은 ISR 에서 제거된다.

복제 실패 시간은 [replica.lag.time.max.ms] 를 통해 설정

acks = 0

리더 파티션이 메시지를 받으면 즉시 프로듀서에게 ack 메시지를 반환. (잘 수신했는 지 별도 확인이 없음)
메시지를 리더 파티션에 쓰기 직전에 브로커가 죽는다면 메시지 유실된다.
안정성은 낮지만, 프로듀서 입장에서는 네트워크 오버헤드가 가장 낮으므로 처리량을 높일 수 있음

acks = 1

리더 파티션에만 메시지를 잘 썼다면 ack 메시지를 반환.
리더 파티션에 메시지를 썼음을 보장할 수 있지만, 만약 리더 파티션이 위치한 브로커가 다운되는 경우 팔로워에는 복제가 되지 않았기 때문에 메시지 손실이 발생할 수 있음
세가지 옵션 중 처리량/안정성 면에서 중간 값

acks = all (-1)

min.insync.replicas에 설정한 개수 만큼의 레플리카에 메시지를 쓴 경우에만 ack 응답
- 다시 언급하지만 리더 파티션은 레플리카 개념에 포함된다.
replication.factor=N 이고 min.insync.replicas=M 이면, N-M 개의 브로커가 다운되는 상황까지는 topic 운영을 이어갈 순 있다.
min.insync.replicas=2 일 때로 가정
- 리더 파티션 + 팔로워1 까지 작성이 완료되었을 때 ack를 반환
- 리더를 포함한 세 개의 복제본이 동기화되어 있으면, 이후 쓰기 작업은 정상적으로 진행된다.
- 만약 세 개의 복제본 중 적어도 두 개가 동기화되어 있으면, 여전히 쓰기 작업은 가능합니다.
- 그러나 min.insync.replicas보다 적은 수의 복제본이 ISR에 속해있다면, 여기선 두개의 브로커가 사용 불가능하면, 브로커는 더 이상 쓰기 작업을 진행하지 않고 브로커에선 프로듀서에게 NotEnoughReplicasException 에러를 보낸다.
참고