AWS障害、“マルチAZ”なら大丈夫だったのか？　インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」（1/3 ページ）

公開 2019年08月28日 19時04分

更新 2019年08月29日 14時58分

著者

井上輝一

[ITmedia]

印刷する Googleで優先するソースとして追加

　8月23日に起きたクラウドサービス「AWS」（Amazon Web Services）の東京リージョンでの障害は、国内のさまざまなサービスに影響を及ぼした。

　AWSが同日午後8時ごろに復旧するまで、モバイル決済サービス「PayPay」や、仮想通貨取引所「Zaif」、オンラインゲーム「アズールレーン」などで利用できない、もしくは利用しづらい状況が続いた。PCショップの「ドスパラ」はECサイトの不具合が長引き、翌日の24日には実店舗を臨時休業して対応に当たっていた。

　AWSという1つのサービス障害が起きただけで、多くの企業やサービスに影響を及ぼしたため、「クラウドサービスはもろい」という論調も散見された。

リージョンとアベイラビリティーゾーンの関係（AWS社の説明より引用）

　しかし、インフラエンジニアたちからは違う意見が聞こえてくる。なぜなら、問題が起きたのはAWSの中でも「データセンター（アベイラビリティーゾーン、AZ）1カ所のうちの、一部の仮想マシン」だったからだ。AWSの東京リージョンを構成するAZは4つあり（うち1つは通常利用できない設定）、それぞれ地理的に離れている。つまり、AWSの東京リージョン全体が利用不能になったのではなく、障害が出たのは一部にすぎないということだ。

　一部のエンジニアからは、「複数のAZを利用してサービスを冗長化する『マルチAZ』構成だったら、サービスは継続できたのではないか」という声もあった。その一方で、「マルチAZでも障害対応に時間がかかった／AWS自体の復旧まで待たなければならなかった」という話も聞こえてきた。

　AWSの障害に、各社はどのように対応したのか。ITmedia NEWS編集部では問題に直面した企業やエンジニアに聞き取り調査を行い、4例の回答を得た。どんな構成でどんな問題が起きたのか、実情が見えてきた。

前提　何にどんな問題が起きていたのか

　今回のAWS障害について、状況を整理しておこう。まず、提供元のAWS社は世界中の22カ所にサービス拠点となる「リージョン」を持っている。東京リージョンには「アベイラビリティーゾーン」（AZ）と呼ばれるデータセンターが4カ所ある。ただし、うち1カ所には利用制限があるため、ユーザーは通常、東京リージョンの中で最大3カ所のAZを利用してサービスを構成できる。

AWSのグローバルインフラストラクチャマップ（2019年8月時点）

　ユーザーはAZを指定して（もしくは指定をAWSに任せて）、仮想マシンであるEC2インスタンスや、ストレージのEBSボリューム、データベースのRDSなどをそのAZ上で動作させることができる。

AWSでEC2インスタンスを設定する際、どのAZを利用するか初めに決められる　このアカウントの場合、ap-northeast-1aがAZ ID「apne-az4」に当たる

　AWSの障害は、「apne1-az4」（以下az4と表記）というIDのAZで発生した。AWS社の説明では、制御系の異常で冷却システムがうまく動作せず、サーバが過熱し、障害に陥ったのだという。AWS社は、これによりEC2インスタンスとEBSボリューム、RDSに影響が出たと公表しているが、エンジニアの方々に聞くと他のAWSサービスでもエラーが出ていたことから、過熱したサーバに割り当てられていた複数のサービスに影響があったと考えられる。

　あるAZで問題が起きた場合でもサービスを継続できるよう、AWS社は同リージョン内の複数のAZを用いた冗長化構成（マルチAZ）を推奨している。

ロードバランサー障害、2AZでは切り離せず

　しかし、あるIT系会社の情報システム部のエンジニアA氏は「マルチAZだったが障害対応が難しい状況だった」と話す。

次ページへロードバランサーの設定に落とし穴

印刷する

SpecialPR

この記事の著者

井上輝一

2016年3月からITmediaにジョイン。ITmedia Mobile、PC USER、LifeStyle、ヘルスケアで編集・執筆を兼務。2017年4月からITmedia NEWSでの兼務も開始。2019年4月にNEWS専属となる。スマートフォンやPCといったガジェット系の他、理系（神経科学）のバックグラウンドを生かして科学系のネタや、量子コンピュータ、ブロックチェーン、AIなど多岐に渡って取材している。