米アマゾンウェブサービス（Amazon Web Services）のクラウドサービス「AWS」で8/23昼過ぎに大規模な障害が全国的に発生しました。
AWSは同日、発生した障害について、東京リージョンを構成する4つのアベイラビリティーゾーン（以下AZとする）のうちの1つで、仮想マシンサービス「EC2」とリレーショナルデータベース「RDS」で障害が発生したと発表しました。
しかもその原因は、冗長化冷却システムに障害が起きたことによるものだそうです。結果として、AZ内にいたEC2サーバが過熱状態となり、大規模障害に至りました。
個人でも法人でも、この影響を受けた人の数は計り知れなかったと思いますが、この影響を受けたものと、受けなかったものの違いがあったので、今回はそこを簡単にまとめておこうと思います。
障害が発生したのは4つのAZのうち1つだった
まず、知らない人のために補足しておくと、「AZ」とはAWSが持つ自社のデータセンターであり、AWSのクラウドサービスを利用するユーザは、そこのデータセンターの仮想環境を借りて、webサーバの構築などができます。
そして、今回障害が発生したのは、東京リージョンにあるAZの中の一つです。
マルチAZ（複数のAZでwebサーバやDBを構成すること）にすればいい
つまり残りの3つは無事だったわけですね。
例えば、データセンターAとデータセンターBを間借りしてwebサイトを作った場合、仮に一方のデータセンターAがお亡くなりになったとしても、データセンターBのほうが生き残っているため、webサイトじたいの運用は続けることができるわけです。
シングルAZのイメージ図
マルチAZのイメージ図
今回障害が発生して、特に影響を受けなかった個人や法人は、こういった対策を取っていたために、大規模障害の影響をほぼ受けずに済んだのではないかと思われます。
全部マルチにしとけばいい?
じゃぁデータセンター複数借りたマルチAZ構成にしたほうが得じゃん!というとそんな単純な話ではなく、借りているデータセンターが多いということはその分、間借りするためのレンタル費用は発生するわけです。
こういったことから、「あえて」マルチAZにしていない構成のものもあれば、コストインパクトが大きいため「必ず」マルチAZにして、障害発生時の対策を取る（これを耐障害性を上げるという）パターンも考えられます。
なので、一概に「全部マルチAZにしとけよ!」という簡単な話ではないということだけは理解しておいたほうがいいですね。
とはいえ、今回のAWS大規模障害は、多くのゲーム会社やECサイト運営会社に影響を与えたことに違いは無いため、この機会に自社や個人のシステム構築を見直す人が出てきそうですね。
【通信障害について】
— アズールレーン公式 (@azurlane_staff) August 23, 2019
13:10分頃に発生しました、クラウドサーバー側の通信障害について、一部障害の解消が確認されました。
現在は各サーバーの通信状況の点検を行っております。
ご迷惑をかけてしまい、誠に申し訳ございませんでした。
サーバー開放まで今しばらくお待ち下さい。#アズールレーン
以上、本日はオタクでありつつも一エンジニアである私の、今日発生した「AWS大規模障害」についてのまとめでした。
一応、AWSソリューションアーキテクト所持者なので、このあたりは自負を持っています。
今後も似たような問題が発生した場合は、考察やまとめなどを書いていこうと思います。
AWSソリューションアーキテクトを取得したときの記事はこちら。
