AWS障害からの復旧を早めるには？設計・バックアップ・運用対策

アマゾンウェブサービス（AWS）では、冗長化したシステムでも障害の影響を完全に避けられるとは限りません。障害に備える際は、サービスをどの程度の時間で復旧させるのか、どの時点までデータを戻すのかをあらかじめ決めておく必要があります。

その目標に応じて、バックアップ、マルチAZ・マルチリージョン、DR（災害復旧）戦略を選定します。あわせて必要になるのが、障害発生時の復旧手順と運用体制です。

本記事では、AWS障害からの復旧を早めるための設計と対策、復旧手順、平常時の運用について解説します。 

AWS障害からの復旧ではRTO・RPOを先に決める

AWSの障害復旧対策では、まずシステム停止による業務影響を確認し、必要な復旧水準をRTO（目標復旧時間）とRPO（目標復旧時点）として定めます。これを基準に、バックアップの頻度や冗長構成、待機環境を選びます。

業務への影響と復旧の優先順位を整理する

受注や決済を担うシステムでは、短時間の停止でも売上や顧客対応に影響する可能性があります。一方、代替手段で一定時間業務を継続できるシステムでは、求められる復旧水準は異なります。

AWSでは、事業影響分析（BIA）によってシステム停止が事業や顧客へ与える影響を把握し、復旧要件を定めます。業務やシステムを重要度ごとに分類し、復旧の優先順位を決めておくことで、障害時の判断も速くなります。

RTO（目標復旧時間）・RPO（目標復旧時点）を設定する

復旧の優先順位を決めたら、システムごとにRTOとRPOを設定します。

• RTO（Recovery Time Objective／目標復旧時間）：サービス停止から復旧までに許容できる時間

• RPO（Recovery Point Objective／目標復旧時点）：障害発生時に許容できるデータ損失の時間的な範囲

たとえば、RTOが1時間なら1時間以内のサービス復旧を、RPOが15分なら最大15分程度のデータ損失を想定したバックアップやデータ複製を設計します。

復旧水準を高めるほど、冗長構成や待機環境、データ複製に必要なリソースも増えます。業務影響とコストのバランスから、現実的な目標値を設定します。

>> 関連記事：AWS環境診断で何がわかる？確認項目と改善の進め方

AWSの障害復旧を支える設計・対策

復旧目標に応じて、バックアップ、マルチAZ、マルチリージョンなどの構成を選び、障害時の切り替え方法まで設計します。

バックアップから復旧できる状態をつくる

データの破損や消失に備え、必要なデータを定期的にバックアップします。取得頻度は、許容できるデータ損失の範囲に合わせて設定します。

AWS Backupを利用すると、複数のAWSサービスにまたがるバックアップを一元管理し、バックアップのスケジュールや保持期間を自動化できます。

>> 関連記事：AWS Backup導入ガイド｜EC2・RDSの自動バックアップ設定と運用トラブルを防ぐ実践知識

あわせてリストアを実施し、データを正常に利用できるか、想定した時間内に復旧できるかを検証します。

マルチAZで可用性を高める

AWSリージョンは、複数のAvailability Zone（AZ）で構成されています。ワークロードを複数AZに分散すると、1つのAZで障害が発生しても、別のAZを利用してサービスを継続・復旧できます。

フェイルオーバー方式は、利用するAWSサービスやシステム構成によって異なります。データの保護方法や切り替え手順も事前に設計します。

マルチリージョンで広域障害に備える

リージョン全体の障害まで想定する場合は、別リージョンに復旧環境を用意します。

構成としては、別リージョンへデータを複製して障害時に環境を立ち上げる方法と、平常時から複数リージョンで稼働してトラフィックを切り替える方法があります。

マルチリージョンでは、データ同期、トラフィックの切り替え、復旧後の切り戻しなど、設計・運用の範囲が広がるため、必要な復旧水準とコストを踏まえて採用を判断します。 

RTO・RPOとコストに応じてDR戦略を選ぶ

複数リージョンでDRを設計する場合、AWS Well-Architected Frameworkでは、次の4つの戦略が示されています。 

復旧時間を短縮するほど、平常時に必要なリソースや運用負荷は大きくなる傾向があります。利用するAWSサービスやアプリケーション構成、データ同期方式も考慮し、必要な復旧水準を満たせる戦略を選びます。

AWSで障害が発生したときの復旧手順

障害発生時は影響範囲を把握し、事前に決めた基準に沿って復旧方法を選びます。サービスへの影響が大きい場合は、原因の完全な特定を待たずにフェイルオーバーやリストアを進め、詳細な原因分析は復旧後に行います。

1. 障害情報と影響範囲を確認する

AWS側の障害は、AWS Health Dashboardで確認できます。サインインすると、自社アカウントのサービスやリソースに関係するイベントも確認できます。

自社システムについては、監視情報やログから、影響を受けているリソース、エラーの内容、発生時刻などを把握し、復旧方針の判断材料とします。

2. 復旧方針を判断してフェイルオーバー・リストアを行う

障害の種類と復旧目標に応じて対応を選びます。正常な環境へ処理やトラフィックを切り替えられる場合はフェイルオーバーを実行し、データの破損や消失がある場合は復旧時点を決めてバックアップからリストアします。

復旧方法や判断条件をランブックなどに定めておけば、障害発生後の判断や作業開始までの時間を短縮できます。

3. 復旧後の正常性を確認する

アプリケーションの動作、データの欠損や不整合、外部システムとの連携、監視やアラートの状態を確認します。

インフラが稼働しているだけでなく、ユーザーがサービスを正常に利用できる状態になったことを確認して復旧完了とします。

4. 原因を分析して再発防止につなげる

サービス復旧後は、障害の原因に加え、検知や復旧判断に時間がかかった要因、復旧手順が想定どおり機能したか、設定した復旧目標を達成できたかを確認します。

課題はアーキテクチャ、監視設定、ランブック、対応体制などへ反映し、同様の障害が発生した際の復旧時間短縮につなげます。

障害からの復旧を早めるための運用対策

復旧時間を短縮するには、システム構成に加えて、監視、復旧手順、対応体制、テスト、自動化まで平常時から整備します。

監視とアラートで障害を早期検知する

Amazon CloudWatchでは、AWSリソースやアプリケーションのメトリクスを監視し、条件に応じてアラームを発生させ、通知や自動アクションにつなげられます。

監視対象やしきい値だけでなく、アラートを受けた担当者が何を確認し、どの条件で復旧対応へ移るかも決めておきます。

>> 関連記事：AWS監視設計の基本｜CloudWatch活用と運用設計のポイント

復旧手順と対応体制を事前に整備する

想定する障害ごとに、確認項目、判断基準、復旧方法、担当者、連絡先、エスカレーション先をランブックなどにまとめます。

夜間や休日にも稼働するシステムでは、24時間365日の対応体制も必要です。自社だけで維持しにくい場合は、外部支援の活用も選択肢となります。

サーバーワークスでは、AWS環境の24時間365日の監視を提供しており、プランに応じて標準障害対応や復旧対応も委託できます。 

DRテストで実際に復旧できるか確認する

DRテストでは、バックアップからの復元、フェイルオーバー、ランブックの実行などを検証します。

確認対象は、復旧の成否だけではありません。復旧時間やデータの状態から目標の達成度を評価し、見つかった課題をシステム構成、監視設定、復旧手順へ反映します。 

復旧作業を自動化・標準化する

定型的な復旧作業を自動化すると、作業時間の短縮や操作ミスの抑制につながります。

たとえば、AWS Systems Manager Automationでは、AWSリソースに対する一連の処理をランブックとして定義できます。

自動化するのは、処理内容と判断条件が明確で、事前にテストできる作業です。人の判断が必要な工程と分けることで、担当者による対応のばらつきも抑えられます。 

まとめ

AWS障害への備えでは、業務への影響を踏まえて復旧目標を定め、バックアップ、マルチAZ、マルチリージョン、DR戦略を選びます。

障害時は影響範囲から復旧方法を判断し、フェイルオーバーやリストアを実行します。その後、原因分析と再発防止へつなげる流れです。

平常時から監視、ランブック、DRテスト、自動化を整備し、復旧にかかる時間を短縮します。24時間365日の対応が必要な場合は、AWS運用支援も活用し、自社の監視・障害対応体制を補完しましょう。