속도 제한 및 탄력적인 오류 관리

이득:

• 속도 제한(RPM/ITPM/OTPM) 및 429 오류 해석 가능
• 지수 백오프 구현 및 재시도 후 재시도
• 일반적인 HTTP 오류 코드(400/401/429/500/529)를 올바르게 분류하고 처리합니다.

프로덕션 환경에서는 항상 완벽하게 응답하는 API가 없습니다. 요청을 너무 빨리 보내 한계에 도달하는 경우도 있습니다. 때로는 서버가 일시적으로 바쁜 경우도 있습니다. 때로는 귀하의 요청이 처음부터 잘못된 경우가 있습니다. 견고한 통합과 아마추어 시도의 차이점은 이러한 상황을 예측하고 자동으로 처리한다는 것입니다. 이 단원에서는 속도 제한(RPM/ITPM/OTPM), 429 오류, 지수 백오프를 사용한 재시도 및 일반적인 HTTP 오류 코드의 적절한 분류에 대해 알아봅니다. 목표: 사용자가 전혀 알아차리지 못할 정도로 강력한 흐름을 구축하는 것입니다.

속도 제한이란 무엇입니까?

공급자는 특정 기간 동안 스위치가 수행할 수 있는 작업량을 제한합니다. 이 보호는; 갑작스러운 비용 폭발로부터 인프라와 사용자 모두를 보호합니다. 한도에는 세 가지 일반적인 유형이 있습니다.

• RPM(분당 요청): 분당 요청 수입니다.
• ITPM(Input Tokens Per Minute): 분당 처리할 수 있는 입력 토큰입니다.
• OTPM(Output Tokens Per Minute): 분당 생산할 수 있는 출력 토큰.

이러한 한도를 초과하면 공급자는 요청을 거부하고 429 오류 코드를 반환합니다. 한도는 일반적으로 계정 수준(등급)에 따라 다르며 시간이 지나면서 늘어날 수 있습니다.

팁: 응답 헤더에서 한도에 접근하는 시기를 확인할 수 있습니다. 대부분의 공급자는 x-ratelimit-remaining-*과 같은 헤더를 사용하여 남은 할당량을 보고합니다. 이러한 값을 모니터링하고 전방 트래픽을 제한하는 것은 429를 받지 않고 문제를 예방하는 가장 성숙한 방법입니다.

429 및 지수 되돌림

429(속도 제한)는 일시적이며 재시도 가능한 오류입니다. 올바른 응답은 요청을 잠시 기다렸다가 다시 시도하는 것입니다. 그러나 계속해서 기다리는 것만으로는 충분하지 않습니다. 모두가 동시에 다시 시도하면 다시 한도에 도달하게 됩니다. 해결책은 지수 백오프입니다. 즉, 시도가 실패할 때마다 대기 시간을 기하급수적으로 늘리는 것입니다.

# 지수 백오프 논리 시도 1 → 429 → 1초 대기 시도 2 ​​→ 429 → 2초 대기 시도 3 → 429 → 4초 대기 시도 4 → 429 → 8초 대기(+ 작은 무작위 "지터")... 최대 N 시도 후 포기하고 보고

여기에 약간의 임의성(지터)을 추가하면 동시에 재시도할 때 요청이 충돌하는 것을 방지할 수 있습니다. 또한 429 응답에는 '재시도 후' 헤더가 포함되는 경우가 많습니다. '이 초 후에 다시 시도하세요'. 이 칭호를 존중하는 것이 맹목적으로 기다리는 것보다 더 정확합니다.

주의: 429가 표시되면 "추가 요청을 보내 강제로" 상황을 더욱 악화시킬 수 있습니다. 한도는 계속 채워지며 요청이 처리되지 않습니다. 올바른 대응은 가속이 아니라 후퇴입니다. 좋은 소식: 대부분의 공식 SDK는 백오프를 통해 자동으로 429 및 서버 오류를 다시 시도합니다. SDK를 수동으로 설치하기 전에 이 SDK 동작을 사용하세요.

HTTP 오류 코드 분류

모든 실수가 같은 것은 아닙니다. 중요한 구별: 재시도할 수 있습니까, 아니면 요청/신원 문제입니까?

코드

의미

다시 시도할 수 있나요?

정답

400

잘못된 요청(형식/매개변수 오류)

아니

요청을 수정하세요. 같은 내용을 다시 보내지 마세요

401

인증 오류(키가 잘못되었거나 누락됨)

아니

키/제목 수정

403

승인 없음(모델/기능에 액세스할 수 없음)

아니

권한/범위 확인

404

찾을 수 없음(잘못된 모델 ID/엔드포인트)

아니

올바른 모델 ID/주소

429

속도 제한을 초과했습니다.

예

후퇴 + 재시도 후

500

서버 오류

예

퇴각해서 다시 시도해보세요

529

서버 과부하

예

퇴각해서 다시 시도해보세요

황금률: 429, 500, 529는 일시적입니다. 철수로 다시 시도됩니다. 400, 401, 403, 404는 요청/신원 문제입니다. 다시 시도해도 문제가 해결되지 않으며 노력만 낭비됩니다. 코드에서는 이 두 그룹을 구별해야 합니다.

단계별: 지속적인 통화

1. 요청을 제출하십시오. 성공하면 계속하세요.
2. 오류 코드를 분류합니다. 다시 시도할 수 있나요?
3. 시도 가능한 경우: 재시도 후 지수 백오프 + 지터를 적용하고 제한된 횟수(예: 최대 5회)를 시도합니다.
4. 시도하지 않은 경우: (형식/키)를 수정하고 중지합니다. 루프에서 동일한 잘못된 요청을 반복하지 마십시오.
5. 포기하는 것을 고려해보세요. n번 시도 후에도 여전히 실패하면 사용자에게 정중한 메시지를 표시하고 이벤트를 기록합니다(추적 장치 11).

# 강력한 호출 의사 코드화 = 0repeat: response = request_at() if response.success: return response if response.code in [429, 500, 529] and try < 5: wait = retry_after ?? (2^시도 초 + 지터) sleep(wait); += 1을 시도해 보세요. response.code가 [400, 401, 403, 404]에 있는 경우 다시 git: save_error(response); return "요청을 수정해야 합니다" return "영구 오류입니다. 나중에 시도하세요"

# 사용자에게 정중한 피드백(재시도가 소진된 경우) "지금은 바빠서 요청을 처리할 수 없습니다. 잠시 후 다시 시도하거나 요청을 저장해 두었습니다. 준비가 되면 연락드리겠습니다."

약한 프롬프트 / 강한 프롬프트(여기서는 오류 메시지 디자인)

# WEAK(사용자에게 원시 오류 표시)"오류 429: rate_limit_error"

# STRONG (사용자 친화적, 안심, 조치 제안) "시스템에 일시적인 정체가 발생했습니다. 귀하의 요청이 안전하게 접수되었으며 자동으로 다시 시도되고 있습니다. 몇 초 내에 결과가 나타나지 않으면 페이지를 새로 고칠 수 있습니다."

최종 사용자에게 원시 기술 오류를 공개하면 신뢰가 약화되고 보안 취약점이 될 수 있습니다. 내부적으로 오류를 분류하고 사용자에게 차분하고 행동 중심적인 메시지를 제공합니다. 기록에 대한 기술적 세부 사항만 작성하면 됩니다.

미니 케이스 3개

사례 1 - 교통 폭발로 인해 보트가 추락했습니다. 캠페인 당일 고객 서비스 봇은 429건의 트래픽 급증을 받았습니다. 코드에는 재시도가 없었고 모든 오류는 사용자에게 "오류"로 직접 반영되었습니다. 지수 재추적 + 재시도 기능을 추가했습니다. 동일한 트래픽으로 요청이 몇 초 지연되어 전달되었지만 사용자에게는 오류가 표시되지 않았습니다.

사례 2 — 루프에서 400을 시도합니다. 잘못된 모델 ID로 인해 통합에서 404가 발생했지만 모든 오류를 "일시적"으로 처리하고 무한 루프에서 다시 시도했습니다. 통나무가 부풀어 오르고 불필요한 부하가 발생했습니다. 그들은 오류 분류를 추가했습니다: 404는 영구적인 것으로 간주되며 루프가 중지되고 모델 ID가 수정됩니다. 교훈: 모든 실수를 다시 시도하지 마세요.

사례 3 — 전면에서 한도를 관리합니다. 데이터 보강 작업이 429 한도에서 지속적으로 실행되었습니다. 그들은 x-ratelimit-remaining 헤더를 따르고 할당량에 따라 트래픽을 조절했습니다. 그래서 그들은 429를 전혀 사용하지 않고 한계 바로 아래에서 꾸준한 속도를 유지했습니다. 작업이 더욱 예측 가능하고 빠르게 완료되었습니다.

일반적인 실수

• 429의 속도 증가: 상황을 더욱 악화시킵니다. 후퇴로 전환하십시오.
• 각 오류 재시도: 400/401/404는 영구적입니다. 다시 시도하는 것은 낭비입니다.
• 고정 대기 사용: 충돌을 생성합니다. 지수 + 지터를 사용합니다.
• '재시도 후' 무시: 공급자가 지정한 시간을 준수하는 것이 가장 정확합니다.
• 사용자에게 원시 오류 공개: 신뢰가 흔들리고 취약점이 생성됩니다. 내부로 분류하세요.
• 무제한 재시도: 상한을 설정합니다(예: 5회 재시도). 그러면 우아하게 포기하세요.

심층: 큐잉, 동시성 및 회로 차단기

하나의 욕망을 견디는 것이 첫 번째 단계입니다. 진정한 성숙은 한계에 도달하지 않고 수많은 요청을 관리하는 것입니다. 여기서는 세 가지 개념이 작용합니다.

대기열: 요청을 즉시 전송하지 않고 제어된 속도로 전송하기 위해 대기열에 넣습니다. 큐는 갑작스러운 트래픽 급증을 완화합니다. 1,000개의 요청이 한 번에 도착하더라도 큐는 한도 이하의 속도로 해당 요청을 해제합니다. 이렇게 하면 429를 방지할 수 있으므로 문제 해결에 대해 걱정할 필요가 없습니다.

동시성 제한: 동시에 "전송"되는 요청 수를 제한합니다. 무제한 병렬 요청은 RPM 및 TPM 제한을 빠르게 채웁니다. 합리적인 동시성 한도(예: 동시 요청 10개 이하)는 제한을 유지하고 시스템을 예측 가능하게 만듭니다.

회로 차단기: 공급자가 모든 요청을 끈질기게 시도하는 대신 계속해서 500/529를 반환하는 경우 잠시 동안 "회로를 중단"하고 요청을 보내지 않고 신속하게 실패합니다. 기다린 후 회로를 다시 켜고 시도해 보세요. 이 패턴은 임시 공급자 오류가 발생하는 경우 시스템이 충돌하는 것을 방지합니다.

이 세 가지 기능을 함께 사용하면 단일 호출의 재시도 논리를 넘어서는 시스템 수준 복원력을 구축할 수 있습니다. 소규모에서는 SDK의 자동 재시도만으로 충분합니다. 규모가 커짐에 따라 큐잉, 동시성 및 회로 차단기는 필수 불가결해졌습니다. 그들은 모두 동일한 공통 목표를 가지고 있습니다. 일시적인 문제를 충돌이 아닌 몇 초의 보이지 않는 지연으로 사용자에게 반영하는 것입니다.

요약하면

속도 제한(RPM/ITPM/OTPM)을 초과하면 429가 반환됩니다. 이는 일시적인 오류이며 재시도 후 지수 백오프 + 지터를 사용하여 재시도됩니다. 500 및 529도 잠정적입니다. 400/401/403/404는 요청/신원 문제이므로 다시 시도해도 해결할 수 없습니다. 강력한 흐름은 오류를 이 두 그룹으로 분리하고, 제한된 횟수만큼 시도하며, 한계를 정면에서 모니터링하고 사용자에게 차분한 메시지를 보여줍니다.

응용과제

통합을 고려해보세요. (1) 발생할 수 있는 오류 코드를 나열하고 "재시도 가능/영구"로 구분합니다. (2) 지수 풀백 계획(초기 보유, 계수, 한도, 지터)을 기록합니다. (3) retry-after 헤더의 사용 방법을 지정합니다. (4) 재시도 횟수가 소진되었을 때 사용자에게 표시할 정중한 메시지를 작성합니다.

체크리스트

• [ ] RPM/ITPM/OTPM 제한과 429에 대해 설명할 수 있습니다.
• [ ] 지수적 후퇴 + 지터 + 재시도 논리를 적용할 수 있습니다.
• [ ] 오류 코드를 재시도 가능/영구적으로 분류할 수 있습니다.
• [ ] 나는 우리가 모든 실수를 시도해서는 안 된다는 것을 알고 있습니다.
• [ ] 원시적인 오류 대신 사용자에게 차분하고 행동 지향적인 메시지를 보여줄 수 있습니다.