サービス検出の回復性 (プレビュー)
Azure Container Apps の回復性を使用すると、単純な回復性ポリシーを使用して、サービス要求のエラーを予防的に防止、検出、復旧できます。 この記事では、Azure Container Apps サービス検出を使用して要求を開始する場合に、Azure Container Apps の回復性ポリシーを構成する方法について説明します。
Note
現時点では、Dapr サービス呼び出し API を使用して行われた要求に回復性ポリシーを適用することはできません。
ポリシーは、コンテナー アプリへの要求ごとに有効です。 要求を受け入れるコンテナー アプリに合わせて、次のような構成でポリシーを調整できます。
- 再試行回数
- 再試行とタイムアウト期間
- 一致の再試行
- サーキット ブレーカーの連続したエラーなど
次のスクリーンショットは、アプリケーションで再試行ポリシーを使用して、失敗した要求からの復旧を試みる方法を示しています。
サポートされている回復性ポリシー
回復性ポリシーを構成する
Bicep、CLI、または Azure portal のいずれを使用して回復性ポリシーを構成する場合も、コンテナー アプリごとに適用できるポリシーは 1 つだけです。
コンテナー アプリにポリシーを適用すると、そのコンテナー アプリから行われた要求 "ではなく"、そのコンテナー アプリに対して行われたすべての要求にルールが適用されます。 たとえば、再試行ポリシーは、App B という名前のコンテナー アプリに適用されます。 App B に対して行われたすべての受信要求は、失敗時に自動的に再試行されます。 ただし、App B によって送信された送信要求は、失敗した場合に再試行される保証はありません。
次の回復性の例では、使用可能なすべての構成を示しています。
resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-11-02-preview' = {
name: 'my-app-resiliency-policies'
parent: '${appName}'
properties: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
connectionTimeoutInSeconds: 5
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
httpStatusCodes: [
502
503
]
errors: [
'retriable-status-codes'
'5xx'
'reset'
'connect-failure'
'retriable-4xx'
]
}
}
tcpRetryPolicy: {
maxConnectAttempts: 3
}
circuitBreakerPolicy: {
consecutiveErrors: 5
intervalInSeconds: 10
maxEjectionPercent: 50
}
tcpConnectionPool: {
maxConnections: 100
}
httpConnectionPool: {
http1MaxPendingRequests: 1024
http2MaxRequests: 1024
}
}
}
ポリシーの仕様
Timeouts
タイムアウトは、実行時間の長い操作を早期終了するために使用されます。 タイムアウト ポリシーには、次のプロパティが含まれています。
properties: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
connectionTimeoutInSeconds: 5
}
}
| Metadata | 必須 | 説明 | 例 |
|---|---|---|---|
responseTimeoutInSeconds |
はい | コンテナー アプリからの応答の待機のタイムアウト。 | 15 |
connectionTimeoutInSeconds |
はい | コンテナー アプリへの接続の確立のタイムアウト。 | 5 |
[再試行の回数]
失敗した操作の tcpRetryPolicy または httpRetryPolicy の戦略を定義します。 再試行ポリシーには、次の構成が含まれています。
httpRetryPolicy
properties: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
httpStatusCodes: [
502
503
]
errors: [
'retriable-headers'
'retriable-status-codes'
]
}
}
}
| Metadata | 必須 | 説明 | 例 |
|---|---|---|---|
maxRetries |
はい | 失敗した http 要求に対して実行される再試行の最大回数。 | 5 |
retryBackOff |
はい | 要求を監視し、タイムアウトと再試行の条件が満たされたときに、影響を受けるサービスへのすべてのトラフィックを遮断します。 | 該当なし |
retryBackOff.initialDelayInMilliseconds |
はい | 最初のエラーから最初の再試行までの遅延。 | 1000 |
retryBackOff.maxIntervalInMilliseconds |
はい | 再試行間の最大遅延。 | 10000 |
matches |
はい | アプリが再試行を試みる場面を制限するように一致値を設定します。 | headers、httpStatusCodes、errors |
matches.headers |
Y* | エラー応答に特定のヘッダーが含まれている場合に再試行します。 *ヘッダーは、retriable-headers エラー プロパティを指定した場合にのみ必要なプロパティです。 使用可能なヘッダー一致の詳細について確認してください。 |
X-Content-Type |
matches.httpStatusCodes |
Y* | 応答で特定の状態コードが返された場合に再試行します。 *ステータス コードは、retriable-status-codes エラー プロパティを指定した場合にのみ必要なプロパティです。 |
502、503 |
matches.errors |
はい | アプリが特定のエラーを返す場合にのみ再試行します。 使用可能なエラーの詳細を確認してください。 | connect-failure、reset |
ヘッダー一致
retriable-headers エラーを指定した場合は、次のヘッダー一致プロパティを使用すると、応答に特定のヘッダーが含まれている場合に再試行できます。
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
}
| Metadata | 説明 |
|---|---|
prefixMatch |
再試行は、ヘッダー値のプレフィックスに基づいて実行されます。 |
exactMatch |
再試行は、ヘッダー値の完全一致に基づいて実行されます。 |
suffixMatch |
再試行は、ヘッダー値のサフィックスに基づいて実行されます。 |
regexMatch |
再試行は、正規表現ルールに基づいて実行されます。正規表現ルールでは、ヘッダー値が正規表現パターンと一致する必要があります。 |
エラー
次のいずれかのエラーに対して再試行を実行できます。
matches: {
errors: [
'retriable-headers'
'retriable-status-codes'
'5xx'
'reset'
'connect-failure'
'retriable-4xx'
]
}
| Metadata | 説明 |
|---|---|
retriable-headers |
再試行をトリガーする HTTP 応答ヘッダー。 いずれかのヘッダー一致が応答ヘッダーと一致する場合、再試行が実行されます。 ヘッダーが一致したときに再試行する場合は必須です。 |
retriable-status-codes |
再試行をトリガーする必要がある HTTP 状態コード。 状態コードが一致したときに再試行する場合は必須です。 |
5xx |
サーバーが 5xx 応答コードで応答した場合に再試行します。 |
reset |
サーバーが応答しない場合に再試行します。 |
connect-failure |
コンテナー アプリとの接続に問題があるために要求が失敗した場合に再試行します。 |
retriable-4xx |
コンテナー アプリが 400 シリーズの応答コード (409 など) で応答した場合に再試行します。 |
tcpRetryPolicy
properties: {
tcpRetryPolicy: {
maxConnectAttempts: 3
}
}
| Metadata | 必須 | 説明 | 例 |
|---|---|---|---|
maxConnectAttempts |
はい | 接続が失敗したときに再試行する最大接続試行回数 (maxConnectionAttempts) を設定します。 |
3 |
サーキット ブレーカー
サーキット ブレーカー ポリシーでは、連続するエラーの数などのトリガーに基づいて、コンテナー アプリ レプリカを負荷分散プールから一時的に削除するかどうかを指定します。
properties: {
circuitBreakerPolicy: {
consecutiveErrors: 5
intervalInSeconds: 10
maxEjectionPercent: 50
}
}
| Metadata | 必須 | 説明 | 例 |
|---|---|---|---|
consecutiveErrors |
はい | コンテナー アプリ レプリカが負荷分散から一時的に削除されるまでの連続するエラー数。 | 5 |
intervalInSeconds |
はい | レプリカが負荷分散プールから削除または復元されたかどうかを判断するための指定された時間。 | 10 |
maxEjectionPercent |
はい | 負荷分散から除外される失敗したコンテナー アプリ レプリカの最大の割合。 この値に関係なく、少なくとも 1 つのホストが削除されます。 | 50 |
接続プール
Azure Container App の接続プールでは、コンテナー アプリに対して確立された再利用可能な接続のプールが維持されます。 この接続プールにより、要求ごとに個々の接続を作成および破棄するオーバーヘッドが軽減されます。
接続プールを使用すると、サービスに許可される要求または接続の最大数を指定できます。 これらの制限により、各サービスのコンカレント接続の合計数が制御されます。 この制限に達すると、既存の接続が解放されるか、閉じられるまで、そのサービスへの新しい接続は確立されません。 接続を管理するこのプロセスにより、リソースが要求によって過負荷になるのを防ぎ、効率的な接続管理を維持します。
httpConnectionPool
properties: {
httpConnectionPool: {
http1MaxPendingRequests: 1024
http2MaxRequests: 1024
}
}
| Metadata | 必須 | 説明 | 例 |
|---|---|---|---|
http1MaxPendingRequests |
はい | http1 要求に使用されます。 コンテナー アプリに対して開いている接続の最大数。 |
1024 |
http2MaxRequests |
はい | http2 要求に使用されます。 コンテナー アプリに対する同時要求の最大数。 |
1024 |
tcpConnectionPool
properties: {
tcpConnectionPool: {
maxConnections: 100
}
}
| Metadata | 必須 | 説明 | 例 |
|---|---|---|---|
maxConnections |
はい | コンテナー アプリへのコンカレント接続の最大数。 | 100 |
回復性の可観測性
コンテナー アプリのメトリックとシステム ログを使用すると、回復性の監視を実行できます。
回復性ログ
コンテナー アプリの [監視] セクションで、[ログ] を選択します。
[ログ] ペインで、コンテナー アプリのシステム ログを使用して回復性を見つけるためのクエリを記述して実行します。 たとえば、次のようなクエリを実行して回復性イベントを検索し、以下の情報を表示します。
- タイム スタンプ
- 環境名
- コンテナー アプリ名
- 回復性の種類と理由
- ログ メッセージ
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s
[実行] をクリックしてクエリを実行し、結果を表示します。
回復性メトリック
コンテナー アプリの [監視] メニューで、[メトリック] を選択します。 [メトリック] ペインで、次のフィルターを選択します。
- コンテナー アプリの名前のスコープ。
- [標準メトリック] メトリック名前空間。
- ドロップダウン メニューの回復性メトリック。
- 結果でデータを集計する方法 (平均、最大値など)。
- 期間 (過去 30 分、過去 24 時間など)。
たとえば、テスト アプリのスコープで [回復性要求の再試行] メトリックを設定し、30 分以内の検索を [平均] で集計した場合、結果は次のようになります。
関連するコンテンツ
Azure Container Apps の Dapr コンポーネントに対する回復性のしくみについて確認します。