429: 단순한 오류가 아닌 복구 신호

추측 대신 헤더를 읽는 이유

세 가지 반사 동작에는 한 가지 숨은 전제가 깔려 있습니다. 클라이언트가 용량이 언제 풀릴지 알 수 없으니, 떠보거나, 고정 간격으로 기다리거나, 떠나야 한다는 것입니다. 그 전제를 받아들이기 전에 두 가지를 나란히 놓아 볼 만합니다. 첫째는 Microsoft Learn이 문서화하는 내용입니다. 100% 사용률에서 서비스는 곧바로 429를 반환하고, 언제 다시 시도할지에 대한 서비스 제공 대기값인 retry-after-ms를 함께 붙입니다. 둘째는 이 저장소의 원천 실행에서 실제로 관측된 retry-after-ms 값을 정제한 공개 집계로, 그 권고된 대기가 실제로 어떤 모습이었는지를 보여 주려고 서술용으로 포함합니다. 둘을 함께 놓으면 “언제 다시 시도해도 안전한가?”는 클라이언트 쪽 추측에서 서비스가 돌려주는 값으로 바뀝니다.

잠시 멈춰 볼 부분은 그 집계의 형태입니다. 권고된 대기는 중앙값에서는 짧았습니다 — 전체 p50 ≈ 43 ms — 그래서 헬스 체크 루프나 무작정 고정 간격으로 물러서는 방식은 대개 서비스가 실제로 요구한 것보다 훨씬 오래 기다리게 됩니다. 하지만 꼬리는 무시할 수 없었습니다. 일부 대기는 17,000 ms 가까이 늘어났습니다(전체 p99 ≈ 16,921 ms). 이 짧은 중앙값·긴 꼬리 형태가 운영에서 중요한 사실입니다 — 헤더는 고정된 리셋 시계가 아니라 수용 제어 신호로 다루어야 합니다. 곧바로 반환되는 429와 retry-after-ms 계약은 Microsoft Learn이 문서화하는 내용이고, 하나의 지연 예산 상한이 언제 기다림을 멈추고 우회할지를 결정해야 한다는 것은 이 저장소가 옹호하는 운영적 추론입니다. 아래 원천 차트가 그 분포를 명시적으로 보여 줍니다.

공식 사양 · 서비스가 알려주는 것

헤더가 공식 수용 신호입니다

Microsoft Learn은 PTU 고이용률 처리를 retry-after-ms 및 retry-after 응답 헤더를 동반하는 즉시 429 경로로 설명합니다. 같은 프로덕션 가이드는 이 대기 시간을 클라이언트 측 재시도에 사용하거나, 요청을 다른 서빙 대상으로 우회하는 데 사용할 수 있다고 설명합니다.

서비스 동작 · 대기가 일정하지 않은 이유

대기 시간: 고정 쿨다운이 아니라 수용 제어

Microsoft Learn은 PTU 이용률을 누수 버킷(leaky bucket) 알고리즘의 변형으로 설명합니다. 각 요청은 추정 컴퓨팅 비용 — 프롬프트 토큰 수에서 캐시된 토큰을 빼고 호출의 max_tokens를 더한 값 — 을 버킷에 더하며, 배포된 용량은 PTU 수에 비례해 계속 빠져나갑니다. 요청이 도착했을 때 이용률이 이미 100%라면, 서비스는 즉시 HTTP 429를 반환하고 다음 요청이 수락되기까지 얼마나 기다려야 하는지를 알려주는 retry-after-ms 및 retry-after 헤더를 붙입니다.

이 대기 시간은 그 순간 버킷이 빠져나가는 방식을 반영하므로 고정 쿨다운이 아닙니다. 따라서 같은 문서화된 계약은 하나가 아니라 두 가지 클라이언트 경로를 뒷받침합니다. 대기 시간이 호출자의 지연 예산에 맞으면 헤더를 존중하고, 그 예산을 넘는 대기는 우회 또는 실패 조건으로 다룹니다. 즉시 반환되는 429와 헤더 계약은 Microsoft Learn이 문서화합니다. 단일 예산 상한이 이 두 경로를 갈라야 한다는 것은 이 저장소가 옹호하는 운영적 추론입니다.

운영 패턴 · 재시도의 단일 소유권

재시도 루프 중첩 금지

안전한 패턴은 일부러 지루합니다. 429 복구를 책임질 컴포넌트를 정확히 하나만 고르세요. SDK가 재시도하도록 구성되어 있다면 SDK가 대기를 담당하게 하세요. 애플리케이션 라우터가 복구를 담당한다면 SDK 자동 재시도를 비활성화하고 라우터가 직접 retry-after-ms를 파싱하게 하세요.

폴백 · 네이티브 또는 커스텀

우회: 비상 버튼이 아니라 정책적 선택

Microsoft Learn의 스필오버 기능은 초과 트래픽을 표준 대상으로 우회할 수 있으며, 스필오버 동작을 식별하는 헤더를 노출합니다. 플랫폼이 지원하는 형태가 들어맞을 때는 이것이 운영 부담이 가장 적은 경로입니다. 그래도 애플리케이션이 PTU 대상이 429를 반환하기 전에 결정해야 하거나, 라우팅 정책이 테넌트, 리전, 지연 예산, 비즈니스 우선순위에 따라 달라질 때는 커스텀 라우터가 여전히 유용합니다.

출처와 근거 경계

Tier 1 — 서비스 계약(Microsoft Learn). 429 수용 동작, 두 재시도 헤더, 누수 버킷 이용률 모델, SDK의 기본 재시도가 여기에 문서화되어 있습니다.

• [1] 프로비저닝된 처리량 배포를 프로덕션에서 운영하기 — 이용률 100%에서의 즉시 429, retry-after-ms 및 retry-after 응답 헤더, 누수 버킷 이용률 모델, 그리고 OpenAI SDK의 기본 429 재시도(max_retries)를 정의합니다. 출처: Microsoft Learn 문서 (2026-06-04 접근) · 아카이브.
• [2] 프로비저닝된 배포의 스필오버로 트래픽 관리하기 — spilloverDeploymentName 속성과 x-ms-spillover-from-deployment 응답 헤더를 통해 비-200(429 포함) 초과분을 표준 배포로 우회하는 스필오버를 정의합니다. 출처: Microsoft Learn 문서 (2026-06-04 접근) · 아카이브.

Tier 2 — 운영적 추론(이 저장소). 경험칙 — 단일 재시도 소유자, 헤더 존중, 플릿의 동기화를 풀기 위한 지터 추가, 그리고 존중한 대기가 거듭 풀리지 않을 때에만 스필오버로 우회 — 은 Learn 사양이 아니라 운영적 판단입니다.

• [3] 이 저장소, docs/10-ptu-admission-controller.md — 헤더 기반 수용 제어기 노트: 단일 재시도 소유자, retry-after-ms 존중, 기본 지터, 그리고 대기가 상한을 넘으면 폴백. 출처.
• [4] 이 저장소, batch_runner/ptu/admission_controller.py — retry-after-ms를 파싱하고 retry-after로 폴백하며 이중 재시도 소유를 거부하는 참조 구현. 출처.

이 주제가 증명하는 것과 증명하지 못하는 것. 접근일 기준 Microsoft Learn이 명시하는 PTU 수용 규칙 — 이용률 100%에서의 즉시 429, retry-after-ms 및 retry-after 헤더, 스필오버 우회 경로 — 과, 이 저장소가 옹호하는 소수의 운영 경험칙 — 헤더 존중, 플릿의 동기화를 푸는 지터 추가, 존중한 대기가 거듭 풀리지 않을 때에만 스필오버 배포로 우회 — 을 문서화합니다. 모든 리전·모델 SKU·향후 API 버전에서 이 계약이 동일하게 유지된다는 것은 검증하지 못하며, 특정 배포를 부하 상태에서 측정하지도 않습니다.