3分でわかる！AWSにおける障害対策【前編】～Amazon CloudWatch（監視サービス）とAuto Recovery（HA機能）～
「ショッピングサイトにアクセスできず、商品が購入できない」、「スマホ決済アプリのシステムがダウン、バーコード決済が使えず」、「災害発生時にホームページへのアクセスが集中、警報などのコンテンツが表示できない」・・・
システムのクラウド移行が進むにつれて、このようなニュースもよく見かけるようになってきました。
世の中に止まらないシステムは存在しないことから、もしものトラブルからシステムを守るためにはどうすれば良いのかを考える必要があります。
クラウドへの移行を検討するときは、オンプレミスのシステムで採用していた障害対策を見直す良いチャンスです。本記事では、アマゾン ウェブ サービス（以降、AWSと略す）における4つの障害対策を前編と後編に分けてお伝えし、システム特性に合わせた使い分けを解説します。
【目次】
- 1. システムに潜む様々なリスク
- 2. 事業継続を考えるための指標
- 3. 障害対策の種類
- 3.1 Amazon CloudWatch（監視サービス）
- 3.2 Auto Recovery（HA機能）
1. システムに潜む様々なリスク
停電、機器故障、人的ミス、ランサムウェアなど、システムには様々なリスクが潜んでいます。システムをAWSなどのクラウドに移行しても、これらのリスクが潜んでいることに変わりはなく、クラウドベンダーと利用者の双方にリスクについての責任があります。リスク対策は利用者側で検討しなければならないケースもあり、もし、リスク対策をしていないと、重要なデータを失うだけでなく、企業の信頼低下、商品取引や窓口業務などの停止による金銭的損失、最悪の場合、経営の破綻に発展することもあり得ます。
クラウドでも、もしものトラブルから復旧するための対策が必要です。
2. 事業継続を考えるための指標
事業継続を考えるとき、2つの指標を定めます。
RTO
RTO（Recovery Time Objective）は、障害発生時にどのくらいの時間でシステムを復旧させるかの目標値です。例えば、システム障害が発生してECサイトにアクセスできなくなると、事業者は利益を得られない状況になります。システム障害が短時間でも多大な損害を受けるケースでは、RTOを短くする必要があります。RTOがゼロに近づくほど復旧時間は短くなりますが、対策にかかるコストは大きくなります。
RPO
RPO（Recovery Point Objective）は、過去のどの時点までのデータを復旧させるかの目標値です。例えば、在庫引当の管理などデータの喪失が許されないシステムでは、復旧時に停止直前までのデータ（RPOが0秒）が求められます。逆に、更新頻度の少ないシステムでは、24時間前のデータ（RPOが1日）で復旧できれば良いケースもあります。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（監視サービス）
Loading component...
Loading component...
Loading component...
3.2 Auto Recovery（HA機能）
Loading component...
Loading component...
Loading component...
Loading component...
Loading component...
「3分でわかる！AWSにおける障害対策」は後編へ続きます！
