HTTP 요청 ID를 Kafka consumer까지 잇는 법

HTTP 요청은 응답을 돌려주고 끝나지만 Kafka 작업은 나중에 처리됩니다. 이 둘을 같은 업무 payload로 억지로 묶지 않고, 별도의 correlation header를 전달하면 JSON 계약을 보존하면서 한 요청의 흐름을 따라갈 수 있습니다.

두 ID를 혼동하지 않기

• Idempotency-Key는 재시도된 업무 명령을 하나로 수렴시키는 값입니다.
• X-Request-Id는 이번 transport attempt의 로그·응답·메시지를 연결하는 값입니다.

Producer는 현재 request ID가 유효할 때만 Kafka record header에 넣고, 없으면 기존 message 전송 경로를 유지합니다. Consumer는 유효한 header를 우선하고, 오래된 메시지의 messageId fallback은 호환성을 위해 남깁니다. 원문 payload와 사용자 정보는 로그에 복사하지 않습니다.

실패도 관측한다

Kafka send()가 반환하는 future의 비동기 실패를 try/catch만으로 잡을 수 없습니다. null future, callback 예외, DLQ 전환을 각각 bounded error log와 metric으로 확인해야 합니다. 성공 로그와 실패 로그를 같은 업무 상태로 기록하지 않는 것도 중요합니다.

확인 질문

1. 이 ID는 업무 중복을 막는가, 아니면 조사만 돕는가?
2. consumer가 재시작해도 header·fallback으로 원 요청을 찾을 수 있는가?
3. 실패 payload를 로그에 남기지 않고 topic·error type·request ID만으로 조사할 수 있는가?

관련 강좌: HTTP 재시도와 요청 상관관계