Azure ストレージ アカウントの Availability メトリックが 100% を下回ったときの考え方について
本ブログではストレージアカウントの Availability メトリックについて、よくいただくご質問について言及できればと思います。
質問
Azure ストレージアカウントのメトリックを監視していたら、Availability メトリックが 100% をほんの少し下回りました。何かストレージに問題がありましたか。
回答
概略
私たちのチームでは上記のようなお問い合わせをいただくことが時々あります。最終的にはケースバイケース、ということになるのですが、大まかな考えたかをお伝えできればと思います。
そして、だいたいの場合の見解としては、ストレージとしては特に問題ない、そのため、特に気にしなくていい、ということになります。また、Availability メトリック が下がったとしても、利用しているアプリケーション側では特に問題にはならない、ということもいえます。なぜこのような見解になるのかを、もう少し補足します。
Availability メトリックとは？
まず、Availability が 100% を切る、という部分について、そもそも、Availability メトリックとは何なのか、ということをイメージできる必要があります。そして、説明としては以下の資料に記載があります。
Microsoft.Storage/storageAccounts でサポートされているメトリック
| REST API の名前 | メトリック |
|---|---|
| Availability | 可用性 ストレージ サービスまたは指定された API 操作の可用性の割合。 可用性は、TotalBillableRequests の値を取得し、それを該当する要求の数 (予期しないエラーが発生した要求を含む) で割ることによって、計算されます。 予期しないエラーすべてが、ストレージ サービスまたは指定された API 操作の可用性の低下をもたらします。 |
これだけだとわかりにくいかと思いますので、少し大まかに言うと、ストレージに対しての全要求数のうち、成功したパーセンテージを示す、ということになります。そして、成功ではないリクエスト、というのは、ストレージの応答として HTTP 500 番台の応答を返したもの (一部例外はありますが、話が発散するため、ここでは言及しません。)と認識してください。
シンプルな例でいうと、ストレージに対して、あるタイミングで 1,000 件のダウンロードのリクエスト ( GetBlob という REST API の呼び出し) があったとします。このリクエストがすべて成功なら可用性は 1,000 ÷ 1,000 × 100 = 100% となりますし、1件だけ 500 ServerTimeoutError が発生したとすると成功したリクエスト数は 1,000 -1 = 999 となるため、999 ÷ 1,000 × 100 = 99.99% となり、100% を下回ることになります。
Availability が 100% を切ったときに考えられることは？
Availability が 100% を切る、ということは、先の節で記載した通り、基本的にはストレージのアクセスの中で一部が http 500 番台のエラーを返した、ということになります。そして、エラーを返したときに考えられることは以下の資料に記載があります。
Azure ストレージ アカウントの可用性に関する問題のトラブルシューティング
そしてここも大まかにエラーとして考えられる要因をまとめますと、以下のものが挙げられます。
- ストレージアカウントのスロットリングの調整による一時的なエラー
- サービスの負荷分散による、一時的なタイムアウト
- サーバー側で処理継続中にクライアントが切断したネットワークエラー
- その他、一時的なエラー
上記のようなエラーが返った場合、”成功したリクエスト数 ＜ 総リクエスト数” ということになるため、Availability のメトリックが 100％ を下回る、ということになります。
Availability が 100% を少しでも下回ったら常に問題があるのか？
ここも最終的にはケースバイケースという言い方ではありますが、多くの場合、少し下回ったという状況では問題はない、ということがほとんどです。
その理由としては、継続的にストレージアカウントにアクセスする場合、プログラムからアクセスしている、ということが多いかと思います。そして、そのような場合、クライアントライブラリ側でストレージへのアクセスをリトライする設定が既定で入っており、仮に何かのアクセスでエラーが返ってきて一度失敗したとしても、リトライが実施され、リトライ後のアクセスで成功をして、結果として実施したかったアクセスが成功した、ということが考えられます。
以下は .NET を使ったストレージへのアクセスの例ですが、既定では 最大再試行回数 が 5回、となっていることが確認できます。そのため、例えば一度 500 エラーで失敗したとしても、次の再試行で成功、ということになれば、アクセス自体は成功、ということになります。まだ、.NET での例を出しましたが、他の言語の SDK も同様の仕組みとなっています。
これらのことより、Availability が一時的に 100％ を少しでも下回った、としてもストレージを利用しているアプリケーション側などで問題になるということは考えにくい、ということになります。
まとめ
サポートとしてお問い合わせをいただいてきた中での見解となりますので、すべての場合にこの見解が当てはまるということにはならないかもしれませんが、経験則の一つとして、少しでも参考になればと思います。
2024 年 04 月 24 日時点の内容となります。
本記事の内容は予告なく変更される場合がございますので予めご了承ください。