Kafka producer retry 증가는 겉으로 보면 client 쪽 문제처럼 보이지만, 실제로는 delivery path가 압박 아래에서 평소보다 더 오래 걸리고 있다는 뜻인 경우가 많습니다.
짧게 말하면 retry는 먼저 delivery timing의 증상으로 봐야 합니다. 그리고 숫자를 무작정 낮추기 전에 broker acknowledgement, network timing, producer guarantee를 확인해야 합니다.
이 글은 retry 증가를 원인과 증상을 혼동하지 않고 읽는 방법을 정리합니다.
producer retry가 보통 뜻하는 것
retry는 send가 기대한 경로 안에서 성공적으로 끝나지 못해서 producer가 다시 시도할 때 발생합니다.
이게 곧바로 data loss나 cluster failure를 뜻하는 것은 아닙니다. 오히려 시스템은 여전히 동작하지만, delivery path가 정상보다 덜 건강하다는 신호인 경우가 많습니다.
retry 숫자만으로는 부족한 이유
retry 증가는 전혀 다른 상황에서 나올 수 있습니다.
- broker acknowledgement가 느려졌다
- network가 불안정하다
- producer timeout budget이 너무 빡빡하다
- cluster가 부하를 받고 있다
그래서 retry는 그 자체를 조정 대상으로 보기보다, timing과 guarantee를 확인하라는 신호로 보는 편이 맞습니다.
timing 설정이 생각보다 훨씬 중요하다
Kafka producer 동작은 한 번의 시도를 얼마나 오래 기다릴지, 전체 delivery budget을 얼마나 줄지에 크게 영향을 받습니다.
delivery.timeout.ms와 request timing, acknowledgement 기대값이 temporary slowdown을 그냥 넘길지, 눈에 띄는 retry storm으로 만들지를 가릅니다.
retry spike를 이해하는 간단한 관점
retry가 증가했다는 건 보통 두 가지 중 하나가 먼저 벌어진 것입니다.
- delivery path가 느려졌다
- 기다리는 budget이 실제 경로보다 더 작아졌다
그래서 첫 질문은 “retry가 몇 개인가”보다 아래가 더 중요합니다.
- latency도 같이 올랐는가
- broker acknowledgement가 느려졌는가
- cluster가 pressure 상태로 들어갔는가
흔한 root cause
1. broker acknowledgement가 평소보다 느리다
cluster는 여전히 트래픽을 받지만, producer가 send 완료까지 기다리는 시간이 길어집니다.
2. network timing이 불안정하다
latency spike나 간헐적인 packet loss만으로도, 대체로 건강한 cluster가 retry-heavy한 상태로 보일 수 있습니다.
3. producer guarantee가 현재 경로보다 더 강하다
ordering, durability, idempotence는 중요하지만, timing 압박을 더 선명하게 드러내기도 합니다.
4. cluster 쪽 pressure가 쌓이고 있다
partition leadership 변화, broker load, disk pressure가 먼저 retry 증가로 드러날 수 있습니다.
retry를 단독 지표처럼 보면 안 되는 이유
retry는 아래와 같이 같이 봐야 합니다.
- request latency
- broker-side load
- error type 분포
- delivery timeout 동작
이 맥락이 없으면 팀이 잘못된 레이어를 고치기 쉽습니다.
실전 점검 순서
1. retry 증가와 latency 증가가 같이 갔는지 본다
둘이 함께 움직였다면 timing pressure가 핵심일 가능성이 큽니다.
2. delivery.timeout.ms와 관련 request timing을 본다
producer budget이 실제 network와 broker 상태와 맞는지 확인합니다.
3. acknowledgement 기대값과 durability 설정을 본다
더 강한 guarantee 경로일수록 producer가 흡수할 수 있는 지연 폭이 달라집니다.
4. broker와 partition 건강 상태를 확인한다
retry는 종종 cluster pressure의 client-side 관측값입니다.
5. 총량보다 error pattern을 본다
반복되는 timeout 패턴 하나가 raw retry count보다 훨씬 더 actionable합니다.
바로 확인할 수 있는 명령들
kafka-topics.sh --bootstrap-server localhost:9092 --describe
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --all-groups --describeproducer metric을 broker와 partition 상태와 함께 봐야 retry가 특정 cluster 변화와 맞물리는지 보입니다.
실전에서 가지면 좋은 관점
retry는 보통 delivery timing 문제의 끝단 증상이라고 보는 편이 가장 유용합니다.
실제로는 아래 문제 중 하나가 먼저 있는 경우가 많습니다.
- broker acknowledgement가 예상보다 느리다
- network timing이 불안정하다
- producer guarantee가 현재 경로가 감당할 수 있는 것보다 강하다
- cluster pressure 때문에 send completion 속도가 줄었다
어떤 timing 문제가 활성화됐는지 모른 채 retry 수만 낮추거나 설정을 느슨하게 만들면, 증상은 줄어 보여도 실제 리스크는 그대로 남을 수 있습니다.
FAQ
Q. retry가 늘면 Kafka가 실패 중이라는 뜻인가요?
항상은 아닙니다. 완전히 죽었다기보다, 평소보다 더 느리거나 덜 안정적이라는 뜻인 경우가 많습니다.
Q. 가장 빠른 첫 단계는 무엇인가요?
retry 증가와 request latency, broker 건강 상태를 동시에 비교하는 것입니다.
Q. timeout만 늘리면 해결되나요?
무작정은 안 됩니다. 지연이 어디서 오는지 보지 않으면 실제 cluster 문제를 그냥 숨길 수 있습니다.
Q. client보다 cluster를 먼저 의심해야 하는 순간은 언제인가요?
retry가 broker load, partition movement, acknowledgement latency와 함께 올라갈 때입니다.
Read Next
- consumer도 함께 불안정하다면 Kafka Rebalancing Too Often을 보세요.
- 긴 처리 사이클 뒤 문제가 드러난다면 Kafka Max Poll Interval Guide를 보세요.
- partition이 고르지 않아 보이면 Kafka Leader Imbalance Guide를 보세요.
Related Posts
Sources:
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.