Amazon Web Services ブログ

オートメーションを活用したCloudEndureによるAWSへの容易な移行

Carmen PuccioとMandus Mombergによる記事。 CarmenとMandusは、AWSパートナーソリューションアーキテクトで、移行に注力しています。

オンプレミス環境からクラウドへのソフトウェアやサービスの移行は、独自の考慮事項と要件を伴うことは明らかです。移行結果に自信を持たせるには、容易に拡張できる移行戦略が必要です。つまり、ワークフローの大部分を自動化する必要があります。なぜクラウド内の自動化が重要であるのかに関する文書が不足しているわけではありません。この記事では、AWSアドバンスト・テクノロジーパートナーであるCloudEndureを使用して自動化された移行を実行する方法を説明し、自動化されたテストを組み込むことに重点を置いて、アプリケーションが移行後に期待どおりに動作することを確信できます。

オンプレミスからAWSへのワークロードの移行には、慎重な計画と正確な実行が必要です。クラウドに移行するにはさまざまな戦略がありますが、移行を容易にするツールも数多くあります。すべての移行ツールは、ダウンタイムとアプリケーションワークロードの影響を最小限に抑え、AWSへの移行を容易にし、データ損失を最小限に抑える、という共通の目標を持っています。

ワークロードをクラウドにすばやく移動したい場合、通常リホスト方式（リフト＆シフト）に従います。リホスト実行時の課題の1つは、移行されたアプリケーションが期待どおりに実行されていることを手動で確認するのにかかる時間です。適切な移行を検証するための自動化および迅速なテストパイプラインを組み込んだ移行は、成功する可能性が高いだけでなく、反復可能なプロセスを活用し、手動検証時間を短縮することで効率を向上させます。

ソリューションの概要

このブログ記事で説明するソリューションでは、CloudEndureとAWS Database Migration Service（AWS DMS）を使用し、ソースAmazon VPCから目的のAmazon VPCへ、オンプレミスからAWSへの、Go Gitサービス（Gogs）の移行について説明します。このデモのために2つの異なるVPCを使用していますが、このブログポストで使用しているツールの自動化と組合せによって、オンプレミスからAWSへの移行を容易に実現することができます。CentOS 7が稼働するモックソース環境の設定では、AWS CloudFormationとAnsibleの組合せを選択しましたので、あなたのテスト用AWS環境でご確認することができます。

CloudEndureはアプリケーションサーバの移行を担当し、AWS DMSはEC2インスタンス上で実行されているMySQLサーバからGogs DBを、完全に管理されたAmazon RDSデータベースに再構築する役目を負います。このデモンストレーションのためDMSを活用し、RDSへのデータベースのレプリケート方法を示しました。もう1つの選択肢として、データベース移行において、CloudEndureによるEC2へのリホストを行うことができます。

CloudEndureは起動時に、移行後のインスタンスでカスタム後処理スクリプトを呼び出す機能があります。この機能を使用すると、カスタム構成を実行し、自動化された承認テストを実行して、移行されたサーバでアプリケーションが正常に動作していることを確認できます。

移行の信頼性のため、AWS Lambda、AWS SNS、AWS SQS、CloudEndureの後処理機能を活用して、一連のテストを実行するための自動テストパイプラインを構築しています。すべてのテストが正常に完了すると、ソース環境から構築されたイメージを使用して高可用性Gogs環境をデプロイするAWS CloudFormationテンプレートが自動的に起動されます。

次の図は、この記事で取り上げる移行プロセスを示しています。

プロセスの仕組みは次のとおりです。

  1. Ansibleは、AWS Application Discovery Service、CloudEndureエージェント、およびGogsソースサーバの再設定およびテストに使用されるスクリプトをインストールします。
  2. AWS DMSは、GogsソースDBサーバを宛先RDSインスタンスに移行します。
  3. CloudEndureエージェントが実行されると、ブロックレベルのコピーが開始され、GogsソースサーバとAWSの初期同期が実行されます。
  4. CloudEndureが初期同期を完了すると、Continuous Data Protection（CDP）エンジンは新しいデータのリアルタイム同期を開始し、サーバはAWSでのテスト準備完了としてマークされます。 CloudEndure.pyスクリプトはconfig.ymlファイルのhosttomigrate変数に基づいて移行を開始します。 （この変数は、CloudEndureダッシュボードにインスタンス名として表示されます）。
  5. CloudEndure.pyスクリプトはCloudEndure APIを呼び出し、ソースインスタンスの最新のスナップショットからテストインスタンスを開始します。
  6. CloudEndureは、最新のスナップショットから宛先に新しいインスタンスを起動し、CloudEndure.shポストプロビジョニングスクリプトを実行します。このスクリプトは次の処理を行います。
    1. DMSが複製しているRDSインスタンスを指すようにGogsを再構成し、Gogsサービスを再起動します。
    2. Gogsサービスが稼動しているかどうかを確認します。稼働している場合、CloudEndure.shポストプロビジョニングスクリプトはCloudEndure_PostProcessing.pyスクリプトを呼び出します。このスクリプトはCloudEndure Pass / Fail SNSトピックに成功通知を送信します。メッセージの例は次のようになります。

      "Message": "{"instanceId": " i-0bb669daff4b1eea1","Pass": "True"}"

    3. CloudEndure Lambda関数は、CloudEndure Pass / Fail SNSトピックに登録されています。ラムダ関数は成功メッセージを探します。成功メッセージを受信すると、着信インスタンスIDに基づいてAmazon Machine Image（AMI）を作成し、AMI情報をAmazon SQSに送信します。 CloudWatchでLambda関数のステータスを追跡できます：
  7. CloudEndure.pyスクリプトは、移行されたインスタンスに関するメッセージをSQSキューに常にポーリングします。メッセージを受信すると、AMIが準備完了であるかどうかを確認します。準備ができたら、スクリプトはGogs CloudFormationテンプレートを起動し、AMI IDをパラメータとして渡します。 CloudFormationテンプレートは、次のような高可用性環境を展開します；

始めましょう

移行プロセスの仕組みが分かりましたので始めてみましょう。まず、CloudEndureでアカウントを設定する必要があります。アカウントをお持ちでない場合は、AWS SaaSサブスクリプションマーケットプレイスのCloudEndure Migration製品ページで登録できます。[1]

アカウントを設定し、CloudEndureのウェブサイトのスタートガイドに従ったら、以下のファイルに慣れておく必要があります。完全な解決策はGitHub上でより詳細に説明されています。

Ansibleプレイブック、変数、ファイル：

  • playbooks/files/CloudEndure.sh  – このファイルはCloudEndureが移行後のスクリプトを実行する/ boot/ce_conversionにデプロイされます。 GogがRDSを指すように再構成し、サービスをテストするために使用されます。
    • reinvent-ent312-source-instances.yml CloudFormationテンプレートは、このファイルのすべてのent312.five0.ninja
      を、Auto Scalingを使用して高可用性のGogs環境用のELBロードバランサを指し示すAmazon Route 53ドメインエイリアスに置き換えます。この値は、CloudFormationテンプレートのGogsDNSパラメータを介してテンプレートに渡されます。
  • playbooks/cloudendure_agent_install.yml
    • einvent-ent312-source-instances.yml CloudFormationテンプレートは、CloudEndure UserNameとパスワードをCloudEndureUserとCloudEndurePasswordのCloudFormationテンプレートのパラメータに基づいて、この「AnEure Playbook」の「Install CloudEndure」セクションに設定します。

CloudEndure.pyスクリプトで使用される移行スクリプトconfig.yml：

ファイルを編集して、次の情報を入力します。

  • username – CloudEndureのユーザー名
  • password – CloudEndureのパスワード
  • hosttomigrate – CloudEndureダッシュボードで移行するホストの名前。 CloudEndureが最初のレプリケーションプロセスを開始するまで、この値はダッシュボードで使用できません。
  • stackname –CloudFormationスタックの名前。 CloudFormationスタックに名前を付けるときに、CloudEndureBlogDemoのデフォルト値を変更することを選択した場合にのみ、これを変更してください。
  • keypairname – Gogs自動スケーリングスタックを起動するためのキーペア
  • gogsdns – Gogs自動スケーリング用にELBロードバランサにマップするRoute 53ドメインエイリアス

CloudFormation テンプレート：

  • reinvent-ent312-migrated-gogs.template
    • この値は、Gogs自動スケーリングのELBロードバランサにマップするRoute 53ドメインエイリアスです。パラメータGogsDNSNameは、CloudEndure.pyスクリプトの実行時にconfig.ymlのgogsdns値に基づいて渡されます。

AWS CloudFormationを使用してソリューションをデプロイする

次に、移行を詳しく見て、各ステップを実行してみましょう。このデモンストレーションでは、CloudFormationテンプレートは、AWSアカウントの別個の仮想プライベートクラウド（VPC）でソース環境を紡ぎ出し、同じアカウント内の宛先VPCに移行します。

まず、AWS CloudFormationテンプレートをAWSアカウントに展開する必要があります。
テンプレートをダウンロードして、独自の実装の出発点として使用することもできます。

「テンプレートの選択」ページで、テンプレートURLのデフォルト設定を維持し、「次へ」を選択します。

デフォルトのスタック名のままにするか、スタックの名前を入力し、下のスクリーンショットごとに値を入力します。

Gogsを構成する際に必要なため、ソースデータベースのユーザー名とパスワードに設定した値に注意してください。次の2つの画面で「次へ」および「次へ」を選択し、「AWS CloudFormationがカスタム名でIAMリソースを作成する可能性があることを確認します」というチェックボックスをオンにして、「作成」を選択します。

CloudFormationがアカウント内のリソースを作成するまでには数分かかります。 {YourStackName} -SourceInstanceResourcesがCREATE_COMPLETEとマークされたスタックが表示されたら、ログインしてGogsを設定できます。

CloudFormationで作成したカスタムDMSタスクは、Gogs DBが存在するかどうかによって異なりますので、CloudFormationスタックが完了する前にGogsをインストールして設定する必要があります。 （この執筆時点では、CloudFormationはDMSリソースをサポートしていませんが、移行の特定の側面について自動化を構築するための具体的な方法の1つを示したいと思います。）

スタックの[出力]タブで、AnatileSourceInstanceを見つけます。 SSHを次のコマンドで値を使用してインスタンスに追加します。

ssh -i {KeyPairYouAssociatedWithTheStack}centos@{ValueFromAnsibleSourceInstance}

インスタンスにSSHしたら、次のコマンドを実行して、更新とCloudFormationのユーザーデータステップが完了していることを確認します。

sudo tail -f /var/log/cloud-init.log

クラウド・イニシエータがインスタンスのブートストラップを終了すると、以下のようなメッセージが表示されます。

Mar 7 18:30:29 ip-10-10-138-101 cloud-init: Cloud-init v. 0.7.5 finished at Tue, 07 Mar 2017 18:30:29 +0000. Datasource DataSourceEc2. Up 369.01 seconds

これでインスタンスへのキーペアを追加する必要があります。そのため、SSHを使用してソースインスタンスに使用したり、Gogを構成したりすることができます。ローカルマシン上で、鍵ペアを保存したディレクトリから、次のコマンドを使用して秘密鍵をクリップボードにコピーします。

cat {KeyPairYouAssociatedWithTheStack}.pem | pbcopy

Ansibleソースインスタンスで、次のコマンドを実行します。

vi key.pem

プライベートキーをviウィンドウに貼り付け、ファイルを保存します。次に、次のコマンドを実行してアクセス許可を変更します。

chmod 400 key.pem

次のコマンドを実行して、ssh-agentが有効になっていることを確認します。エージェントpidを受け取る必要があります（たとえば、Agent pid 417）。

eval `ssh-agent`

ssh-agentにSSH鍵を追加し、空のパスフレーズを入力するためにEnterキーを押します。

ssh-add key.pem 
今度は、あなたのソースGogs DBをAnsible経由でプロビジョニングできます：

ansible-playbook -i playbooks/hosts playbooks/database_provision.yml

ソースのGogsインスタンスをプロビジョニングします。

ansible-playbook -i playbooks/hosts playbooks/gogs_provision.yml

GogsがAnsible経由で設定されると、ログイン環境でGogsをログインして設定することができます。 CloudFormationのSourceInstanceResourcesスタックのOutputsタブにGogsSourceInstanceの値が必要です。

http://{ValueFromGogsSourceInstance}:3000

「Gogsのユーザーとパスワード」フィールドに、CloudFormationのソースデータベースのユーザー名とパスワードから前述した値を入力します。

Gogsであなたの選択したユーザーとパスワードを登録することができます。このデモンストレーションの後半に注意してください。

CloudFormationのDMSスタックが完了したら、セットアップを調べることができます。レプリケーションインスタンスが表示されます。

送信元と宛先の両方のエンドポイントも表示されます。

データベース同期を実行するタスクも表示されます。

DMSの検証が終了したら、AnatileSourceInstance SSHウィンドウに戻り、次のコマンドを実行してApplication Discovery ServiceとCloudEndureをインストールします。

ansible-playbook -i playbooks/hosts playbooks/aws_cli_ads_agent_install.yml

ansible-playbook -i playbooks/hosts playbooks/cloudendure_agent_install.yml

CloudEndureダッシュボードにログインすると、サーバーが表示されます。 CloudEndureはAWSへの最初のブロックレベル同期を完了する過程にあるため、テストの準備が整っている、と表示されるまでに時間がかかることがあります。

CloudEndure DashboardのINSTANCE NAMEの値は、config.ymlファイルのhosttomigrate変数に設定する必要がある値です。
CloudEndure.pyスクリプトを実行して、移行を初期化します。

python scripts/CloudEndure.py

スクリプトの出力例を見るには、READMEを見てください。

スクリプトが終了すると、Lambda関数から作成されたAMIを使用して、AutoScalingと共に高可用性Gogs環境が表示されます。

高可用性のGogs環境がヘルスチェックに合格し、ELBロードバランサの背後でサービスを受けるには数分かかりますが、最終的には、ソース環境で作成したユーザー名を使ってサインインし、RDSを使用するように設定された移行済みGogs環境にアクセス可能です。これは、DMSタスクが移行元GogsデータベースをRDSに移行するのに成功したことを証明します。

サマリー

この記事では、オンプレミス環境からAWSへの移行をスピードアップするために、自動化とテストをツールキットに組み込む方法を示しました。慎重な計画と構成では、移行シナリオ全体で再利用できる一連のツールが用意されています。これにより、ワークロードをより迅速に移行できるようになり、移行後に期待どおりアプリケーションが動作しているという確信が得られます。

 

このブログの内容は、第三者の製品を推奨するものではありません。このブログは情報提供を目的としています。

[1]このブログ記事の手順に従う際に発生した費用については、あなたが責任を負います。

(翻訳は諸岡が担当しました。原文はこちら)