Azure API Management でレート制限を実装するには

レート制限を使用すると、ユーザーまたはサービスが特定の期間に実行できる API 呼び出しの数を制限できます。 レート制限は、公平な使用を確保し、単一のユーザーまたはサービスが API リソースを独占するのを防ぐのに役立ちます。 Azure API Management には、API のレート制限を実装するための便利な方法が用意されています。

Azure API Management を使用する理由

Azure API Management は、組織が外部、パートナー、および内部の開発者に API を発行するのに役立つ、強力で汎用性の高いクラウド サービスです。 API 呼び出しをセキュリティで保護、管理、スケーリングするためのツールが用意されています。 その機能の 1 つはレート制限の制御です。これは、API の正常性と信頼性を維持するのに役立ちます。

Azure API Management でレート制限を構成する

Azure API Management では、ポリシーを使用してレート制限が適用されます。 これらのポリシーは、グローバル、製品、または API 固有のさまざまなスコープで定義できます。 この柔軟性により、API の要件と使用パターンに応じてレート制限を調整できます。

レート制限の実装を開始する前に、レート制限を決定します。 設定する制限は、API の容量と予想されるトラフィックによって異なります。 一般的な制限は、1 秒あたりの呼び出し数、分数、または時間数として設定されます。 たとえば、ユーザーごとに 1 分あたり 1,000 回の呼び出しを許可できます。

Azure API Management で API のレート制限を定義するには、 rate-limit または rate-limit-by-key ポリシーを使用します。 rate-limit ポリシーは、すべてのユーザーに制限を設定します。 rate-limit-by-key ポリシーでは、識別されたキー (サブスクリプションやユーザー ID など) ごとの制限が許可されます。

呼び出しを 1 分あたり 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 を返します。 これを無視するクライアントは再試行を繰り返し、調整された状態のままになります。

Dev Proxy は 、クライアント アプリが実際の API URL を呼び出し続けている間、同じ制限、時間枠、応答ヘッダーを使用して、構成したレート制限動作をシミュレートします。 RateLimitingPlugin を使用する際は、rateLimit および resetTimeWindowSeconds をポリシーの calls および renewal-period に、costPerRequest を 1 に (デフォルトは 2 で、これにより上限が半分になります)、headerLimit および headerRemaining をポリシーのヘッダー名に設定してください。 その前に RetryAfterPlugin を追加すると、クライアントが早すぎるタイミングで再度呼び出した際に、開発プロキシが通知します。 詳細については、「 レート制限 API 応答のシミュレート」を参照してください。 Dev Proxy をインストールするには、「Dev Proxy のセットアップ」を参照してください。

• レート制限への対処方法：クライアントアプリのベスト プラクティス

次のステップ