re:Invent 2024: AWSのバックアップとDR戦略 - Elastic DRとBackupの活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Backup and disaster recovery strategies for increased resilience (COP319)
この動画では、データ保護とDisaster Recoveryの選択肢について解説しています。RPOとRTOの要件に基づいてアプリケーションを4つのTierに分類し、Tier 1/2にはAWS Elastic Disaster Recovery、Tier 3/4にはAWS Backupを活用する方法を紹介しています。特にAWS Elastic Disaster Recoveryは、低コストでPilot Light構成を実現しながら、Warm Standbyレベルの復旧時間とHigh Availabilityに近い復旧ポイントを達成できる点が強調されています。また、ローカルコピー、リモートコピー、Vaultedコピーという3層構造での保護戦略や、Data Bunkerアカウントを活用したRansomware対策など、具体的な実装方法についても詳しく説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
データ保護の進化：選択肢の拡大とAWSの役割
今日は皆さんに質問があります。ほとんどの方は飛行機でここまでいらっしゃったと思いますが、お父さんやお母さんが学校まで歩いていた、しかも雪の中、上り坂を往復で歩いていた、という経験をお持ちの方はどれくらいいらっしゃいますか？昔は、どこに行くにも歩いていましたよね。どこかに行きたければ、歩くしかなかったんです。他の選択肢はありませんでした。でも今のre:Inventでは、選択肢がたくさんあります。歩くこともできます - 私は昨日19,000歩も歩きました。バスに乗ることもできますし、タクシーやUberを使うこともできます。ここでも、人生でも、移動手段を選べるようになったんです。
バックアップと災害復旧について考えてみると、長い間、そのプロセスには一つの方法しかありませんでした。データをテープにコピーし、時にはそのテープをさらにコピーしてオフサイトに保管する。いつも同じやり方でした。しかし、今日の環境では、より多くの選択肢があります。DRを実現するのか？バックアップ、レジリエンス、可用性のどれを使うのか？そしてコンプライアンスにはどう対応するのか？今日は、こういった判断の仕方と、皆さんの環境でどのように実践できるかについてお話ししていきます。
私はMarkです。こちらは同僚のYanivです。これから、私たちが日々お客様のこうした意思決定をどのようにサポートしているかについてご紹介していきます。Markが言及したように、選択肢があり、正解にたどり着くための方法は一つではありません。そこで、まずは組織にとって適切なツールとアプローチを理解するための基本的な要因を見ていきましょう。
このスライドはよく使うもので、もしかしたら使いすぎかもしれませんが、データのレジリエンスとデータ保護について話すとき、このメンタルモデルが非常に重要だと考えています。AWSはクラウドに責任を持ちます。つまり、データ保護の文脈では、クラウドのレジリエンスに責任を持ちます。一方、お客様はクラウド内のデータに責任を持ちます。AWSはRegion、Availability Zone、パッチ適用、物理的セキュリティに責任を持ち、お客様はアーキテクチャ、ネットワーキング、アプローチ、ソリューション、選択するツールに責任を持ちます。しかし、お客様が責任を持つべき重要な点として、コンプライアンスの確保とデータのテストがあります。
テストを行い、コンプライアンスを確保することは非常に重要です。私の友人が数年前、テープバックアップを使用していた会社にいたときの話ですが、災害が発生しました。大きな被害ではありませんでしたが、実際にバックアップからリストアしようとしたとき、テープは空っぽで、何ヶ月もバックアップが取られていなかったことが判明したのです。必要なときにデータが利用できることを確認しておく必要があります。テストは本当に重要で、この後も繰り返し強調していきます。
皆さんのほとんどがご存知かと思いますが、次の基本的な概念はRPOとRTOです。RPO（Recovery Point Objective：目標復旧地点）は、どれだけのデータ損失まで許容できるか、つまり最新のスナップショットがどれだけ新しいものになるかを示します。RTO（Recovery Time Objective：目標復旧時間）は、どれだけのダウンタイムまで許容できるか、つまりどれだけ早くシステムを復旧させる必要があるかを示します。もちろん、両方ともできるだけ低い値が望ましいのですが、その値を下げることと、コストや解決策の複雑さとの間にはトレードオフが存在します。
一方では、より高いRPOとRTOを許容する場合、数時間単位の比較的シンプルな解決策、つまりBackupを選択することができます。より高度な機能を持ち、より低いRPOとRTOを実現する解決策として、Disaster Recoveryがあります。そして、もう一方では、非常に複雑で高価にはなりますが、ほぼリアルタイムで対応できるHigh Availabilityがあります。ここで疑問となるのは、これらの選択肢の中からワークロードに対してどれを選ぶべきかということです。RPOとRTOが分かったら、まず最初にアプリケーションの階層化（Tiering）を行う必要があります。
AWS Elastic Disaster Recovery：柔軟な災害復旧ソリューション
標準化された階層化を使って、アプリケーションをグループ化する方法を理解する必要があります。 これまで19の階層を持つお客様や、たった1つの階層しか持たないお客様と仕事をしてきました。1つというのは少なすぎますし、19というのはおそらく多すぎます。まずは4つの階層から始めることをお勧めします。ここで理解していただきたいのは、環境の大部分がTier 1やTier 2になるわけではないということです。最も早い復旧時間と最も低い目標復旧地点のカテゴリーに入るのは、およそ30%程度になるはずです。
これらの異なる階層を実現するためのAWSプロダクトを見てみると、Tier 1とTier 2の環境にはAWS Elastic Disaster Recovery（DRS）が優れたソリューションとなります。Tier 3とTier 4にはAWS Backupが適しており、これらについては後ほど詳しく説明します。 まずはDRSについて説明しましょう。オンプレミスやクラウド（AWSを含む）上のすべてのサーバーにインストールするAgentから始まります。EC2サーバーの場合は、このAgentで保護します。データは継続的にAWSクラウドの別の部分に送信されます。データが書き込まれると、Continuous Data Protectionと呼ばれるプロセスを通じて、可能な限り早くコピーを作成します。このサービスは、復旧に必要なEC2サーバーとEBSデバイスの作成を自動化します。
ここで基本に立ち返ってみましょう。AWSは世界中に34のRegionを持っており、各Regionには少なくとも1つのAvailability Zoneがあります。これは少なくとも1つのデータセンターで構成され、他のAvailability Zoneから分離されています。これらが、アーキテクチャやワークロードを構築する際の基本的な構成要素となり、異なるRegionやAvailability Zoneに配置することで、耐障害性の高いワークロードを構築できます。データをAWSに移行すると、ストレージには冗長性と耐久性が組み込まれているため、安心です。私たちはテストと監査を実施し、冗長化されたデバイスにデータを保存します。
しかし、水害、火災、地震などによってデータを失う可能性のある状況が発生することがあります。 必ずしも不可抗力の出来事である必要はありません。アプリケーションデータの破損、単純なヒューマンエラー、Ransomware、悪意を持って環境に侵入してデータを破壊する者、あるいはデータを削除してしまう誤ったポリシー変更かもしれません。AWSは削除リクエストに従わなければならず、インフラストラクチャも破損する可能性があります。AWS環境では、EC2インスタンスが故障したり、データベースに障害が発生したりする可能性があります。さらに、自然災害やAWSの地域的な障害によって、リージョンやAvailability Zoneが影響を受けることもあります。
リソースを保護するためのベストプラクティスは普遍的で、考慮すべき点が多くあります。ベストプラクティスとして、迅速な対応のためのローカルコピー、災害復旧のためのリモートコピー、そしてサイバーレジリエンスのためのVaultedコピーを持つべきです。特に注目したいのはブロックストレージです。その理由は、AWSのブロックストレージであるAmazon EBSが単一のAvailability Zoneリソースであるためです。ほとんどのワークロードがブロックストレージで実行されるサーバーベースのアプリケーションであるため、Availability Zone障害時でもレジリエントであることを確保する必要があります。
オンプレミスから移行されたワークロードのほとんどは、ブロックストレージとしてAmazon EBSを使用しています。そのため、ワークロードの保護方法について考える必要があります。 これは基本的なレベルから始まり、スナップショットを取得することができます。AWSにはData Lifecycle Managerのようなスナップショットをスケジュールできるツールがあり、不要なアクセスをブロックする、あるいは少なくともブロックするための予防措置を講じることができます。
さらに高度な対策も可能です。 その上にDisaster Recoveryソリューションを追加できます。Disaster Recoveryソリューションは、重要度の高いワークロードに対してRTOとRPOを低く抑えられるだけでなく、ソース環境を中断することなくテストを実施する機能も提供します。これは監査やコンプライアンスの確保を考える際に非常に重要で、特に規制当局から運用を中断することなく保護されていることを示すよう求められる場合に重要です。
そして、包括的な保護のためにバックアップソリューションを追加することができます。先ほど見たように、サイバーレジリエンスへの対応に役立つVaultedコピーを保持することができます。 AWSは、コンプライアンスの状況やレジリエンスの状態を理解するための様々なツールを提供しています。また、これらの機能を提供する優れたパートナーやサードパーティツールも用意されています。
クラウド時代のDisaster RecoveryとBackupの新たな可能性
では、AWSではどのようなアプローチを取るべきか、話を戻しましょう。先ほど、レジリエンス戦略には個別の選択肢があり、High Availabilityはバックアップではなく、バックアップはDisaster Recoveryではないという話をしました。しかし、AWSでDisaster Recoveryを利用し始めると、何年も前には存在しなかったものがあります。それは「Elasticity（弾力性）」です。 クラウドには、ディスク、帯域幅、コンピューティングパワーの面で大量の余剰キャパシティがあります。 そのため、もはや個別のオプションを選ぶ必要はなくなりました。
より柔軟なフレームワークが手に入ったのです。Pilot LightやWarm Standbyのような新しいクラウドDisaster Recovery戦略が実現可能になりました。これらは以前は非常に高価な構成でしか実現できなかったものです。 現在では、AWS Elastic Disaster Recoveryサービスを使用することで、Pilot Lightのコストで、Warm Standbyの時間目標を達成し、さらにはHigh Availabilityソリューションに近いRecovery Point Objectiveを実現できます。しかもPilot Light構成の低コストで実現できるのです。
これにより、以前のオンプレミスのDisaster Recoveryソリューション（プライマリサイトと同じくらい高価なリカバリサイトが必要でした）が、 はるかに低コストのクラウドベースのリカバリオプションに変わりました。より多くのパターンが使えるようになっています。オンプレミスからAWSへ、あるいは他のクラウドからAWSへの移行だけでなく、リージョン間やAvailability Zone間での保護も可能です。単一のAvailability Zoneで実行されているワークロードを、別のAZや別のリージョンに自動的に保護したり、他のクラウドワークロードをAWSに保護したり、オンプレミスワークロードをAWSに保護したりすることができます。
AWS Elastic Disaster Recoveryには5つの主要なメリットがあります。最初の3つ、つまり迅速なリカバリ、低コスト、データ保護については既にお話ししました。ここでは残りの2つ、簡単なテストとランサムウェアからのリカバリについてお話ししたいと思います。 テストは、Disaster Recoveryプロダクトの設定、デプロイ、運用のライフサイクルの一部であるべきです。セットアップし、テストを行い、その後フェイルオーバーに備えた運用状態に入ります。必要な時にスイッチを切り替え、すべてをDisaster Recoveryサイトにフェイルオーバーし、そしてフェイルバックします。ただし、テストは1回限りのものではありません。年1回、あるいはもっと頻繁に、より定期的なサイクルで考える必要があります。
AWS Elastic Disaster RecoveryサービスはAmazon EBSをベースに構築されており、スナップショットを使用します。
これらのスナップショットは本質的に不変であり、ランサムウェア被害からの迅速な復旧に最適なソリューションとなっています。本番環境とDR環境のアカウントを分離する堅牢な機能を備えており、同時に侵害されることを防ぎます。主要なAWS Partnerが提供するEndpoint Detection and Responseツールと連携して、イベントを特定し、AWS DRS内で復旧計画を立てることができます。Point-in-Time Recovery機能により、設定した期間内に収集されたスナップショットから復元することが可能です。
AWS Elastic Disaster Recoveryサービスのエージェントの仕組みについてご説明しましょう。物理サーバー、仮想サーバー、クラウドベースのサーバーなど、既存のサーバーにエージェントをインストールすることで、AWS Cloudにデータを送信します。 AWS Cloudに送信されたデータは、私たちが「ステージングゾーン」と呼ぶ場所に保存されます。このステージングゾーンには、ステージングサーバーに接続されたEBSボリュームを含むVPCがあります。レプリケーションサーバーがソースからすべてのデータを受信し、EBSディスクに保存します。 復旧が必要になった場合は、ボタンをクリックするだけで、リカバリーターゲットサーバーとリカバリーターゲットEBSデバイスのリソースが作成されます。
これらはすべてお客様のアカウント内で動作するため、完全なコントロールが可能です。データは、お客様のポリシーに従って、お客様の暗号化キーで暗号化されますが、すべての処理はお客様のアカウント内で行われます。レプリケーションサーバーイメージの管理や復旧環境への変換プロセスは私たちが担当しますが、すべてお客様のアカウント内で透明性を持って実行されます。このプロセスは、リージョン間やAvailability Zone間の復旧でも同様に機能し、 データはステージングアカウントに流れ込み、そこからターゲットアカウントへと復旧が行われます。
AWS Backupは異なる目的で使用され、これについては同僚が説明させていただきます。開発チームのメンバーとして、Markと私はDRとその利点について長々と話すことができますが、私たちにはバイアスがあることを認識しています。ステージングエリアの軽量なコンピューティングとストレージリソースによってPilot Light実装のコストを削減するよう努めていますが、それでもPilot LightはBackupよりコストがかかります。データの重要性が低いTier 3やTier 4のアプリケーション、あるいはAWS Elastic Disaster Recoveryで保護できないリソースについては、Backupの方が適している場合があります。
重要なのは、BackupかDRかという二者択一ではなく、両方が必要だということです。先ほど説明したように、DRをリモートコピーとして実装する場合でも、保管用コピーとしてのBackupソリューションが必要です。多くのお客様は、最初の数日間は AWS Elastic Disaster Recoveryを使用して1時間ごとのPoint-in-Time保護を行い、その後はAWS Backupを使用してコンプライアンス目的の週次、月次、年次スナップショットを低コストで保存しています。AWS Backupは、AWSアカウント内のすべてのサービスとリソースにわたってポリシーを設定できる、一元管理された完全マネージド型のツールで、包括的なコンプライアンス構造と分析インサイトを提供します。AWS Backupは主にクラウドリソースを扱いますが、Storage Gatewayを通じてオンプレミスのリソースにもアクセスできます。
サイバーレジリエンスの実現とベストプラクティス
Tier 3アプリケーションの例を見てみましょう。 Availability Zone環境では、EBSボリュームを持つEC2インスタンス、Amazon EFSファイルシステム、そしてAmazon RDSデータベースがあります。基本的な保護として、EBSボリュームのスナップショットを取得し、S3バケットに保存します。RDSインスタンスでも同様のプロセスを実行し、EFSファイルシステムはAWS Backupを使用してバックアップします。Availability Zoneが利用できなくなった場合、 S3バケットはリージョン全体で利用可能な状態を維持するため、別のAvailability Zoneにデータを復元することができます。EFSファイルシステムもリージョン全体で利用可能です。
基本的には、S3バケットからEBSスナップショットとデータベースのデータを素早く復元します。しかし、リージョン全体がダウンした場合で、クロスリージョンの回復力を確保したい場合はどうすればよいでしょうか？ここでのポイントは、ストレージ層、特にS3バケットとAWS Backupのレプリケーションにあり、S3バックアップのクロスリージョンレプリケーションを有効にすることができます。
リージョンがダウンした場合、同じプロセスに従います - S3バケットからEBSボリュームとRDSボリュームに復元します。この場合、EFSファイルシステムの復元にはAWS Backupを使用する必要があります。これが重要な違いです。なぜなら、EFSはリージョンレベルでの可用性しかありませんが、AWS Backupを使用して復元できるからです。より複雑なシナリオでは、データの破損やRansomwareの影響を受ける可能性があります。その場合はそれほど単純ではなく、対応を開始する前に、いつどのように影響を受けたのかを理解する必要があります。
サイバーレジリエンスのより高度なセットアップについて話す前に、このような状況から身を守るために重要なBackup Vaultの概念について説明しましょう。Backup Vaultは、バックアップリソースの論理的な構造で、アクセスの制御、ロック、個別の暗号化が可能です。Ransomwareから身を守りたい、より複雑な状況でどのように活用できるか見てみましょう。
この例では、Workloadアカウントでワークロードが実行されています。 Workloadアカウントで重要なのは、すべてのリソースにバックアップポリシーが設定され、確実にバックアップされていることです。 そして、Data Bunkerアカウントという概念があります。これは、侵害されにくくするために計算処理を行わないアカウントです。 このアカウントには特定時点のバックアップのみを保存し、それ以外の処理は一切行いません。
私たちのソリューションとログを使用して脅威を特定し、脅威が発生した時点とリストアしたい時点を把握したら、ワークフローを開始します。 このプロセスでは、データとPoint-in-timeバックアップを別のアカウントにプッシュします。このアプローチについて多くの質問を受けますが、プライマリアカウントが侵害されたことを想定する必要があります。そのため、このユースケースでは、別のアカウントでワークロードをリストアできる準備が必要です。影響を受けた時点で初めて、Backup Vaultを使用してリカバリを開始するために、そのPoint-in-timeデータを対象のアカウントにプッシュし始めます。
ここで重要なのは、脅威による影響を受けた時点を特定することです。しかし、最善のアプローチは、そもそも侵害を防ぐことです。AWSにはそのためのツールがあり、また多くのパートナー企業も優れたツールを提供しています。これらのアプローチについては、専用のセッションで詳しく説明されています。
これらすべてをまとめて、このコンセプトを振り返ってみましょう。同じAvailability Zone内にローカルコピーを持つことが重要です。これは、何かを誤って削除したり、ミスを犯したりした場合に、素早く復旧するためのタクティカルコピーです。また、リモートのDisaster Recoveryコピーも必要です。 本セッションでは、AWS Elastic Disaster Recoveryを提案しました。なぜなら、必要な数だけテストを実施でき、比較的低コストで低いRTOとRPOを実現でき、クロスリージョンで実行できるからです。さらに、ランサムウェアからの復旧用コピーも必要で、これによってサイバーレジリエンスを確保できます。
これら3つの層がベストプラクティスを表しています。 さて、約30分間のセッションを聞いていただいた後で、まだ実施していない場合、明日から何をすべきでしょうか？
まず最初に考えていただきたいのは、ビジネス要件に応じてアプリケーションを適切なティアに分類することです。Tier 1が何かを私たちが決めることはできません。それはビジネス側が決めることです。ビジネス側と話し合い、何が重要で、なぜ重要なのかを理解する必要があります。次に必要なのは、リカバリ機能のテストです。 年1回未満しかテストを行わない組織も多く見られる一方で、年に複数回テストを実施している組織も多く見られます。リカバリ機能のテストがいかに重要かということは、いくら強調してもし過ぎることはありません。実際、リカバリ機能のテストの重要性は、むしろ過度に強調したいくらいです。
今日だけでも、本番環境でどれだけの変更が発生しているか考えてみてください。パッチ適用は何回行われていますか？アプリケーションコードの変更は何回ありましたか？開発者が新しいアップデートをプッシュした回数は？これらの変更の量は、Recovery（復旧）にかかる時間に直接影響します。もしテストしていなければ、その時間は全く予測できないのです。そして4つ目のポイントとして、テストや復旧の際にトラブルシューティングの時間を確保することを確認してください。私たちは多くのお客様と復旧やテストを行っていますが、システムは起動するものの、すべてが正常に動作しないことがあります。トラブルシューティングの時間が必要なのです。RTOを設定する際にもこれを考慮してください。最後の変更の直後にテストを行っていない限り、100%すべてが正常に起動すると保証することはできません。ですから、必ずトラブルシューティングの時間を確保してください。
さて、これまで多くの選択肢について話してきました。実際、私たちにはDR、Backup、Complianceがあります。かつては、これらすべてを実現する方法は1つしかありませんでしたが、今はそうではありません。複数の目標があり、時にはそれらを達成するために複数のツールが必要になることもあります。BackupとDRの両方が重要で、脅威の種類や問題の原因によって、異なる復旧プロセスが必要になります。BackupとDRの戦略を設計する際には、このことを必ず考慮してください。では、本日はご参加いただき、ありがとうございました。このあと、もしくはセッション終了時に質疑応答の時間を設けていますので、ぜひアンケートにもご協力ください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion