次の方法で共有


サービス検出の回復性 (プレビュー)

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 はい アプリが再試行を試みる場面を制限するように一致値を設定します。 headershttpStatusCodeserrors
matches.headers Y* エラー応答に特定のヘッダーが含まれている場合に再試行します。 *ヘッダーは、retriable-headers エラー プロパティを指定した場合にのみ必要なプロパティです。 使用可能なヘッダー一致の詳細について確認してください。 X-Content-Type
matches.httpStatusCodes Y* 応答で特定の状態コードが返された場合に再試行します。 *ステータス コードは、retriable-status-codes エラー プロパティを指定した場合にのみ必要なプロパティです。 502503
matches.errors はい アプリが特定のエラーを返す場合にのみ再試行します。 使用可能なエラーの詳細を確認してください。 connect-failurereset
ヘッダー一致

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 コンポーネントに対する回復性のしくみについて確認します。