도달한 제한 식별
HTTP 429는 요청 과다를 뜻하며 Retry-After를 포함할 수 있습니다. 계산 방식과 범위는 서비스마다 다릅니다. 평균이 낮아도 짧은 시간창의 한도를 넘을 수 있습니다.
| 개념 | 제한 대상 | 유용한 대응 |
|---|---|---|
| 할당량 | 기간 내 총량 | 공유 예산 계획. |
| 속도 | 짧은 시간창의 도착량 | 시작 시점 분산. |
| 동시 실행 | 진행 중인 작업 | 동시 작업 제한. |
| Retry-After: 120 | 120초 대기 | 전체 기한과 재시도 안전성 확인. |
허용된 수요 계획
- 집계 기준이 계정, 프로젝트, 사용자, 경로 중 무엇인지 확인하세요. 초기화 시간대, 작업별 비용, 공유 예산도 검토하세요.
- 유한 대기열로 폭주를 평탄화하고 진행 중인 작업은 별도 제한하세요. 취소를 전달하고 불필요해진 작업을 버리세요.
- Retry-After를 HTTP 날짜 또는 초 단위 대기로 해석하세요. 전체 시간 예산 내에서 지키고, 없을 때도 대기 상한을 정하세요.
보호를 우회하지 않고 재시도 평가
429는 작업을 안전하게 반복할 수 있다는 증거가 아닙니다. 멱등성, 총시간, 시도 수를 확인하세요. 거부와 대기열 길이를 측정하고 지속 수요가 계약을 넘으면 필요를 줄이거나 용량을 협의하세요.
1차 자료
요청 제한 남용을 관찰 가능하게 만듭니다.
요청 제한은 정상적인 사용과 비정상적인 행동을 구분하고 해석 가능한 이벤트를 생성할 때 더 효과적입니다. 오류 코드만으로는 남용 패턴의 시작, 지속 기간 및 도달 범위를 숨길 수 있습니다.
- 임계값, 결정, 경로 및 최소한의 컨텍스트를 비밀 정보 없이 기록합니다.
- 반복적인 거부와 정상적인 사용자에게 미치는 영향을 연관시킵니다.
- 경고가 조사 또는 비례적인 조정으로 이어지는지 테스트합니다.
1차 자료: ACSC and partners — Event logging and threat detection. 관련 방법: 실무 가이드 읽기.