피드로 돌아가기
Dev.toBackend
원문 읽기
HTTP 202와 Polling 패턴을 통한 Long-Running Operation 최적화
Async APIs: The 202 Accepted + Polling Pattern for Long-Running Operations
AI 요약
Context
보고서 생성 및 비디오 트랜스코딩과 같은 고부하 작업 시 HTTP 연결 유지로 인한 Gateway Timeout 발생 위험 존재. 클라이언트의 무분별한 재시도로 인한 중복 작업 수행 및 Load Balancer의 연결 강제 종료 문제 해결 필요.
Technical Solution
- POST 요청 시 작업을 큐에 적재 후 즉시 202 Accepted 상태 코드와 리소스 위치를 알리는 Location 헤더 반환
- 전용 상태 확인 Endpoint를 구축하여 Job의 진행 상태(Pending, Running, Done, Failed)를 추적하는 구조 설계
- Retry-After 헤더를 통한 클라이언트의 폴링 주기 제어로 서버 리소스 낭비 방지 및 트래픽 최적화
- 작업 완료 시 303 See Other 응답을 통해 상태 확인 URL과 실제 결과 리소스 URL을 분리하여 관심사 분리 달성
- 상태 확인 로직의 Idempotency 보장 및 단순 Key Lookup 방식으로 조회 비용 최소화 설계
실천 포인트
- 202 Accepted 응답 시 반드시 Location 헤더에 상태 확인 URL을 포함할 것 - Retry-After 헤더를 통해 클라이언트가 서버에 가하는 부하를 능동적으로 제어할 것 - 상태 확인 API는 연산 로직을 배제하고 단순 조회만 수행하도록 설계할 것 - 오래된 작업 기록의 TTL을 설정하여 저장 공간 낭비를 방지하고 410 Gone 응답을 처리할 것 - 클라이언트 환경이 콜백 수신 가능 시 Polling 대신 Webhook 도입을 검토할 것