Skip to content

MS_AzureRetryDesign

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azure上でのリトライ設計・実装

概要

下記を参照。

補足（原文はリンクのみのため、要点を補う）

クラウドでは、一時的な障害（transient fault）は正常な事象である。
サービス側のスケール調整、ノードの入れ替え、
スロットリング（Azure API Management の
レート制限や Azure SQL Database の DTU 上限）など、
設計どおりに動いていても失敗が返る場面が常にある。
したがってリトライは「例外的な保険」ではなく
標準の設計要素として組み込む必要がある。

詳細

補足（原文が概要のみのため、要点を補う）

リトライしてよい失敗・いけない失敗

分類 例 対応
一時的（transient） 接続タイムアウト、429 Too Many Requests、503 リトライする
恒久的 401（認証失敗）、403、404、SQL の構文エラー リトライしない（何度やっても同じ）
判定困難 500 慎重に。回数を絞る

恒久的な失敗をリトライすると、障害を悪化させるだけである。
「とりあえず 3 回リトライ」という実装が最も危険。

指数バックオフとジッター

一定間隔でリトライすると、

  • 復旧しかけたサービスに再び負荷が集中する、
  • 多数のクライアントが同時にリトライして波を作る（Thundering Herd）、

という問題が起きる。対策は次の 2 つ。

待ち時間 = base × 2^(試行回数)   ← 指数バックオフ
           + random(0, jitter)   ← ジッター（波をずらす）

サーキット ブレーカーとの組み合わせ

リトライだけでは、相手が完全に落ちている場合に無駄な待ちが積み上がる。
一定回数失敗したらしばらく呼び出し自体をやめる（オープン）、
時間経過後に少量だけ試す（ハーフオープン）という制御を併用する。

Closed（通常）──失敗が閾値超──▶ Open（即座に失敗を返す）
    ▲                                  │ 一定時間後
    └────成功────  HalfOpen（試行）◀──┘

詳細は クラウド アプリケーション アーキテクチャ ガイド の
クラウド デザイン パターンを参照。

実装：まず SDK の組み込み機能を使う

自前でリトライを書く前に、SDK が持つ機能を確認すること。
二重にリトライを実装すると、

  • 試行回数が掛け算になり（3 × 3 = 9 回）、
  • タイムアウトが想定の何倍にもなる、

という事故になる。

対象 組み込みのリトライ
Azure SQL Database EF Core の EnableRetryOnFailure()（接続の回復性）、Microsoft.Data.SqlClient の接続回復性
Azure SDK for .NET RetryOptions（各クライアントの ClientOptions）
HTTP 全般 Polly ＋ IHttpClientFactory

Polly を使う場合も、
HttpClient のタイムアウトとリトライ回数の積が
全体のタイムアウトを超えないよう設計すること。

冪等性が前提になる

リトライは同じ処理が複数回実行され得ることを意味する。
「タイムアウトしたが、サーバー側では成功していた」という場合、
単純なリトライは二重登録になる。

  • 更新系には冪等キー（クライアント生成の一意な ID）を持たせる、
  • あるいはサーバー側で重複を検出する、

といった設計が併せて必要になる。
これを欠いたリトライは、可用性を上げる代わりにデータを壊す。

参考

Microsoft Learn

Tags: 移行, インフラストラクチャ, クラウド, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally