次の方法で共有


API Management のバックエンド

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

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

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

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

バックエンドの利点

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 アーキテクチャは分散型性質を持つため、サーキット ブレーカーのトリップ ルールはおおよそのものです。 ゲートウェイの異なるインスタンスは同期せず、同じインスタンスの情報に基づいてサーキット ブレーカー ルールを適用します。

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

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

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

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'myAPIM/myBackend'
  properties: {
    url: 'https://mybackend.com'
    protocol: 'https'
    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-1backend-2 という名前が付けられています。 両方のバックエンドが最も優先度の高いグループに含まれています。グループ内では、backend-1 の方が backend-2 よりも重みが大きくなります。

負荷分散プールを持つバックエンド リソース用の 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
        }
      ]
    }
  }
}

制限事項

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