2019年8月23日発生のAWS障害の概要と原因【現役エンジニアが解説】

PROGRAM

2019年8月23日16時40分現在、AWSの東京リージョンにおいて、ネットワーク系の障害が発生しており、EC2やRDSのサービスを使用することができない状況が続いています。

※2019年8月23日21時00分現在では、両サービスとも徐々に復旧しています。

以下、今回の障害の詳細を解説しています。

障害の概要

障害の概要

2019年8月23日(金) 12時50分頃より、
AWSのEC2やRDSの一部のサービスを使用することができなくなり、
アクセス不能になったため、多くのWebサービスやゲームなどに接続できない状況が続いています。

実際に、メイプルストーリーやFGOなどのゲーム、PayPayなどのWebサービスが利用できない大規模な障害が発生しています。

私自身のAWS環境でも確かに、2019年8月23日12時52分頃から接続できなくなったことを確認しています。

ただし、東京リージョンの全てのサーバーではなく、一部のサーバーに限定されるようです。
私はap-northeast-1aのアベイラビリティゾーンを使用しているのですが、
その中のデータベースのあるEC2インスタンスにだけ接続ができなくなっており、
その他のWebサーバー等には普通に接続ができているという状況になっています。

AWS Service Health Dashboard

AWS公式のAWS Service Health Dashboardによれば、
2019年8月23日14時27分頃、AWS側で原因の特定ができ、復旧に向けて作業中との告知がありましたが、
2019年8月23日16時40分現在では、いまだ復旧されずに、原因の詳細すら発表されていません。

追記
2019年8月23日17時20分現在では、私のAWS環境のEC2インスタンスの通信が復旧したことを確認しました。
どうやらネットワーク通信状態の問題というのは本当のようで、ログを確認したところインスタンス自体はずっと問題なく動いていたようです。

ここで参考までに、ネットワーク障害の種類を解説しておきます。
主に以下の3つに分けられると思います。

ネットワークハードの障害

これはハード、すなわち機器自体が故障したことによる障害のことです。
例えば、回路がいかれてしまったとか機器が物理的に破損してしまったという場合です。
こういう場合は機器を交換したり、代替のものを用意しないといけないので、在庫がない場合はどうしても復旧までに時間がかかってしまいます。

悪意のある者がネットワークを攻撃し続ける、いわゆるDDos攻撃があると、負荷に耐えられずハードが死んでしまう場合がありますが、今回もその可能性は十分に考えられます。

ネットワークソフトの障害

これはハードは無事なものの、プログラムのバグやメモリオーバーなどで発生する障害を指します。
このタイプの障害も多いと思います。複雑な処理を行うのはソフトウェアだからです。
ハードが故障しないように制御するのもソフトの役割なため、ソフトの制御により発生した障害は、実はハードの障害を未然に防いでくれていたりもします。
とはいっても利用者的には溜まったものではありませんが・・・

ネットワーク設定変更による障害

これは人が誤って設定を変えてしまった場合などに発生する障害を指します。
例えば、直前に正しい設定に書き換えたつもりが実は間違っていたなどの場合です。
これも意外と多いと思います。実際に人間が作業するとミスって結構発生しますよね。
AWSまで規模が大きくなると通常時はほぼ安定して動作しているはずなので、何か特別なことをしない限りは障害が発生することはないので、今回もこの可能性は高いかもしれません。

【予想】障害の原因

【予想】障害の原因

AWS公式のAWS Service Health Dashboardでは、
2019年8月23日16時40分現在では、まだ原因の詳細は公表されていません。
セキュリティ上の問題もあるので、このまま原因は公表されない可能性もあります。

これはあくまで現役エンジニアとしての予想ですが、おそらく障害の原因は、
ネットワーク機器(ルーターやロードバランサー等のハード)の不良や故障だと思います。
それがDDos攻撃によるものか、経年劣化によるものなのかまではわかりません。

この記事を読まれている方の中には、本当はネットワークの問題ではなくて、ひょっとしたらデータも壊れているかもしれないと心配される方もいるかと思いますので、
そうではない理由を以下に挙げておきます。

告知のDetailsがNetwork Connectivity

AWS公式のAWS Service Health Dashboardを確認すると、
今回の障害のDetails欄にNetwork Connectivityと書いてあることがわかります。

これを単純に受け取れば、すなわち、インスタンス(サーバー)自体ではなく、ネットワークの方が原因なことがわかります。
つまり、インスタンスそのものやその中身は無事ということです。

インスタンスの状態がrunning

AWSコンソール
AWSコンソールで障害が発生しているインスタンスを確認すると、状態がstoppedになっていないので、
インスタンス自体は生きているということになります。

もしインスタンスそのものが落ちてしまっていたら、問題はインスタンスだけになりますから、
コンソール上の表示はstoppedの状態になるはずです。

被害ユーザーが多すぎる

Twitterで通信障害で検索をかけると、たくさんの企業が障害やメンテナンスの告知を出しており、被害を受けていることがわかります。
それだけの企業のAWS上の仮想マシンが一気に死んでしまうというのは考えられません。

全ての物理サーバーがたまたま全部落ちることは確率から言って考えづらいからです。
(仮想マシンとはいえ、そんなに何台分も物理的に一つのサーバーに載せられません。)

つまり、今回の障害は、AWSの仮想マシンにアクセスするための橋が落とされただけの状態で、インスタンスは無事と見受けられます。

追記
AWS公式のAWS Service Health Dashboardによれば、
2019年8月23日20時18分、一部の冗長化された空調設備の管理システム障害でマシンのオーバーヒートが発生したことが原因だと発表されました。
つまり、ソフトの制御の障害がハードの障害を引き起こしたと言えます。今回はハードとソフトの複合障害であったことがわかります。

障害の復旧

障害の復旧

2019年8月23日21時00分現在においては、多くのEC2やRDSインスタンスにおいて復旧が確認できています。
私のAWS環境でも既に復旧が完了しており、よく利用するネットゲームやWebサービスにおいても復旧が確認できています。

復旧に時間がかかる理由に関しては、主に以下が挙げられます。

トラフィック量が多い

なぜ原因の特定から復旧にこれほどまでに時間がかかっているかというと、
それは、復旧後みながまた一気に接続してしまうと、ネットワークやサーバーが負荷に耐えられずに死んでしまうからです。

例えば、2011年に大きな地震があったときのことを思い出して下さい。
あの地震の直後、みなが一斉に帰ろうとして道路に車がたくさん集まり、交通が麻痺してしまいましたよね?
同じようなことがネットワークの世界でも言えるのです。
復旧直後、みな「待ってました!」と言わんばかりに接続をしようと思うので、全体的に一気に復旧するのは大変危険なことなのです。
そのためAWS側としては、徐々に復旧させていくやり方を取らざるを得ないものと思われます。

交換機器の手配に時間がかかる

私は、今回の障害はネットワーク機器等のハードの不良や故障が原因と考えています。
もしこれが本当であれば、交換機器や代替機器を手配しないといけません。
在庫があればすぐに交換できますが、なければ取り寄せないといけません。

Amazonさんならお急ぎ便でなんとかできそうではありますが(苦笑)
ハードがどのくらい壊れたかにもよりそうです。

エンジニアの招集に時間がかかる

通常、サーバー監視や保守部隊というのは常駐で24時間365日いるものですが、
機器の不良や故障、不具合が生じた際に、それを復旧できるエンジニアはどうしても数が限られます。
そのため、対応できるエンジニアを事後に集める必要があります。それに時間がかかっているという可能性もあります。
もしアメリカ本部と連携しなければならないとすれば、障害発生時は向こうは夜中ですのでさらに対応が遅れることになります。

まとめ:障害の復旧には時間がかかるので事前対策が大事

もしまだ復旧されていない方がいらっしゃいましたら、もう少しだけ待ってみましょう。
AWSはクラウドサービスの中では最もよく利用されているサービスといっても過言ではありません。
数が多ければ当然障害もそれ相応に発生しますので、今後は障害発生時の対応を事前によく考えておくことを強くお勧めします。