MS_Polly

Polly(Retry, Circuit Breaker, Timeout, Bulkhead, Fallback)

• 戻る（HttpClientの類の使い方、クラウド設計パターン（MS_CloudDesignPatterns.md））
  • Exponential Backoff（指数バックオフ）
  • Polly

概要

• 「障害回復力のある一時的な障害処理ポリシー」を実装する。
• スレッドセーフかつ Fluent Interface で表現・実装できる。

詳細

以下のようなポリシーを組み合わせて実装できる。

機能

Retry

• 時間を空けて再実行する。
• Exponential Backoff（指数バックオフ）を併用する。

Circuit Breaker

設定で指定した回数のエラーが連続して発生した場合、Exceptionを返す。

※ 回路が開いた（Open）状態では即座に BrokenCircuitException を返し、
一定時間後に半開（Half-Open）で試行し、成功すれば閉じる（Closed）。

Timeout

指定した時間が経過しても処理が終わらない場合、Exceptionを返す。

• 悲観的タイムアウト
  • 通常のタイムアウト
  • クライアント側なので処理を抜けるだけになる。
• 楽観的タイムアウト
  • 悲観的タイムアウトでは、処理を抜けるだけになるが、
  • 楽観的タイムアウトでは、CancellationTokenによるキャンセル処理を実装できる。

移行メモ: Polly の用語では、CancellationToken に対応して処理そのものを中断できる 側が Optimistic（楽観的）、 対応していない処理に対して呼び出し側だけが先に諦める（作業スレッドは走り続ける）側が Pessimistic（悲観的）。原文の説明はこの区別と一致している。

Bulkhead Isolation

• 並列に実行可能なリクエスト数を制限する。
• コンシューマー・バルクヘッドとも呼ぶ。
• セマフォを使って同時実行可能数を制限している。

Fallback

エラーが発生した場合に、最終的に返したい値は Fallback を使って指定する。

Cache

Cacheを、他の Policy と組み合わせて柔軟に処理に組み込める。

PolicyWrap

上記（Retry, Circuit Breaker, Timeout, Bulkhead, Fallback）を組み合わせる。

• PolicyWrap · App-vNext/Polly Wiki

補足（最新化）: Polly v8 で API が刷新され、 Policy.Handle<T>().Retry() 系の構文は「Polly.Core」の ResiliencePipelineBuilder に置き換えられた（V7 構文は互換のため残るが非推奨）。 PolicyWrap に相当するのはパイプラインへの複数ストラテジ追加。 Bulkhead は RateLimiter ストラテジ（System.Threading.RateLimiting 連携）に、 Cache は Polly 本体から外れ HybridCache などに委ねる方針になっている。

また .NET 8 以降は Microsoft.Extensions.Http.Resilience が提供され、 AddStandardResilienceHandler() を呼ぶだけで Retry / Circuit Breaker / Timeout / RateLimiter の標準構成が付く。

見解

実装例

• ラッパーでも良いと思うが、DI の実装例が多い。
• 更にクリーン・アーキテクチャ的な実装例もある。

実装箇所

「障害回復力のある一時的な障害処理ポリシー」を実現する際の実装箇所。

• クライアント実装
  • 所詮、クライアント側実装ではある。
  • サーバ実装で担保すべきところもありそうだ。
• サーバ実装（クライアント実装だけでは完結しない）
  • クラウド設計パターンの調整（絞り弁 / Throttling）（MS_CloudDesignPatterns.md）
  • Device Flow や CIBA の slow_down などは、サーバーが指示する。
  • API Gateway に流量制御してくれる機能があるのでコレを使用するのも手。

利用シーン

• 機能的に十分、足りてるんだろうけど、

  • 結局、書き直す。
  • 若しくは、ユースケース毎にラッパを作成する。

  ことになる気がする。

• なんとなく、この全ポリシーを組み合わす機会が少ないので、
  ありがたみが少ない（その割に複雑な）気がする。

• ケースバイケース（オーバースペックにならないようにすべき）

  • 冒頭にも書いた「ユースケース毎にラッパ」に該当する、
    HttpClientをシングルトンにしている様な実装箇所を、
    HttpClientFactoryにして、Polly統合するのが現実的か。
  • MAXは、クリーン・アーキテクチャ化だが、段階がある。
  • また、Pollyのような、クライアント実装だけではなく、
    サーバ実装で担保すべきところもありそう。

参考

• C# と Polly を使って回復力の高いアプリケーションを書く - しばやん雑記
• Polly で指数バックオフを含む HTTP 呼び出しの再試行を実装する
• Bulkhead pattern - Cloud Design Patterns
• Cache-Aside pattern - Cloud Design Patterns
• App-vNext/Polly - GitHub

NuGet

• Polly
• Microsoft.Extensions.Http.Resilience

---

Tags: .NET開発, 通信技術, .NET Standard, .NET Core, ASP.NET, ASP.NET Web API, クラウド系開発