【経営者・エンジニア向け】AWS障害の考察：クラウドにおける耐障害性構成とバックエンドエンジニアの重要性
昨日（2019/08/23）、AWS東京リージョンで大規模な障害が発生し、日本のWEBサービスの多くで障害が発生した。
障害範囲自体は、東京リージョンのEC2（仮想サーバサービス）とRDS（データベースサービス）の一部のテナントだったが、4時間近くにわたり多くのサービスで障害が発生してしまった。
そこで露呈したのが、「クラウド神話」と「耐障害性」だった。
今回は、AWSやAzureの様なIaaSでサービスを展開するときの、耐障害性の考え方について解説する。
AWSとは？
AWSという言葉、初めて聞く人もいるかもしれないが、AWSとはAmazon Web Serviceの略だ。
クラウドサービスの基盤（IaaS）となるAWSは、すごく簡単に言えば様々なサービスと連携、拡張が可能なレンタルサーバみたいなものである。
今回の障害で、日本の多くのサービスがAWSを利用していることが露呈した。
では、AWSとはいったいどんなサービスなのか？
AWSは、主に以下のサービスを提供している。
- 仮想（≒レンタル）サーバ機能 [Amazon EC2]
- 可用性、冗長性の高いデータベース [Amazon RDS]
- ビックデータ基盤 [Amazon Redshift]
- CDNサービス [Cloud Front]
その他にも、様々なサービスを有しており、IoTやAI、ビックデータ、ブロックチェーン等の最先端の技術を低コストで利用できる。
参考記事：【エンジニア・AWS初心者向け】AWSでできることを目的別にまとめてみた
データセンター内の冷却装置の故障から発生した大規模障害
さて、話は戻るが、今回のAWS大規模障害の原因は、以下の様に冷却装置の不具合が原因だ。
参考記事：AWS障害、大部分の復旧完了 原因は「サーバの過熱」
データセンターは、数多くのネットワーク機器やサーバーをホスティング（＝設置）しているため、排熱量が非常に多い。
そのため、データセンター内の施設は、いくつもの冷却装置を備え、エアフロ―（空気の流れ）を作って、常に冷却した空気が機器に当たるように設計されている。
今回の障害は、データセンター内の冷却装置の一部に不具合が発生し、一部のサーバやネットワーク機器が冷却できなくなり熱暴走を起こしたのが原因と発表されている。
サービス提供側は、どうすれば障害を防げたのか？
今回は物理的な障害だったが、IaaS側でこのような障害が発生した場合、サービス提供側はどのように対応すればよかったのだろうか？
このような場合、
- コールドスタンバイの構築：普段利用しないサーバやサービスを動かすネットワークやサーバーを構築し、通常時は停止しておく。障害時のみ起動する。
- 冗長化構成の導入：EC2の様な仮想サーバはELBといわれるロードバランサで冗長化。RDSの様なデータベースは、リージョン間レプリケーション構成にする。
といった対策が考えられる。
今回、障害が大きくなったサービスの多くが、AWS東京リージョン（拠点）に構築されたネットワーク上を中心に稼働していた。
しかし、このように1拠点に依存してしまうと、いざ障害が発生したときに復旧するまで時間がかかってしまう。
本来AWSは、アメリカのみならず、東アジア、東南アジア、オセアニア、ヨーロッパ等多くのリージョンを持っている。
オンプレミスやただのレンタルサーバであればマルチリージョンは難しいが、AWSならいくつかの拠点を設けることが可能なので、それを利用しない手はない。
そこで、１、２それぞれの案を、技術（構成）、運用、費用面それぞれについてまとめてみた。
| 案１：コールドスタンバイの構築 | 案２：冗長化構成の導入 | |
| 技術（構成）面 |
|
|
| 運用面 |
|
|
| 費用面 |
|
|
どの案をとるか？は、予算やサービス構成次第でもあるので、もし冗長構成をどのようにすればよいかお困りの方はお気軽に相談してほしい。ご予算にあった案を提示させていただく。
それでも強いクラウドサービス
話は変わるが、稀に、
という極論に走る人がいるが、それはまたナンセンスだ。
冗長構成といっても、今回の様なデータセンター内の物理障害なら、同一拠点に集約した冗長構成でも防ぎようがない。
上記で述べた通り、AWSの様に世界各地にデータセンターを持っているクラウドサービスだからこそ、より強固な冗長構成が可能なのだ。
障害と戦うのはバックエンドに強いエンジニア
今回の、AWS障害で改めて認識したのは、
バックエンドエンジニアはこのような障害時こそ力を発揮する！
ということだ。
IaaSの障害は、バックエンドエンジニアでも何かすぐにできることはないのだが、それでも障害範囲の切り分けや復旧準備などできることは数多い。そして、今回の様な障害復旧は、ルーティンになっていないレアケースであるほどAIで自動復旧することは難しい。
逆に、バックエンドに強いエンジニアがいないと、このようなレア障害が起きた場合に、問題の切り分けどころか迅速な復旧プランを考えることすらおぼつかなくなる。
マナブ氏には申し訳ないが、この話ばかりは誤りであると強く主張させていただく。
経営者やマーケターサイドからしても、ライバルがサービスダウンしている最中に自分のサービスが使える状態ならば、それだけで差別化を図ることができる。特に今回の様な障害はレアだからこそ印象に残りやすい。
もし、自社やパートナーにバックエンドに強いエンジニアがいない場合、早急に育成もしくは発掘することをおすすめする。
また、そのようなリソースがない方向けに、私の会社ではリモートSEサービスを提供しているのでこちらも参考していただければ幸いである。
AWS環境構築支援、ITインフラサポート