COLUMN

【AWSの障害対策】5つの事例から起きうる障害を学び対策を考える

どのようなシステムであっても必ず障害発生の可能性はあります。AWSも例外ではありません。日本でも、2019年8月23日に東京リージョンで大規模障害が発生し、広範囲に影響を及ぼしました。今回は、万が一に直面する前に、AWSで起きうる障害にはどのような種類があるのか整理し、また過去に起きた大規模障害の実例に学ぶことにより、障害対策として平常時から準備しておいたほうがよい点について考えます。

AWSのSLA

クラウドサービスは、特段の断りが無い限り、一般的に継続的なサービス提供を前提としているものが多く、AWSにもサービス稼働率や返金などについて規定しているSLA（Service Level Agreement：サービスレベル合意）があります。障害によりサービス停止（ダウンタイムと言います。）が一定期間発生した場合には、SLAの規定に応じた対応をAWSは行います。

AWSによる障害への補償（SLA）

契約者（利用者）は、別途締結された特別な契約が無い限り、AWSが設定したSLAに合意した上で各サービスを利用する必要があります。
一般的にSLAには、サービス事業者が契約者に対して、対象サービスの稼働率目標などを規定しそれを下回った際にどのような補償をするかなどを明示されています。サービスによっては、一定期間連続してサービス提供がなされなかった（できなかった）場合の返金や次の支払いタイミングでの相殺などが規定されている場合もあります。
ただし、SLAは、クラウド事業者と契約者個別の間で、基本的にサービス申込時に個別に合意する形になりますので、大規模障害が発生したからといって一概に全契約者が返金対象になるわけではないことに注意しましょう。例えば、リージョンの基盤（AWSの特定AZなどの基盤）での大規模障害が発生した場合などにおいても、特別のアナウンスなどがクラウド事業者から無い限り、返金についての規定がSLAにあり、かつ、SLAで規定されている対象となる条件（申告やログの提出が必要など）を契約者が満たさない限りは返金対象になりません。
また、例えばAWSにおいてAmazon EC2とAmazon RDSとなど、複数のサービスを連携させて利用している場合において、Amazon RDSの障害によりサービスが使えず、その影響によりEC2上に立てたホームページ上で意図していない表示がなされたとしても、Amazon EC2自体がサービス停止していない限り、Amazon RDSのSLAが規定している範囲のみが返金対象となり、Amazon EC2についての返金はありません。

AWSで特によく利用される以下の主要サービスでは個別にSLAが設定されており、それぞれのサービスのサービスコミット（稼働率）の目標値と、AWSがそれを守れなかった場合のサービスクレジット（返金）の割合を決めています。（ただし返金対象はAWSに直接起因するリージョン単位の障害のみ）

• Amazon Elastic Compute Cloud（EC2）
• Amazon Elastic Block Store（EBS）
• Amazon Relational Database Service (Amazon RDS)
• Amazon Simple Storage Service (Amazon S3)
• Amazon CloudFront
• Amazon Route53

個別にSLAが規定されていないサービスや、返金規定がない（サービス個別の）SLAもありますので、必要に応じて、利用を検討しているサービスのSLAについて確認しましょう。

AWSで起きうる障害の種類

AWSで起きうる障害には以下の種類があります。

• （1）AWS側の要因によって起きるもの
• （2）利用者側の要因によって起きるもの
• （3）いずれの要因でもないもの（不可抗力）

AWSで起きた障害の事例

これまでAWSで起きた大規模障害にはどのようなものがあるでしょうか。主な事例を紹介します。

ap-northeast-1（東京リージョン）で生じた大規模障害（2019.8.23）

【原因】

冷却システム障害（AWS側）

【概要】

AWSの東京リージョンの内の1つのデータセンター（availability-zone ＝AZ）で、AZ内の制御システムに問題が発生し、複数の要因により冗長化された冷却システムに障害が発生しました。それによってAZ内の一部のサーバーの温度が許容限度を超えた結果、サーバーの電源が停止し始め、同一AZ内のEC2や他のサービスのパフォーマンス劣化なども発生しました。復旧するまでの間、大手ショッピングサイトやキャッシュレスサービスサイト、またゲームサイトなどでもサービスを停止するなど、大規模な影響を及ぼした事例です。

us-east（米国東部リージョン）で生じた大規模障害（2017.3.1）

【原因】

人為的操作ミス（AWS側）

【概要】

人為的操作ミスによりS3 API が利用できなくなったことから、S3コンソール、EC2の新規インスタンスの起動、EBS)ボリューム 、AWS Lambdaを含め、US-EAST-1リージョンにおける、ストレージとしてS3を利用するその他のAWSサービスにも大規模な障害が発生した事例です。

ap-southeast-2（シドニーリージョン）で発生した障害（2016.6.5）

【原因】

天災（豪雨）

【概要】

2016年6月5日にオーストラリア東海岸で発生した大規模な豪雨で、シドニーで約8万500軒の家やオフィスでの停電や広範囲な通信障害などが発生しました。これに伴ってAmazonクラウドのシドニーリージョンでもAmazon EC2などに一部障害が発生した事例です。

us-east（米国東部リージョン）で生じた新機能追加時と同時期のネットワーク障害により発生した障害（2015.9.20）

【原因】

追加された新機能の想定を上回る利用による過負荷＋ネットワーク障害（AWS側）

【概要】

AWSの作業者がAmazon DynamoDBの新機能としてテーブルに新たなインデックスを付加できるGlobal Secondary Indexesを追加しました。しかし、想定を上回る多数の利用者がこの機能を利用したことで、管理のためのメタデータが劇的に増大。同じタイミングでたまたまDynamoDBのストレージサーバー群の一部でネットワーク障害が発生していたことにより、大規模な障害に発展しました。 DynamoDBを利用しているEC2 Auto Scaling、Simple Queue Service、CloudWatch、コンソールなどに一時的な障害が発生した事例です。

eu-west（欧州リージョン）で発生した落雷停電によって発生した障害（2011.8.8）

【原因】

天災（落雷）

【概要】

eu-westにおいて、電力会社の変圧器が落雷により故障し、電力の供給が停止しました。これによりEC2、EBS、RDSに障害が発生したという事例です。

AWSの障害発生を想定した対策

障害発生に備えるための対策で重要なことは、システムの稼働継続性を高めた設計と障害状況の迅速な把握です。そこで、AWS側で障害が発生した場合における障害対策について考えてみましょう。

障害に備える設計の考え方-Design for Failure

2019年に発生した東京リージョンでの大規模障害は、障害は必ず発生し得るという、日常忘れがちな点を改めてユーザーが思い知らされる結果となりました。それでなくてもAWSにおいては、単体でEC2インスタンスを運用している場合には「いつ落ちてもおかしくない」という前提のもとにサービス提供されていると言われている方もいらっしゃいます。

また、過去の障害の例でも見てきたように、大規模な障害や天災などが発生した場合、AZ(availability-zone)が丸ごと落ちてしまうこともありえます。また、突然落ちるまでではないにしても、時にEC2インスタンスはAWSから強制的に再起動を求められることもあります。

AWS上にシステム構築する場合は、こうした障害がいつでも発生しうるという前提に基づいて設計を行う必要があります。AWSを使って提供するサービスの重要度を考慮して、インスタンスが唐突に落ちたり、AZの1つが丸ごとダウンしたりしたとしてもシステムの稼働を継続できるような（高可用性＝high-availability＝HA）を備えた構成が推奨されています。このようにあらかじめ障害を見据えた設計を考えることを「Design for Failure」と呼びます。
具体的には、大半の故障に対して自動的（もしくはほぼ自動的）に修正して正常なサービスに割り当てることが容易にできるようになっているAWSの仕組みを利用します。
例えばEC2のケースでは、ユーザーがAWS基盤の異常を検知した場合、不安定なリソース（インスタンスやボリューム）を破棄して、直ちに新たな別のリソースを調達して運用を継続するような設計が推奨されています。

障害を前提にしたリスク分散設計

東京リージョンで発生した障害にも見るように、単独のAZを使って運用されていたシステムは停止してしまいましたが、複数のAZ（MultiAZ）で運用を行っていたシステムにはダウンを免れたものもありました。このように複数のAZに、リソースを分散させる、S3やEBSの場合は別のリージョンにバックアップするなど、あるゾーンやリージョンに障害が発生しても、他のゾーンに置いたサーバーがそのバックアップの役目を果たして、無停止あるいは早急な復旧ができるような、リスクを分散した運用方法が重要となります。

（設計や運用方法によってはMultiAZでの運用でも影響があったケースもあるようですので、一概にMultiAZで運用を行っていた場合でもサービス停止などの影響がないとは言いきれません。）

障害に関する情報を集める

AWS上で障害が発生した場合には、でき得る限り早く、発生している障害に関わる情報を得ることが必要です。そのためにはさまざまな方法があります。

Twitterの障害アカウント

非公式ですがTwitterには東京リージョンのみのAWS障害情報をツイートしているアカウント@awsstatusjpがあります。AWSの東京リージョン及びリージョンなしサービスのステータスに更新があった際にツイートします。全リージョン対象のアカウントは@awsstatusjp_allです。

Dashboard表示

コンソールにログインしてDashboardを見る時には、右上に表示される「アラート」欄に何かサービス運用や障害に関する情報が表示されていないか注意しましょう。AWSからEC2やEBSの再起動を求められる場合や、ボリューム差し替えの要請などもこの「アラート」に表示されます。

AWS Service Health Dashboard

AWS Service Health Dashboardを見るとAWSにおける各サービスの稼働状況がわかります。
https://status.aws.amazon.com/
都度見に行くのは面倒なため、RSSリーダーにサイトのRSSフィードを登録しておくと更新があった時にはすぐわかるので便利です。

リリースノート

サービスのアップデート情報などはここに掲載されます。ブックマークしておくとよいでしょう。
https://aws.amazon.com/jp/releasenotes/

監視体制の構築

AWSに構築した自社のサービスに異常がないか、監視体制を構築するにはAmazon CloudWatchを活用する方法があります。Amazon CloudWatch の利用により、AWS のリソース、アプリケーション、およびサービスを統括的に把握することができるように、ログ、メトリクス、およびイベントという形式でモニタリングデータと運用データを収集し、それらを自動化されたダッシュボードを使って可視化することができます。

また、異常なメトリック動作が発生した場合には、メール等でアラームを飛ばすなどの監視体制が可能です。障害が発生した時に迅速に措置を講じるには、Auto Scaling などを自動的に開始する自動化されたアクションをセットアップすることもできるため、平均解決時間の短縮に役立ちます。

障害に備える運用・復旧体制の確立

障害発生に対して、日頃からそれに備える監視体制や復旧体制の構築が必須となります。障害が発生した場合には自動・手動あらゆる手段を使ってそれを検知し、正常な稼働体制に復旧させなければなりません。発生した時になってから混乱を招かないように、常日頃からさまざまな障害を仮定した復旧リハーサルが必要です。また、システムの復旧だけではなく、障害が発生し確認した後の社内外との連絡網や指示系統、連絡すべき内外の組織なども、定期的に確認をしておきましょう。人の混乱は何よりも復旧を妨げますし、考えられるあらゆるケースを想定しておかなければ、復旧の方針や道筋を立てることも困難になります。

まとめ

どのようなシステムであっても必ず障害発生の可能性はあります。堅牢とも言われるAWSであっても例外ではありません。過去のAWSの障害発生の事例を学ぶとともに、起きうる障害の種類を整理し、それぞれに対応する障害対策を立てることが重要です。障害の要因が天災によるもの、人為的なもの、原因がAWS側にある場合と利用者側にある場合などさまざまなパターンがありますので、それぞれに即した監視・リスク分散・運用・復旧体制を構築しましょう。障害対応は単にプランを構築するだけではなく、考えられ得る障害を想定した復旧リハーサルを日頃から実施することも必要です。