acks 옵션
카프카 프로듀서의 acks옵션은 0, 1, all(또는 -1) 값을 가질 수 있다.
이에 대해서 우리는 이전 포스팅에서 간단히 살펴봤었다.
https://devfunny.tistory.com/747
[아파치 카프카 어플리케이션 프로그래밍] 5. 프로듀서의 중요 개념과 옵션값
프로듀서 프로듀서는 카프카 브로커로 데이터를 전송할때 내부적으로 파티셔녀, 배치 생성 단계를 거친다. 전송하고자 하는 데이터는 ProducerRecord 인스턴스를 생성하여 설정한다. 필수 파라미터
devfunny.tistory.com
| value | 설명 |
| 0 default | 프로듀서가 전송한 즉시 브로커에 데이터 저장 여부와 상관 없이 성공으로 판단한다. |
| 1 | 리더 파티션에 데이터가 저장되면 전송 성공으로 판단한다. |
| -1 or all | min.insync.replicas 개수에 해당하는 리더 파티션과 팔로워 파티션에 데이터가 저장되면 성공하는 것으로 판단한다. |
이 옵션을 통해 프로듀서가 전송한 데이터가 카프카 클러스터에 얼마나 신뢰성 높게 저장할지 지정할 수 있다. 복제 개수가 1인 경우 acks옵션에 따른 성능 변화는 크지 않다. 그러나 안정적으로 데이터를 운영하기 위해서는 복제 개수가 2 이상으로 운영하는 경우가 대부분이기 때문에 각 acks별 동작 방식에 대해 이해를 하고, 카프카의 동작 방식을 상세히 알고 설정해야한다.
acks = 0
1) 리더 파티션에 데이터가 적재되지 않았더라도 성공으로 판단한다.
프로듀서가 리더 파티션으로 데이터를 전송했을때 리더 파티션으로 데이터가 저장되었는지 확인하지 않는다. 리더 파티션은 데이터가 저장된 이후에 데이터가 몇번째 오프셋에 저장되었는지 리턴하는데, 프로듀서는 리더 파티션에 데이터가 저장되었는지 여부에 대한 응답 값을 받지 않는다. 그렇기 때문에 프로듀서가 데이터를 보낸 이후에 이 데이터가 몇번재 오프셋에 저장되었는지 확인할 수 없다.
2) retries 옵션값이 무의미하다.
프로듀서에는 데이터의 전송이 실패했을때 재시도를 할 수 있도록 retries 옵션을 설정할 수 있는데, acks가 0일때 프로듀서는 전송을 하자마자 데이터가 저장되었음을 가정하고 다음 데이터를 전송하기 때문에, 데이터 전송이 실패한 경우를 알 수 없다.
3) 데이터가 유실되더라도 지속적으로 다음 데이터를 보낸다.
데이터 유실이 발생될 수 있다. 프로듀서는 리더 파티션으로부터 응답값을 받지 않기 때문에 계속해서 데이터를 전송한다. 그렇기 때문에 데이터 전송 속도는 acks를 1 또는 all로 설정했을 때보다 훨씬 빠르다. 데이터 유실이 발생하더라도 전송속도가 중요한 경우라면 이 옵션값을 사용하면 된다.
acks = 1
1) 리더 파티션에 데이터가 저장되었으면 성공으로 판단한다.
프로듀서는 데이터가 리더 파티션에만 정상적으로 적재되었는지를 확인한다. 만약 리더 파티션에 정상적으로 적재되지 않았다면 리더 파티션에 적재될 때까지 재시도할 수 있다.
2) 데이터 유실이 발생할 수 있다.
리더 파티션에 적재되었음을 보장하지만, 팔로워 파티션은 보장하지 않는다. 리더 파티션에 데이터가 정상적으로 적재되었다해도, 복제 개수를 2 이상으로 운영할 경우 팔로워 파티션에는 아직 데이터가 동기화되지 않을 수 있는데, 팔로워 파티션이 데이터를 복제하기 직전에 리더 파티션이 있는 브로커에 장애가 발생하면 동기화되지 못한 일부 데이터가 유실될 수 있다.
3) 전송속도가 느리다.
리더 파티션에 데이터가 적재될 때까지 기다린 뒤 응답 값을 받기 때문에 acks를 0으로 설정했을 때보다 전송 속도가 느리다.
acks = all 또는 acks = -1
1) 속도가 느리다.
acks를 all 또는 -1로 설정할 경우 프로듀서는 보낸 데이터가 리더 파티션과 팔로워 파티션에 모두 정상적으로 적재되었는지 확인한다. 리더 파티션뿐만 아니라 팔로워 파티션까지 데이터가 적재되었는지 확인하기 때문에 0 또는 1 옵션보다도 속도가 느리다.
2) 안전하게 데이터를 전송한다.
팔로워 파티션에 데이터가 정상적으로 적재되었는지 기다리기 때문에 일부 브로커에 장애가 발생하더라도 프로듀서는 안전하게 데이터를 전송하고 저장할 수 있음을 보장할 수 있다.
3) min.insync.replicas 옵션값에 따라 데이터의 안정성이 달라진다.
모든 리더 파티션과 팔로워 파티션의 적재가 아닌 ISR에 포함된 파티션들로 판단하기 때문이다.
참고 (브로커와 리더 파티션, 팔로워 파티션의 모습)
min.insync.replicas 옵션값
프로듀서가 리더 파티션과 팔로워 파티션에 데이터가 적재되었는지 확인하기 위한 최소 ISR그룹의 파티션 개수이다.
| value | 설명 |
| 1 | ISR 중 최소 1개 이상의 파티션에 데이터가 적재되었음을 확인한다. 이 경우는 ISR 중 가장 처음 적재가 완료되는 파티션은 리더 파티션이기 때문에 acks = 1로 했을때와 동일한 동작을 한다. |
| 2 | 이때부터 acks를 all로 설정하는 의미가 있다. ISR의 2개 이상의 파티션에 데이터가 정상 적재되었음을 확인한다는 뜻이다. ISR의 2개 이상의 파티션에 적재되었음을 확인한다는 뜻은, 적어도 리더 파티션과 1개의 팔로워 파티션에 데이터가 정상적으로 적재되었음을 보장한다. |
1) 위 옵션값을 설정할때는 복제 개수도 함께 고려해야한다.
운영하는 카프카 브로커 개수 < min.insync.replicas 옵션값 의 경우
프로듀서가 더는 데이터를 전송할 수 없다. NotEnoughReplicasException 또는 NotEnoughReplicasAfterAppendException이 발생하기 때문이다.
(예시)
복제 개수가 3이고, min.insync.replicas를 3으로 설정했을 경우 브로커 3대 중 1대에 이슈가 발생하여 동작하지 못하는 상황이 생기면 프로듀서는 데이터를 해당 토픽에 더는 전송할 수 없다. 왜냐하면 최소한으로 복제되어야 하는 파티션 개수가 3인데 팔로워 파티션이 위치할 브로커의 개수가 부족하기 때문이다.
2) 절대로 브로커 개수와 동일한 숫자로 설정하면 안된다. 토픽별 min.insync.replicas 옵션값은 브로커 개수 미만으로 설정해서 운영해야한다.
브로커 3대로 클러스터를 운영하면서 min.insync.replicas 옵션을 3으로 설정하는 경우
카프카 클러스터의 버전 업그레이드와 같은 상황이 발생하면 롤링 다운 타임이 생긴다.
브로커가 1대라도 중단되면 프로듀서가 데이터를 추가할 수 없다. 왜냐하면 min.insync.replicas가 3일 경우에는 최소한 브로커가 3대 이상 실행중이여야 3개의 복제본(리더 파티션 1, 팔로워 파티션 2)이 생기는 것을 만족할 수 있기 때문이다.
만약 브로커를 3대 이상으로 묶어 클러스터로 운영할때는 복제개수는 3, min.insync.replicas를 2로 설정하고 프로듀서는 acks = all로 설정하는 것을 추천한다.