2020年 2月 26日に Azure 東日本リージョンで障害が発生しました。
複数のユーザーに影響が出たようで SNS に投稿があっただけでなく、ネットニュースにもなっています。
Microsoft から情報が出てきたので簡単にまとめてみます。（3/5 時点での見解です）
※公式情報から得た個人的見解です
※調査中のため、情報が更新される可能性があります
英語本文
上記のリンクから英語の記事を確認できます。コピペをしたものが以下です。
RCA Pending - Azure Storage and dependent services - Japan East (Tracking ID PLWV-BT0)
In light of new information, the following RCA is still preliminary and our investigations are continuing. While we have not changed any of the text below, we will provide an update once our investigation concludes.Summary of Impact: Between 03:29 UTC and 10:02 UTC on 26 Feb 2021, a subset of customers in Japan East may have experienced service degradation and increased latency for resources utilizing Azure Storage, including failure of virtual machine disks. Some Azure services utilizing Storage may have also experienced downstream impact.
Root Cause: There were contributing factors that led to customer impact.
Firstly, we had an active deployment in progress on a single storage scale unit. Our safe deployment process normally reserves some resources within a scale unit so that deployments can take place. In addition to this space being reserved for the deployment, some nodes in the scale unit entered an unhealthy state and so they were removed from use from the scale unit. The final factor was that resource demand on the scale unit was unusually high.
In this case, our resource balancing automation was not able to keep up and spread the load to other scale units. A combination of all these factors resulted in a high utilization of this scale unit causing it to be heavily throttled in order to prevent failure. This resulted in a loss of availability for customers and Azure services attempting to utilize Storage resources within the impacted storage scale unit.
Mitigation: To mitigate customer impact as fast as possible, unhealthy nodes were recovered which restored resources to the service. In addition, engineers took steps to aggressively balance resource load out of the storage scale unit.
Once Storage services were recovered around 06:56 UTC, dependent services started recovering. We declared full mitigation at 10:02 UTC.
Next steps: We sincerely apologize for the impact this event had on our customers. Next steps include but are not limited to:
Improve detection and alerting when auto-balancing is not keeping up to help quickly trigger manual mitigation steps.
Reduce the maximum allowed resource utilization levels for smaller storage scale units to help ensure increased resource headroom in the face of multiple unexpected events.
Provide Feedback: Please help us improve the Azure customer communications experience by taking our survey: https://aka.ms/AzurePIRSurvey
日本語訳（google 翻訳）
ちょっと英語だと何を言っているのか理解しずらいので Google 翻訳にかけて必要な所だけピックアップしてみました。
影響の概要：2021年2月26日の03：29UTCから10：02UTCの間に、日本東部の一部のお客様が、仮想マシンディスクの障害など、AzureStorageを利用するリソースのサービスの低下と遅延の増加を経験した可能性があります。ストレージを利用する一部のAzureサービスでも、ダウンストリームの影響が発生している可能性があります。
新しい情報に照らして、以下のRCAはまだ暫定的なものであり、調査は継続中です。以下のテキストは変更していませんが、調査が終了したら更新を提供します。
影響が出たのは ストレージ 関連のサービスのようです。
あと、この情報は変更する可能性があるようです。
では、なぜ障害が発生したのかを確認してみます。
まず、単一のストレージスケールユニットでアクティブな展開が進行中でした。私たちの安全な展開プロセスは通常、展開を実行できるように、スケールユニット内にいくつかのリソースを予約します。このスペースが展開用に予約されていることに加えて、スケールユニット内の一部のノードが異常な状態になったため、スケールユニットから使用できなくなりました。最後の要因は、スケールユニットのリソース需要が異常に高かったことです。
この場合、リソースバランシングの自動化は、負荷を維持して他のスケールユニットに分散することができませんでした。これらすべての要因の組み合わせにより、このスケールユニットの使用率が高くなり、障害を防ぐために大幅にスロットルが調整されました。これにより、影響を受けるストレージスケールユニット内でストレージリソースを利用しようとするお客様とAzureサービスの可用性が失われました。
要するに、
「ストレージを使うサービスを利用するときは、デプロイが実行されるとデータセンター内でスペースが予約される」
「データセンター内の一部で使用不可のものがあった」
「そもそも需要が高かった」
以上の理由で、負荷が非常に高く負荷分散が追い付かなかった ということでしょうか。
3つの条件が満たされないと起きなかった現象のようなので、頻発するのものではないのかな。と期待します
おまけ
「データセンター内の一部で使用不可のものがあった」
が引っかかる方がいるかもしれないので、少し言及しておきます。
Azure に限らずパブリッククラウドといえどもハードウェアの故障は必ず起きます。むしろ、そういう故障時の管理をプロバイダーに委任しているのがクラウドの特徴の1つだと思っています。
今回の「一部使用不可」がハードウェアの故障かどうかはわからないです。
が、パブリック クラウドでもオンプレと同じくそういうことは起きているんだな～と、ユーザーに代わって色々直してくれたんだな～とポジティブに捕えようと思います。