マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

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

詳細

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

機能

Retry

Circuit Breaker

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

Timeout

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

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

Bulkhead Isolation

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

Fallback

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

Cache

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

PolicyWrap?

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

見解

実装例

  • ラッパーでも良いと思うが、DIの実装例が多い。

実装箇所

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

  • クライアント実装
    • 所詮、クライアント側実装ではある。
    • サーバ実装で担保スべきところもありそうだ。
  • サーバ実装
    クライアント実装ダケでは完結しない。
  • API Gatewayに流量制御してくれる機能があるのでコレを使用するのも手。

利用シーン

  • 機能的に十分、足りてるんだろうけど、
    • 結局、書き直す。
    • 若しくは、ユースケース毎にラッパを作成する。

ことになる気がする。

  • なんとなく、

    この全ポリシーを組み合わす機会が少ない

ので、ありがたみが少ない(その割に複雑な)気がする。

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

参考

NuGet

Qiita

Microsoft Docs

Exponential Backoff(指数バックオフ)


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-03-21 (土) 11:50:32 (112d)