Azure API Management を使用した高度な要求調整

2025-06-08

適用対象: すべての API Management レベル

受信要求を調整する機能は、Azure API Management の重要な役割です。 API Management を使用すると、API プロバイダーは要求のレートまたは転送される要求/データの合計を制御することで、API プロバイダーが API を不正使用から保護し、さまざまな API 製品レベルの価値を作成できます。この記事では、クォータとレート制限を作成して適用する方法について説明します。

転送率の制限とクォータ

転送率の制限とクォータは、さまざまな目的で使用されます。

レート制限

レート制限は、通常、短いボリュームバーストや激しいボリュームバーストから保護するために使用されます。たとえば、呼び出しボリュームが多いときにバックエンドサービスのデータベースにボトルネックがあることがわかっている場合は、 rate-limit-by-key ポリシーを設定して、高い呼び出しボリュームを禁止できます。

注意事項

調整アーキテクチャの分散特性により、レート制限が完全に正確になることはありません。許可される要求の構成数と実際の数の違いは、要求のボリュームとレート、バックエンドの待機時間、およびその他の要因によって異なります。

Quotas (クォータ)

クォータは通常、より長い期間にわたって通話レートを制御するために使用されます。たとえば、特定の 1 か月内に特定のサブスクライバーによって実行可能な呼び出しの合計数を設定できます。 API を収益化する場合は、階層ベースのサブスクリプションに対してクォータを異なる方法で設定することもできます。たとえば、Basic レベルのサブスクリプションでは 1 か月あたり 10,000 回以下の通話を行うことができますが、Premium レベルでは毎月 100,000,000 件の通話を行うことができます。

API Management では、通常、レート制限は、スパイクから保護するためにノード間で高速に伝達されます。これに対し、使用量クォータ情報は長期的に使用されるため、その実装は異なります。

注

基になるコンピューティングリソースがサービスプラットフォームで再起動されると、クォータに達した後、API Management が要求を短時間処理し続ける可能性があります。

製品ベースの調整

API プロバイダーは、特定のサブスクリプションをスコープとするレート調整機能を使用して、API を使用するためにサインアップした開発者に制限を適用できます。ただし、この種の調整は、たとえば、API の個々のエンドユーザーを調整する場合には役立ちません。開発者のアプリケーションの 1 人のユーザーがクォータ全体を消費し、開発者の他のユーザーがアプリケーションを使用できないようにすることができます。また、大量の要求を生成する複数の顧客は、不定期のユーザーへのアクセスを制限する可能性があります。

カスタムキーベースの調整

注

rate-limit-by-keyポリシーとquota-by-key ポリシーは、Azure API Management の従量課金レベルでは使用できません。

キーごとのレート制限ポリシーとキーごとのクォータポリシーは、トラフィック制御に対するより柔軟なソリューションを提供します。これらのポリシーを使用すると、トラフィックの使用状況を追跡するために使用されるキーを識別する式を定義できます。この手法を次の例に示します。

IP アドレス制限

次のポリシーでは、1 つのクライアント IP アドレスを 1 分あたり 10 回の呼び出しのみに制限し、1 か月あたり合計 1,000,000 呼び出しと 10,000 KB の帯域幅を適用します。

<rate-limit-by-key  calls="10"
          renewal-period="60"
          counter-key="@(context.Request.IpAddress)" />

<quota-by-key calls="1000000"
          bandwidth="10000"
          renewal-period="2629800"
          counter-key="@(context.Request.IpAddress)" />

インターネット上のすべてのクライアントが一意の IP アドレスを使用している場合、これはユーザーによる使用を制限する効果的な方法である可能性があります。ただし、NAT デバイス経由でインターネットにアクセスするため、複数のユーザーが 1 つのパブリック IP アドレスを共有している可能性があります。ただし、認証されていないアクセスを許可する API の場合は、 IpAddress を使用するのが最適なオプションである可能性があります。

ユーザー ID の調整

エンドユーザーが認証されている場合は、ユーザーを一意に識別する情報に基づいて調整キーを生成できます。

<rate-limit-by-key calls="10"
    renewal-period="60"
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />

この例では、Authorization ヘッダーを抽出し、 JWT オブジェクトに変換し、トークンのサブジェクトを使用してユーザーを識別する方法を示します。次に、その値をレート制限キーとして使用します。ユーザー ID が他の要求の 1 つとして JWT に格納されている場合は、代わりにその値を使用できます。

ポリシーの組み合わせ

ユーザーベースの調整ポリシーは、サブスクリプションベースの調整ポリシーよりも制御性が高くなりますが、両方の機能を組み合わせることに価値があります。収益化された API の場合、製品サブスクリプションキーによる調整 (サブスクリプションごとの呼び出しレートの制限とサブスクリプション別の使用量クォータの設定) は、使用レベルに基づく料金を実装するための優れた方法です。ユーザーごとに調整できるきめ細かい制御は補完的であり、あるユーザーの行為によって別のユーザーのエクスペリエンスの機能が低下するのを防ぎます。

クライアント主導の調整

ポリシー式を使用して調整キーが定義されている場合、API プロバイダーは調整の範囲を選択します。ただし、開発者は、自分の顧客をレート制限する方法を制御したい場合があります。 API プロバイダーは、開発者のクライアントアプリケーションが API にキーを通信できるようにカスタムヘッダーを導入することで、この種類のコントロールを有効にすることができます。

<rate-limit-by-key calls="100"
          renewal-period="60"
          counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>

この手法により、開発者のクライアントアプリケーションはレート制限キーを作成する方法を決定できます。クライアント開発者は、ユーザーにキーのセットを割り当て、キーの使用状況をローテーションすることで、独自のレートレベルを作成できます。

複数のリージョンまたはゲートウェイに関する考慮事項

rate-limit、rate-limit-by-key、azure-openai-token-limit、llm-token-limitなどのレート制限ポリシーでは、API Management ゲートウェイのレベルでカウンターを使用します。そのため、API Management の複数リージョンデプロイでは、各リージョンゲートウェイに個別のカウンターがあり、リージョンごとにレート制限が個別に適用されます。同様に、ワークスペースを含む API Management インスタンスでは、ワークスペースゲートウェイごとに制限が個別に適用されます。

quotaやquota-by-keyなどのクォータポリシーはグローバルです。つまり、API Management インスタンスのレベルで 1 つのカウンターが使用されます。

概要

API Management では、API サービスを保護して価値を追加するためのレートとクォータの調整が提供されます。カスタムスコープルールを持つ調整ポリシーでは、これらのポリシーをより細かく制御して、顧客がより優れたアプリケーションを構築できるようにします。この記事の例では、クライアント IP アドレス、ユーザー ID、クライアント生成値を使用してレート制限キーを作成することで、これらのポリシーを使用する方法を示します。ただし、ユーザーエージェント、URL パスフラグメント、メッセージサイズなど、メッセージの他の多くの部分を使用できます。

レート制限とクォータポリシー