3分でわかる！AWSにおける障害対策【前編】～もしものトラブルでもサービスを継続するために～

「ショッピングサイトにアクセスできず、商品が購入できない」、「スマホ決済アプリのシステムがダウン、バーコード決済が使えず」、「災害発生時にホームページへのアクセスが集中、警報などのコンテンツが表示できない」・・・
システムのクラウド移行が進むにつれて、このようなニュースもよく見かけるようになってきました。
世の中に止まらないシステムは存在しないことから、もしものトラブルからシステムを守るためにはどうすれば良いのかを考える必要があります。
クラウドへの移行を検討するときは、オンプレミスのシステムで採用していた障害対策を見直す良いチャンスです。本記事では、アマゾンウェブサービス（以降、AWSと略す）における4つの障害対策を前編と後編に分けてお伝えし、システム特性に合わせた使い分けを解説します。

【目次】

1. システムに潜む様々なリスク
2. 事業継続を考えるための指標
3. 障害対策の種類
- 3.1 Amazon CloudWatch（監視サービス）
- 3.2 Auto Recovery（HA機能）

1. システムに潜む様々なリスク

停電、機器故障、人的ミス、ランサムウェアなど、システムには様々なリスクが潜んでいます。システムをAWSなどのクラウドに移行しても、これらのリスクが潜んでいることに変わりはなく、クラウドベンダーと利用者の双方にリスクについての責任があります。実際に大規模障害は起こっており、空調設備のオーバーヒートや冷却システムの電力が喪失した結果、Amazon Elastic Compute Cloud（Amazon EC2）インスタンスのダウンや、Amazon Elastic Block Store（Amazon EBS）のパフォーマンス低下によってシステムが利用できなくなりました。リスク対策は利用者側で検討しなければならないケースもあり、もし、リスク対策をしていないと、重要なデータを失うだけでなく、企業の信頼低下、商品取引や窓口業務などの停止による金銭的損失、最悪の場合、経営の破綻に発展することもあり得ます。
クラウドでも、もしものトラブルから復旧するための対策が必要です。

2. 事業継続を考えるための指標

事業継続を考えるとき、2つの指標を定めます。

RTO

RTO（Recovery Time Objective）は、障害発生時にどのくらいの時間でシステムを復旧させるかの目標値です。例えば、システム障害が発生してECサイトにアクセスできなくなると、事業者は利益を得られない状況になります。システム障害が短時間でも多大な損害を受けるケースでは、RTOを短くする必要があります。RTOがゼロに近づくほど復旧時間は短くなりますが、対策にかかるコストは大きくなります。

RPO

RPO（Recovery Point Objective）は、過去のどの時点までのデータを復旧させるかの目標値です。例えば、在庫引当の管理などデータの喪失が許されないシステムでは、復旧時に停止直前までのデータ（RPOが0秒）が求められます。逆に、更新頻度の少ないシステムでは、24時間前のデータ（RPOが1日）で復旧できれば良いケースもあります。RPOがゼロに近づくほど喪失するデータ量は少なくなりますが、対策にかかるコストは大きくなります。

図1：RTOとRPO

ポイント

RTOやRPOは業種や業務のシステム特性によって異なります。システム特性によって、障害対策を検討する必要があります。

3. 障害対策の種類

AWSにおける障害対策には、次の4種類があります。このうち、前編では「Amazon CloudWatch（監視サービス）」と「Auto Recovery（HA機能）」について、後編では「AWS Backup（バックアップ）」と「HAクラスタソフトウェア」について解説します。

前編【本記事】

Amazon CloudWatch（監視サービス）
Auto Recovery（HA機能）

後編

AWS Backup（バックアップ）
HAクラスタソフトウェア

3.1 Amazon CloudWatch（監視サービス）

システムのどの部分に障害が発生しているかが分かると、障害発生から検知までの時間を短縮でき、結果、RTOを短くすることができます。そこで、AWSではAWSリソースとAWSで実行されているアプリケーションをリアルタイムでモニタリングするためのAmazon CloudWatchが提供されています。例えば、Amazon EC2から、CPU使用率、ディスクのI/O回数、ネットワークトラフィックなどのメトリクス（監視項目）を取得します。そして、データをグラフ化してAWS Management Consoleに表示することで、障害が発生している箇所を特定することができます。
メトリクスに対してしきい値（CPU使用率90%以上など）を設定し、しきい値にもとづいてアラームを作成できます。Amazon CloudWatchアラームでは、メトリクスに応じてアクションを実行できます。アクションは、Amazon Simple Notification Service（Amazon SNS）やAmazon EC2 Auto Scalingに送信することができます。Amazon SNSでは、メトリクスがしきい値に達したときにメッセージを送信します。また、Amazon EC2 Auto Scalingでは、負荷に応じてAmazon EC2インスタンスの台数を自動調整します。
このように、Amazon CloudWatchを使用すると、システム全体のリソース使用率やアプリケーションパフォーマンスを監視することができます。しかし、オートスケールに対応していないアプリケーションなどを障害時にどのようにして自動で復旧させるかは別途、考える必要があります。
Amazon CloudWatchは、従量課金制です（無料利用枠あり）。

（補足）
Amazon CloudWatchの料金についてはAWSのウェブサイトでご確認ください。
- Amazon CloudWatchの料金

図2：Amazon CloudWatchのしくみ

3.2 Auto Recovery（HA機能）

RTOをさらに短くするには、障害検知後の復旧アクションの自動化が必要です。HA（High Availability：高可用性）機能を使うと復旧アクションが自動化でき、ある一定の可用性が確保できます。Amazon EC2では、Amazon EC2インスタンスの障害を検知して自動で復旧するためにAuto Recoveryが提供されています。検知できるAmazon EC2 インスタンスの障害は、次の2つに分類されます。

StatusCheckFailed_System
Amazon EC2インスタンスをホストしているハードウェアの障害（ネットワーク接続や電源、物理サーバーの故障など）
StatusCheckFailed_Instance
Amazon EC2インスタンス内部の障害（メモリー枯渇やファイルシステムの破損など）

障害が発生すると、同じアベイラビリティゾーン（Availability Zone）内でAmazon EC2インスタンスを再起動することで復旧を試みます。Amazon EC2インスタンスの復旧後もインスタンスIDやIPアドレスは維持されるため、障害発生前と同じ運用が可能です。
しかし、アベイラビリティゾーン障害時は自動で復旧できないため、AWSが提唱しているベストプラクティス（複数のアベイラビリティゾーンでの実装）に則るためには別途、考える必要があります。また、Amazon EC2インスタンスにインスタンスストアがアタッチされている場合はサポートされないなど、いくつか要件もあります。Auto Recoveryについては「AWSの可用性について考える～AZ構成やAuto Recoveryなどの仕組みを解説～」もご覧ください。
Auto Recoveryの利用に追加料金はありません。

図3：Auto Recoveryのしくみ

「3分でわかる！AWSにおける障害対策」は後編へ続きます！

3分でわかる！AWSにおける障害対策【後編】

こちらもおすすめ

オンプレミスからクラウドへ移行で障害対策に疑問や不安を抱えていませんか？HAクラスタリング・ソフトウェア「PRIMECLUSTER」が解決します。

クラウドでも起こりうる大規模障害、「止まる」を前提に障害対策をしていますか？
（「PRIMECLUSTER」のページへ）

備考

Amazon Web Services、AWS、Amazon EC2、Amazon EBS、Amazon CloudWatch、AWS Management Console、Amazon SNS、Amazon EC2 Auto Scalingは、Amazon.com, Inc. またはその関連会社の商標です。