[Kafka] 프로듀서 멱등성 보장하기

개요

멱등성은 동일한 작업을 여러 번 수행하더라도 동일한 결과가 나타나는 특성을 의미합니다. 따라서 멱등성을 지닌 프로듀서는 같은 데이터를 여러 번 전송하더라도 해당 데이터가 카프카 클러스터에 단 한 번만 저장되도록 보장합니다.

그렇다면 프로듀서에 어떻게 멱등성을 적용하고, 이를 통해 데이터의 중복 저장 없이 정확히 한 번만 저장되도록 보장할 수 있을까요? 이번 글에서는 프로듀서에 멱등성을 보장하도록 적용하는 방법에 대해 상세하게 알아보도록 하겠습니다.

 

 

메시지 전송 방식

Producer와 Broker의 설정 및 구성에 따라 Kafka에서는 메시지 전달 보장 수준을 아래와 같이 세 가지 방식으로 구분합니다.

https://medium.com/@andy.bryant/processing-guarantees-in-kafka-12dd2e30be0e

• 최대 한 번 (At most once): 메시지가 한 번만 전송되며, 재전송은 발생하지 않는다. 그러나 이로 인해 메시지가 유실될 수 있는 가능성이 있다.
• 최소 한 번 (At least once): 메시지가 반드시 전송되며, 최소한 한 번 이상은 전송이 보장된다. 그러나 이 과정에서 메시지가 중복으로 전송될 수 있다.
• 정확히 한 번 (Exactly once): 메시지가 정확히 한 번만 전송되며, 재전송은 일어나지 않는다. 따라서, 메시지가 유실되지 않는 것이 보장된다.

각각의 처리 방식에 대해 프로듀서의 관점에서 조금 더 자세히 살펴보도록 하겠습니다.

 

At most once(최대 한번)

https://www.nasa1515.com/apache-kafka-pruducer-processing-method-ack-idempotence/#at-most-once

'최대 한 번' 전략에서는 메시지가 단 한 번만 전송됩니다. 이는 메시지에 대한 응답 확인(Ack)을 받지 못하더라도 재전송을 하지 않음을 의미하며, 이를 통해 중복 전송을 방지합니다. 그러나 이 전략의 한계점으로는 네트워크 문제 등으로 인해 메시지를 제대로 받지 못하는 경우, 해당 메시지가 유실될 수 있다는 점이 있습니다.

이 전략은 메시지의 손실 가능성을 감수하면서도 중복 전송을 방지하는 접근 방식이며, 높은 처리량과 짧은 대기 시간을 쉽게 달성할 수 있습니다. 따라서 대량의 로그 수집이나 IoT 등의 환경에서 유용하게 사용되는 전략입니다.

 

At least once(최소 한 번)

https://www.nasa1515.com/apache-kafka-pruducer-processing-method-ack-idempotence/#at-least-once

'최소 한 번' 방식에서는 메시지의 중복을 허용하지만, 메시지의 손실은 허용하지 않습니다. 이 방식에서 프로듀서는 브로커로부터 응답 확인(Ack)을 받지 못했을 때 브로커가 메시지를 저장은 했지만 응답만 전송하지 못했는지, 아니면 메시지 저장과 응답 전송 모두 실패했는지를 판단할 수 없습니다.

따라서, 브로커가 메시지를 저장했으나 응답만 전송하지 못한 경우, 프로듀서는 응답을 받지 못했기 때문에 같은 메시지를 재전송하게 됩니다. 이로 인해 중복된 메시지가 브로커에 저장될 수 있습니다. 즉, 이 전략은 메시지의 손실을 방지하기 위해 중복 저장을 허용하는 접근 방식으로 데이터의 완전성을 최우선으로 두는 경우에 매우 유용합니다.

 

Exactly once(정확히 한 번)

https://www.nasa1515.com/apache-kafka-pruducer-processing-method-ack-idempotence/#exactly-once

'정확히 한 번' 방식은 멱등성(idempotence) 원칙을 가장 잘 따르는 방식입니다. 이 방식에서는 메시지가 딱 한 번만 전달되며, 어떠한 메시지도 손실되지 않아야 합니다. 프로듀서 ID와 시퀀스 번호를 활용해 응답 확인(Ack)을 받고 메시지를 전송하는 과정이 필수적입니다. 하지만 이런 특성 때문에 다른 방식에 비해 응답 대기 시간이 길어지고, 처리량이 상대적으로 떨어집니다.

이 방식은 메시지가 유실 없이 정확히 한 번만 전송되는 것을 보장해야 하는 상황에서 사용됩니다. 

 

 

Producer Acknowledgements(acks)

Apache Kafka의 Producer Acknowledgements (acks) 설정은 프로듀서가 브로커에게 메시지를 보낸 후 받는 응답의 수준을 결정합니다. 

프로듀서의 확인 응답(acks) 설정에는 3가지의 옵션이 존재합니다.

• acks=0: 이 설정에서는 프로듀서가 브로커에게 메시지를 보내고, 어떠한 응답도 기다리지 않습니다. 이는 가장 빠른 전송 속도를 제공하지만, 메시지가 실제로 브로커에 도달했는지 확인할 수 없어 데이터 손실의 위험이 가장 높습니다.
• acks=1: 프로듀서는 리더 브로커가 메시지를 받았을 때만 응답을 받습니다. 이 설정은 메시지가 최소 한 곳의 브로커에 저장되었음을 보장하지만, 이 브로커가 장애가 발생하면 메시지가 손실될 수 있습니다. 이 옵션은 전송 속도와 신뢰성 사이에서 균형을 제공합니다.
• acks=all 또는 acks=-1: 이 설정은 프로듀서가 리더 브로커 뿐만 아니라 모든 ISR(In-Sync Replicas)에 의해 메시지가 처리되었다는 확인을 받을 때까지 기다립니다. 이는 데이터 신뢰성을 최대화하지만, 전송 속도가 느려질 수 있습니다. 이 옵션은 모든 레플리카가 동기화되어 데이터의 내구성이 가장 중요한 경우에 사용됩니다.

조금 더 자세히 알아보겠습니다.

 

acks=0

https://magpienote.tistory.com/251

acks=0 설정은 '최대 한번(At most once)' 전송 전략에 해당합니다.

이 설정을 사용하는 경우, 프로듀서는 메시지를 전송한 순간에 메시지가 성공적으로 작성된 것으로 간주합니다. 즉, 브로커로부터의 응답을 기다리지 않습니다.

이런 상황에서, 만약 브로커가 오프라인 상태가 되거나 예외가 발생하여 데이터 쓰기 작업이 중단되더라도 프로듀서는 이를 알 수 없습니다. 결과적으로 이런 경우에는 데이터가 손실될 수 있기에, acks=0 설정은 메시지의 유실이 허용되는 상황에서 유용하게 사용됩니다.

 

acks=1

https://magpienote.tistory.com/251

acks=1 설정은 '최소 한번(At least once)' 전송 전략에 해당되며, 이 설정을 사용하면 프로듀서는 리더 브로커로부터 확인 응답을 받는 시점에 메시지 쓰기가 성공했다고 판단합니다.(카프카 v1.0부터 v2.8까지 default 설정입니다.)

주의할 점은 acks=1 설정에서는 프로듀서가 오직 리더가 데이터를 저장한 시점에만 응답을 받기 때문에, 리더 이외의 레플리카들이 데이터를 성공적으로 복제했는지는 확인하지 못합니다. 따라서 리더 브로커가 갑자기 오프라인 상태가 되고, 레플리카들이 아직 데이터를 복제하지 못한 경우에는 데이터 손실이 발생할 수 있습니다.

만약 브로커가 확인 요청을 받지 못했다면 프로듀서는 데이터 쓰기를 성공적으로 처리하기 위해 요청을 재시도할 수 있습니다. 결국 acks=1 설정을 사용하면 재시도를 통해 중복 전송을 허용하지만, 프로듀서가 리더를 통해 데이터 쓰기가 성공했는지 확인할 수 있기 때문에 데이터의 안정성은 acks=0에 비해 높아지게 됩니다.

 

acks=all or -1

https://magpienote.tistory.com/251

acks=all 또는 acks=-1 설정은 '정확히 한 번(Exactly once)' 전송 전략에 해당합니다. 이 설정을 사용하면, 프로듀서는 리더 브로커를 포함한 모든 레플리카 브로커들로부터 확인 응답을 받은 시점에 메시지 쓰기가 성공했다고 판단합니다.(카프카 v3.0부터 default 설정입니다.)

이 방식은 acks=1 설정에 비해 더 높은 데이터 안정성을 제공하는데, 프로듀서는 모든 레플리카 브로커들이 데이터를 성공적으로 저장했다는 확인을 받기 때문에 어떠한 브로커에 문제가 발생하더라도 데이터 손실 위험이 크게 줄어듭니다. 하지만 모든 레플리카 브로커들로부터 응답을 받아야 하므로, 네트워크 지연이나 브로커의 부하 등으로 인해 전체 메시지 전송 시간이 늘어날 수 있습니다.

하지만 아직까지도 중복 전송이 가능하다는 문제가 존재하는데, 다음과 같은 상황입니다.

https://medium.com/@shesh.soft/kafka-idempotent-producer-and-consumer-25c52402ceb9

위 이미지는 프로듀서가 브로커에게 메시지를 보내고, 브로커가 프로듀서에게 ack를 보내는 과정입니다. 현재까지는 모두 정상적입니다. 하지만 프로듀서가 브로커에게 보낸 메시지에 대한 응답이 네트워크 지연 등의 이유로 프로듀서에게 돌아오지 않는 상황을 가정해 보겠습니다. 

https://medium.com/@shesh.soft/kafka-idempotent-producer-and-consumer-25c52402ceb9

위 상황에서는 'y'라는 메시지를  프로듀서가 브로커에게 보냈는데, 이 메시지는 브로커에 의해 정상적으로 파티션에 저장되었지만 ack가 프로듀서에게 도착하지 못했습니다. 이러한 경우 프로듀서는 오류로 판단하고 동일한 메시지인 'y'를 다시 보내게 됩니다. 그 결과 브로커에는 'y'메시지가 중복으로 저장됩니다.

따라서 멱등성 있는 '정확히 한 번(Exactly once)'을 구현하기 위해서는 acks 설정뿐만 아니라 idempotent 설정 그리고 Brocker의 max.in.flight.requests.per.connection 설정, min.insync.replicas 설정, retries도 같이 되어야 합니다. 이 부분은 아래에서 좀 더 알아보겠습니다.

 

 

멱등성 보장 설정

멱등성(idempotence)이란 프로듀서가 레코드를 전송했지만, 네트워크 이슈 등으로 인해 ack를 받지 못한 경우에도 중복 메시지의 전달 및 저장을 방지하는 것을 의미합니다. 이를 위해 카프카는 프로듀서 ID(PID)와 시퀀스 번호를 기반으로 메시지를 추적하고, 동일한 커밋에 대해 중복 처리를 방지합니다.

멱등성을 보장하기 위한 설정은 다음과 같습니다.

• acks: 프로듀서가 요청을 보내고 리더가 레플리카의 수신을 확인해야 하는 개수를 결정. 'all' 또는 '-1'로 설정한다.
• enable.idempotence: 프로듀서가 레코드 쓰기 작업을 단 한 번만 허용할 것인지를 결정. 'true'로 설정해야 멱등성을 보장한다.
• max.in.flight.requests.per.connection: 한 번에 몇 개의 요청을 전송할 것인지를 결정. 이 값은 1 이상 5 이하로 설정해야 한다.
• retries: 메시지를 전송하기 위해 재시도되는 횟수를 결정. 이 값은 0 이상으로 설정해야 한다.
• min.insync.replicas: 동기화하는 레플리카의 수를 결정. acks=all일 경우 보통 2로 설정한다(브로커 설정이다).

위의 모든 설정값을 적용하지 않으면 ConfigException이 발생하므로 주의가 필요합니다.(설정값을 확인하는 부분)

 

enable.idempotence

카프카 v3.0 부터는 acks=all(-1)과 enable.idempotence=true가 default로 적용되었습니다 그러나 v2.8 이하 버전에서는 acks=-1과 enable.idempotence=false가 default 설정이므로, 이러한 버전에서는 별도로 설정을 변경해줘야 합니다.

https://medium.com/@shesh.soft/kafka-idempotent-producer-and-consumer-25c52402ceb9

enable.idempotence=true로 설정하면, 위 이미지처럼 각 프로듀서에는 고유한 프로듀서 ID(PID)가 할당됩니다. 프로듀서는 메시지를 브로커에게 보낼 때마다 이 PID를 포함하며, 각 메시지는 순차적으로 증가하는 시퀀스 번호를 받습니다. 프로듀서가 메시지를 보내는 각 토픽 파티션마다 별도의 시퀀스가 유지되고, 브로커는 파티션별로 성공적으로 처리된 PID-시퀀스 번호 조합 중 가장 큰 값을 추적합니다.

https://medium.com/@shesh.soft/kafka-idempotent-producer-and-consumer-25c52402ceb9

위 이미지를 보면 브로커는 프로듀서의 요청이 PID/토픽파티션 쌍에서 마지막으로 커밋된 메시지보다 시퀀스 번호가 정확히 1만큼 크지 않은 경우, 프로듀서의 요청을 거부하는 것을 볼 수 있습니다. 이를 통해 프로듀서는 실패에 따른 요청 재시도를 할 수 있지만, 모든 메시지는 로그에 정확히 한 번만 기록됩니다. 하지만 새로운 프로듀서 인스턴스에는 새로운 고유 PID가 할당되므로, 단일 프로듀서 세션 내에서만 멱등성을 보장할 수 있습니다.

 

max.in.flight.requests.per.connection

카프카에서 max.in.flight.requests.per.connection 설정은 멱등성(idempotence)을 보장하는 데 중요한 역할을 합니다. 이 설정은 한 번의 연결에서 동시에 처리할 수 있는 최대 요청 수를 의미합니다. 카프카 v0.11 버전 이상에서는 멱등성이 활성화된 프로듀서의 경우, 이 값을 5 이하로 설정하는 것이 권장되는데 그 이유는 다음과 같습니다.

• 메시지 순서 보장: 카프카의 멱등 프로듀서는 같은 파티션에 대해 메시지의 순서를 보장해야 합니다. max.in.flight.requests.per.connection 값이 5 이하일 때, 프로듀서는 한 메시지가 실패하면 그 후의 메시지들은 서버에 전송되지 않습니다. 이러한 동작은 메시지의 순서가 변경되지 않도록 보장하는 데 중요합니다. 만약 이 값이 5보다 크다면, 프로듀서는 재시도하는 동안 다른 메시지들을 전송할 수 있어, 메시지 순서가 뒤바뀔 위험이 있습니다.
• 중복 메시지 방지: 멱등성 프로듀서는 메시지의 중복 전송을 방지합니다. max.in.flight.requests.per.connection 값이 너무 크면 네트워크 지연 등의 문제로 인해 중복 메시지가 발생할 가능성이 증가합니다. 따라서 이 값을 5 이하로 설정하여 이러한 문제를 줄일 수 있습니다.

https://magpienote.tistory.com/251

 

 

코드

실제 코드에서는 다음과 같이 프로듀서의 속성을 설정하여 멱등성 기능을 활성화할 수 있습니다.

Properties properties = new Properties();

// 멱등성 활성화 설정
properties.setProperty(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true");

enable.idempotence를 true로 설정하면 데이터가 정확히 한 번만 적재되도록 하기 위해 프로듀서의 몇 가지 옵션이 자동으로 설정됩니다. 대표적으로 데이터 재전송 횟수를 결정하는 retries는 기본값인 Integer.MAX_VALUE로 설정되고, acks 옵션은 all로 설정됩니다.

 

 

멱등성 프로듀서의 한계

멱등성 프로듀서는 동일한 세션 내에서만 정확히 한 번의 전달을 보장합니다. 여기서 '동일한 세션'이란, PID(Producer ID)의 생명주기를 의미합니다. 만약 멱등성 프로듀서로 작동하는 프로듀서 애플리케이션에 문제가 발생해 종료되고 다시 시작하면 PID가 변경됩니다.

동일한 데이터를 전송하더라도, PID가 바뀌면 브로커는 다른 프로듀서 애플리케이션이 다른 데이터를 보냈다고 판단합니다. 따라서 멱등성 프로듀서는 장애가 발생하지 않는 상황에서만 데이터를 정확히 한 번 적재하는 것을 보장한다는 점을 명심해야 합니다. 

 

 

멱등성 프로듀서 사용 시 오류 확인

멱등성 프로듀서는 시퀀스 번호를 0부터 시작하여, 데이터를 전송할 때마다 이 번호를 1씩 증가시킵니다. 브로커는 멱등성 프로듀서가 전송한 데이터의 PID와 시퀀스 번호를 확인하는 과정에서, 시퀀스 번호가 일관성을 유지하지 않는 경우에는 OutOfOrderSequenceException을 발생시킬 수 있습니다.

이 예외는 브로커가 예상했던 시퀀스 번호와 실제로 받은 데이터의 시퀀스 번호가 일치하지 않을 때 발생합니다. OutOfOrderSequenceException이 발생하면, 시퀀스 번호의 순서가 뒤바뀔 수 있으므로, 순서가 중요한 데이터를 전송하는 프로듀서는 이 예외가 발생했을 때 적절히 대응할 수 있는 방안을 고려해야 합니다.

 

 

참고

• https://magpienote.tistory.com/251
• https://www.nasa1515.com/apache-kafka-pruducer-processing-method-ack-idempotence/
• https://www.conduktor.io/kafka/kafka-producer-acks-deep-dive/