HTTP 429 Too Many Requests: 의미와 해결 방법

이 오류의 의미와 확인 방법

• 브라우저, API 클라이언트, 모니터링 도구 또는 checker가 429 Too Many Requests를 수신합니다.
• 응답은 사이트 전체가 아니라 하나의 URL, API route, HTTP 메서드, IP 주소, 계정 또는 클라이언트에만 영향을 줄 수 있습니다.
• 일정 시간이 지나면 요청이 다시 작동할 수 있으며, 이는 일시적인 rate limit과 일치합니다.
• 응답에 Retry-After 또는 기타 rate limit 관련 헤더가 포함될 수 있습니다.
• 요청이 HTTP를 처리하는 endpoint에 도달했기 때문에 DNS가 확인되고 TLS가 성공할 수 있습니다. 그러나 이러한 확인 결과만으로 애플리케이션 계층에서 요청이 허용되었다고 볼 수는 없습니다.
• 제한 범위가 IP, identity, token 또는 session으로 설정된 경우 클라이언트나 네트워크에 따라 결과가 다를 수 있습니다.

가능성이 높은 순서의 주요 원인

1. 요청 속도 제한을 초과했습니다. 애플리케이션, API gateway 또는 웹 서버가 IP 주소, 계정, session, API key, route 또는 다른 클라이언트 identity를 기준으로 요청을 제한할 수 있습니다.
2. 프록시, CDN 또는 WAF가 자체 정책을 적용했습니다. 중간 계층은 요청이 origin server에 도달하기 전에 429를 반환할 수 있습니다.
3. 자동화된 트래픽이 너무 빠르게 요청을 전송합니다. Crawler, 모니터링 검사, script, 재시도 또는 병렬 worker는 개별 요청이 유효해 보여도 제한을 트리거할 수 있습니다.
4. 클라이언트가 backoff 없이 재시도합니다. 오류 후 반복적으로 재시도하면 클라이언트가 제한 window 안에 계속 머물거나 부하가 커질 수 있습니다.
5. 설정 또는 배포로 유효 임계값이 변경되었습니다. 최근 rule, routing 변경, authentication integration 또는 proxy 정책으로 인해 집계되거나 제한되는 요청이 달라졌을 수 있습니다.
6. 제한은 의도적이지만 클라이언트 workflow가 이에 맞지 않습니다. 예를 들어 batch process에는 즉시 재시도를 반복하는 대신 요청 속도 조절, connection reuse 또는 승인된 request quota가 필요할 수 있습니다.

해결 방법

방문자 및 API 사용자

1. 조사하는 동안 빠른 새로고침, 병렬 요청 및 자동 재시도를 중단하세요.
2. 응답 헤더에서 Retry-After를 확인하세요. 값이 있으면 지정된 지연 시간 또는 시점까지 기다린 후 다시 시도하세요.
3. 지연 시간 후 동일한 메서드로 정확히 같은 URL 또는 API endpoint를 다시 시도하세요. 제한을 피하려고 메서드를 바꾸거나 요청을 반복적으로 변형하지 마세요.
4. 클라이언트를 제어할 수 있다면 exponential backoff와 jitter를 적용한 횟수 제한 재시기를 사용하고, 서비스에 문서화된 request quota를 준수하세요. API가 재시도 동작을 정의하지 않은 경우 반복해도 안전하지 않은 요청은 재시도하지 마세요.
5. 문제가 하나의 클라이언트, 계정, API key, 네트워크 또는 endpoint에 영향을 주는지 확인하세요. 다른 클라이언트에서 결과가 다르다는 사실만으로 원인을 판단할 수는 없습니다.
6. 429가 계속되면 endpoint, 메서드, 타임스탬프, 응답 헤더 및 요청 빈도 설명을 포함해 사이트 또는 API 운영자에게 문의하세요. 공유하는 자료에서는 cookie, authorization 값 및 API secret을 삭제하세요.

사이트 운영자 및 개발자

1. 영향을 받은 메서드, URL, 클라이언트 identity 및 요청 빈도와 일치하는, 권한이 부여된 가장 작은 테스트로 응답을 재현하세요. 상태, 타임스탬프 및 관련 응답 헤더를 기록하세요.
2. 응답을 생성한 계층을 확인하세요. 아키텍처에 맞는 순서로 CDN 또는 WAF 응답 세부 정보, reverse-proxy 로그, 웹 서버 로그 및 애플리케이션 로그를 확인하세요. origin이 응답을 생성했다고 가정하지 마세요.
3. 관련 로그에서 동일한 타임스탬프, route, 클라이언트 식별자 및 rate-limit 결정을 검색하세요. 무엇을 집계했는지, 어떤 limit window 또는 정책이 적용되었는지 확인하세요.
4. 영향을 받은 요청을 정상 요청과 비교하세요. HTTP 메서드, authentication context, source identity, route, caching path 및 최근 배포 또는 설정 변경을 확인하세요.
5. 제한이 의도된 것이라면 클라이언트 안내를 개선하세요. 적절한 경우 정확한 Retry-After 값을 반환하고, quota를 문서화하며, 클라이언트가 짧은 재시도 loop 대신 제어된 backoff를 사용할 수 있도록 하세요.
6. 제한이 잘못 적용되었다면 응답을 생성한 계층에서 권한이 부여된 범위 내의 가장 좁은 수정만 적용하세요. 관련 없는 보안 또는 abuse 방어 기능을 약화하지 않고 영향을 받은 route에 대한 효과를 검증하세요.
7. 동일한 요청과 속도로 다시 테스트한 다음 대표적인 인접 route와 클라이언트 identity를 테스트하세요. 의도한 제한이 여전히 작동하고 합법적인 트래픽이 더 이상 차단되지 않는지 확인하세요.

예방 및 해결 확인 방법

• API 및 자동화된 클라이언트를 위한 request quota, 제한 범위 및 재시도 동작을 정의하고 문서화하세요.
• 적절하고 서비스 설계에서 지원되는 경우 Retry-After를 포함해 유용한 rate-limit 정보를 반환하세요.
• 클라이언트에서 즉시 반복 재시도 대신 jitter를 적용한 횟수 제한 exponential backoff를 구현하세요.
• route, 클라이언트 identity, 네트워크 및 배포별 429 비율을 모니터링하여 광범위한 증가와 개별적인 abuse 또는 오작동하는 클라이언트를 구분하세요.
• CDN, WAF, proxy, server 및 application의 rate-limit 설정을 version control로 관리하고 릴리스 전에 변경 사항을 검토하세요.
• 배포 후 중요한 API 메서드와 public route를 테스트하고, 임계값에 도달했을 때의 예상 동작도 확인하세요.
• 429 응답을 생성한 컴포넌트와 연결할 수 있도록 정제된 요청 및 정책 결정 로그를 충분히 보존하세요.

자주 묻는 질문