인프런 커뮤니티 질문&답변
작성한 질문수
중복 컨슘 방지에 대해서 여쭤보고 싶습니다!
작성
·
25
0
만약 카프카를 사용하고 있고 처리 실패하는 경우 retry 큐로 보내서 재시도 하는 방식을 사용하고 있다고 가정하겠습니다.
만약 서버가 메시지를 받아서 처리하던 중에 리밸런싱이 발생했습니다. 메시지를 성공적으로 처리했고 커밋을 하려했지만 리밸런싱이 발생해 커밋을 하지 못했습니다. 그럼 그 메시지는 다른 컨슈머가 다시 받아서 중복으로 처리할 수 있을것 같은데 어떻게 방지를 할 수 있나요..?
찾아보니 인박스 패턴이라는것이 있던데 메시지를 받았을 때 상태를 저장하고 이후에 재시도를 해도 상태값이 있다면 패스하는 방식으로 이해를 했습니다.
하지만 위에 상황에서 첫 컨슘에서 메시지를 처리하고 있다가 리밸런싱이 발생했고 이후에 다시 처리할 때 상태값이 있어서 패스 했습니다. 하지만 이후에 첫 컨슘에서 처리중에 예외가 발생했다면 어떻게 처리를 해야할까요...?
답변 2
0
안녕하세요 YOGURT님 질문 주셔서 감사합니다.
우선 처리 실패에 대해서는 DLQ를 사용하는 패턴을 구현하셨다는걸로 이해를 하였습니다.
그리고 정확히 한번 즉 exactly-once 정책을 보장하고 싶은 고민으로 보입니다.
우선 해결해야 하는 부분은 컴슈머 입장에서의 멱등성 보장입니다.
어떤 전략을 사용하냐에 따라 다르지만, 기본적으로 중복된 메시지가 들어와도 이미 처리가 되었다면, 더이상 처리가 되지 않도록 하는 방식 구현이 되면 좋습니다. 대표적으로 처리한 ID를 기록해두면 좋겠죠 이를 통해서 멱등성도 보장이 가능하고요
말씀해 주셨던 인박스 패턴이라는게 결국 이런 멱등성을 보장하기 위한 패턴ㅇ입니다. 상태 저장소에 기록함으로써 처리하였던것을 기록하고 검증하는 것이죠.
근데 조금 제가 이해가 안가는 부분이 있는거 같아요.
하지만 위에 상황에서 첫 컨슘에서 메시지를 처리하고 있다가 리밸런싱이 발생했고 이후에 다시 처리할 때 상태값이 있어서 패스 했습니다. 하지만 이후에 첫 컨슘에서 처리중에 예외가 발생했다면 어떻게 처리를 해야할까요...?
해당 부분에서 첫번쨰에서 리밸런싱 발생 -> 하지만 인박스 패턴 및 리밸런싱이 발생해도 상태값을 통해 다시 같은 메시지를 스킵 -> 이후의 첫 컨슘??
이 첫 컨슘이 어떤 컨슘을 의미하시는지 상황이 명확하게 그려지지는 않는거 같아서요. 혹시 마지막에 질문주신 부분을 좀 더 상세하게 설명해 주실 수 있을까요??
음 아직도 잘 어떤 상황을 가정하신지 잘 이해가 안가네요 ㅠㅠ 제가 이런 부분에서 부족해서 죄송스럽습니다.
제가 아직까지 이해한바로는
A(컨슈머)에서 이벤트를 수신
A에서 이벤트를 받고 일련의 작업을 진행
A에서 작업을 수행하는 도중인데, 리밸런싱이 발생
리밸런싱으로 인해서 메시지를 재수신, 하지만 이떄 A의 작업은 마무리가 되어서 상태 저장소에 존재
그리고, 재수신한 메시지를 처리하려고 하는데, 상태 저장소에 존재하기 떄문에 스킵
해당 과정이 인박스 패턴
이 과정까지는 이해가 되었는데 추가로 말씀해주신 이전에 처리하고 있던곳에서 예외가 발생하였다는것이 무슨 뜻인지 아직 잘 그려지지가 않는거 같습니다.
0
안녕하세요, 인프런 AI 인턴입니다. YOGURT님.
질문해 주신 내용은 Kafka에서 메시지 중복 소비를 방지하기 위한 전략에 관한 것입니다. Kafka는 기본적인 메시지 브로커 시스템으로, 메시지의 중복 소비를 방지하는 데 여러 가지 기법들이 존재합니다.
재시도 시나리오 및 중복 방지
리밸런싱 중 문제:
1. 리밸런싱 발생: Kafka에서 컨슈머 그룹 내의 파티션 재할당(Rebalancing)이 발생했을 때, 작업 도중 커밋에 실패한 경우에는 메시지가 실제로 다시 전달될 수 있습니다. 이는 메시지 처리가 완료되지 않았음을 의미하므로, 기본적으로는 최적의 정확성을 위해 메시지가 다시 처리될 수 있도록 설계됩니다.
2. 커밋되지 않은 메시지: 리밸런싱 이후 메시지를 커밋할 수 없었다면, Kafka는 해당 메시지를 다른 컨슈머가 소비할 수 있도록 합니다. 이때, 중복 처리를 방지하기 위해 주로 메시지의 상태를 데이터베이스에 저장하는 방식이 사용됩니다.
인박스 패턴:
- 인박스 패턴의 활용: 메시지 수신 즉시 그것에 대한 상태를 데이터베이스나 캐시와 같은 외부 저장소에 기록해두는 방법을 통해 중복 처리 방지를 도모합니다.
- 문제 발생 시 처리: 작업 도중 예외가 발생할 경우와 성공적으로 메시지를 처리했으나 커밋 실패로 리밸런싱이 되는 경우, 이후에 동일 메시지가 들어오면 상태를 검사하여 중복 처리를 피할 수 있습니다. 성공 처리는 상태의 업데이트 또는 데이터베이스 트랜잭션 완료 상태로도 표시될 수 있습니다.
예외 처리 및 재시도 전략
- 상태 관리: 메시지 처리 중 예외가 발생하면 해당 메시지를 실패 상태로 업데이트하고, 특정 횟수 이상 실패하면 추가적인 대처(알림 발송 등) 전략을 줄 수 있습니다.
- Failover 및 Retry 큐: 실패한 메시지를 Retry 큐로 보내는 방식으로 정책적으로 처리 횟수 및 예외 상황에 따른 로직을 추가 구현할 수 있습니다.
추가 자료
이 링크들은 메시지 중복 소비와 관련된 더 많은 정보를 제공하며, Kafka의 메시지 재처리 및 Offset 관리에 대해 논의합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
아 잘못 적은거같아요! 스킵하고 커밋을 했는데 이전에 처리하고 있던곳에서 예외가 발생한 경우입니다..!