Microsoft Azureの国内リージョンでストレージサービスに起因する障害が相次いでいる。日本時間3月31日22時50分から翌4月1日6時にかけて、顧客の一部がAzure東日本リージョンのリソースに接続できない状態が続いた。
米マイクロソフトの公式サイト「Azureの状態の履歴」によれば、今回の障害の根本原因は「冷却系」とのこと。東日本リージョン内で一部の拡張ユニットが冷却できない状態になったため、データ保護のために特定のストレージユニットとコンピューティングユニットが自動シャットダウンされた。これにより、Azureストレージサービスと、ストレージを利用するAzure App Service (Web Appsなど)やVirtual Machines（VM）など、多くのサービスが影響を受けた。
4月1日2時20分頃の「Azureの状態」。東日本リージョンのStorageとVirtual Machinesに警告が出ている
Azure東日本リージョンでは、3月8日にもストレージサービスとそれを利用するサービスの一部に約2時間接続できなくなる障害が起こっている。この際はストレージのデータ配置を管理するバックエンドコンポーネントのバグが原因だった。また、3月28日にはAzure西日本リージョンで、VMやAzure App Serviceなどに約3時間アクセスできなくなる障害が起こった。ここでは、西日本リージョンへ新しく追加したストレージスケールユニットに間違ったIPアドレスが割り当てられたためリージョン内のデータセンター間で接続がブロックされ、この接続に関係するVMなどのサービスが影響を受けた。
Azureの国内リージョンでの障害が年度末の3月に続いた。これは筆者の憶測になるが、日本固有の状況として、新年度からの予算で新たにAzureのサービスを契約する企業が増えた可能性がある。4月からのユーザー数や利用規模の急増に対応するために、3月中に国内リージョンでストレージユニットなどの増強を急いだ結果、設定ミスに起因する障害や、拡張したユニットの冷却が追い付かなくなるなどの障害が続いたのではないだろうか。マイクロソフトには、4月以降のサービスの安定稼働と、日本市場の会計年度を加味した計画的なサービス増強が求められる。
そしてユーザー側は、今回の障害を教訓に、クラウドサービスを使う際は障害が起こることを想定して自社システムの可用性を維持するための対策を講じておくことが重要だ。2月末に発生したAWS S3の障害を例示する間でもなく、障害はすべてのクラウドサービスで発生する可能性がある。
3月の一連のAzureストレージ障害でも、2月のAWSストレージ障害でも、ユーザーにとって失われたのは「サービスの可用性」であり、「ユーザーのデータ」が失われたわけではない。データはクラウドベンダー側が複数のコピーを持って冗長化している、という信頼の上で、ユーザーにできることは障害発生時に可能な限り自社システムを停止させない（HA）設計にすることだ。
また、Azureの一連の障害は東日本リージョンと西日本リージョンでそれぞれ別のタイミングで発生している。計画メンテナンスやソフトウェアの更新は、ペアになるリージョン（Azureのリージョンは必ずペアになっている）で同じタイミングに実施しない運用になっており、今回のようなソフトウェアのバグや設定ミスによる障害は東西リージョンで同時には起こりづらい。サービス停止回避のために、東西リージョンでディザスタリカバリー（DR）構成をとっておくことが有効な事案だった。
Azureの主要サービスのHA（※ここでは、特定のリージョン内でサービスの可用性を高めること）構成と、DR（※ここでは、東西リージョンでフェールオーバー可能にすること）構成について、日本マイクロソフト デベロッパー エバンジェリズム統括本部 エバンジェリストの佐藤直生氏（NEO）に話を聞いた。
