今回のコラムでは、クラウドの障害対策の4つの方法と、最も信頼性のある構成について考えていきます。
2019年の8月23日にAWSの東京リージョンで大規模な障害が発生しました。この障害のため、東京リージョンに配置される一部のEC2™インスタンス（IaaS）、RDS（データベースのサービス）が使用不可となりました。
最近は多くの重要なシステムがクラウドのIaaSに移行されています。今回の障害を受けて、不安を感じた事業者は少なくなかったでしょう。
しかし、この障害において、当社の高可用性ソリューションである「AZをまたいだHAクラスター構成」は被害を受けずサービス提供を継続できました。今一度、システムの障害対策が十分なのかどうか考えてみましょう。
Contents
AWSの障害を確認する方法
AWSでもし障害が発生した場合、簡単に確認する方法をいくつか紹介します。動作がおかしい場合など、まずは確認してみましょう。
ダッシュボードで確認
AWSで障害が発生したことは、ダッシュボードから確認ができます。まずはAWSにログインし、管理画面を開きます。もし、画面右上にあるベル型のアイコンにチェックが入っていたら、何か情報があるということです。そこをクリックすると、ダッシュボードが開き、「Open Issue」が確認できます。表示されている数字が発生した件数であり、イベント内容と事象が発生したリージョン名、発生日時が開示されています。
発生しているイベントをクリックすれば右側のペインに開くため、そこで詳細情報を確認しましょう。ダッシュボード以外にも、公式に各リージョンの状況を発表しているサイト「Service Health Dashboard」でも障害情報を確認できます。これは各リージョンのサービス状態を一覧で参照できるものです。
各サービスの右にある「RSS」をクリックすると、過去の障害情報が記載されています。これをRSSリーダーで読み取れば、過去をさかのぼって、障害履歴が確認することができます。一番下にあるリンク「AWS Post-Event Summaries」にアクセスすると、これまで起きた大規模障害に対する原因と対策レポートも確認できます。
Twitterで検索
公式サイトでの障害発生情報は、小さな障害や単なるバグは記載されないこと、反映が遅いことから、現在の状況をリアルタイムに確認できません。そのため、参考程度に見るとよいでしょう。
AWSの調子が悪く、何が起きているのかすぐに確認したい場合は、Twitterを見ることをおすすめします。これは非公式情報ですが、誰かがつぶやいていたら、何かしら障害が起きた可能性が高いということです。
東京リージョン関連の障害発生用の非公式Twitterアカウント（@awsstatusjp）もあるため、参考にしてみるとよいでしょう。これは、公式サイトの各サービス状況の横にあるRSSフィードを自動収集したものです。
日本や世界におけるAWSの過去の障害情報
これまで実際に起きた、AWSの過去の障害事例を紹介します。どのようなことが起きたのか、自社システムの可用性を高めるための参考にしてみてください。
EU-WEST（2011年）
2011年にEU-WESTリージョンで障害が発生し、EC2・RDS・EBSのサービスにそれぞれ問題が発生しました。
これらのサービスは一旦停止され、利用者からはアクセスできないようになりました。原因は、電力事業者の110kv 10メガワット変圧器が故障したためです。
この故障により、完全に電力供給を失いました。通常であれば、バックアップの発電機から電力が供給されるのですが、大規模な地絡事故の影響もあり、正常に作動できなかったようです。停電時は短時間の電力供給をする無停電電源装置（UPS）が作動しましたが、電力をすぐに使い果たしてしまい、影響のあるサーバーは全てダウンしてしまいました。
再発防止として、バックアップ発電機からの供給方法を改善し、大規模な事故に影響を受けないような仕組みを検討するとのことです。
影響を受けた利用者に対しては、EBS ボリューム、EC2™ インスタンス、RDS データベースインスタンスの利用料金10日分が提供されました。さらに、誤ってスナップショットのブロックを削除するEBS ソフトウェアバグの影響を受けた利用者には、EBS利用料金30日分が提供されることになりました。
US-EAST（2011年）
2011年にUS-EASTリージョンにおいて、EC2の障害が発生しました。サービスは停止状態になり、復旧するまでにかかった期間は約3日間です。
原因は、ネットワーク増強時のヒューマンエラーでした。ネットワーク増強のために、スケーリング作業をします。最初の作業として、プライマリーネットワークのトラフィックを別のルーターに移動しなければならなかったのですが、誤って低レベルトラフィック側のルーターに分岐させてしまったようです。
ルーターは大量のトラフィックを扱いきれず、各ノードに問題を起こしていきました。一つの事象から、さまざまな問題を発生させ、結果的にはAZデータベースインスタンスの0.4%を損失してしまったのです。Amazonは、この事象で、大規模なリカバリ処理に多くのディスク容量が必要だと判明したため、大きくストレージの容量を増やすことを発表しています。
問題発生により被害が出た利用者には、影響を受けたEBS ボリューム，EC2™ インスタンス，RDS データベースインスタンス利用量の100%について、10日分のクレジットを提供することになりました。
US-EAST1（2012年）
2012年6月にUS-EAST1リージョンで発生した事故により、InstagramやNetflixなどのサービスに影響を及ぼしました。
これは、自然災害による電源障害が原因です。嵐が起きた夜、電源がダウンしたため電力供給がUPSに切り替わったのですが、電力が枯渇して一部のデータセンターが停止したのです。
これが引き金となり、EC2・EBS・ELB・RDSなどのサービスに障害が発生し、複数のアベイラビリティゾーンに波及しました。電気供給は発電機に切り替わりましたが、通常運転に戻ったあと2度目の電力障害が起きてしまうなど、電力供給トラブルがたびたび発生。
前例で電力障害によるサービス停止が相次いだにもかかわらず、再度このような問題が発生してしまいました。堅ろうにハードウエアを守っているデータセンターといえども、自然災害は想定できないような事象を発生させるようです。
US-EAST（2012年）
2012年12月24日のクリスマスイブにアメリカでAWSの障害が発生し、Netflixなどのサービスがトラブルに巻き込まれました。場所は、US-EASTリージョンです。
メンテナンス時のオペレーションミスが、システム障害を発生させました。発生箇所はロードバランサ―であり、このミスにより一部のステートデータが削除されてしまったのです。
被害の拡大を止めるべく、ステートデータを復旧し、正常運用に戻しました。障害発生から復旧までにかかった時間は約1日です。この事象により、Amazonは運用中のELBステートデータに対するアクセスコントロールについて、変更管理システムの承認なしには変更できないようにしました。また、データリカバリープロセスも改善し、迅速にリカバリできるようにするとのことです。
このように、大企業のシステムでも、サービスを停止させてしまうことがあります。
AP-SOUTHHEAST-2（2016年）
2016年にオーストラリア東海岸を襲った豪雨により、AP-SOUTHHEAST-2リビジョンで障害が発生しました。主に影響が出たサービスはEC2です。
豪雨被害が深刻化する中、やがてEC2への接続障害が散見されるようになりました。発生していた事象は、電源障害です。回復措置として、電源の修理、影響を受けていたインスタンスの接続復旧作業を実施。事象が発生して、約18時間後に全回復しています。
豪雨被害は、日本各地で多く発生しています。このように、システムがいつトラブルに巻き込まれるかわかりません。高い可用性を実現するためには、クラウドシステムといえども、状態の監視から遠隔地に設置した待機系への切り替えなどの仕組みを独自で導入しておくとよいでしょう。
US-EAST-1（2017年）
2017年に、US-EAST-1リージョンがダウンし、クラウドストレージであるS3のサービスが一部停止、もしくは全く使えなくなる事象が発生しました。
この障害は、サービスを利用している顧客のウェブサイトやアプリケーション、デバイスに影響を与えています。大きな混乱を招いた故障ですが、原因は作業中の誤ったコマンド入力によるものでした。ちなみにUS-EAST-1リージョンの利用者が少ない日本などでは、おもだった影響はなかったようです。
コマンドは確率された手順に則ったものでしたが、このように注意を払いながらも、原因不明な故障が起きる場合があります。作業は既知の問題に対処するためのものでした。メンテナンスを行う以上、稼働しているシステムに影響を与える可能性は大いにあるのです。クラウドサービスはデータセンターで電源を冗長化していたり、耐震設計のラックを利用していたりするなど、ハードウエアを守る対策は得意としています。
しかし、アプリケーションエラーによる対策の強化は、これからかもしれません。
AP-NORTHEAST-1（東京リージョン）（2019年）
最後は2019年のAP-NORTHEAST-1の東京リージョンで起きた障害事例を紹介します。この事象は主にEC2・EBSに影響を与えました。
条件によっては、RDSやRedshift、ElastiCache またはWorkspacesにも不具合が発生しています。原因は、東京リージョンの単一アベイラビリティーゾーンでのオーバーヒートです。これにより、EC2™インスタンスまたはEBSボリュームのパフォーマンスが低下しました。
データセンターは熱暴走を防ぐために、一定の低い温度で保つよう空調が整備されています。しかし、今回はその空調設備の管理システムに障害が発生したため、温度管理ができなくなってしまったのです。約3時間後に空調は回復し、室温も正常に戻りましたが、その後も回復措置が遅れます。通常は高可用性を実現するための制御システムが、異常事態では逆に悪影響を及ぼしていたからです。
Amazonは、空調ユニットを制御する方法の変更や、バグが発生した場合の制御システムのフェールオーバー機能を無効化にし、今後同じ事象が発生しないよう、対策を講じるとのことです。安心・安全設計のデータセンターでも、予期しないトラブルに巻き込まれる可能性は大いにあります。システムの設置場所を一つにするのではなく、遠隔地へ待機系を用意しておくなどの対策も有効でしょう。
代表的な4つの障害対策
こうしたさまざまな障害に備え、クラウド上では次の4つの対策がよく使われています。
1．Auto Recoveryによる対策（AWSの標準機能）
2．監視ツールと手動操作による対策
3．バックアップによる対策
4．HAクラスターによる対策
Auto Recoveryによる対策（AWSの標準機能）
クラウドの標準機能で障害対策を取られているケースは多いと思います。例えばAWSの場合は EC2の「Auto Recovery」機能が有名です。
Auto Recoveryは、物理ホスト側の問題を検知してEC2™インスタンスを自動復旧してくれるサービスです。EC2™インスタンス上で動いているアプリケーションの障害までは検知してくれませんが、基板側の障害については一定の信頼を得られます。
＜概念図：Auto Recovery＞
しかし2019年の8月23日にAWSの東京リージョンで発生した大規模障害では、Auto Recoveryでも自動復旧に失敗するケースがあったようです。原因としては、Auto Recoveryは作動したが、肝心の物理ホスト側が障害から回復しておらずに自動復旧が失敗したのではないかと考えられます。
多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、ECサイトや銀行ATMなど止められないシステムの対策としては、確実に別のAZ（Availability Zone）での復旧が対策になると考えられます。AZをまたいで復旧することで、別のAZで起こった障害から隔離できる確率が上がるといえます。
監視ツールと手動操作による対策
EC2上でZabbixなどの監視ツールを使って障害対策をされるケースもあります。監視ツールが障害を検知したら手動で再起動させるという運用もよく聞きます。この方式の長所は、Auto Recoveryでは検知できないアプリケーションの障害も監視ツールが検知してくれる点にあります。
反面、手動操作を前提としているので、人的な負担や復旧時間の長さ、操作ミスのリスクがあります。また、今回のような大規模障害の場合は、そもそも仮想マシンの再起動の操作ができない可能性もあります。
＜概念図：監視ツールと手動再起動＞
多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、止められないシステムの対策としては、自動的に障害を検知して別のAZで復旧できる仕組みが必要になります。
バックアップによる対策
バックアップはどのシステムでも使われていますが、障害対策の観点では次の点に注意が必要です。
まずバックアップは、バックアップを取った時点の状態に確実に戻せます。この点はメリットでもありますが、障害が起きた時点のできるだけ近くの状態に戻すことはあまり得意ではありません。（RPO（目標復旧時点）の観点）
＜概念図：バックアップからの復旧＞
またバックアップからのリストアにはそれなりに時間がかかるので、大事なシステムをすぐに復旧させたい場合は注意が必要です。（RTO（目標復旧時間）の観点）
さらに今回のような障害時にバックアップを取ったデータを別のAZで復旧させたい場合には、ネットワークなどの環境の相違点の対応が必要になる場合もあります。多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、基幹系など止められないシステムの対策としては、RTOとRPOが短くかつ他のAZでも修正不要で復旧できる仕組みとの併用が必要です。
これらから基幹系など止められないシステムに対しては、下記の要素が必要になります。
HAクラスターによる対策
HAクラスターとは稼働系と待機系でサーバーを2台用意し、稼働系システムに障害が発生した際に自動的に待機系システムに切り替える仕組みです。
HAクラスターソリューションは、これまで説明した「障害の自動検知と自動復旧」「別のAZでの復旧」「RPOとPTOの短縮」すべてを実現するソリューションです。
代表的なHAクラスターソリューションとしては、サイオステクノロジーのHAクラスターソフトLifeKeeperとデータレプリケーションソフトDataKeeperがあります。
LifeKeeperは当社のHAクラスター製品で、グローバルで25年・6万ライセンス以上使われている実績のある製品です。AWSやAzureなどのパブリッククラウドにもいち早く対応しており、既に多くの導入実績があります。
DataKeeperは当社のデータレプリケーション製品で、ブロックレベルのリアルタイム・レプリケーションにより、LifeKeeperに論理的な共有ストレージとして認識されます。これにより、物理的な共有ストレージが使えないクラウド環境でも、オンプレと同じ感覚でHAクラスターの構築が可能です。
＜AWS上での構成例のイメージ＞
下記ページでは導入事例や詳細な構築手順ガイドを公開しております。ぜひこれらをご覧いただいて、今後のクラウド環境の障害対策にお役立てください。
【オンデマンド動画】コスト最適化のためのクラウド障害対策
本記事で解説した代表的な4つの障害対策と対応できる障害の種類について解説したウェビナーもございます。
約20分でお好きな時にご視聴頂けますので是非ご活用ください。
【アジェンダ】
・クラウド障害対策はなぜ必要か？
・障害対策のための要件のまとめかた
・代表的な４つのクラウド障害対策
・その他ソリューションとの組み合わせ
まとめ
AWSなどの大手クラウドプラットフォームサービスでも、多くの障害事例があります。システムを運用している限り、いつどのような事象が発生するのかわかりません。
運用を守るためには、独自の高可用性を実現できる仕組みづくりが必要です。SIOS LifeKeeperは、ハードウエアからアプリケーションまで、幅広い障害を検知した際に自動で待機系へ切り替えます。素早い判断で、業務停止時間を大きく減らすことができます。
クラウドの障害から止められないシステムを守るためには、システム停止の許容時間やコスト負担に応じて様々な選択肢があります。自社の要件に応じて適切な方法を選び、対策を検討してみてはいかがでしょうか。
