この記事の目次
AWSで発生する大規模障害
Amazon.comが提供するクラウドサービス「Amazon Web Services（AWS）」では毎年どこかのリージョンで大規模障害が発生しています。
東京リージョンも例外ではなく、2020年10月22日に東京リージョンで大規模障害が発生しています。この大規模障害によりAWSのEC2を利用するPayPayアプリなどの一部ネットサービスが利用できない事態が発生しました。
AWSでシステムやサービスを構築・提供する場合、AWSで障害が発生することを前提に考え、システムが安定的に稼働できるように対策することが重要です。
そこで、過去に発生した大規模障害の事例と障害への対策のポイントについて紹介します。AWSでシステムやサービスを構築・提供する際に参考にしてください。
大規模障害の事例
実際AWSでどのような障害が起きているか、概要や原因を交えて、直近のAWSで発生した大規模障害を紹介します。
2020年11月25日米国東部リージョンの一部での大規模障害
米国時間2020年11月25日に米国東部（バージニア北部、US-EAST-1）リージョンで発生した大規模障害が発生しました。 概要と原因を解説します。概要
米国時間2020年11月25日に米国東部（バージニア北部、US-EAST-1）リージョンでAWSが提供する分析サービス「Amazon Kinesis」で大規模障害が発生しました。 Kinesisはストリーミングデータに対してリアルタイムで収集・処理・分析を行うサービスです。Netflixなどの多くの企業に利用されていますが、Amazon CloudWatchといったAWSが提供するサービスでも利用されています。 この大規模障害により数時間もの間、Kinesisを利用する多くのサードパーティーのオンラインサービスは影響を受けました。原因
大規模障害の原因はKinesisのフロントエンドフリートへの容量追加をきっかけにして、OSのスレッド数がOSの設定で許容しているスレッド数を超過したことでした。 2020年11月25日午前2時44分（太平洋標準時）から約1時間かけてKinesisのフロントエンドフリートへの容量の追加作業をしました。その後、Kinesisのフロントエンドフリートの全サーバーで、スレッド数がOSの設定で許容しているスレッド数を超過したのです。2020年10月22日東京リージョンの大規模障害
日本時間2020年10月22日に東京（AP-NORTHEAST-1）リージョンで発生した大規模障害が起きました。 概要と原因を解説します。概要
日本時間2020年10月22日の大規模障害では２種類の障害が報告されました。 1つ目が日本時間 11:42から11:53の間、東京（AP-NORTHEAST-1）リージョンのAZ（APNE1-AZ2）にて一部のEC2でネットワーク障害が発生したというものです。2つ目は日本時間11:42から13:09の間、AZ（APNE1-AZ2）の一部のEBSでパフォーマンスが低下したというものです。 この大規模障害により、AWSを利用するPayPayアプリなどの一部ネットサービスが一時的に利用できないという影響が発生しました。原因
大規模障害の原因は東京（AP-NORTHEAST-1）リージョンのAZ（APNE1-AZ2）で一部のEC2にネットワーク接続性の問題があったことでした。ネットワーク接続性の問題に関する詳細についてはAWSから報告されていません。2019年8月23日東京リージョンの大規模障害
日本時間2019年8月23日に東京（AP-NORTHEAST-1）リージョンで発生した大規模障害について紹介します。 概要と原因を説明します。概要
日本時間2019年8月23日12時36分より東京（AP-NORTHEAST-1）リージョンの１つのアベイラビリティゾーン（AZ）で大規模障害が発生しました。 障害が発生したAZ内のEC2やEBSのパフォーマンス劣化だけではなく、RDSなどの他のサービスにも影響が報告されています。他にも個別のいくつかのケースで、複数のAZで稼働している利用者のシステムで予期せぬ影響があったことを確認しています。 障害の影響を受けたEC2とEBSの大部分は日本時間2019年18:30までに復旧しました。しかし、復旧するまでの数時間の間、UNIQLOオンラインストアなどの「障害が発生したAZ内のEC2を利用するサービス」が停止する事態となり、大規模な影響を与えました。原因
大規模障害の原因はデータセンターの一部エリアで温度が上昇し、そのエリア内のEC2サーバーの停止が発生したことでした。AWSは温度上昇の原因を空調設備の管理システム障害と発表しています。AWSの障害への対策
障害対策では「システムが継続して稼働できる設計」と「迅速で正確な障害状況の把握」が重要です。
ここでは障害への対策のポイントについて紹介します。障害対策を考える際の参考にしてください。
リソースを分散する設計
AWSの障害の対策ではリソースを１つのリージョンにのみ置くのではなく、マルチリージョンあるいはマルチAZを利用して、分散するように設計することが重要です。 マルチリージョンあるいはマルチAZを利用して、リソースを分散しておくことで、ある１つのリージョンで障害が発生した場合に、他のリージョンでシステムを継続できる可能性が高くなります。障害の情報収集
AWSの障害対策として障害が発生した際に迅速に障害情報を収集することも重要です。 次はAWSからの障害情報を取得する方法を紹介します。AWSコンソールのDashboard
AWSコンソールにログインして、右上の「アラート」欄より障害のアラートが出ているか、確認することが可能です。また、Dashboardを表示すると「Open issue」欄に発生中の障害が表示されます。AWS Service Health Dashboard
AWS Service Health DashboardではAWSの各サービスの稼働状況が掲載されています。 各サービスごとにRSSフィードが用意されているので、利用サービスのRSSフィードをRSSリーダーに登録すると、利用サービスの掲載内容に更新があった際にすぐ通知を受け取ることが可能です。監視体制の構築
障害に迅速に対応するには、システム異常を直ちに検知する監視体制の構築が求められます。 AWSリソースをモニタリングする「Amazon CloudWatch」を利用すると、AWSのリソースやサービスなどのモニタリングデータや運用データをグラフ化して確認できます。また、CloudWatchで異常を検知した場合、メールでアラームを飛ばすなどの監視体制を構築することが可能です。復旧体制の確立
AWSでシステムを構築する場合は、障害発生後もシステムの稼働を継続できるようにインフラ設計を行うことが必要です。 AWSでは大半の故障を自動的（あるいは、ほぼ自動的）に修正し、正常なサービスに戻すような仕組みを提供しています。例えば、EC2のインスタンスが故障した場合、CloudWatchを利用することで故障を自動的に修正し、正常なサービスを割りふることも可能です。 AWSではこのようなAWSの機能を利用して、障害発生後もシステムの稼働を継続できるように設計することを推奨しています。まとめ
今回は大規模障害の事例と障害への対策のポイントについて紹介しました。
AWSでは毎年どこかのリージョンで大規模障害が発生していると聞くと、システムを安定的に稼働するのが難しいように感じられます。しかし、どのように素晴らしいシステムでも必ず障害が発生するリスクを抱えています。
平常時から障害への対策を十二分に検討し、障害に備えることで、システムを安定的に稼働することが可能です。是非今回の記事を参考にして障害への対策を検討してみてください。]]>
