1707551059
2024-01-29 03:55:31
本書は、以下の日本語で出版されたオリジナル記事の要約版です。 現時点でのメモです 2024 年 1 月 27 日。
Azure API Managementのバックエンドプール – Logico Inside (logico-jp.io)
Azure API Managementのバックエンドでサーキットブレーカーを構成する – Logico Inside (logico-jp.io)
最近、サーキット ブレーカーと負荷分散プール機能が API Management バックエンドに追加されました。 どちらも 2024 年 1 月 27 日の時点でパブリック プレビュー段階にあります。
Azure API Management バックエンド | Microsoft Learn
パブリック プレビューでは、Bicep、ARM、または REST API のいずれかを使用する必要があります (2023-05-01-preview 以降)、サーキット ブレーカーと負荷分散プールを構成します。 CLI または PowerShell のコマンドはなく、Azure Portal には専用の構成ページもありません。
バックエンド – REST API (Azure API 管理) | Microsoft Learn
Microsoft.ApiManagement/service/backends 2023-05-01-preview – Bicep、ARM テンプレート、Terraform AzAPI …
負荷分散されたプール
以前は、バックエンドにはバックエンド サービスのエンドポイントを 1 つだけ含めることができました。 トラフィックを複数のバックエンド サービスに分散する必要がある場合は、バックエンド サービスの前に L4/L7 ロード バランサーをプロビジョニングして展開する必要があります。 負荷分散されたプールを使用すると、マネージド/アンマネージド ロード バランサーを使用せずに、リクエスト トラフィックを複数のバックエンド サービスに分散できます。 この機能は他の API ゲートウェイ製品にすでに含まれていますが、ついに Azure API Management にも導入されました。
制限
2024 年 1 月 27 日以降、いくつかの制限があります。
- ラウンドロビンは唯一の負荷分散オプションです。 (他の負荷分散方法が GA に実装されることを期待しています。)
- ドキュメントで説明されているように、内部仮想ネットワークにデプロイされた Developer SKU と Premium SKU を含む API Management インスタンスは HTTP 500 をスローする場合があります。
BackendConnectionFailureゲートウェイ エンドポイント URL とバックエンド URL が同じ場合にエラーが発生します。 詳細は以下のURLをご参照ください。
Azure API Management バックエンド | Microsoft Learn - ネストされた負荷分散プールはサポートされていません。
サーキットブレーカー
もう 1 つの機能であるサーキット ブレーカーは、アプリケーションが失敗する可能性のある操作の実行を繰り返し試行することを防ぐための一般的なパターンです。 以前はバックエンド サービスにサーキット ブレーカーを独自に実装する必要がありましたが、この機能を実装する必要はありません。
サーキット ブレーカー パターン – Azure アーキテクチャ センター | Microsoft Learn
制限
2024 年 1 月 27 日の時点で、いくつかの制限が見つかりました。
- バックエンド サーキット ブレーカーは、API Management Consumption SKU ではサポートされていません。
- サーキットブレーカーの「半開」状態はサポートされていません。
詳細については、ドキュメント内の「注意」を参照してください。
Azure API Management バックエンド | Microsoft Learn
構成
準備
以下のエンドポイントがバックエンドに使用されます。
/api/test /api/test
API フロントエンドの場合、次の構成を使用します。
この場合、ルーティング エンドポイントに変更が加えられない限り、リクエストは通常、次の URL にルーティングされます。 inbound セクション。
サーキットブレーカー
バックエンドのサーキット ブレーカーを構成するには、次の JSON を REST API 経由で公開します。 言うまでもなく、ARM と Bicep を使用してサーキット ブレーカーを構成できます。
{
"type": "Microsoft.ApiManagement/service/backends",
"apiVersion": "2023-05-01-preview",
"name": "test1",
"properties": {
"description": "backend (test1)",
"type": "Single",
"protocol": "http",
"url": "/api/test",
"circuitBreaker": {
"rules": [
{
"failureCondition": {
"count": "3",
"errorReasons": [
"Server errors"
],
"interval": "PT5M",
"statusCodeRanges": [
{
"min": "500",
"max": "599"
}
]
},
"name": "myBreakerRule",
"tripDuration": "PT10M"
}
]
}
}
}
に関して properties.circuitBreaker.rules.failureCondition.interval そして properties.circuitBreaker.rules.tripDuration、どちらも ISO8601 の期間仕様に従う必要があります。 上記の例の場合、 interval (エラー数を収集する期間) は 5 分であり、 tripDuration (サーキットブレーカーが落ちている時間)は10分です。
同じ設定を行う必要があります test2。
負荷分散されたプール
最後のセクションで構成した 2 つのバックエンドを使用して、負荷分散プールを構成します。 それでも、 properties.url は必須の場合、指定された URL は無意味です。 この場合は指定しても大丈夫です http://localhost に properties.url。 また、次の点にも注意してください Pool で指定する必要があります properties.type、 の代わりに Single。 次に、次の JSON が REST API 経由で投稿されます。 前のセクションで述べたように、ARM と Bicep も使用できます。
{
"type": "Microsoft.ApiManagement/service/backends",
"apiVersion": "2023-05-01-preview",
"name": "backendPool",
"properties": {
"description": "Load balanced backends",
"type": "Pool",
"protocol": "http",
"url": "http://localhost",
"pool": {
"services": [
{
"id": "/backends/test1"
},
{
"id": "/backends/test2"
}
]
}
}
}
それでおしまい。 さあ、テストの時間です。
試してみよう。
この例では、バックエンド test2 常にHTTPを返します 503 (サービスは利用できません)。 APIM リクエスト トレース機能を使用して動作を観察するために、5 秒ごとに API を呼び出しました。
チュートリアル – 要求トレースを使用して Azure API Management で API をデバッグする | Microsoft Learn
6 回の API 呼び出しの後、サーキット ブレーカーが作動します。 test2 HTTPを返します 503 (サービス利用不可) エラーが 3 回発生しました。
7 回目または 8 回目の呼び出しで、API リクエストは通常バックエンドにルーティングされます。 test2 負荷分散されたプール内にありますが、APIM がバックエンドのサーキット ブレーカーを検出したため、リクエストはバックエンド test1 にのみルーティングされます。 test2 つまずいている。 10 分後、サーキットブレーカーの作動が停止し、通常の状態に戻ります。 負荷分散されたプールは、プール内のバックエンドの 1 つに API リクエストを分散します。
これらの機能を活用してみてはいかがでしょうか retry ポリシー?
負荷分散されたプールとサーキット ブレーカーを使用すると、 retry の政策 backend セクションでは、より洗練された方法で API リクエストのルーティングを構成できます。 次のエントリでも書きましたが、L7 ロードバランサでの設定と同様に、より簡単にフォールバックを設定できます。
Azure API Management ポリシーを使用して、再試行を構成し、HTTP に基づいて別のインスタンスにフォールバックします。
バックエンドに導入された両方の機能を使用すると、 retry これは、Azure OpenAI サービス インスタンスの 1 つに要求を分散するためのもので、負荷分散されたプールを使用し、それをバックエンド サービスとして指定するためのものです。 以下はポリシーの設定例です。
@("Bearer " + (string)context.Variables["msi-access-token"])
このポリシー構成は、以下に示す要件を満たしています。
結論
以前のバックエンドには負荷分散機能やサーキット ブレーカー機能がありませんでしたが、現在は両方とも Azure API Management に追加されています。 どちらもすぐに GA に到達し、より洗練された方法で API リクエストをバックエンドにルーティングできるようになることを期待しています。
#Azure #API #Management #を利用して #API #トラフィックを複数のバックエンド #サービスに分散します