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

　A氏の会社のAWS環境は2つのAZによる冗長構成で、「一部のEC2インスタンスがaz4にあり影響を受けたが、インスタンスを一度止め、再開することで復活した。おそらく、az4の中でも生きているサーバへ割り当てられたのだろう」という。

　しかし、問題は別の箇所だった。トラフィックを複数のインスタンスへ自動的に分散させる「ロードバランサー」（ELB）でも障害が起き、外部からサービスにアクセスしようとすると500エラーなどを返し、正常に読み込めない状況だった。

　トラフィックの分散という特性から、ELBの設定には最低でも2つのAZを指定しなくてはいけない。しかし、A氏の環境は2AZ構成だったことから、障害のあるELBを切り離そうとしてもできない状況だったという。

　振り返ると、東京リージョンに4つ目のAZが追加され、3AZ構成を組めるようになったのは2018年1月のことだった。A氏の環境はそれ以前に構築していたことから、「社内ネットワークアドレスの割り振りや仮想ネットワーク（VPC）を2AZで設計しており、変更には手間が掛かることと、片方のAZに障害があってももう片方で対応できると考えていたことから、2AZ運用のままだった」と明かす。

　障害対応として3つ目のAZを新たに利用することも検討したが、「その頃にはAWS社から原因を特定したという発表があったため、復旧を待った方がいいと判断した」という。

ファイアウォール無効化で復旧したという報告も

　類似する事例として、AWSのコンサルティングなどを手掛けるクラスメソッドは自社メディアで、「ELBで利用していたファイアウォール（WAF）の保護設定を一時的に解除することで、ELBの5XX系エラーを抑制できた」と報告していた。

　聞き取り調査に応じたエンジニアのB氏も、同様に「WAFの一時無効で障害を回復できた」と話した。

FGOは「そもそも障害対象ではなかった」

　AWSの障害で「さまざまな国内のオンラインゲームがサービスを停止した」と伝えられる中、AWSを利用しながらサービスを継続できていたオンラインゲームの一つに「Fate/Grand Order」（FGO）がある。

（関連記事：「Fate/Grand Order」ユーザー爆増の裏側で、エンジニアが挑んだデータベースとの戦い ）

　FGOを開発・運営するディライトワークスに障害対応について聞いたところ、「FGOで利用しているAWSのリージョン自体は公表していない」と断った上で、「FGOで利用しているAZは障害の対象ではなかった」と明かした。

外部サービスによりEC2を短時間で自動復旧できた例

　「az4の障害により一時的にサービスが止まったが、9分で復旧できた」と明かすのは、広告配信などを手掛けるVOYAGE GROUPの大谷和紀チーフデベロッパーだ。

　同社の子会社が管理する広告配信サーバは2AZでEC2インスタンスを稼働させる体制で、片方のAZが問題のaz4だった。「一瞬のサービス停止はあったが、『Spotinst』というクラウド管理サービスを導入していたおかげで比較的短時間で復旧できたようだ」（大谷チーフ）という。

　Spotinstは、クラウドの運用コストを削減しながら可用性（システムの継続稼働能力）の低いインスタンスを自動リプレースなどすることで、クラウド運用を最適化する外部サービス。

　「はっきりとは分からないが、ログを見る限りでは障害に対してSpotinstがある程度うまく動作したようだ」（大谷チーフ）

復旧に時間がかかったインスタンスも　明暗分けた「コンテナ化」

　広告配信サーバについては難を逃れたが、「バックエンドでデータを集計し、配信サーバへ設定を反映するバッチ処理サーバの復旧には3時間ほどかかった」と大谷チーフは振り返る。「障害があったAZにインスタンスを固定していて、設計自体も古かった」と問題点を話す。バッチ処理系は実行環境を仮想化環境である「コンテナ」にまとめていなかったため、障害時の緊急対応に時間を要したという。

この記事の著者

関連記事

• 

  AWS障害、大部分の復旧完了　原因は「サーバの過熱」

• 

  AWS、東京リージョンで障害　段階的に復旧　「PayPay」「Zaif」など影響受ける【追記あり】

• 

  AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず

• 

  「Fate/Grand Order」ユーザー爆増の裏側で、エンジニアが挑んだデータベースとの戦い