AWS運用をラクにするなら！東京リージョン障害から学ぶ障害対策

どうも、クラウドエンジニアの大田と申します。

昨年2019年8月23日にAWSの東京リージョン障害が起きて久しいですね。

大規模障害の発生から約1年が過ぎた現在、既に過去の出来事として記憶が薄れてしまっている方も多いのではないでしょうか。一方、当時の障害の当事者だった皆さんは眠れない夜の記憶が蘇るのではないでしょうか（震

一部の方々においては、多大なサービス・システム影響が発生したこともあり、監視・障害対応やサポート対応に追われた日だったかと思います。

今回は、そんな東京リージョン障害から得たAWS運用における気付きや学びを共有できればと思います。

AWS東京リージョン障害とは？

AWSからの公式発表 ^[※1] では下記の通り記載されています。

日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一定の割合の EC2 サーバの停止が発生しました。この結果、当該アベイラビリティゾーンの EC2 インスタンスへの影響及び EBS ボリュームのパフォーマンスの劣化が発生しました。このオーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因です。日本時間 15:21 に冷却装置は復旧し、室温が通常状態に戻り始めました。室温が通常状態に戻ったことで、影響を受けたインスタンスの電源が回復しました。日本時間 18:30 までに影響を受けた EC2 インスタンスと EBS ボリュームの大部分は回復しました。少数の EC2 インスタンスと EBS ボリュームは、電源の喪失と過大な熱量の影響を受けたハードウェアホスト上で動作していました。これらのインスタンスとボリュームの復旧には時間がかかり、一部につきましては基盤のハードウェアの障害によりリタイアが必要でした。

（中略）

今回の事象はデータセンターで使用されるいくつかの冷却システムの制御と最適化に使用されるデータセンター制御システムの障害によって引き起こされました。

（中略）

この度の事象発生時、異なるアベイラビリティゾーンの EC2 インスタンスや EBS ボリュームへの影響はございませんでした。複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。

東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要

読むのがめんどくさい方のために3行で要約すると、

• AWS側の空調設備管理システム（冷却システム）の障害が原因
• 特定のAZ（アベイラビイリティゾーン）のみで発生し、他AZへの影響はなし
• 主に影響のあったサービスは「EC2」「EBS」（他は「RDS」「Redshift」「ElastiCache」「Workspaces」等、一部お客様では「ALB」や「AWS WAF」も影響を受けた）

といった状況でした。

AWS運用（発生事象編）：東京リージョン障害で実際に何が起きたのか

では、当時どのような事象や影響が発生していたのかが気になりますよね。
本ブログでは、実際に起きていた障害の一例をご紹介します。

発生期間

2019年8月23日（金） 12:50頃 から 20:36頃

障害が発生したAZ

東京リージョン (AP-NORTHEAST-1) 内の、1つのアベイラビリティゾーン(AZ ID: apne1-az4)

障害事例

以下いずれかのリソース障害が発生。

• EC2のステータスチェックが0/2となる（使用不能）
• EC2の起動状態が pending から遷移しない（Force Stopも効かない場合もある）
• シングルAZのRDSが使用出来ない、またはマルチAZのRDSでフェイルオーバーが発生する
• EBSのパフォーマンス低下
• 一部EBSボリュームの故障
• オートリカバリを含む、再起動（STOP&START）後も、接続できない
• 停止もしくは起動に時間がかかる（起動に失敗する場合もある）
• EC2〜RDS間のゾンビコネクションが発生
  └CPU負荷のスパイク
  └DBコネクションの急増
  └プログラム側の問題によって、disconnectされていない　等
• ALB（Application Load Balancer）の 500 Internal Server Error 頻発
  AWS WAF（Web Application Firewall）やスティッキーセッションと組み合わせ利用の場合

補足

AZ ID: apne1-az4 以外のアベイラビイリティゾーン内のリソース影響はなし

※後日、AWSからは AZ ID: apne1-az4 以外の異なるアベイラビリティゾーンに所属するEC2インスタンスやEBSボリュームへの影響は無かったと公表あり

実際に、複数のアベイラビリティゾーンでアプリケーションやシステムを稼働させていたお客様は、大規模障害発生中も可用性への影響が少ない状態でした。そのため、冗長化の一環として、マルチAZ構成も検討の余地があるかと思います。

なお、アーキテクチャについては後述しますので、一旦割愛します。

AWS運用（実対応編）：東京リージョン障害で実際にどう対処したのか

発生した障害に対して、当時、弊社がどのように対処したのか、AWS側の動きとともにざっくり流れをご紹介しておきます。

12:50 頃　─

• 複数のお客様環境において障害を連続検知
• 順次、個別対応および原因究明を開始

EC2  13:18　RDS  14:22　─

• 各リソースの障害に関する初報がAWSより発表

EC2  14:27　RDS  15:25　─

• AWSにて根本原因の特定がされたと発表
• 弊社では、引き続き復旧対応
  EC2のSTOP&STARTを行うも、一部インスタンスにおいて、停止中（stopping）もしくは起動中（pending）の状態が続くケースを確認

EC2  15:40　RDS  16:01　─

• 復旧が開始されたアナウンスがAWSより発表

EC2  18:39　RDS  20:46　─

• 大部分の復旧がAWSよりアナウンスされる
• 弊社のほとんどのお客様においても復旧を確認

発生直後は弊社の障害検知システムやAWSのService Health Dashboardなどを確認し、発生している事象の整理を実施していました。また、営業部のメンバーと連携しながらお問い合わせのあったお客様への個別対応を進めつつ、検知したアラートの全量把握や全インスタンスの状態確認、AWSサポートへの問い合わせ、弊社 cloud link サービスのシステム「Simple Dashboard」への初報掲載等を行っていました。

AWS運用（未来編）：今後の運用を東京リージョン障害から考える

障害にどこまで備えるか、というのはITビジネスを運営する上での至上命題と言えます。サービスやシステムの可用性をどこまで高めるか、と言い換えることもできるでしょう。

東京リージョン障害のような大規模障害でなくても、EC2やEBSに障害が発生したり、故障したりする可能性は十分に考慮しておくべきです。また、RDSのようなマネージドサービスであったとしても、100％絶対に壊れない保証があるわけではありません。

そこで、AWS運用における障害対策の考え方を各種お伝えしていきます。

Design for Failure

• 単一障害点 (SPOF) をなくす ^[※2]
• すべてが失敗し得るという前提で考える
  • 仮に物理的なハードウェアが故障したり、削除したりリプレースされてもアプリケーションが機能し続けることがゴール
  • 個々のコンポーネントが失敗してもアプリケーション全体の停止を招かないようにする

RTO（目標復旧時間）の向上

• 障害時に自動復旧する設定や再起動やリストアでサービスが復旧するような作りにする ^[※3]
• ステートレス(サーバに固有の情報を極力持たせない) ^[※4]

DR（ディザスタリカバリ）におけるAWSの強み ^[※6]

• 地理的分散が容易
• 求めるDR対策のレベルに応じた選択肢が豊富
• 低コストから始められる

Multi-AZ構成の推奨

AWS公式ではマルチAZ構成を推奨しております。

アプリケーションで最大の可用性を必要とされるお客様には、この複数アベイラビリティゾーンのアーキテクチャに則ってアプリケーションを稼働させることを引き続き推奨します（お客様にとって高可用性に課題を生じ得る全てのアプリケーションのコンポーネントは、この耐障害性を実現する方法の下で稼働させることを強く推奨します）。

東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要

今回は特定のAZ（AZ ID: apne1-az4）において発生した障害のため、冗長化構成をとることで単一AZでの障害によるサービス・システム停止の回避が期待できます。より高い可用性が求められる場合には、3AZ構成への設計変更もご検討ください。

なお、AZ変更には詳細な設計が必要になりますので、ご希望の場合はご相談くださいませ。


アプリ設計を見直す

以上のような考え方に加え、アプリケーションの設計を本格的に見直すことも検討されるかと思います。その場合は記事最下部の「参考記事」のAWS上のアプリ設計の考え方 ^[※5] をご参照ください。

バックアップ戦略を見直す

EC2やEBSは物理サーバーや物理ディスクと同様にバックアップが必要です。弊社が提供するAWS管理用ダッシュボード「SimpleDashboard」等で、定期的なバックアップを取得可能です。

バックアップ計画の見直し、再検討を推奨いたします。

主要サービスの監視

お客様自身で管理・運用する必要があるEC2のほか、AWSのマネージドサービスに対する監視も有効と言えます。EC2やEBSだけではなく、ALBやRDSなどにも一部影響があったことを踏まえると、対象サービスの監視や障害時の連絡等を迅速に行うことで、影響を最小限にとどめられることが期待できます。

弊社では以上のような監視サービスも対応可能です。

情報収集

＜基本編＞

• AWSの「Service Health Dashboard」を確認する ^[※7]
  ※ご利用中の地域(Asia Pacific等)を選択し、ご参照ください
• 弊社 cloud link サービスのシステム「Simple Dashboard」を確認する
  • 「cloud linkからのお知らせ」欄
  • 各サーバーの「システム状態」および「インスタンス状態」が正常であることを確認
  • 弊社への緊急時のお問い合わせ
    （監視・運用サービスをご契約頂いていない請求代行のお客様は、AWSに直接お問い合わせいただく必要がございます）
• AWSマネジメントコンソールから「Personal Health Dashboard」を確認する ^[※8]
  （AWSアカウントやIAMユーザーをお持ちのお客様向け）

＜番外編＞

• Twitter
• Amazon Web Services 障害発生マップ ^[※9]

検知体制

• CloudWatchアラームの設定
  • Eメール
  • HTTP/HTTPSエンドポイント　等
• AWSとチャットツールの連携
  • AWS Chatbotを用いてSlackやChimeを連携させる

AWS運用をラクにするなら！東京リージョン障害から学ぶ障害対策（まとめ）

いかがでしたでしょうか。
AWS運用における障害時の設計は、

• どの程度の規模、頻度の障害に対し、
• どのようなリスクが想定されるのか
• 想定リスクに対し、何をどこまで対応するのか

といった基本的な考え方がベースになってきます。
リスクとコストを天秤にかける上で、AWSのSLA ^[※10] 等もご参考いただけるかと思います。

「障害対応体制を整える時間や予算がない…」「障害をできるだけ意識しないでAWS運用したい！」といった方には、弊社の「cloud link」サービスをオススメしております。

AWS運用最適化サービス cloud link (クラウドリンク)
https://aws.taf-jp.com/cms/

「cloud link」では、AWS運用のみならず、AWS導入支援、保守、請求代行など様々なサービスをご提供しております。下記のキーワードにピンと来た方はぜひ弊社までお問い合わせくださいませ。

• 24時間365日のAWS運用・監視（障害対応含む）
• サーバーの自動バックアップ
• サーバーの自動起動、終了設定
• 初期費用0円
• 最短1営業日からお渡し
• AWS操作代行
• 請求代行（円決済の代行）　など

AWSインフラに関する設定や障害時対応を含む運用管理を気にせず、OS内設定やアプリケーション開発、運用に集中いただける環境をご提供いたします（お客様のご要望に応じて、AWSインフラに関する必要な操作権限をお渡し、お客様自身で運用いただくことも可能です）。

参考記事

[※1] 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要：
https://aws.amazon.com/jp/message/56489/

[※2] SlideShare | AWSでアプリ開発するなら 知っておくべきこと（SPOFをなくす：19〜21ページ）：
https://www.slideshare.net/keisuke69/aws-73040279#19

[※3] Amazon EC2 Auto Recovery｜インスタンスの復旧：
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-recover.html

[※4] AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス-（12〜23ページ）：
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2016#12

[※5] SlideShare | AWSでアプリ開発するなら 知っておくべきこと：
https://www.slideshare.net/keisuke69/aws-73040279

[※6] AWS Black Belt Online Seminar AWSで実現するDisaster Recovery：
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-awsdisaster-recovery
・AWSのDRの考え方と構成例（DRにおけるAWSの強み：11,15ページ）
・本格的なDRの検討事項例（DRの検討事項：19〜21ページ）
※コストとのトレードオフで複数のシナリオが存在します

[※7] Service Health Dashboard（SHD）：
https://status.aws.amazon.com/

[※8] Personal Health Dashboard（PHD）：
https://phd.aws.amazon.com/phd/home?region=ap-northeast-1#/dashboard/open-issues

[※9] Amazon Web Services 障害発生マップ：
https://downdetector.jp/shougai/aws-amazon-web-services/mappu/

[※10] Amazon Compute サービスレベルアグリーメント：
https://aws.amazon.com/jp/compute/sla/