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 バージョン 2023-03-01 プレビュー以降、API Management ではバックエンド リソースのサーキット ブレーカー プロパティが公開されており、多すぎる要求でバックエンド サービスが過負荷になるのを防ぐことができます。

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

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

Note

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

例

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

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

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

負荷分散プール (プレビュー)

API バージョン 2023-05-01 プレビュー以降では、API やそれらのバックエンド全体の負荷分散要求に複数のバックエンドを実装する場合に、API Management はバックエンド プールをサポートしています。 現時点では、バックエンド プールはラウンドロビン負荷分散をサポートしています。

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

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

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

Note

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

例

API Management REST API、あるいは Bicep または ARM テンプレートを使って、バックエンド プールを構成します。 次の例では、API Management インスタンス myAPIM のバックエンド myBackendPool がバックエンド プールで構成されています。 プール内のバックエンドの例は、backend-1 と backend-2 という名前が付けられています。

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

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-05-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    protocol: 'http'
    url: 'https://example.com'
    pool: {
      services: [
        {
          id: '/backends/backend-1'
        }
        {
          id: '/backends/backend-2'
        }
      ]
    }
  }
}

制限事項

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

関連するコンテンツ