検索
ニュース

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

思わぬ大障害に発展し、復旧に時間を要したAWS東京リージョン。その回避方法はあったのか。これからの対応の指針とすべく、AWSの最上位パートナー認定を取得している企業に話を聞いた。

Share
Tweet
LINE
Hatena

 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なども影響を受けた。今回の障害では復旧までに時間がかかったこともあり、決済サービスやオンラインゲームなど多くのサービスが動かない状況に陥った。

photo
AWSからの説明

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

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

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

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

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

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

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

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

photo
サーバーワークス 佐藤豊課長
       | 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る