Azure Storage クライアント ライブラリの再試行ポリシーに関する推奨事項

このポストは、5 月 22 日に投稿した Azure Storage Client Library Retry Policy Recommendations の翻訳です。 Azure Storage クライアント ライブラリ (SCL) の再試行ポリシーをどのように構成するかについては、Gaurav Mantri が執筆した「SCL 2.0 – 再試行ポリシーの実装 (英語)」でわかりやすく説明されています。しかし、どの再試行ポリシーの設定を使用すればよいかの実践的な解説は、なかなかありません。この記事では、マイクロソフトのチームが高負荷シナリオで SCL を実際に使用した経験に基づいて、推奨事項をお伝えします (低負荷シナリオについては、既定の再試行ポリシーで十分に機能します)。 ExponentialRetry と LinearRetry 応答時間を短くすることを考慮する必要がないバッチ処理では、ExponentialRetry (英語) クラスを使用するとよさそうに思いがちです。一時的なエラーを可能な限りすばやく解決するために再試行を迅速に行い、同時に、障害が発生しているサービスの問題が拡大することを防ぐため、サーバーには過大な負荷を掛けないようにしたいと考えるでしょう。 しかし、ここで Storage サービスへの接続品質を追跡できるようにしておくことの必要性について検討してください。タイムアウト時間を非常に長く設定したまま ExponentialRetry (英語) で何度も再試行すると、ほとんどの一時的なエラーについて、例外への対応は不要になりますが、その一方で、問題が頻繁に発生した場合にそれを把握することができません。応答時間は追跡できますが、問題の原因が一時的なエラーかどうかまではわかりません。 このため、より詳細な診断情報を得るには、LinearRetry (英語) クラスの使用が最適です。再試行の間隔を相対的に短くして、回数を数回のみに限定すると、試行はかなり短い時間で失敗します。これによりユーザーが例外を把握し、障害のレポートを作成しつつバックオフを実装できます。ほとんどの要求を最終的に正常に完了させるには、このバックオフが非常に重要です。 MaximumExecutionTime IRequestOptions (英語) インターフェイスに、MaximumExecutionTime (英語) プロパティもあります。この値には、すべての再試行処理が終了するまでの時間の上限を設定します。大規模な処理は失敗するまでにある程度の時間を要するため、実行する処理の種類によっては、非常に大きな値を設定する必要があります。チームでは、高負荷条件下で大規模な処理が要求された場合は、この値が 10 秒未満の場合に頻繁にエラーが発生することを確認しました。MaximumExecutionTime を 60 秒に設定すると、このような例外を回避できます。ただし、これが有効なのはバックグラウンド処理の場合で、ユーザーが操作する処理の場合には調整が必要です。 また、チームでは、ServerTimeout (英語)…