Functions アプリで回復可能な障害がサービス停止に変わる経緯はこうです：依存関係がタイムアウトし始め、すべての Functions インスタンスが即座に無限にリトライし、依存関係は数百の同時失敗リクエストで叩かれ、一時的な問題として始まったものがシステム全体のバックプレッシャーイベントになります。
この話はご存知でしょう。Azure Functions は素早くスケールアウトします — それが目的です。しかし、「素早くスケールアウト」と「即座にリトライ」が合わさると、障害を劇的に悪化させる可能性があります。
2つのパターンが役立ちます。指数バックオフとサーキットブレーカー。両方が、Service Bus でトリガーされる Azure Functions でネイティブサポートされるようになりました。
2つのパターン、異なる役割
これらのパターンは補完的で、代替ではありません：
指数バックオフは答えます：いつリトライすればよいか？ 依存関係が回復する時間を確保するためにリトライ間の遅延を増加させます。メッセージレベルで、リトライタイミングを調整します。
サーキットブレーカーは答えます：今この依存関係を呼び出すべきか？ 障害のしきい値に達した後、不健全な依存関係への繰り返し呼び出しを停止し、クールダウン期間後に慎重に調査します。システムレベルで、リトライストームを防ぎます。
両方が必要です。バックオフはメッセージごとのリトライペーシングを処理します。サーキットブレーカーは集合的な健全性の決定を処理します。
Service Bus に特に重要な理由
キューはバーストトラフィックを吸収します、これは良いことです。しかし制御がなければ、ワーカーが失敗する呼び出しに計算リソースを無駄にし続ける間、キューが成長する可能性があります。ポイズンメッセージは、あるべき時間より長くアクティブのままです。ホットパーティションや下流の容量制限がカスケード問題を生み出します。
より安全な設計：
- 一時的な障害を検出する
- 指数バックオフで次の試行を遅らせる
- 障害しきい値に達したら依存関係への呼び出しを停止する（サーキットオープン）
- クールダウン期間後に慎重に再開する（サーキット調査）
- 回復不能な作業を dead-letter または隔離パスに移動する
ネイティブサポートの外観
新しいサポートは既存の Azure Functions ホストモデルと統合されます — 追加ライブラリなし、カスタム実装なし。設定は host.json に入ります：
{
"extensions": {
"serviceBus": {
"messageHandlerOptions": {
"maxRetryCount": 5,
"retryPolicy": {
"mode": "exponentialBackoff",
"minBackoff": "00:00:02",
"maxBackoff": "00:05:00",
"maxRetryCount": 5
}
}
}
}
}
サーキットブレーカーの設定は、不健全な依存関係が回復中に叩かれないよう、障害のしきい値とリセット間隔を設定します。
対応言語
これは .NET だけではありません。この機能は dotnet、JavaScript、TypeScript、Python をカバーします — Azure Functions の Service Bus トリガーでサポートされる言語の完全セットです。
まとめ
リトライパターンを設定するのは、下流の停止が発生して Functions が問題をより悪化させてしまう最初の事態が起きるまで、退屈に感じるものです。これを積極的に設定するのは安価です。インシデント中に改修するのはそうではありません。
元の投稿：Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions
