API Management のバックエンド

[アーティクル]
12/03/2024

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

API Management の "バックエンド" (つまり "API バックエンド") は、フロントエンド API とその操作を実装する HTTP サービスです。

特定の API をインポートすると、API Management によって API バックエンドが自動的に構成されます。たとえば、以下をインポートするときに、API Management によってバックエンド Web サービスが構成されます。

OpenAPI の仕様。
SOAP API。
Azure リソース (HTTP によってトリガーされる Azure 関数アプリやロジックアプリなど)。

API Management が API バックエンドとしての使用をサポートする Azure リソースは他にもあります。その例を次に示します。

Service Fabric クラスター。
カスタムサービス。

バックエンドの利点

API Management ではバックエンドエンティティがサポートされているため、API のバックエンドサービスを管理できます。バックエンドエンティティは、バックエンドサービスに関する情報をカプセル化し、API 間での再利用性を促進し、ガバナンスを強化します。

次の 1 つ以上のバックエンドを使用します。

バックエンドサービスへの要求の資格情報を承認する
ヘッダーまたはクエリパラメーターの認証用に名前付きの値が構成されている場合に、API Management の機能を利用して Azure Key Vault でシークレットを維持できます。
サーキットブレーカールールを定義し、バックエンドを過剰な要求から保護します。
複数のバックエンドへのルート要求または負荷分散要求

バックエンドエンティティの構成と管理は、Azure portal で、または Azure API やツールを使用して行います。

set-backend-service ポリシーを使用してバックエンドを参照する

バックエンドを作成すると、お使いの API でバックエンドを参照できるようになります。 set-backend-service ポリシーを使って、受信 API 要求をバックエンドに転送します。 API 用にバックエンド Web サービスを既に構成している場合は、set-backend-service ポリシーを使って、バックエンドエンティティに要求をリダイレクトできます。次に例を示します。

<policies>
    <inbound>
        <base />
        <set-backend-service backend-id="myBackend" />
    </inbound>
    [...]
<policies/>

set-backend-service ポリシーで条件付きロジックを使用して、場所、呼び出されたゲートウェイ、またはその他の式に基づいて有効なバックエンドを変更できます。

たとえば、呼び出されたゲートウェイに基づいて別のバックエンドにトラフィックをルーティングするポリシーを次に示します。

<policies>
    <inbound>
        <base />
        <choose>
            <when condition="@(context.Deployment.Gateway.Id == "factory-gateway")">
                <set-backend-service backend-id="backend-on-prem" />
            </when>
            <when condition="@(context.Deployment.Gateway.IsManaged == false)">
                <set-backend-service backend-id="self-hosted-backend" />
            </when>
            <otherwise />
        </choose>
    </inbound>
    [...]
<policies/>

サーキットブレーカー

API Management ではバックエンドリソースのサーキットブレーカープロパティが公開されており、多すぎる要求でバックエンドサービスが過負荷になるのを防ぐことができます。

サーキットブレーカープロパティを使って、サーキットブレーカーをトリップするルールを定義します。たとえば、定義した期間中の障害状態の数や割合、障害を示す状態コードの範囲などです。
サーキットブレーカーがトリップすると、API Management により、定義された期間バックエンドサービスへの要求の送信が停止され、クライアントに 503 サービス利用不可応答が返されます。
構成されたトリップ期間が経過すると、サーキットはリセットされ、バックエンドに対してトラフィックが再開されます。

バックエンドのサーキットブレーカーは、バックエンドが過負荷状態から復旧できるようにするためのサーキットブレーカーパターンの実装です。これにより、API Management ゲートウェイとバックエンドサービスを保護するために実装できる一般的なレート制限ポリシーとコンカレンシー制限ポリシーが強化されます。

Note

現時点では、バックエンドサーキットブレーカーは API Management の従量課金レベルではサポートされていません。
API Management アーキテクチャは分散型性質を持つため、サーキットブレーカーのトリップルールはおおよそのものです。ゲートウェイの異なるインスタンスは同期せず、同じインスタンスの情報に基づいてサーキットブレーカールールを適用します。
現在、バックエンドサーキットブレーカーに構成できるルールは 1 つだけです。

例

API Management REST API または Bicep または ARM テンプレートを使って、バックエンドでサーキットブレーカーを構成します。次の例では、1 時間にサーバーエラーを示す 5xx 状態コードが 3 つ以上ある場合に API Management インスタンス myAPIM の myBackend でサーキットブレーカーがトリップします。

サーキットブレーカーは 1 時間後にリセットされます。応答に Retry-After ヘッダーが存在する場合、サーキットブレーカーは値を受け入れ、指定された時間待機してからバックエンドに要求を再度送信します。

Bicep
ARM

サーキットブレーカーを持つバックエンドリソース用の Bicep テンプレートに次のようなスニペットを含めます。

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'myAPIM/myBackend'
  properties: {
    url: 'https://mybackend.com'
    protocol: 'http'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: [
              'Server errors'
            ]
            interval: 'PT1H' 
            statusCodeRanges: [
              {
                min: 500
                max: 599
              }
            ]
          }
          name: 'myBreakerRule'
          tripDuration: 'PT1H'  
          acceptRetryAfter: true
        }
      ]
    }
   }
 }

サーキットブレーカーを持つバックエンドリソース用の ARM テンプレートに次のような JSON スニペットを含めます。

{
  "type": "Microsoft.ApiManagement/service/backends",
  "apiVersion": "2023-09-01-preview",
  "name": "myAPIM/myBackend",
  "properties": {
    "url": "https://mybackend.com",
    "protocol": "http",
    "circuitBreaker": {
      "rules": [
        {
          "failureCondition": {
            "count": "3",
            "errorReasons": [ "Server errors" ],
            "interval": "PT1H",
            "statusCodeRanges": [
              {
                "min": "500",
                "max": "599"
              }
            ]
          },
          "name": "myBreakerRule",
          "tripDuration": "PT1H",
          "acceptRetryAfter": true
        }
      ]
    }
  }
}

負荷分散プール

API やそれらのバックエンド全体の負荷分散要求に複数のバックエンドを実装する場合、API Management ではバックエンド "プール" がサポートされます。

バックエンドプールは、次のような場合に使用します。

個々のバックエンドのサーキットブレーカーを持つことができる複数のバックエンドに負荷を分散させます。
アップグレードのために、あるバックエンドのセットから別のバックエンドに負荷をシフトします (ブルーグリーンデプロイ)。

バックエンドプールを作成するには、バックエンドの type プロパティを pool に設定し、プールを構成するバックエンドの一覧を指定します。

Note

現時点では、バックエンドプールには単一のバックエンドしか含めることができません。型 pool のバックエンドを別のバックエンドプールに追加することはできません。プールには最大 30 個のバックエンドを含めることができます。
API Management アーキテクチャは分散型の性質を持つため、バックエンドの負荷分散はおおよそのものです。ゲートウェイの異なるインスタンスは同期せず、同じインスタンスの情報に基づいて負荷分散を適用します。

負荷分散のオプション

API Management では、バックエンドプールに対して次の負荷分散オプションがサポートされています。

ラウンドロビン: 既定では、要求はプール内のバックエンド全体で均等に分散されます。
重み付け: 重みはプール内のバックエンドに割り当てられ、要求は各バックエンドに割り当てられた相対的な重みに基づいてバックエンド全体に分散されます。このオプションは、ブルーグリーンデプロイの実行などのシナリオに使用します。
優先度ベース: バックエンドは優先度グループに編成され、要求は優先度グループの順にバックエンドに送信されます。優先度グループ内では、要求はバックエンド全体で均等に、または各バックエンドに割り当てられた相対的な重みに従って (割り当てられている場合) 分散されます。

Note

サーキットブレーカールールがトリップされているため、優先度の高いグループ内のすべてのバックエンドが使用できない場合にのみ、優先度の低いグループのバックエンドが使用されます。

例

API Management REST API、あるいは Bicep または ARM テンプレートを使って、バックエンドプールを構成します。次の例では、API Management インスタンス myAPIM のバックエンド myBackendPool がバックエンドプールで構成されています。プール内のバックエンドの例は、backend-1 と backend-2 という名前が付けられています。両方のバックエンドが最も優先度の高いグループに含まれています。グループ内では、backend-1 の方が backend-2 よりも重みが大きくなります。

Bicep
ARM

負荷分散プールを持つバックエンドリソース用の Bicep テンプレートに次のようなスニペットを含めます。

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    pool: {
      services: [
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-1'
          priority: 1
          weight: 3
        }
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-2'
          priority: 1
          weight: 1
        }
      ]
    }
  }
}

負荷分散プールを持つバックエンドリソース用の ARM テンプレートに次のような JSON スニペットを含めます。

{
  "type": "Microsoft.ApiManagement/service/backends",
  "apiVersion": "2023-09-01-preview",
  "name": "myAPIM/myBackendPool",
  "properties": {
    "description": "Load balancer for multiple backends",
    "type": "Pool",
    "pool": {
      "services": [
        {
          "id": "/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-1",
          "priority": "1", 
          "weight": "3" 
        },
        {
          "id": "/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-2",
          "priority": "1",
          "weight": "1"    
        }
      ]
    }
  }
}

制限事項

Developer レベルと Premium レベルの場合、ゲートウェイのエンドポイントの URL とバックエンドの URL が同じであるときに、内部仮想ネットワークにデプロイされた API Management インスタンスから HTTP 500 BackendConnectionFailure エラーがスローされることがあります。この制限に遭遇した場合は、テクニカルコミュニティブログの内部仮想ネットワークモードにおける自己連鎖 API Management 要求の制限に関する記事の手順に従ってください。
現在、バックエンドサーキットブレーカーに構成できるルールは 1 つだけです。

ブログ: Azure OpenAI Service での Azure API Management のサーキットブレーカーと負荷分散の使用
Azure portal を使用して Service Fabric バックエンドを設定します。

次の方法で共有

API Management のバックエンド

バックエンドの利点

set-backend-service ポリシーを使用してバックエンドを参照する

サーキットブレーカー

例

負荷分散プール

負荷分散のオプション

例

制限事項

フィードバック

その他のリソース

次の方法で共有

API Management のバックエンド

バックエンドの利点

set-backend-service ポリシーを使用してバックエンドを参照する

サーキット ブレーカー

例

負荷分散プール

負荷分散のオプション

例

制限事項

関連するコンテンツ

フィードバック

その他のリソース

サーキットブレーカー