8/23にAWSで障害が起きました。
身近なサービスでの影響もあり、各種メディアやブログで話題となっていたことは記憶に新しいかと思います。
自分は、以下の記事の通り、AWSソリューションアーキテクトを取得はしたものの、その実、まったくAWSには触っていないクラウド初心者ですが、一通り話題が過ぎ去った感があるので、備忘的に、今回の障害をまとめておきたいと思います。
基本的には、色々な記事で拝見させていただいた内容をまとめただけなので、特に目新しい話はないかと思いますが、初心者なりの理解ということで書いていこうかと。
内容は大きく3つで整理します。
①何が起きた？
②何が問題？
③今後どうなる？
①何が起きた？
8/23 12:36頃、東京リージョンにある、単一のAZが利用不可となりました。
当初のAWSの報告では、障害の原因は冷却制御システムのバグとのことで、それにより、影響範囲は仮想マシンを提供するAmazon EC2とブロックストレージを提供するAmazon EBSのそれぞれ一部と公表していました。
ポイントは単一のAZのみの障害だということであり、そのためマルチAZ構成になっているシステムには影響はないというのがAWSの基本スタンスでした。
そのため、今回の障害での返金は、SLAに照らし合わせると基本ないようです。
・起きた事象が簡潔にまとまっています。
・当初のAWS公式報告がまとまっています。
・ちょっと難しくて理解しきれていませんが、「Single EC2 Instance」を除いて、単一のAZ障害では返金がないようです。
しかし、あまりに影響は大きすぎました。
以下の記事によると、200近いサービスに影響があった可能性があり、ざっと見てみるだけども名だたる有名企業のサービスが並んでいます。
・この記事の著者の方が、確認した範囲で影響発表されていた（非公式含む）サービスとのことで、同時期に報告されたものを集めたもので、全てがAWS障害が原因かどうかは不明であり、あくまで可能性ですが、そういったものを差し引いても影響の大きさが垣間見えます。
この影響範囲の広さや、実際の現場の声から、当初のAWSの公式見解であった「単一のAZ障害のため、マルチAZになっていれば可用性は担保される」という内容には、疑問の声が多かったように思います。
確かに個人的にも、ソリューションアーキテクトを取得した際に、散々マルチAZの話は出てきたので、これだけのサービスが、単一のAZ障害に耐えられないというのは、信じがたいと思っていました。
結果、AWSは8/28に、マルチAZ構成であっても影響が発生したことを公式に認め、説明を修正しました。
ALBの予期せぬ動きなど、当初から話題になっていた影響を認めた形かと思います。
ただ、その説明の歯切れは悪く、対応は個別という姿勢をAWS側は示しています。
これ以降、追加の公式の情報公開もなく、自分の観測範囲でも、特段目新しい話は出なかったように思います。
・8/28のAWSの公式発表がまとまっています。
②何がポイント？
では、今回の障害でのポイントはどこだったのでしょうか。
大きく2つあるかと思います。
ひとつは、「AWS側の対応」です。
AWSの当初の見解だった、単一のAZ障害であればマルチAZ構成であれば影響はないという立場が、今回の障害で完全にではないにせよ、崩れたのは大きいのではないでしょうか。
AWSとしても予期せぬ影響だったということだと思いますが、完全に後出しになってしまったのは、よろしくない対応だったと思います。
まぁそれは置いておいて、もっとよろしくないのは、それ以降の情報が公に公開されていないことでしょう。
後出しになってしまった点は、AWSとしても予想外だったのでしょうから、しょうがないと考えても、詳細の情報を隠すことには、メリットがないように思います。
個別対応するのではなく、今後の参考にするためにも、しっかりと情報公開してほしいところです。
ふたつ目は、「利用側の冗長構成の在り方」でしょう。
良くも悪くも、今回の障害で、各企業がクラウドの冗長構成の在り方に対して、改めて考える必要があることを示した形になったかと思います。
今まで冗長構成を取っていなかったために、今回の障害でそのリスクが実際の影響として発現した企業もあったのではないでしょうか。
または、冗長構成を取っていたとしても、それがちゃんと機能する形になっていないことが露見されたケースもあるのではないでしょうか。
各企業それぞれの、問題点がきっと見えたはずなので、そこに対してどう対応していくかが、ポイントになるでしょう。
③今後どうなる？
では、今後、この件はどうなるでしょうか。
ひとつ目の問題である「AWS側の対応」に対しては、AWSの動きを見守るしかないでしょう。もしかしたら、今後もう大きな動きはないかもしれません。
対して、ふたつ目の「利用側の冗長構成の在り方」については、各企業が色々な動きを見せるかもしれません。
今回の障害のケースでは、AZは3重構成にしていれば影響を防げたという話があるため、2重構成になっていた企業は見直す方向かもしれません。
もしくは、今回の障害を重く見て、マルチリージョンやマルチクラウドへ舵を切るということもあるかもしれません。
どういった構成が良いというのは、費用対効果を見るしかありません。
可用性を追い求めて、マルチクラウドにした結果、運用が煩雑になり、実際に障害が起きたらうまく運用できなかった、なんてことになったら笑い話にもなりません。
今回の障害で、クラウドは怖いからオンプレミスにしようなんてことがあれば、それもまた笑い話にならないぐらいの思考停止です。
誤解を恐れず書けば、「どこまで障害を許容できるか」「どれだけサービス停止を許容できるか」という点を、ゼロベースで考え直すところから、話を始めなければ、最適な構成を作ることは難しいでしょう。
"念のため"、"一応"、"不安だから"といった曖昧な言葉に逃げずに、冷静に慎重に丁寧に議論をしていくことが重要かと思います。
・AWSの障害は世界レベルで観ると、年1は何か起きているようです。
・日本では東京リージョンで3つのAZの冗長構成に出来るようになったのが2018年1月だったため、2つのAZ構成にしていたところが多かったようです。
・クラウドだろうがなんだろうが、障害は起きるので、そういった事実から目を背けずに、徹底的に考えることが重要だと思います。
今回の件を踏まえて、専門の企業がAWS障害回避のための対策をまとめたホワイトペーパーも出してくれています。かなりまとまっていると思うので、是非参考にしてみると良いと思います。
