.NET を使用して再試行ポリシーを実装する
クラウドで実行されるアプリケーション、またはリモート サービスやリソースと通信するアプリケーションは、一時的な障害を処理できる必要があります。 これらのアプリケーションでは、ネットワーク接続の一時的な喪失、サービスまたはリソースがビジーのときの要求のタイムアウト、またはその他の要因により、障害が発生することがよくあります。 開発者は、安定性と回復性を向上させるため、一時的な障害を透過的に処理するようにアプリケーションを構築する必要があります。
この記事では、.NET 用 Azure Storage クライアント ライブラリを使用して、Azure Blob Storage に接続するアプリケーションの再試行ポリシーを設定する方法について説明します。 再試行ポリシーは、失敗した要求をアプリケーションが処理する方法を定義しており、アプリケーションのビジネス要件とエラーの性質に合わせて常に調整する必要があります。
再試行オプションを構成する
Blob Storage の再試行ポリシーはプログラムで構成され、さまざまなサービス要求やシナリオに再試行オプションを適用する方法を制御します。 たとえば、ユーザーの操作に基づいて要求を発行する Web アプリでは、応答性を高め、エラーが発生したときにユーザーに通知するために、再試行回数が少なく、遅延が短いポリシーを実装する場合があります。 または、バックグラウンドでバッチ要求を実行するアプリやコンポーネントでは、要求が正常に完了するための時間があるように、再試行回数を増やし、エクスポネンシャル バックオフ戦略を使用する場合があります。
次の表は、RetryOptions クラスのプロパティと、その型、簡単な説明、変更を加えなかった場合の既定値をまとめたものです。 アプリのニーズに合わせて、これらのプロパティの値を事前に調整しておく必要があります。
プロパティ | タイプ | 説明 | 既定値 |
---|---|---|---|
[遅延] | TimeSpan | 固定アプローチの再試行間の遅延、またはバックオフベースのアプローチの計算の基準となる遅延。 サービスから Retry-After 応答ヘッダーが提示された場合、次の再試行はヘッダー値に指定された期間だけ延期されます。 | 0.8 秒 |
MaxDelay | TimeSpan | サービスから Retry-After 応答ヘッダーが提示されない場合の、再試行間隔の最大許容延期期間。 サービスから Retry-After 応答ヘッダーが提示された場合、次の再試行はヘッダー値に指定された期間だけ延期されます。 | 1 分 |
MaxRetries | INT | 中断されるまでの最大再試行回数。 | 5 (「注意」を参照) |
Mode | RetryMode | 再試行の遅延を計算するために使用する方法です。 | 指数 |
NetworkTimeout | TimeSpan | 個々のネットワーク操作に適用されるタイムアウト。 | 100 秒 |
Note
StorageClientOptions
は、MaxRetries
の既定値を 3 から 5 に増やします。 その他のすべてのプロパティの既定値は、RetryOptions
と同じです。
この Blob Storage のコード例では、BlobClientOptions クラスの Retry
プロパティで再試行オプションを構成します。 その後、再試行オプションを使って、BLOB サービス用のクライアント オブジェクトを作成します。
// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptions = new BlobClientOptions()
{
Retry = {
Delay = TimeSpan.FromSeconds(2),
MaxRetries = 5,
Mode = RetryMode.Exponential,
MaxDelay = TimeSpan.FromSeconds(10),
NetworkTimeout = TimeSpan.FromSeconds(100)
},
};
BlobServiceClient blobServiceClient = new BlobServiceClient(
accountUri,
new DefaultAzureCredential(),
blobOptions);
この例では、BlobServiceClient
オブジェクトから発行された各サービス要求が、BlobClientOptions
オブジェクトで定義されている再試行オプションを使います。 アプリのニーズに基づいて、サービス クライアントに対してさまざまな再試行戦略を構成できます。
geo 冗長性を使用してアプリの回復性を向上させる
高可用性と障害に対する優れた回復性が必要なアプリの場合は、再試行ポリシーの一部として Azure Storage の geo 冗長オプションを利用できます。 geo 冗長レプリケーション用に構成されたストレージ アカウントは、プライマリ リージョンで同期的にレプリケートされた後、数百マイル離れたセカンダリ リージョンに非同期的にレプリケートされます。
Azure Storage には、geo 冗長レプリケーションのためのオプションがあります。geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージ (GZRS) の 2 つです。 ストレージ アカウントで geo 冗長性を有効にするだけでなく、セカンダリ リージョンのデータへの読み取りアクセスを構成する必要もあります。 ストレージ アカウントのレプリケーション オプションを変更する方法については、「ストレージ アカウントがレプリケートされる方法を変更する」をご覧ください。
この例では、BlobClientOptions
で GeoRedundantSecondaryUri プロパティを設定します。 このプロパティが設定されている場合、セカンダリ URI は再試行中に GET
または HEAD
要求に使用されます。 セカンダリ URI からの応答の状態が 404 の場合、この状態コードはリソースがまだ伝達されていない可能性があることを示すので、要求の後続の再試行ではセカンダリ URI が再度使用されません。 それ以外の場合、後続の再試行はプライマリ URI とセカンダリ URI の間で交互に行われます。
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");
// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptionsGRS = new BlobClientOptions()
{
Retry = {
Delay = TimeSpan.FromSeconds(2),
MaxRetries = 5,
Mode = RetryMode.Exponential,
MaxDelay = TimeSpan.FromSeconds(10),
NetworkTimeout = TimeSpan.FromSeconds(100)
},
// Set the secondary storage URI
GeoRedundantSecondaryUri = secondaryAccountUri
};
BlobServiceClient blobServiceClient = new BlobServiceClient(
accountUri,
new DefaultAzureCredential(),
blobOptionsGRS);
geo 冗長性を利用するアプリでは、設計に関するいくつかの特定の考慮事項に留意する必要があります。 詳しくは、「geo 冗長性を使用して高可用性アプリケーションを設計する」をご覧ください。