Introduction

프로듀서의 옵션중에 acks=all과 브로커 옵션중 min.insync.replicas에 대해서 알아보겠다. acks=all 옵션은 겉으로 보기엔 모든 팔로워들이 메세지를 수신 및 리플리케이션 하면 acks응답을 보낸다 처럼 보인다. 하지만 중요한점은 acks응답을 보내는 주체는 리더라는 점과 리더가 ISR 그룹 내의 팔로워들에게서 리플리케이션 완료 여부를 확인한다는 점이다.

그럼 여기서 중요한 점은 리더가 리플리케이션 완료 여부를 확인하는 기준이 무엇일까 다. 앞서 토픽을 생성할 때 추가했던 replication factor나 default replication factor의 경우 해당 토픽에 얼마 만큼의 브로커가 리플리케이션에 참여할것인지를 결정하는 것이다. 또 리플리케이션은 팔로워가 각각 독립적인 개체로써 리플리케이션을 진행한다는 것이다.

다시 요점으로 돌아와서 acks=all과 min.insync.replicas에는 어떤 관계가 있을까가 이 글의 주 목적이다. min.insync.replicas는 ack응답을 보내기 위한 리더가 확인해야할 최소 리플리케이션의 수를 지정하는 브로커 관련 옵션이다. 아무리 메세지 무손실을 위해 acks=all의 옵션을 프로듀서에서 적용을 해 두었더라도 min.insync.replicas가 1로 설정되어 있으면 리더만 메세지를 수신하여도 리플리케이션의 조건이 충족되기 때문에 ack응답을 보내게 된다. 즉 메세지 손실이 일어날 가능성이 있다.

그렇다면 replicaiton facotr와 min.insync.replicas의 수를 동일하게 설정하면 메세지 손실이 발생하지 않을까? 라는 생각을 하게 될 것이다. 앞선 내용들이 이해가 되었다면 아마 가장 강력하게 메세지 무손실을 보장하는 방법이라고 생각한다. 하지만 여기선 한가지 문제가 있다. 바로 카프카 브로커의 다운이다. 만약 리플리케이션이 3으로 구성되고 min.insync.replicas의 옵션도 3으로 지정해 두었다고 가정할 때 하나의 브로커가 다운되게 되면 가용 가능한 카프카 브로커는 2대이다. 이 상황에서 프로듀서가 메세지를 전송하게 되면 리플리케이션 조건을 충족시킬수 없으므로 에러가 발생하고 클러스터 전체 장애와 비슷한 상황이 나타나게 된다.

그렇기 때문에 해당 옵션을 사용하게 될 때에는 정확한 이해를 통한 사용이 필요하다. 참고로 카프카에서는 topic replication.facter=3, min.insync.replicas=2를 권장한다.