Dapr コンポーネントのレジリエンス
回復性ポリシーは、コンテナー アプリの障害を予防的に防止し、検出し、回復します。 この記事では、Dapr を使用するアプリケーションに回復性ポリシーを適用して、状態ストア、pub/sub メッセージ ブローカー、シークレット ストアなど、さまざまなクラウド サービスと統合する方法について説明します。
Dapr コンポーネントを使用して、次の送信および受信操作の方向の再試行、タイムアウト、サーキット ブレーカーなどの回復性ポリシーを構成できます。
- 送信操作: 次のような Dapr サイドカーからコンポーネントへの呼び出し:
- 状態の永続化または取得
- メッセージの発行
- 出力バインドの呼び出し
- 受信操作: 次のような Dapr サイドカーからコンテナー アプリへの呼び出し:
- メッセージ配信時のサブスクリプション
- イベントを配信する入力バインド
次のスクリーンショットは、アプリケーションで再試行ポリシーを使用して、失敗した要求からの復旧を試みる方法を示しています。
サポートされている回復性ポリシー
回復性ポリシーを構成する
Bicep、CLI、または Azure portal を使用して回復性ポリシーを作成するかどうかを選択できます。
次の回復性の例では、使用可能なすべての構成を示しています。
resource myPolicyDoc 'Microsoft.App/managedEnvironments/daprComponents/resiliencyPolicies@2023-11-02-preview' = {
name: 'my-component-resiliency-policies'
parent: '${componentName}'
properties: {
outboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
inboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
}
重要
すべての回復性ポリシーを適用したら、Dapr アプリケーションを再起動する必要があります。
ポリシーの仕様
Timeouts
タイムアウトは、実行時間の長い操作を早期終了するために使用されます。 タイムアウト ポリシーには、次のプロパティが含まれています。
properties: {
outbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
inbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
}
| Metadata | 必須 | 説明 | 例 |
|---|---|---|---|
responseTimeoutInSeconds |
はい | Dapr コンポーネントからの応答を待機しているタイムアウト。 | 15 |
[再試行の回数]
失敗した操作に対する httpRetryPolicy の戦略を定義します。 再試行ポリシーには、次の構成が含まれています。
properties: {
outbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
inbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
}
| Metadata | 必須 | 説明 | 例 |
|---|---|---|---|
maxRetries |
はい | 失敗した http 要求に対して実行される再試行の最大回数。 | 5 |
retryBackOff |
はい | 要求を監視し、タイムアウトと再試行の条件が満たされたときに、影響を受けるサービスへのすべてのトラフィックを遮断します。 | 該当なし |
retryBackOff.initialDelayInMilliseconds |
はい | 最初のエラーから最初の再試行までの遅延。 | 1000 |
retryBackOff.maxIntervalInMilliseconds |
はい | 再試行間の最大遅延。 | 10000 |
サーキット ブレーカー
circuitBreakerPolicy を定義して、高い失敗率の原因になる要求を監視し、一定の基準を満たした場合に、影響を受けるサービスへのすべてのトラフィックを遮断します。
properties: {
outbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
},
inbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
| Metadata | 必須 | 説明 | 例 |
|---|---|---|---|
intervalInSeconds |
いいえ | サーキット ブレーカーが内部カウントをクリアするために使用される周期的な時間 (秒)。 指定しない場合は、timeoutInSeconds で指定したのと同じ値が間隔に設定されます。 |
15 |
consecutiveErrors |
はい | 回線がトリップしてオープンになるまでに許容される要求エラーの発生数。 | 10 |
timeoutInSeconds |
はい | 障害直後のオープン状態の時間 (秒)。 | 5 |
サーキット ブレーカー プロセス
consecutiveErrors (consecutiveFailures > $(consecutiveErrors)-1 としてのサーキット トリップ条件) を指定すると、回線がトリップしてハーフ オープンになるまでに許容されるエラーの数が設定されます。
回線は timeoutInSeconds の時間ハーフ オープンになり、その間 consecutiveErrors 件の要求が連続して成功する必要があります。
- 要求が成功すると、 回線がクローズになります。
- 要求が失敗した場合、回線はハーフ オープン状態のままです。
intervalInSeconds の値を設定しなかった場合、連続した要求の成否に関わらず、timeoutInSeconds に設定した時間が経過すると回路はクローズ状態にリセットされます。 intervalInSeconds を 0 に設定すると、回線が自動的にリセットされることはなく、consecutiveErrors の要求が連続して成功することによってのみ、ハーフ オープン状態からクローズ状態に移行します。
intervalInSeconds の値を設定した場合、ハーフ オープン状態で送信された要求が正常に行われたかどうかに関係なく、回線がクローズ状態にリセットされるまでの時間を決定します。
回復性ログ
コンテナー アプリの [監視] セクションで、[ログ] を選択します。
[ログ] ウィンドウで、コンテナー アプリのシステム ログを使用して回復性を見つけるためのクエリを記述して実行します。 たとえば、回復性ポリシーが読み込まれたかどうかを確認するには、次のようにします。
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Loading Resiliency configuration:"
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
[実行] をクリックしてクエリを実行し、ポリシーが読み込まれているかどうかを示すログ メッセージを含む結果を表示します。
または、コンポーネントでデバッグを有効にし、次の例のようなクエリを使用して、実際の回復性ポリシーを見つけることができます。
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Resiliency configuration ("
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
[実行] をクリックしてクエリを実行し、結果のログ メッセージとポリシー構成を表示します。
関連するコンテンツ
Azure Container Apps 組み込みのサービス検出を使用したサービス間通信の回復性のしくみを確認する