속도 제한을 사용하면 사용자 또는 서비스가 특정 기간에 수행할 수 있는 API 호출 수를 제한할 수 있습니다. 속도 제한을 사용하면 공정한 사용을 보장하고 단일 사용자 또는 서비스가 API 리소스를 독점하지 못하도록 방지할 수 있습니다. Azure API Management는 API에 대한 속도 제한을 구현하는 편리한 방법을 제공합니다.
Azure API Management를 사용하는 이유
Azure API Management 는 조직이 외부, 파트너 및 내부 개발자에게 API를 게시하는 데 도움이 되는 강력하고 다양한 클라우드 서비스입니다. API 호출을 보안, 관리 및 크기 조정하기 위한 도구를 제공합니다. 해당 기능 중 하나는 API의 상태 및 안정성을 유지하는 데 유용한 속도 제한을 제어하는 것입니다.
Azure API Management에서 속도 제한 구성
Azure API Management는 정책을 사용하여 속도 제한을 적용합니다. 전역, 제품 또는 API별 다양한 범위에서 이러한 정책을 정의할 수 있습니다. 이러한 유연성을 통해 API의 요구 사항 및 사용 패턴에 따라 속도 제한을 조정할 수 있습니다.
속도 제한을 구현하기 전에 속도 제한을 결정합니다. 설정한 제한은 API의 용량 및 예상 트래픽에 따라 달라집니다. 일반적인 제한은 초당 호출 수, 분 또는 시간 단위로 설정됩니다. 예를 들어 사용자당 분당 1,000건의 호출을 허용할 수 있습니다.
Azure API Management에서 API에 대한 속도 제한을 정의하려면 rate-limit 또는 rate-limit-by-key 정책 중 하나를 사용합니다. 정책은 rate-limit 모든 사용자에 대한 제한을 설정합니다. 이 rate-limit-by-key 정책은 식별된 키당 제한(예: 구독 또는 사용자 ID)을 허용합니다.
다음은 호출을 분당 1,000으로 제한하는 정책의 예입니다.
<policies>
<inbound>
<base />
<rate-limit calls="1000" renewal-period="60" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
지정된 호출 수를 초과하면 Azure API Management는 429 Too Many Requests 상태 코드와 retry-after 응답 헤더 및 다시 시도할 수 있는 시기를 나타내는 메시지를 함께 보냅니다.
HTTP/1.1 429 Too Many Requests
content-type: application/json
retry-after: 60
{
"statusCode": 429,
"message": "Rate limit is exceeded. Try again in 60 seconds."
}
응답 헤더에 속도 제한 정보 노출
기본적으로 Azure API Management는 응답 헤더에 속도 제한 정보를 노출하지 않습니다. 속도 제한을 전달하지 않으면 앱이 제한을 초과하고 제한을 받지 않도록 하는 것이 어려워집니다. 속도 제한 정보를 노출하려면 rate-limit 정책을 remaining-calls-header-name 및 total-calls-header-name 속성으로 확장하십시오.
<policies>
<inbound>
<base />
<rate-limit calls="1000" renewal-period="60" remaining-calls-header-name="ratelimit-remaining" total-calls-header-name="ratelimit-limit" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
지금 API를 호출하면 각 응답에 ratelimit-remaining와 ratelimit-limit 헤더가 포함됩니다. 헤더는 API가 제한을 초과하기 전에 처리할 수 있는 호출 수를 더 많이 전달합니다.
요약
Azure API Management에서 속도 제한을 구현하면 강력하고 확장 가능한 API를 만들 수 있습니다. 속도 제한을 사용하여 API가 사용자에게 안정적이고 효율적으로 제공하는지 확인할 수 있습니다. 핵심은 적절한 균형을 찾는 것입니다. 속도 제한이 너무 엄격한 경우 유용성을 저해할 수 있습니다. 속도 제한이 너무 관대하면 API를 압도할 위험이 있습니다. 신중한 계획 및 지속적인 모니터링을 통해 이 균형을 달성하고 정상 API 환경을 유지할 수 있습니다.
클라이언트 테스트
API에 속도 제한을 구현한 후 API를 호출하는 앱이 이를 처리하는지 확인합니다. 클라이언트가 rate-limit 또는 rate-limit-by-key에 의해 설정된 제한을 초과하면 API Management는 429 Too Many Requests 헤더와 함께 Retry-After를 반환합니다. 이를 무시하는 클라이언트는 계속 다시 시도하고 계속 제한된 상태로 남습니다.
| Approach | 찾은 내용 | 당신이 놓친 것 |
|---|---|---|
| 프로덕션을 기다리세요 | 실제 클라이언트 행동 | 사용자가 한도에 도달할 때까지 손상된 모든 클라이언트 |
| 클라이언트 테스트에서의 모의 API 관리 | 클라이언트의 재시도 분기 실행 여부 | 실제 한도, 헤더, 재설정 타이밍, 그리고 클라이언트의 실제 HTTP 스택 |
| API Management 인스턴스를 제한될 때까지 호출하세요 | 실제 동작 | 테스트 인스턴스가 필요하며 호출을 소모하지 않고는 필요할 때 한도에 도달할 수 없습니다. |
| 클라이언트의 트래픽을 가로채고 사용자의 제한을 시뮬레이션합니다. | 실제 API URL의 제한, 윈도우 및 헤더, 그리고 클라이언트가 Retry-After에 명시된 시간만큼 대기하는지 여부 |
클라이언트 코드만 단독으로입니다. 그것에 대해서는 단위 테스트를 유지하세요. |
Dev Proxy는 클라이언트 앱이 실제 API URL을 계속 호출하는 동안 동일한 제한, 기간 및 응답 헤더를 사용하여 구성한 속도 제한 동작을 시뮬레이션합니다.
rateLimit 및 resetTimeWindowSeconds를 정책의 calls 및 costPerRequest로 설정하고, renewal-period를 1로 설정하며(기본값은 2이며, 이 값은 한도를 절반으로 줄입니다), headerLimit 및 headerRemaining를 정책의 헤더 이름으로 설정한 상태에서 RateLimitingPlugin를 사용합니다. 클라이언트가 너무 일찍 다시 호출할 때 개발자 프록시가 알려주도록 그 앞에 RetryAfterPlugin를 추가합니다. 자세한 내용은 API 응답의 속도 제한 시뮬레이션을 참조하세요. Dev Proxy를 설치하려면 Dev Proxy 설정을 참조하세요.
- 속도 제한을 처리하는 방법: 클라이언트 앱에 대한 모범 사례
다음 단계
GitHub에서 Microsoft와 공동 작업
이 콘텐츠의 원본은 GitHub에서 찾을 수 있으며, 여기서 문제와 끌어오기 요청을 만들고 검토할 수도 있습니다. 자세한 내용은 참여자 가이드를 참조하세요.
Dev Proxy