8月23日(金)に発生したAWSの広域障害について、発生中の真っただ中にレポートを書きましたが、その日の夜、8時半頃にドコモのレンタル自転車に乗っている人を見かけ、「お、AWS収束したのか」と物理的に察しました。オンラインの事変をオフラインで知る。ITが私たちの生活に深く根強いているのがよくわかりますね。

で、AWS障害の原因は？

さて、このAWS障害ですが、原因もオンラインとオフラインにありました。23日の12時半頃に冗長化された空調管理システムに障害が起き、サーバーがオーバーヒート。結果、一部のEC2サーバーが停止し、EC2インスタンスとEBSボリュームのパフォーマンスが低下したようです。また、13時半頃にはEC2 RunInstances APIにも影響を及ぼし、エラー率が上昇しました。

15時半頃に冷却装置が復旧し、室内温度が戻ったためにインスタンスの電源も回復。そこから３時間ほどで大部分のEC２インスタンスとEBSボリュームは戻りましたが、一部のインスタンスは影響を強く受けたハードウェアホスト上で動いていたために普及に時間がかかりました。

サーバーのオーバーヒートとはかなり物理的な原因だったんですね。細田守監督の『サマーウォーズ』のワンシーンでサーバーをオーバーヒートから守るために巨大な氷の塊を周りに並べていく部分を思い出しましたが、イメージとしてはまさにそんな感じだったのでは？

どうして空調システムに障害が？

Amazonによると、今回のシステム障害はデータセンターの冷却システムの制御と最適化を担うデータセンター制御システムに発生したそうです。このシステムにはサードパーティのデバイスと繋ぐためのサードパーティ製コードが組み込まれており、制御ホスト群から制御ホストの 1 つを外す処理を行っていたところ、そのロジックのバグによりフェイルオーバーの間の制御システムとデーターセンター機器の情報交換が過度に発生してしまい、制御システムが応答できなりました。

Amazonは障害対策として障害が発生すると冷却システムが最大冷却を始めるよう設定していましたが、一部のシステムがこのモードに切り替わらず停止しました。

オペレーターがすぐさま冷却システムを、熱風を輩出する「パージ」モードというモードに切り替えようとしましたが失敗。そこで影響が出ている機器を全て主導で調査し、問題があるプログラマブルロジックコントローラをリセットすることでシステムを修復しました。

システム自体は戻りましたが、現在もこのサードパーティと共同で障害の原因について詳しい調査が行われています。

どうしていればよかったの？

Amazon公式の説明では、今回の障害は単一アベイラビリティゾーンで発生したため、マルチアベイラビリティゾーンでアプリケーションを稼働させていたサービスは可用性を確保できていたということです。

当社のフルマネージドサービス「cloud.config」はAzureのマルチリージョンを利用することで障害対策をしていますが、絶対に落とせないサービスなどはマルチリージョンやマルチクラウドを使って、冗長性を高める施策が必要です。

しかし当然冗長化を高めるということはコストの増加につながります。運営のコストと障害のリスクを鑑みて、冗長化の程度を判断することが重要でしょう。けれど忘れてはいけないのは通常時には高すぎるように思えるコストも、障害発生時の損失やブランド力の低下を思えば安い場合があるということです。

AWSのようにどんなに盤石なクラウドサービスでも、自社オンプレでも、障害を全くなくすことは不可能です。ならば考えなければならないのは、ビジネスとしてリスクとどのように向き合っていくか、どこまで保険をかけておくかという障害ありきの事業計画でしょう。

P.S.

もう一つのアマゾン、ブラジルの熱帯雨林の火災の方は、ブラジルが群を出動させて消火活動に乗り出したようです。地球の肺と呼ばれるだけの酸素を作り出す熱帯雨林の自己復元力を失う前に火を止めることができるでしょうか？　こちらの収束のニュースも早く耳にしたいですね。

参考

Amazon.com「東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要」