Amazon Web Services ブログ

AWS 上で Google Cloud ワークロード向けのディザスタリカバリサイト構築 (Part 1)

ディザスタリカバリ (DR) 戦略を有することはビジネスの継続性やお客様のワークロードのレジリエンスの面において重要な要素です。レジリエンスとは、お客様のアプリケーションとそれを支えるインフラストラクチャが一貫して意図された通りに正しく実行し続ける事を意味します。

プライマリワークロードをクラウドで稼働させているお客様が DR のために別のクラウドプロバイダーを使用する場合があります。その理由としては、コンプライアンスや規制要件、あるいはお客様の組織でマルチクラウド戦略の採用を義務付けているためかもしれません。

この2部構成のブログシリーズでは、1例としてGoogle Cloud Platform (GCP) でホストされているサンプルアプリケーションの DR サイトとして AWS Cloud の使用が必要となるユースケースを取り上げます。

AWS と GCP 間のコネクティビティの構築、AWS Elastic Disaster Recovery (AWS DRS) を用いたソース環境 (GCP) から AWS へのレプリケーション、テスト及び GCP から AWS へのフェイルオーバー実施までの手順を説明します。最後にパート2の記事では、DR の試験のフォローアップのために、 AWS から GCP へフェイルバックを行います。

前提条件

  • AWS アカウントと GCP のプロジェクトがある事
  • Amazon Virtual Private Cloud (Amazon VPC) と必要なサブネットを有する GCP 上の Virtual Private Cloud がある事
  • GCP 上で数台のテスト用 VM を稼働させている事
  • AWS DRS のレプリケーションサーバーを稼働させるための Amazon VPC 上の専用サブネットがある事

ソリューションの概要とチュートリアル

次の図は、GCP から AWS への DR ソリューションのアーキテクチャの概要を表しています。

 

パート１となるこのブログでは、次の設定を行います。

  1. ネットワークの構成
  2. AWS DRS の設定
  3. DNS カットオーバーの実行

1. ネットワークの構成

レプリケーションに必要となるネットワーク接続を構成します。このパートを完了時には、次の図のような構成となります。

次の手順でネットワークの設定を行っていきます。

a. ネットワークコンポーネントを GPC と AWS 上に作成
b. GCP と AWS の間で site-to-site VPN 接続を確立
c. AWS DRS の前提条件を整える

a. ネットワークコンポーネントを GPC と AWS 上に作成

GCPでの作業

はじめに、Cloud Router のドキュメント中の手順に従い Cloud Router を作成します。 Network はプルダウンメニューから dr-vpc (前提条件の Step2 の手順中で作成済み)を選択します。同様に、 Region は us-central1 (Iowa)を選択し Google ASN は 65444 を入力します。

次に、 Cloud Architecture Center の手順に従い、GCP との VPN 接続を作成します。まず、 VPN 接続のタイプとして high availability (HA) を選択し、次に Cloud HA VPN gateway を作成します。その際に、VPN gateway name の名前の入力、VPC の選択(dr-vpc)、リージョンを選択 (us-central1)します。

VPN gateway が作成されると、2つのパブリック IPアドレス が割り当てられます。これらの IPアドレス は後ほど使用するため、値を控えておきます。

AWSでの作業

以下を作成していきます。

  • インターネットゲートウェイ

インターネットゲートウェイを作成し、VPC にアタッチします。詳細な手順は Amazon VPC User Guide を参照ください。

  • 仮想プライベートゲートウェイ (VGW)

デフォルト値である Amazon ASN (64512) を設定し、先ほど設定した Amazon VPC へアタッチします。詳細な手順は AWS VPN User Guide を参照ください。

仮想プライベートゲートウェイ作成後、Amazon VPC にアタッチします。

  • カスタマーゲートウェイ

各トンネルごとに1つずつ、合計2つのカスタマーゲートウェイを作成します。1つ目のカスタマーゲートウェイに対して、前手順 (GCP での作業) で控えておいた ASN と IP アドレスを設定します。同様に2つ目のカスタマーゲートウェイに対しても同様の手順で設定を進めていき、IP アドレスは控えておいた2つ目の IP アドレスを指定します。詳細な手順は AWS VPN User Guide を参照ください。

カスタマーゲートウェイの作成後、カスタマーゲートウェイのステータスが、Available となっていることを確認します。

b. AWS と GCP 間で Site-to-Site VPN を作成

注記:以降の手順を進める前に、GCP と AWS 双方のVPC 間の通信を行うため、ルーティングテーブルおよびセキュリティ構成(セキュリティグループ、ネットワークアクセスリスト、ファイヤーウォールルール等)に問題が無いことを確認します。

AWSでの作業

これまでの手順でネットワークコンポーネントの起動と実行が完了しているため、それらを使用し Site-to-Site VPN 接続の作成を進めます。 AWS マネジメントコンソールにて VPC の画面にアクセスし、左側ペイン中の Virtual private network (VPN) の下にある、 Site-to-Site VPN 接続を選択し、Create VPN Connection をクリックます。遷移する画面で、名前タグの欄に名前を設定し、先ほど作成した仮想プライベートゲートウェイとカスタマーゲートウェイの ID をそれぞれ選択します。ルーティングオプションは Dynamic (requires BGP)を選択します。その他の設定はデフォルトのまま、Create VPN connection をクリックします。詳細な手順はSite-to-Site VPN 接続の作成 を参照ください。

VPN 接続の作成後、トンネルが2つ作成されます。VPN 接続の状態は Pending と表示されており、作成した2つのトンネルがこの時点ではダウン状態であると表示されています。これらをアップ状態にするには、GCP 側での設定が必要となります。設定を行うために、先ほど作成した VPN 接続の設定ファイルをダウンロードします。ダウンロードしたファイルを開き、トンネル毎に以下パラメータが記載されている行を確認し、値を控えます。

  • Outside IP Addresses > Virtual Private Gateway
  • Inside IP Addresses > Customer Gateway
  • Inside IP Addresses > Virtual Private Gateway

2番目のVPN トンネルの作成も同様の手順を繰り返します。

GCPでの作業

ここからは GCP に切り替えます。 VPN 接続の作成を開始したページに戻り、引き続きピア構成を作成します。Add a peer VPN Gateway を選択し、2 つのインターフェイスを選択します。 Peer VPN gateway interfaces の下の Interface 0 IP address に、前の手順で作成した仮想プライベートゲートウェイの Outside IP アドレスを設定します。 Interface 1 IP address は、２番目のトンネルへ AWS から払い出されている仮想プライベートゲートウェイの別のOutside IP アドレスを設定します。この記事では、この部分の詳細については割愛いたします。

次に、ADD VPN TUNNELを選択し、BGP セッションの設定を行います。

AWS の ASN の値(64512)を設定します。Cloud Router の BGP IP と BGP Peer IP にAWS のIP を入力します。

この時点で VPN 接続の2つのトンネルのステータスが Established と表示され、BGP セッションステータスもEstablished となっているはずです。

AWS に戻り、同様にVPN トンネルが表示されていることを確認します。

C. AWS DRSの要件を整える

ソースサーバーのレプリケーションを行うため、AWS Replication Agent インストールを進めていきます。インストールの事前準備として、GCP からAWS の方向で2つ TCP ポート(1500と443)の許可が必要です。TCP 443 番ポートはソースサーバーが AWS DRS エンドポイント(次の例では us-east-2.amazonaws.com ) へ接続するために必要です。TCP 1500 番ポートは、GCP からAWS へのデータレプリケーションに使用されます。また、GCP 上のサーバーは、AWS DRS Agent のソフトウェアをダウンロードするために Amazon Simple Storage Service (S3) へのアクセスが必要です。

次の図は、ネットワーク要件を示したものです。詳細については Performing a failback を参照ください。

レプリケーションを開始する前に、接続性を確認するための簡易なテストをします。GCP 上の VM から、接続性を確認するため2つの Telnet 接続を開始します。1 つ目の Telnet 接続は、ポート443 で AWS DRS エンドポイント宛てであり、2 つ目は AWS のステージングサブネット上に作成したサーバーへのポート 1500 宛ての接続です。どちらも接続されていることが確認できます。

2. AWS DRSの設定

AWS DRS を設定するために以下の手順を行います。

a. AWS DRS で使用する AWS Identity and Access Management (IAM) ユーザを AWS 上に作成
b. AWS Replication Agent を GCP上のソースサーバ環境にインストール
c. AWS DRS の起動設定
d. フェイルオーバの準備と実施

a. AWS DRS で使用するAWS Identity and Access Management (IAM) ユーザをAWS 上に作成

AWS Replication Agent installation instructions の手順に従い、AWS DRS が AWS アカウントとやり取りを行うために使用する IAM 認証情報を作成します。本記事では IAM ユーザー名は drs-agent-user として作成します。次の手順で使用するため、作成された IAM ユーザーのアクセスキー等の認証情報を控えておいてください。

b. AWS Replication Agent を GCP 上のソースサーバ環境にインストール

AWS Replication Agent のインストールと AWS へのレプリケーション開始が可能となりました。次のコマンドでソースサーバーにエージェントのダウンロードとインストールします。 GCP 上のソースサーバである各仮想マシンに対しても同様のコマンド繰り返し実行していきます。

wget -O ./aws-replication-installer-init.py

sudo python3 aws-replication-installer-init.py

エージェントのインストールプロンプトでは、リカバリ先のリージョン名 (us-east-1)、AWS Access Key ID 及び AWS Secret Access Key を入力します。エージェントはこれらの認証情報を使用し、AWS DRS の認証を行います。認証が成功した場合、 AWS DRS のコンソール画面にはソースサーバーが表示され、 server ID が返されます。そして、レプリケーションがすぐに開始されます。

c. AWS DRS の起動設定

このステップでは、 Amazon Elastic Compute Cloud (EC2) の起動テンプレートの作成と設定を行います。これらは、ドリル (Drill) /ディザスタ (Disaster)のためにターゲットインスタンスを構成するために必要です。不適切な設定により、AWS 上でレプリケーションインスタンスやドリル/リカバリインスタンスを正常に起動できないことがあります。そのため、適切な組み合わせを選定していきます。AWS DRS で用いる EC2 の起動テンプレートの設定例については、EC2 launch template を参照ください。

訳注：ドリル(Drill)は訓練や反復演習といった意味合いです。

d. フェイルオーバの準備と実施

レプリケーション完了すると AWS DRS の管理画面中の Data replication status が Healthy と表示され、AWS 上のリカバリ インスタンスのテストが可能となります。フェイルオーバーの前準備としては、ネットワークおよびアプリケーションの全設定が適切に構成されているのかを確認する目的で継続的にドリルを実行する必要があります。ドリルの実行は無停止で行え、障害発生時に備えるという意味でも重要なものとなりす。

ドリルを開始する際には、ソース サーバーの Ready for recovery が Ready と表示されており、Data Replication Status が Healthy と表示されていることを確認します。その後、Initiate recovery job メニューを展開し、Initiate drill を選択します。

復旧したい時点を選択します。AWS DRS はデフォルト設定で7日、最大で365日前まで遡ることをサポートしています。スナップショットを保持期間を長くすると、コストが増加することは注意ください。このデモでは、Use most recent data を選択しています。これは、リカバリを開始した後に AWS DRS がソースサーバーから取得する最終スナップショットです。これにより、目標復旧時点 (Recovery Point Objective : RPO) が数秒となります。

Last recovery result カラムにはリカバリの起動時間と状態が表示されます。ドリルインスタンスの起動が成功していれば、 Successful と表示され、起動中であれば Pending と表示されます。

フェールオーバーとは、プライマリサイトからセカンダリサイトへトラフィックをリダイレクトする事となります。本記事の場合、フェールオーバーは GCP から AWS へのものとなります。ドリルインスタンスの正常稼動を確認後、Initiate recovery job メニューから Initiate recovery を選択し、回復インスタンスを開始します。リカバリインスタンスの起動手順や考慮事項は、ドリルインスタンスを開始する場合と同様となります。

3. DNS カットオーバー: GCP から AWS へのユーザートラフィックのリダイレクト

この時点では、ユーザートラフィックはプライマリサイトである GCP に流れており、フェイルオーバプロセスの最終ステップではユーザートラフィックを GCP から AWS へ切り替えます。このステップは AWS DRS の管理外の内容となります。通常は DNS レコードを更新し、ユーザートラフィックの向き先を正常なサイトである AWS へ向けることで対応します。

正常なサイトを指すように DNS レコードを更新する手順は、プライマリワークロードで使用している DNS プロバイダーによって異なります。考慮すべき点をいくつか以下に示します。

  • プライマリの Domain Name System (DNS)として Cloud DNS を使用している場合、Cloud DNS のゾーンを手動で変更し、レコードセットを AWS (お客様の DR サイト)側のリソースを指すように更新する必要があります。このリソースは、Elastic Load Balancing または EC2 である可能性があります。本稿執筆時点では、Cloud DNSはフェイルオーバーを自動化する方法を提供してていません。
  • スケーラブルで可用性の高いDNS ウェブサービスである Amazon Route 53 を使用している場合、ヘルスチェックと Route53 DNS フェイルオーバルーティングポリシーの組み合わせによって、DNS 更新によるフェイルオーバプロセスの自動化が可能です。
    フェイルオーバルーティングは、対象のリソースが正常な場合、対象リソースへトラフィックをルーティングし、対象リソースが異常な場合は別のリソースへトラフィックをルーティングします。フェイルオーバポリシーを作成する際には、GCP 上のリソースをプライマリ、 AWS 上のリソースをセカンダリとして指定します。 Route 53 アクティブ/パッシブフェイルオーバのヘルスチェックに基づいたルーティングは、 Route 53 が担当します。
  • DNS プロバイダーと合わせてコンテンツ配信ネットワーク (CDN) である Amazon CloudFront を利用することも可能です。エッジロケーションのグローバルネットワークを利用し、静的および動的な Web コンテンツを低レイテンシーかつ高速な転送速度で安全に配信可能です。Amazon CloudFront はオリジンフェイルオーバーをサポートしており、AWS のオリジンと AWS 外の HTTP オリジンを組み合わせ、それらの間でフェイルオーバーロジックを設定可能です。このような場合、 GCP をアプリケーションのプライマリ、AWS をセカンダリという風に2つのオリジンを設定可能です。フェイルオーバ用に設定した HTTP ステータスコードや、タイムアウト設定に従い、プライマリオリジンが利用不可となった事を CloudFront が検出すると、CloudFront はセカンダリオリジンである AWS へコンテンツを要求します。詳細については、CloudFront オリジンフェイルオーバーによる高可用性の最適化を参照ください。
  • 他の選択肢としては、Cloudflare Load Balancing のような、GCP と AWS 間でヘルスチェックに基づいたトラフィックの自動負荷分散が行える外部プロダクトが利用可能です。構成例については、 Cloudflare のブログの記事である、How to Load Balance Site between GCP and AWS using Cloudflare を参照ください。(注釈: このブログは外部ブログであり、 AWS による技術検証は行われておりません)

ソリューションのコストと料金

このデモで発生するコストに影響を与える主要なコンポーネントは次の通りです。

  • AWS DRS : AWS にアクティブにレプリケートしているサーバーの1 時間あたりのフラットな料金に基づきます。それに加えて次のコストも考慮する必要があります。
    • Amazon Elastic Block Storage (EBS) ボリューム
    • EBS スナップショット
    • レプリケーションサーバーとして使用する EC2 インスタンス
    • ドリルとリカバリに使用する EC2 インスタンス

詳細については AWS DRS の料金ページを参照ください。

  • AWS Site-to-Site VPN: EC2 のオンデマンド料金ページで説明がある通り、各 VPN の接続時間とデータ転送アウトに対して費用が発生します。このソリューションでは、大半のトラフィックが GCP から AWS へ送信されます。 このブログのパート2ではフェイルバックアプローチの説明時にデータの転送を方向を逆向きにします。 AWS VPN の料金の詳細については、AWS VPN の料金ページを参照ください。
  • GCP Egress トラフィック：詳細については、Google Cloud VPN の料金ページを参照ください。
  • GCP Cloud VPN：詳細については Google Cloud VPN の料金ページで参照ください。
  • その他、お客様が選択されたサービスの料金ページを参照ください。

最後に

事業継続戦略の導入は、DR 戦略において重要な要素です。このブログでは GCP (プライマリサイト) でホストされているアプリケーションのサンプル DR ソリューションについて説明しており、VPN 接続を使用し、2つのクラウド間のネットワークの確立方法を紹介しました。また、 AWS DRS を使用して GCP 上のプライマリサーバを AWS 上のリカバリサイトにレプリケートする方法を紹介しました。フェイルオーバの準備(起動テンプレートの設定と継続的なドリルの実行)および、DNS の変更による最終的なカットオーバーを行う際のいくつかの考慮事項について説明しました。

このブログシリーズのパート2では、DR 演習の完了後やプライマリサイトの障害対処後に AWS から GCP へレプリケーションバックする方法について学びます。コメントや質問があれば、お気軽にコメント欄にご記入ください。
この記事はアマゾン ウェブ サービス ジャパンの畠泰三が翻訳を担当しました。 (原文はこちら)

Ebrahim (EB) Khiyami

Ebrahim (EB) Khiyami

Ebrahim (EB) Khiyami は、AWSのシニアソリューションアーキテクトです。AWS Well-Architected Framework のスペシャリストであり、マイグレーションとディザスタリカバリの SME でもああります。仕事以外の多くの時間は、サッカーをしたり、観戦をしたり、指導をしています。

Shanmugam Shanker

Shanmugam Shanker

Shanmugam Shanker は AWS プロフェッショナルサービスのリードコンサルタントです。AWS のサービスを利用して革新的なソリューションを構築し、顧客のビジネス目標の達成を支援することに情熱を注いでいます。趣味は、家族や友人と過ごすことや、PS ゲーム及びハイキングです。