災害対策と事業継続計画（BCP）！DR戦略とバックアップの設計
こんにちは！現役クラウドエンジニアのAkrです。
「【AWSプロフェッショナルへの道】現役クラウドエンジニアが贈る実践ガイド」の第24回をお届けします。前回は、KMSとSecrets Managerを使ってデータの暗号化と機密情報の管理方法を学び、セキュリティの最後の砦を築きました。しかし、地震、津波、大規模な停電、または人為的なミスによるシステム障害といった災害は、いつ発生するかわかりません。
今回は、これらの不測の事態に備えるための災害対策（Disaster Recovery - DR） と 事業継続計画（Business Continuity Plan - BCP） をテーマに、AWSでどのようにDR戦略を設計し、バックアップ体制を構築するかを徹底的に解説します。
「障害が発生したらどうすればいいの？」「本番環境のデータをどうやって守ればいいの？」「どのくらいの時間で復旧できればいいの？」といった疑問を持つかもしれません。DR戦略は、ビジネスの継続性を確保するために不可欠な要素です。本記事では、DR戦略を立てる上で重要な指標であるRPOとRTOから、AWSが提供する主要なDR戦略、そしてAWS Backupサービスを使った効率的なバックアップ管理までを学び、ビジネスの継続性を守るためのスキルを身につけます。
1. DR戦略の基本：RPOとRTO
DR戦略を立てる上で最も重要な指標が、RPOとRTOです。これらの目標値を明確に定義することから、DR戦略の設計は始まります。
-
RPO (Recovery Point Objective - 目標復旧時点):
- 災害発生時にどの時点までのデータ損失を許容できるかを示します。
- 例えば、「RPOが1時間」であれば、最大1時間分のデータ損失は許容できます。RPOが短いほど、より頻繁なバックアップやデータレプリケーションが必要になります。
-
RTO (Recovery Time Objective - 目標復旧時間):
- 災害発生後、どのくらいの時間でシステムを復旧できるかを示します。
- 例えば、「RTOが4時間」であれば、4時間以内にシステムを完全に復旧させ、サービスを再開する必要があります。RTOが短いほど、より高度で自動化されたDR戦略が必要になります。
RPOとRTOの要件は、アプリケーションの重要度によって異なります。ミッションクリティカルなシステムほど、RPOとRTOは短く設定する必要があります。
2. AWSが提供する主要なDR戦略
AWSでは、RPOとRTOの目標値に応じて、以下の4つの主要なDR戦略をサポートしています。コストと複雑さも考慮して、適切な戦略を選択します。
2.1. バックアップ＆リストア (Backup and Restore)
- 概要: 最もシンプルで低コストな戦略です。本番環境のデータを定期的にバックアップし、災害発生時にそのバックアップから新しい環境にリストア（復元）します。
- RPO/RTO: RPOはバックアップの頻度によって決まります。RTOはリストアと復旧にかかる時間次第なので、数時間から数日と長くなる傾向があります。
- AWSサービス: AWS Backup、S3、EBSスナップショット、RDSスナップショットなど。
- 適しているケース: RPOとRTOが比較的長くても許容できる、重要度の低いアプリケーションや、開発・テスト環境。
2.2. パイロットライト (Pilot Light)
- 概要: 本番環境のコアコンポーネント（最小限のインスタンスやデータベース）を別のリージョンに常に起動させておき、災害発生時に残りのリソースを迅速にスケールアップします。
- RPO/RTO: バックアップ＆リストアよりもRPOとRTOが短くなります。データはほぼリアルタイムでレプリケーションされますが、RTOはスケールアップにかかる時間によって決まります。
- AWSサービス: RDSリードレプリカ、EBSスナップショットのリージョン間コピー、Auto Scalingグループなど。
- 適しているケース: 中程度の重要度を持つアプリケーション。
2.3. ウォームスタンバイ (Warm Standby)
- 概要: 本番環境の縮小版を別のリージョンに常に稼働させておきます。災害発生時には、この縮小版にトラフィックを切り替え、必要に応じてスケールアップします。
- RPO/RTO: パイロットライトよりもさらにRPOとRTOが短くなります。災害発生時にすぐにトラフィックを受け入れられるため、RTOは数分から数時間と短くなります。
- AWSサービス: Route 53、ALB、EC2インスタンス、RDSなど。
- 適しているケース: 重要なアプリケーションで、数時間のサービス停止が許容される場合。
2.4. マルチサイトアクティブ/アクティブ (Multi-Site Active/Active)
- 概要: 複数のリージョンで本番環境と全く同じ規模のシステムを同時に稼働させ、常にトラフィックを分散させます。
- RPO/RTO: ほとんどゼロに近いRPOとRTOを実現できます。一つのリージョンに障害が発生しても、他のリージョンがサービスを継続するため、ダウンタイムはほぼ発生しません。
- AWSサービス: Route 53のフェイルオーバー、ALB、RDSマルチAZ、DynamoDBグローバルテーブルなど。
- 適しているケース: RPOとRTOがほぼゼロでなければならない、ミッションクリティカルなアプリケーション。
3. AWS Backupを活用したバックアップの設計と管理
DR戦略の基本となるバックアップ＆リストア戦略を効率的に実現するのがAWS Backupです。
3.1. AWS Backupとは？
- AWS Backupは、EC2、EBS、RDS、DynamoDB、EFS、S3など、複数のAWSサービスにわたるバックアップを一元管理するフルマネージドサービスです。
- バックアップ計画（Backup Plan）を一度設定すれば、あとは自動的にバックアップ、保持、削除を行ってくれます。
3.2. 実践！AWS Backupでバックアップ計画を立てよう
EC2インスタンスのバックアップを自動化するバックアップ計画を作成してみましょう。
- AWSマネジメントコンソールで「AWS Backup」サービスに移動します。
- 左のナビゲーションペインから「バックアッププラン」→「バックアッププランを作成」をクリックします。
-
バックアッププランの作成方法: 「
プランを定義する」を選択します。 -
バックアッププラン名:
weekly-ec2-backup -
バックアップルール:
-
バックアップルール名:
weekly-rule -
バックアップ頻度:
毎週 - バックアップウィンドウ: バックアップを開始する時間帯を、システムへの影響が少ない時間（例: 深夜）に設定します。
-
ライフサイクル:
- 移行先: バックアップを低コストなコールドストレージに移行するまでの期間を設定できます。
- 保持期間: バックアップを保持する期間を設定します。
-
バックアップルール名:
-
リソースの割り当て:
- バックアップ対象とするリソースを指定します。
-
リソースの割り当て名:
ec2-resources -
リソースの選択: 「
リソースタイプ」でEC2を選択し、「リソースID」でバックアップ対象のEC2インスタンスを選択します。 -
タグ付けによる選択:
keyとvalueでタグを指定して、自動的に対象を増やすこともできます。
- 「プランを作成」をクリック。
これで、指定したスケジュールで自動的にEC2インスタンスのバックアップ（EBSスナップショット）が取得され、設定した期間保持されるようになります。
4. まとめ
今回は、災害に備えるためのDR戦略とバックアップの設計について、AWSのサービスを交えて学びました。
- RPO（目標復旧時点） と RTO（目標復旧時間） という2つの重要な指標を理解し、これに基づいてDR戦略を選択する必要があることを学びました。
- AWSが提供する4つの主要なDR戦略（バックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイトアクティブ/アクティブ）の特徴と使い分けを学びました。
- AWS Backupサービスを使って、EC2インスタンスなどのバックアップを効率的かつ自動的に管理する方法を実践しました。
災害対策は、システムの信頼性とビジネスの継続性を確保する上で不可欠です。この知識は、あなたのサービスを不測の事態から守るための重要な武器となるでしょう。
この記事が皆さんのAWS学習の一助となれば幸いです。
もしこの記事が役に立ったと感じたら、ぜひ「いいね」👍をお願いします！励みになります！