Writer:NTT東日本アベAWSの障害対策-原因と事例を学び障害対策を考えるどのようなシステムであっても必ず障害発生の可能性はあります。AWSも例外ではありません。日本でも、2019年8月23日に東京リージョンで大規模障害が発生し、広範囲に影響を及ぼしました。今回は、万が一に直面する前に、AWSで起きうる障害にはどのような種類があるのか整理し、また過去に起きた大規模障害の実例に学ぶことにより、障害対策として平常時から準備しておいたほうがよい点について考えます。Agreement:サービスレベル合意)があります。障害によりサービス停止(ダウンタイムと言います。)が一定期間発生した場合には、SLAの規定に応じた対応をAWSは行います。AWSによる障害への補償(SLA)契約者(利用者)は、別途締結された特別な契約が無い限り、AWSが設定したSLAに合意した上で各サービスを利用する必要があります。一般的にSLAには、サービス事業者が契約者に対して、対象サービスの稼働率目標などを規定しそれを下回った際にどのような補償をするかなどを明示されています。サービスによっては、一定期間連続してサービス提供がなされなかった(できなかった)場合の返金や次の支払いタイミングでの相殺などが規定されている場合もあります。SLAは、クラウド事業者と契約者個別の間で、基本的にサービス申込時に個別に合意する形になりますので、大規模障害が発生したからといって一概に全契約者が返金対象になるわけではないことに注意しましょう。リージョンの基盤(AWSの特定AZなどの基盤)での大規模障害が発生した場合などにおいても、特別のアナウンスなどがクラウド事業者から無い限り、返金についての規定がSLAにあり、かつ、SLAで規定されている対象となる条件(申告やログの提出が必要など)を契約者が満たさない限りは返金対象になりません。EC2についての返金はありません。AWSで特によく利用される以下の主要サービスでは個別にSLAが設定されており、それぞれのサービスのサービスコミット(稼働率)の目標値と、AWSがそれを守れなかった場合のサービスクレジット(返金)の割合を決めています。Route53個別にSLAが規定されていないサービスや、返金規定がない(サービス個別の)SLAもありますので、必要に応じて、利用を検討しているサービスのSLAについて確認しましょう。AWSで起きうる障害の種類AWSで起きうる障害には以下の種類があります。(1)AWS側の要因によって起きるもの(2)利用者側の要因によって起きるもの(3)いずれの要因でもないもの(不可抗力)AWSで起きた障害の事例これまでAWSで起きた大規模障害にはどのようなものがあるでしょうか。主な事例を紹介します。=AZ)で、AZ内の制御システムに問題が発生し、複数の要因により冗長化された冷却システムに障害が発生しました。それによってAZ内の一部のサーバーの温度が許容限度を超えた結果、サーバーの電源が停止し始め、同一AZ内のEC2や他のサービスのパフォーマンス劣化なども発生しました。復旧するまでの間、大手ショッピングサイトやキャッシュレスサービスサイト、またゲームサイトなどでもサービスを停止するなど、大規模な影響を及ぼした事例です。Lambdaを含め、US-EAST-1リージョンにおける、ストレージとしてS3を利用するその他のAWSサービスにも大規模な障害が発生した事例です。天災(豪雨)【概要】2016年6月5日にオーストラリア東海岸で発生した大規模な豪雨で、シドニーで約8万500軒の家やオフィスでの停電や広範囲な通信障害などが発生しました。EC2などに一部障害が発生した事例です。Indexesを追加しました。想定を上回る多数の利用者がこの機能を利用したことで、管理のためのメタデータが劇的に増大。同じタイミングでたまたまDynamoDBのストレージサーバー群の一部でネットワーク障害が発生していたことにより、大規模な障害に発展しました。Service、CloudWatch、コンソールなどに一時的な障害が発生した事例です。天災(落雷)【概要】eu-westにおいて、電力会社の変圧器が落雷により故障し、電力の供給が停止しました。これによりEC2、EBS、RDSに障害が発生したという事例です。障害発生に備えるための対策で重要なことは、システムの稼働継続性を高めた設計と障害状況の迅速な把握です。そこで、AWS側で障害が発生した場合における障害対策について考えてみましょう。Failure2019年に発生した東京リージョンでの大規模障害は、障害は必ず発生し得るという、日常忘れがちな点を改めてユーザーが思い知らされる結果となりました。それでなくてもAWSにおいては、単体でEC2インスタンスを運用している場合には「いつ落ちてもおかしくない」という前提のもとにサービス提供されていると言われている方もいらっしゃいます。過去の障害の例でも見てきたように、大規模な障害や天災などが発生した場合、AZ(availability-zone)が丸ごと落ちてしまうこともありえます。落ちるまでではないにしても、時にEC2インスタンスはAWSから強制的に再起動を求められることもあります。AWS上にシステム構築する場合は、こうした障害がいつでも発生しうるという前提に基づいて設計を行う必要があります。AWSを使って提供するサービスの重要度を考慮して、インスタンスが唐突に落ちたり、AZの1つが丸ごとダウンしたりしたとしてもシステムの稼働を継続できるような(高可用性=high-availability=HA)を備えた構成が推奨されています。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の再起動を求められる場合や、ボリューム差し替えの要請などもこの「アラート」に表示されます。Dashboardを見るとAWSにおける各サービスの稼働状況がわかります。https://status.aws.amazon.com/都度見に行くのは面倒なため、RSSリーダーにサイトのRSSフィードを登録しておくと更新があった時にはすぐわかるので便利です。リリースノートサービスのアップデート情報などはここに掲載されます。ブックマークしておくとよいでしょう。CloudWatchを活用する方法があります。リソース、アプリケーション、およびサービスを統括的に把握することができるように、ログ、メトリクス、およびイベントという形式でモニタリングデータと運用データを収集し、それらを自動化されたダッシュボードを使って可視化することができます。異常なメトリック動作が発生した場合には、メール等でアラームを飛ばすなどの監視体制が可能です。自動的に開始する自動化されたアクションをセットアップすることもできるため、平均解決時間の短縮に役立ちます。障害発生に対して、日頃からそれに備える監視体制や復旧体制の構築が必須となります。障害が発生した場合には自動・手動あらゆる手段を使ってそれを検知し、正常な稼働体制に復旧させなければなりません。発生した時になってから混乱を招かないように、常日頃からさまざまな障害を仮定した復旧リハーサルが必要です。システムの復旧だけではなく、障害が発生し確認した後の社内外との連絡網や指示系統、連絡すべき内外の組織なども、定期的に確認をしておきましょう。人の混乱は何よりも復旧を妨げますし、考えられるあらゆるケースを想定しておかなければ、復旧の方針や道筋を立てることも困難になります。まとめどのようなシステムであっても必ず障害発生の可能性はあります。堅牢とも言われるAWSであっても例外ではありません。過去のAWSの障害発生の事例を学ぶとともに、起きうる障害の種類を整理し、それぞれに対応する障害対策を立てることが重要です。障害対応は単にプランを構築するだけではなく、考えられ得る障害を想定した復旧リハーサルを日頃から実施することも必要です。ECS」の主な機能と使い方RECOMMENDその他のコラム2020.01.15オンプレミスとAWS、どちらを選ぶ?連携するメリットとあわせて解説オンプレミスは、企業内にサーバーを始めとするシステム全体を構築するシステム形態です。最近は、オンプレミスとクラウドを併用するハイブリッドクラウドも広まっています。AWSにはハイブリッドクラウドを実現するためのサービスがいくつか用意されているので、活用してください。今回は、S3の概要、メリットと主な利用例、利用にあたっての主な手順と料金についてまとめています。CloudWatchは、AWS上で動作している各サービスやアプリケーションの稼働状況を監視するサービスです。初期費用や固定費も必要なく、利用量に応じた料金体系となっており、簡単かつ手軽に始められます。AWSで利用しているサービスの統合的なシステム監視が実現できます。Azureの導入支援サービスのご相談、お問い合わせをお待ちしております。