Amazon Web Services ブログ
クラウドでのスケーラブルでコスト効率に優れた災害対策
災害が発生した場合、ビジネスを継続するために定期的なデータバックアップ以上のことが必要になる場合があります。ビジネスの目標復旧時間 (RTO) を満たす完全リカバリには、データの処理に使用されるインフラストラクチャ、オペレーティングシステム、アプリケーション、および構成も含める必要があります。ランサムウェアの脅威の増大に伴い、完全なポイントインタイムリカバリを実行できる必要性が浮き彫りになっています。ランサムウェア攻撃の影響を受けた企業では、古い、場合によっては手動のバックアップからデータを復元するだけでは不十分です。
これまで、企業は物理的災害対策 (DR) インフラストラクチャを個別にプロビジョニングすることを選択していました。しかし、要求されるまでアイドル状態のままであるハードウェアや設備への投資を伴い、スペースとコストの両方が法外になる可能性があるとお客様から伺っています。また、このインフラストラクチャは、要求があった場合、現在のビジネス負荷は最初のプロビジョニング以降に大幅に増加している可能性があり、これに対応できる状態にあることを確認するため、通常手動で行われる定期的な検査とメンテナンスに関するオーバーヘッドも発生します。これにより、テストが困難になり、コストも高くなります。
2021 年 11 月 17 日（米国時間）、CloudEndure Disaster Recovery に基づく、物理的サーバー、仮想サーバー、およびクラウドサーバー向けの、完全にスケーラブルで費用対効果に優れた AWS Elastic Disaster Recovery (DRS) を発表できることを嬉しく思います。
DRS により、お客様は、必要になるまでアイドル状態のままのオンプレミスの DR インフラストラクチャに投資することなく、AWS を弾力性のあるリカバリサイトとして使用できます。有効化されると、DRS はオペレーティングシステム、アプリケーション、データベースのレプリケーションを常時維持します。これにより、企業は、災害発生後、数秒の目標復旧時点 (RPO)、数分の RTO を達成できます。例えば、ランサムウェア攻撃の場合、DRS は以前の時点へのリカバリも可能にします。
DRS は、現在のセットアップに合わせて必要に応じて拡張できるリカバリを提供し、その準備状態を維持するために時間のかかる手動プロセスを必要としません。また、災害対策読み取り演習を実施する機能も備えています。バックアップからのデータのリストアをテストすることが重要であるのと同様に、継続的なレプリケーションやユーザーアクティビティに影響を与えることなく、コストパフォーマンスに優れた方法でリカバリ演習を実施できれば、リカバリを依頼する必要がある場合に、目標とお客様の期待に応えることができるという確信を得ることができます。
Elastic Disaster Recovery の実行
有効化されると、DRS は物理的サーバー、仮想サーバー、またはクラウドベースのサーバーからブロックストレージボリュームを継続的に複製し、数秒で測定されるビジネス RPO をサポートできるようにします。リカバリには、物理的インフラストラクチャ、VMware vSphere、Microsoft Hyper-V、および AWS へのクラウドインフラストラクチャで実行されているアプリケーションが含まれます。サポートされている Windows および Linux オペレーティングシステムで実行されるすべてのアプリケーションとデータベースをリカバリできます。DRS は、AWS 上のサーバーのリカバリプロセスを調整し、数分で測定される RTO をサポートします。
DRS は、サーバーにインストールしたエージェントを使用して、AWS アカウント内の選択したリージョンのステージングエリアサブネットにデータを安全にレプリケートします。ステージングエリアサブネットは、手頃な価格のストレージと最小限のコンピューティングリソースを使用して、コストを削減します。DRS コンソール内では、必要に応じて、別のAWS リージョンにある Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをリカバリできます。DRS のレプリケーションとリカバリの手順を自動化することで、特別なスキルセットを必要とせずに、1 つのプロセスで災害対策機能をセットアップ、テスト、運用できます。
DRS は、長期契約や一定数のサーバーを契約する必要がなく、時間単位で支払うという柔軟性を提供します。これは、オンプレミスまたはデータセンターのリカバリソリューションよりもメリットがあります。DRS は、従量制料金制で時間単位で課金されます。料金の詳細については、製品ページをご覧ください。
Elastic Disaster Recovery を探る
リソースの災害対策を設定するには、まずデフォルトのレプリケーション設定を構成する必要があります。前述したように、DRS は、物理的サーバー、仮想サーバー、クラウドのサーバーで使用できます。この記事では、災害対策用のソースサーバーとして EC2 インスタンスの収集を使用します。
前述の DRS コンソールのホームから、[デフォルトのレプリケーション設定の設定] を選択すると、短い初期化ウィザードが表示されます。ウィザードでは、ステージングに使用する Amazon Virtual Private Cloud (VPC) サブネットを最初に選択する必要があります。このサブネットは自分のリソースと同じ VPC にある必要はありませんが、プライベートではない、または世界に対してブロックされていないサブネットを選択する必要があります。以下では、自分のリージョンのデフォルト VPC からサブネットを選択しました。レプリケーションインスタンスに使用するインスタンスタイプを変更することもできます。推奨されるデフォルト値をそのまま使用することを選択し、[次へ] をクリックして続行します。
また、次の 2 ページではデフォルト設定を変更せずに残しました。 ボリュームとセキュリティグループでは、ウィザードは汎用 SSD (gp3) Amazon Elastic Block Store (EBS) ストレージタイプを使用し、DRS が提供するセキュリティグループを使用することを提案します。[追加設定] ページでは、パブリックインターネット経由でルーティングするのではなく、データレプリケーションにプライベート IP を使用することを選択し、スナップショットの保持期間 (デフォルトは 7 日間) を設定できます。最後に [次へ] をクリックすると、ウィザードの [レビューと作成] ページが表示されます。[デフォルトの作成] を選択すると、デフォルトのレプリケーション設定を構成するプロセスが完了します。
レプリケーション設定が確定したら (必要に応じて、[ソースサーバー] コンソールページの [アクション] メニューから後で編集できます)、サーバーをセットアップします。2 つの Windows Server 2019 インスタンスと 3 つの Amazon Linux 2 インスタンスを含むテストフリートを EC2 で実行しています。DRS ユーザーガイドには、各サーバタイプでエージェントを入手してセットアップする方法に関する詳細な説明が記載されているため、ここでは繰り返しません。各サーバーインスタンスでエージェントを実行して構成すると、ソースサーバーリストが自動的に更新され、新しいソースサーバーが追加されます。このビューには、初期同期のステータス、および各ソースサーバーの将来のレプリケーションとリカバリのステータスがまとめられています。
リストでホスト名のエントリを選択すると、詳細ページが表示されます。ここでは、リカバリダッシュボード、基盤となるサーバに関する情報、ディスク設定 (初期化ウィザードで選択したデフォルトの gp3 タイプまたはセットアップ中に選択したタイプからステージングディスクタイプを変更する機能を含む)、演習または実際のリカバリジョブを開始することを選択した場合に作成されるリカバリインスタンスを管理する起動設定 (以下を参照) を表示できます。
データバックアップと同様に、バックアップがデータの復元に実際に使用できることを定期的に検証することが確立されたベストプラクティスですが、災害対策にも同様のベストプラクティスをお勧めします。そこで、サーバーがすべて構成され、完全にレプリケートされた状態になったので、2 台のサーバーについてポイントインタイム (PIT) リカバリの演習を開始することにしました。これらのインスタンスでは、最初のレプリケーションに続いて、追加のソフトウェアをインストールしました。私の予想では、おそらくこのインストールがひどく間違っていたか、ランサムウェア攻撃の被害に遭った可能性があります。いずれにせよ、必要なときにサーバーをリカバリできることを知り、確信したかったのです。
ソースサーバーリストで、変更した 2 つのサーバーを選択し、[リカバリジョブの開始] ドロップダウンメニューから [演習の開始] を選択します。次に、関心のあるリカバリ PIT を選択します。このビューはデフォルトで [Any] に設定され、選択したサーバーのすべてのリカバリ PIT スナップショットが一覧表示されます。または、[すべて] にフィルターを適用することもできます。つまり、選択したすべてのサーバに適用される PIT スナップショットだけが一覧表示されます。[すべて] を選択し、インスタンスへの追加ソフトウェアのインストールが完了した直後の時間を選択し、[演習の開始] をクリックしました。
ソースサーバーリストに戻ります。このリストには、リカバリが進むにつれてステータスが表示されます。ただし、詳細については、リカバリジョブ履歴ビューに切り替えました。
ジョブ ID をクリックすると、さらにドリルダウンして、リカバリに関係する (およびそれぞれをさらにドリルダウンできる) ソースサーバの詳細ページと、リカバリジョブログ全体を表示できます。
注 — 演習または実際のリカバリの最中に EC2 コンソールにアクセスすると、DRS によって開始され、(レプリケーションサーバーに加えて) アカウントで実行されている 1 つ以上の追加のインスタンスがわかります。AWS Elastic Disaster Recovery Conversion Server という名前のこれらの一時インスタンスは、PIT スナップショットを実際の復旧インスタンスに処理するために使用され、ジョブが完了すると終了します。
復旧が完了すると、自分の EC2 環境に 2 つの新しいインスタンスが表示されます。これらは、選択したポイントインタイムリカバリと一致する状態であり、DRS 初期化ウィザードで前に選択したインスタンスタイプを使用しています。これでリカバリ演習を終了する前に、これらに接続してリカバリ演習が期待どおりに実行されたことを確認できます。これが実際のリカバリだったとしたら、元のインスタンスを終了してリカバリバージョンに置き換えるか、ビジネスの災害対策を完了するために必要なその他のタスクを処理するかを選択できます。
災害対策環境を今すぐセットアップする
AWS Elastic Disaster Recovery は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、および欧州 (ロンドン) のリージョンで一般提供されています。セットアップと運用の詳細については、AWS Elastic Disaster Recovery ユーザーガイドを確認し、DRS の利用を今すぐ開始して、アイドル状態のリカバリサイトリソースの排除、従量制料金の使用、デプロイの簡素化を行い、災害対策目標を改善しましょう。
原文はこちらです。