AWS障害、どうすれば回避できた？　冗長性はどこまで？　AWSのパートナー企業に聞く（1/2 ページ）

公開 2019年09月12日 19時17分

更新 2019年09月13日 10時45分

[ITmedia]

印刷する

　8月23日、Amazon Web Services（AWS）東京リージョンで大規模な障害が発生した。東京リージョンの1つのアベイラビリティゾーン（Single-AZ）で発生した障害で、Amazon EC2とAmazon EBSに影響があった。またAmazon EC2をベースにしてるであろうAmazon RDS、Amazon ALB、Amazon ElastiCache、Amazon Redshift、Amazon Workspacesなども影響を受けた。今回の障害では復旧までに時間がかかったこともあり、決済サービスやオンラインゲームなど多くのサービスが動かない状況に陥った。

AWSからの説明

　障害発生当初は「データセンターのラックの数本が死んだ程度で、直にリカバリーされて上がってくるのではとみていた」というのは、AWSの最上位パートナー認定を取得しているサーバーワークスの城航太課長（クラウドインテグレーション部技術四課）だ。実際にはなかなかリカバリーはされず、障害発生から30分後くらいにはかなり大規模な障害だと分かってきた。障害は終息に向かわず、徐々に拡大していた。まずは影響範囲の切り分けのため、詳細な監視を続けるしかなかったという。

サーバーワークス城航太課長

　どのようにすれば障害を回避できたのか、今回の障害を踏まえ、可用性向上のためにどれほどコストを割くべきか──サーバーワークスに聞いた。

Single-AZの障害では収まらなかった

　障害発生時、AWSからは、Single-AZ内で障害が起きているとのアナウンスはあった。とはいえ「1つのAZの障害とは分かったが、全てが落ちているわけではない。そのため対象のAZで複数サービスを使っている場合は、1つ1つ稼働状況を評価する必要があった」と城氏は振り返る。サーバーワークス事業戦略室の石田知也室長は「死んでいくものがだんだんと増えている状況では、どう対処するのが良いかの判断は難しい」という。

サーバーワークス石田知也室長

　Single-AZの障害だったはずが、複数のAZ（Multi-AZ）配置の構成をとっているところでも動きがおかしなものが出てきた。「AWSでは基本的にAZ内で障害が収まるようなアーキテクチャになっている。しかし1つのAZで大規模な障害が発生すれば、監視やメンテナンス用の通信が一気に増大し他のAZとの間でネットワーク障害の状態に発展することもある。そうなれば実際に動いているサービスも落ちているように見える。これはかなり厄介だ」（石田氏）。この状態では、対処しようとコマンドを投げても返ってこないこともある。実際にどれが落ちているのかが分かりづらく、どう対処すれば良いかの判断はさらに難しくなる。

　今回の障害ではMulti-AZ配置のものにも影響が出たが、サーバーワークスで運用管理を請け負っていた、Multi-AZ配置にして自動切り替えするようにしていたサービスのほとんどは、おおむね問題なく処理が継続された。「Multi-AZ配置になっていれば、起動できないあるいはリソースが足りない状況は避けられた」と、サーバーワークスの佐藤豊課長（クラウドインテグレーション部技術五課）はいう。とはいえ、Multi-AZ配置にしていても、アプリケーションの中で障害が発生したAZのサービスを参照していれば、手動で参照先を変更するなどが必要だ。