特集

とはいえクラウド依存の流れは止まらない

8月23日金曜日の午後、Amazonが展開するクラウドサービス「AWS」の東京リージョンにおいて大規模な障害が発生しました。
詳しくは公式のアナウンス解説記事などを参照いただきたいと思います。
少なくとも観測されているだけで金融系からSNS系、各種のオンラインサービスやECサイト、様々な公式サイトやゲームなど、ほぼ同時間帯に障害のアナウンスがされており、これだけAWSが使われているのかとある種感慨のようなものすらあります。

さて、今回の障害は東京リージョンのデータセンタでの空調設備の管理システム障害が原因とされており、オーバーヒートが発生したとしています。
結果としていくつかのEC2サーバの停止やEBSのパフォーマンス低下が発生したと説明しています。よくあると困るタイプのトラブルではありますが、データセンタやサーバルームなどを運用する上では比較的よくあるタイプの障害だったのかなという印象も受けます。
きちんとしたデータセンタであれば空調や冷却システムも冗長化されており、AWSにおいても例外ではありませんが、今回は制御システムにバグがありフェイルセーフに失敗、手動での操作も失敗したため被害が拡大したということのようです。
上記のITmediaの記事でも触れられていますが、2017年4月にはMicrosoft Azureの東日本リージョンでも冷却システムが原因の大規模障害が発生しています。

この障害を受けて一部でクラウドサービスの脆さを指摘する論調もありますが、必ずしもそうとは言い切れない点には注意が必要です。

今回の障害に関しては複数ある内の単一のアベイラビリティゾーン(AZ)におけるものであり、マルチAZの構成をしていれば影響を回避もしくは軽減できた可能性が指摘されていました。
もちろんシステムの設計・構成によってはマルチAZにしていても影響を受けたという声もありケース・バイ・ケースで、28日にはAmazon側も「マルチAZ構成でも影響を受けた」と公式に認め、やや説明が二転三転しました。
2つのマルチAZではなく3つのマルチAZにしておけば軽減できたかもしれないという意見もあり、もっと極論すればマルチリージョンの構成を採っているとさらに回避することが可能だったのではないかと思われます。
この辺りは今後AWS運用のノウハウや、あるいはAWS側の機能として回避のためのソリューションが増えていくことに期待というところでしょうか。
AWSの仕組み上、この辺りの構成はコストとの兼ね合いもあるため「こうしておけばよかった」という明確な答えはありませんが、Amazon側からは回避するためのソリューションがそれなりに提供されていることは抑えておくべきポイントです。
また仮にオンプレミスだからと言って今回のような冷却システムにまつわる問題を回避できるのかというとそんなことはなく、むしろその部分についてもデータセンタ事業者に委託をするのか、あるいは自前で管理することになるので、かえって手間暇が増える可能性もあります。
被害を受けた企業が多いことから大規模障害とは言われますが、5〜6時間で復帰した点について、インフラ運用を経験している人から見れば早かった方とも言えます。

今回の障害をもって「やっぱりクラウドサービスは危険だ」と思うのは自由ですが、総合的にコストや手間などを考えてどのようなサービスを利用するのが良いのか、どのような構成を採用するのがよいのかを検討する必要があるのは言うまでもありません。そしてここ数年の趨勢として、可用性や安定性はもちろん柔軟性やコストメリットなどを踏まえても、それなりの事情があって自社で持たざるを得ないという場合以外、クラウドサービスに移っていくという流れはそう変わらないのではないかと思います。

脆さを指摘している日経新聞ですらAWSにメリットがあることを認めているわけですしね。