HTTP 요청 ID를 Kafka consumer까지 잇는 법
HTTP 요청은 응답을 돌려주고 끝나지만 Kafka 작업은 나중에 처리됩니다. 이 둘을 같은 업무 payload로 억지로 묶지 않고, 별도의 correlation header를 전달하면 JSON 계약을 보존하면서 한 요청의 흐름을 따라갈 수 있습니다.
목차
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으로 확인해야 합니다. 성공 로그와 실패 로그를 같은 업무 상태로 기록하지 않는 것도 중요합니다.
ID 수명 비교
| 값 | 생성 시점 | 유지 범위 | 중복 방지 | 로그 규칙 |
|---|---|---|---|---|
| Request ID | HTTP attempt 시작 | 응답·producer·consumer | 아니요 | 형식·길이 검증 후 |
| Idempotency key | 업무 명령 생성 | 재시도 전체 | 예 | 원문보다 hash 권장 |
| Message ID | event 생성 | topic·DLQ·재처리 | event 중복 판정 | 허용 |
| User ID | 인증 | 사용자 수명 | 아니요 | metric label 금지 |
HTTP ──X-Request-Id──▶ producer ──record header──▶ consumer MDC
└── Idempotency-Key ──▶ command store (별도 수명) ─────┘
Consumer는 finally에서 MDC를 지워야 다음 메시지에 이전 ID가 섞이지 않습니다. header가 없거나 허용 길이를 넘으면 bounded ID나 message ID를 사용하고 사용자 문자열을 로그 context로 승격하지 않습니다.
확인 질문
- 이 ID는 업무 중복을 막는가, 아니면 조사만 돕는가?
- consumer가 재시작해도 header·fallback으로 원 요청을 찾을 수 있는가?
- 실패 payload를 로그에 남기지 않고 topic·error type·request ID만으로 조사할 수 있는가?
관련 강좌: HTTP 재시도와 요청 상관관계