인프런 커뮤니티 질문&답변
작성한 질문수
멱등성 프로듀서 retries 관련 질문입니다.
해결된 질문
작성
·
36
·
수정됨
0
1. retries가 Integer.MAX_VALUE로 설정되는 이유?
아래와 같은 이유로 retries가 Integer.MAX_VALUE로 설정되는 것인지 궁금합니다.
멱등성 프로듀서는 각 파티션 단위에서만 멱등성이 보장되는 것으로 알고 있습니다. (SID를 브로커의 메모리에 저장하기 때문에)
레코드에 key가 없고 라운드로빈으로 파티션을 결정하는 형태라는 가정하에서, 강의에서 소개해주신 예제(프로듀서가 레코드를 정상적으로 보냈으나 네트워크 이슈 등으로 ack를 받지 못한 케이스)를 생각해봤을 때, retries를 Integer_MAX_VALUE로 설정한 이유는 다른 파티션으로 레코드를 보내는 상황을 막기 위함인 건가요?
위 예제의 강의 자료내 그림에 대해서도 질문이 있는데, ack를 받지 못했을 때 send()를 통해 다시 보내는 것처럼 그림이 되어 있는데, 이것이 실제로 프로듀서가 다시 send() 하는 것을 의미하신 건지, retry를 의미하신 건지 궁금합니다.
2. retries를 Integer.MAX_VALUE로 설정되어도 괜찮은가요?
네트워크 순단 등은 괜찮을 것 같은데 애플리케이션과 카프카 브로커 간 장기적인 네트워크 문제가 발생한다면 retries Integer.MAX_VALUE 설정은 단일실패지점이 되지 않을까 싶은 생각이 들었습니다.(데이터 정합성도 중요하지만 애플리케이션에서 다른 여러 서비스를 운영하고 있을 경우 서비스의 지속성이 더 중요할 경우)
이런 점을 고려하여 멱등성 프로듀서를 사용할 때는 애플리케이션 내에서 프로듀서를 별도의 스레드 풀로 관리하는 비동기 처리, 비동기 큐 관리(Backpressure 등)을 반드시 마련해야하는지 궁금합니다.
답변 2
1
안녕하세요.
1. retries가 Integer.MAX_VALUE로 설정되는 이유?
멱등성 보장과는 크게 관련이 없을것 같습니다. 멱등성 프로듀서가 설정되기 전인 카프카 2.3의 producer config를 보면 retries가 2147483647로 설정되어 있기 때문입니다. 예상치 못한 네트워크의 오류 등의 이슈로 데이터를 전송하지 못한 부분에 대해 지속적으로 재처리하기 위한 목적으로 이렇게 큰 값을 설정한 것으로 보입니다. 마지막으로 send() 메서드를 호출한 이후로는 내부적으로 무한 루프가 돌면서 재처리를 진행한다고 보시면 좋을 것 같아요.
2. retries를 Integer.MAX_VALUE로 설정되어도 괜찮은가요?
send() 메서드를 호출한 이후에 내부적으로 무한루프가 돌면서 retry를 수행하게 됩니다. 다행히도 카프카 프로듀서에는 request.timeout.ms 옵션이 존재합니다. 이 옵션은 성공/실패를 return하기 까지 기다리는 최대 시간인데 기본값은 2분이므로, 만약 2분까지 기다리는 것(브로커의 장애, 네트워크의 장애 등)이 부담스러우시다면 이 옵션을 수정하는 것을 추천드립니다.
마지막으로 멱등성 프로듀서를 사용 여부와 관계없이 프로듀서를 스레드풀로 반드시 관리해야 하는 것은 아닙니다. 필요에 따라 그렇게 사용하셔도 되지만 필수는 아닐 것 같습니다. 다만, 개인적으로 권장하는 것은 producer code를 짜실때 send()메서드 이후 비동기(Callback)로 결과를 받을 수 있도록 짜는 것이 중요할 것 같습니다.
0
안녕하세요, 인프런 AI 인턴입니다.
김경민 님의 멱등성 프로듀서 관련 질문에 대해 답변드리겠습니다.
1. retries가 Integer.MAX_VALUE로 설정되는 이유?
멱등성 프로듀서는 중복된 데이터 전송을 방지하기 위해 각 파티션 단위에서 멱등성을 보장합니다. retries가 Integer.MAX_VALUE로 설정되는 것은 다음과 같은 이유에서 가능합니다:
- 프로듀서가 네트워크 문제 등으로 인해 브로커로부터 ack를 받지 못했을 경우, 데이터의 일관성을 유지하기 위해 최대한 재시도하여 데이터를 손실 없이 전달하려는 목적이 있습니다.
- 라운드로빈 방식으로 파티션을 선택할 때, retry 설정을 통해 같은 파티션에 계속 전송을 시도함으로써 데이터가 다른 파티션으로 잘못 전송되는 상황을 방지할 수 있습니다.
강의 자료의 그림에서 언급된 부분은 retry 상황을 설명한 것이며, 프로듀서가 send()를 통해 재전송하는 것이 아닌, 내부적으로 이미 보내진 메시지를 다시 시도하는 것을 의미합니다.
2. retries를 Integer.MAX_VALUE로 설정되어도 괜찮은가요?
Integer.MAX_VALUE로 설정하는 것은 retries 무제한에 가깝고, 장기적인 네트워크 문제 시 단점이 될 수 있습니다. 이로 인해 리소스가 계속 차단되는 상황이 생길 수 있어, 다음과 같은 전략이 필요합니다:
- 비동기 프로듀서 처리: 다른 비즈니스 로직에 영향을 미치지 않도록 별도의 스레드 풀로 관리하는 것이 유리합니다.
- 비동기 큐 관리: Backpressure 기술을 활용하여 네트워크 장애 시에도 처리되지 않은 데이터를 효율적으로 관리할 수 있도록 해야 합니다.
이런 방식으로 멱등성 및 데이터 정합성을 유지하면서 애플리케이션의 지속성을 확보할 수 있습니다. 추가적인 문의 사항이 있으시면 언제든지 질문해 주세요!