このエントリは2024/01/27現在の情報に基づいています。将来の機能追加や変更に伴い、記載内容からの乖離が発生する可能性があります。

このエントリは以下の続き。

バックエンドに対するサーキットブレーカー機能追加に関するドキュメント記述はこちら。Consumption SKUでは使えない点に注意。

サーキット ブレーカー (プレビュー) / Circuit breaker (preview)
https://learn.microsoft.com/azure/api-management/backends#circuit-breaker-preview

設定にあたっては、バックエンドプールの構成と同様、現時点ではBicep、ARM、もしくはREST APIのみ利用でき、バージョンは2023-05-01-preview以後を使う必要がある（CLIやPowerShellにはコマンドがなく、Portalにも固有の設定ページはない）。

Backend
https://learn.microsoft.com/rest/api/apimanagement/backend?view=rest-apimanagement-2023-05-01-preview
Microsoft.ApiManagement service/backends 2023-05-01-preview
https://learn.microsoft.com/azure/templates/microsoft.apimanagement/2023-05-01-preview/service/backends

設定例

バックエンドプールの場合と同様、以下のようなバックエンドサービスがプールとして構成されているものとする。

• <URL1>/api/test
• <URL2>/api/test

APIフロントエンドは以下のように設定しておく。

<APIMのURL>/suffix/foo

この場合、バックエンドの呼び出しURLは、Inboundセクションで変更しない限り以下のようになる。

<URL1 or URL2>/api/test/foo

プールの要素となるバックエンドで、サーキットブレーカーを構成する（説明のため、test1を代表例とし、properties.credentialsなどは省略）。以下のJSONをREST APIに投げ込んでバックエンドを作成する。properties.circuitBreaker.rules.failureCondition.intervalとproperties.circuitBreaker.rules.tripDurationはISO8601 duration specificationに従って記述する。以下の例の場合、interval (エラーがカウントされる間隔) は5分、tripDuration (回線がトリップする期間) は10分。

{
  "type": "Microsoft.ApiManagement/service/backends",
  "apiVersion": "2023-05-01-preview",
  "name": "test1",
  "properties": {
    "description": "backend (test1)",
    "type": "Single",
    "protocol": "http",
    "url": "<URL1>/api/test",
    "circuitBreaker": {
      "rules": [
        {
          "failureCondition": {
            "count": "3",
            "errorReasons": [
              "Server errors"
            ],
            "interval": "PT5M",
            "statusCodeRanges": [
              {
                "min": "500",
                "max": "599"
              }
            ]
          },
          "name": "myBreakerRule",
          "tripDuration": "PT10M"
        }
      ]
    }
  }
}

test2についても同様に構成する。バックエンドプールについては設定変更しない。

テスト

今回、test2は常にHTTP 503 (Service Unavailable) を返すようにしてある。1秒ごとにAPIを呼び出し、動作をAPIMのトレース機能で確認してみる。

6回呼び出すと、サーキットブレーカーが落ちる (tripする) 条件に到達する。7回目以後そのまま呼び出しを継続すると、通常だとバックエンドプールのラウンドロビン負荷分散に従ってtest2にリクエストがルーティングされるところだが、サーキットブレーカーにより、test1にのみリクエストが送信される。10分後には正常に戻るので、またラウンドロビンで負荷分散する。

バックエンドのプールとretryポリシーを組み合わせると、以下のエントリで記載したようにフォールバックはL7 Load Balancerを使うのと同じくかなりシンプルにできる。サーキットブレーカー機能を使った場合、サーキットブレーカーが落ちたバックエンドは呼び出されないので、より一層バックエンドの呼び出しで失敗しなくなり、フォールバックにより例外をAPI呼び出し元に返しづらくなることがわかる。

• API Management
• Azure
• Technology