マイクロサービスの HTTP 通信は、どこかで必ず失敗します。

Microsoft が .NET 8 から提供する Microsoft.Extensions.Http.Resilience を使えば、リトライ・タイムアウト・サーキットブレーカー・レートリミッターを含むパイプラインを1行で設定できます。

この記事でわかること：

  • なぜ HTTP 通信に耐障害性が必要か
  • AddStandardResilienceHandler で設定される5つの戦略の中身
  • インストール方法と基本的な使い方
  • POST リクエストのリトライ無効化など実践的なカスタマイズ

https://learn.microsoft.com/en-us/dotnet/core/resilience/http-resilience

なぜ HTTP 通信に耐障害性が必要か

クラウドアプリケーションの HTTP リクエストは、一時的なネットワーク障害やサーバー負荷による失敗が避けられません。依存するサービスが増えるほど、ひとつの失敗が連鎖する「カスケード障害」のリスクも高まります。

一般的な対策は4種類あります。タイムアウト（応答を待ち続けない）、リトライ（一時的な失敗を再試行）、サーキットブレーカー（障害中のサービスへの通信を一時停止）、レートリミッター（同時リクエスト数の制限）。これらを個別に実装すると設定コストが高く、一貫性も保ちにくくなります。

Microsoft.Extensions.Http.Resilience はこれらをひとつにまとめたパイプラインを提供するライブラリです。

インストール方法

NuGet からパッケージを追加します。

dotnet add package Microsoft.Extensions.Http.Resilience

または .csproj に直接記述します。

<PackageReference Include="Microsoft.Extensions.Http.Resilience" />

最新バージョンは 10.5.0（2026年4月更新）で、.NET 8 以上に対応しています。

AddStandardResilienceHandler の使い方

IHttpClientBuilder に対して AddStandardResilienceHandler を呼び出すだけで、5つの戦略が有効になります。

builder.Services.AddHttpClient<ExampleClient>(client =>
{
    client.BaseAddress = new Uri("https://api.example.com");
})
.AddStandardResilienceHandler();

これまでは AddRetry・AddTimeout・AddCircuitBreaker をそれぞれ手動で追加する必要がありましたが、この1行で代替されます。

標準パイプラインに含まれる5つの戦略

標準パイプラインは以下の順で実行されます（外から内の順）。

レートリミッターは同時リクエスト数を最大1,000件に制限し、依存先の過負荷を防ぎます。

合計タイムアウトはリトライ込みで全体の上限を30秒に設定します。30秒を超えると実行を打ち切ります。

リトライはサーバーエラー（HTTP 5xx）・タイムアウト（HTTP 408）・レート超過（HTTP 429）に対して最大3回再試行します。バックオフは Exponential + Jitter で、初回遅延は2秒です。

サーキットブレーカーは最低100リクエスト中10%以上が失敗した場合に回路を開き、5秒間通信を停止します。障害中のサービスへの無駄なリクエストを防ぎます。

試行タイムアウトは1回の試行を10秒でキャンセルします。合計タイムアウトとは別に、個々の試行に上限を設けます。

POST リクエストのリトライを無効にする

リトライはデフォルトで全 HTTP メソッドに適用されます。POST が冪等でないエンドポイントでは、リトライによってデータが重複する危険があります。

特定のメソッドを除外するには DisableFor を使います。

.AddStandardResilienceHandler(options =>
{
    options.Retry.DisableFor(HttpMethod.Post, HttpMethod.Delete);
});

POST・PATCH・PUT・DELETE・CONNECT をまとめて除外したい場合は DisableForUnsafeHttpMethods が手軽です。

.AddStandardResilienceHandler(options =>
{
    options.Retry.DisableForUnsafeHttpMethods();
});

独自パイプラインを構築する

標準パイプラインで要件を満たせない場合は AddResilienceHandler で独自の戦略を組み合わせます。

.AddResilienceHandler("my-pipeline", builder =>
{
    builder.AddRetry(new HttpRetryStrategyOptions
    {
        MaxRetryAttempts = 4,
        Delay = TimeSpan.FromSeconds(2),
        BackoffType = DelayBackoffType.Exponential
    });

    builder.AddTimeout(TimeSpan.FromSeconds(5));
});

必要な戦略だけを選択して組み合わせられるため、細かい制御が必要なケースに向いています。

旧パッケージ Microsoft.Extensions.Http.Polly との違い

以前は Microsoft.Extensions.Http.Polly が同様の用途で使われていました。新しい Microsoft.Extensions.Http.Resilience は Polly v8 をベースに Microsoft とコミュニティが共同開発したもので、テレメトリの統合・依存性注入サポート・設定ベースのカスタマイズが強化されています。

旧パッケージは引き続き動作しますが、新規プロジェクトへの導入は Microsoft.Extensions.Http.Resilience が推奨されます。

まとめ

Microsoft.Extensions.Http.Resilience を使えば、リトライ・タイムアウト・サーキットブレーカー・レートリミッターの組み合わせを最小限のコードで実現できます。まず AddStandardResilienceHandler を追加し、POST リクエストへのリトライ設定など実際の要件に合わせてオプションを調整するのが、最も手軽な導入の流れです。