AWSの国内データセンターで発生したトラブル

　公式発表によれば、AWSで障害が発生したのは東京リージョン（AP-NORTHEAST-1）のとあるアベイラビリティゾーン（AZ、データセンターの集合単位）で、そのAZにある4つのデータセンターのうち、1つの施設だ。障害発生は8月23日金曜日の正午過ぎである。

　AWS側の復旧は、夕方の6時過ぎに大部分のサーバが復帰し、その日のうちに障害ほぼ終了した。とはいえ、多くのユーザー企業にとっては午後の業務時間がすべてつぶれ、サービスによっては翌24日昼間になっても復旧できていないものもあった。

　インフラにAWSを利用していたゲームサイトは利用者へのお詫びやフォローが大変だろうし、同じくECサイトは貴重な週末の2日間、営業機会を損失したことになる。

　アマゾン側の対応を含めて、これからさらに問題が広がる可能性もある。しかし、ここで取り上げたいのは、「なぜこのような広域かつ長時間の障害につながったのか」「その原因や対策はないのか」「このような障害が起きるなら業務にクラウドは不向きなのか」という点だ。

　いまやクラウドは、普通のオンプレミスより堅牢でセキュアだと言われている。しかし当然だが、それでも落ちるときは落ちる。今回のトラブルは、多くの企業に「クラウドのリスク管理」について改めて考える契機となっただろう。

空調トラブルの本当の原因は何か？

　まず原因について考察してみよう。

　AWSのサーバ群は大きく「リージョン」と「AZ」に分けることができる。リージョンはほぼ国に対応する分類だが、複数リージョンを持つ国もある。AZはそのうち、実際のデータセンターごとの区切りと思えばよい。

　AWSでは、ユーザーがサーバインスタンスを立ち上げるとき、リージョンやAZを指定することができる。FT（フォールトトレラント：障害耐性）構成にしたいとき、バックアップを冗長化したいとき、各サーバを複数のAZに分散する。アマゾンが示すベストプラクティスでも、AZの分散、仮想ネットワークの分散、バックアップ系の構成など推奨している。

　原因は東京リージョンのうち1つのAZ、つまり東日本のどこかのデータセンターに発生した空調のトラブルだという。データセンターの空調制御システムは、複数のコントローラーで分散制御されるものだった。通常は、コントローラー（制御ホスト）同士が通信しあい、サーバルーム全体の温度調整を行う設計だ。

　アマゾンの発表によれば、制御ホスト群の1つを切り離そうとしたところ、制御ホストのソフトウェアの不具合により停止。制御トラブルの場合のフェールセーフ機能（温度情報を防ぐため制御システムが止まったら空調はフル稼働させる）が機能せず、また緊急時に通常ソフトウェアをバイパスして、制御デバイスを操作する強制排熱シーケンスもうまく動かなかった。

　制御ホストが分散化されていたのにシステムが停止したのは、ホスト1台を切り離したときに多数の通信が発生したためとある。おそらく、制御ホスト間の状態確認や問い合わせのパケットが輻輳（ふくそう）したものと思われる。結局、制御ホスト群が同時に機能しなくなった。

　発端となった制御ホストの切り離しが、故障なのか定期メンテナンスなのか、あるいは別の理由なのか、詳しい発表はない。さらなる原因調査と、それによる対策強化が望まれる。


　今回のトラブルでは、図らずもAWSやMicrosoft Azureのようなインフラ化したクラウドプラットフォームの影響力があらわになってしまった。改めて、クラウド事業者には、リスク管理・対策の強化、点検は必要だろう。

　しかし、今回のトラブルが大規模、長時間に及んだのは、AWS側だけの問題ではないという声もある。

【次ページ】明暗を分けたユーザー側の対策