[ENT302] レガシーアプリケーションをモダナイズするワークショップに参加してきた #AWSreInvent

[ENT302] レガシーアプリケーションをモダナイズするワークショップに参加してきた #AWSreInvent

Clock Icon2023.11.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

re:Invent 2023 現地参加の田中孝明です。

Modernizing the application stack with AWS modernization pathways というレガシーアプリケーションをモダナイズするワークショップに参加してきたのでそちらのレポートになります。

ワークショップについて

ENT302 | Modernizing the application stack with AWS modernization pathways

このワークショップでは、ワークロードを運用環境で常に利用できる状態に保ちながら、既存のモノリスから疎結合マイクロサービス アーキテクチャにワークロードを段階的にモダナイズする方法を学びます。 AWS の専門家に加わって、実際の移行とモダナイゼーションのシナリオを実装してください。 Amazon EC2 上の仮想マシンから始めて、コンテナへの移動パスウェイを使用してアプリケーションをコンテナ化し、デプロイします。 次に、クラウドネイティブへの移行パスウェイを使用してアプリケーションを分解し、マイクロサービスに移行します。 最後に、マネージド型データベースへの移行パスウェイを使用して、セルフホスト型リレーショナル データベースを Amazon Aurora に移行します。 参加するにはラップトップを持参する必要があります。

いわゆるモノリスな状態を少しづつ、既存の環境を動かしながら移行する方法を一通り触ることができました。

まずは EC2 (Web + MySQL) を二つ用意し、以下のようなモダンな構成へ無停止で移行する手順を一通り学べました。

ワークショップ

コンテナイメージ作成

手順に従い、Dockerfile を作成し、イメージを ECR へ Push するところまで実施しました。

API を AWS App Runner へ移行

先ほど Push した ECR のイメージを利用し、AWS App Runner へサービスを稼働させるところまで実施しました。

EC2 上の MySQL を移行するために DB の接続情報を環境変数に切り出します。

AWS App Runner はデフォルトでは特定の パブリックVPC で実行されるので、EC2 上の MySQL に接続するためのネットワークの接続を行いました。

VPC connector を新たに作成し、Custom VPC で EC2インスタンス で利用されているものを指定しました。

フロントエンドを S3 に移行する

Cloud 9 からフロントエンドのコードで API の接続先を先ほどデプロイした AWS App Runner に向けて修正し、あらかじめホスティングできるように準備された S3 にアップロードします。この時点で S3 からも Webページ が見れるようになり、旧アプリと新アプリが同時に動くことが確認できます。

EC2インスタンス を停止する

Web 用の EC2インスタンス を停止し、S3 にアップロードしたページのみが見れる状態になることを確認します。

セルフマネージド MySQL を Amazon Aurora に移行する

AWS Database Database Migration Service を使用して、セルフマネージド MySQL EC2インスタンス から Amazon Aurora に移行します。 レプリケーションインスタンス、ソースエンドポイント、ターゲットエンドポイントがワークショップ用にあらかじめ作成されていたのでこちらもすぐに移行できました。

手順に従って DMSタスク を作成し、移行を実施します。

Aurora クラスタエンドポイントの構成

新しく作成した Amazon Aurora を AWS App Runner のサービスから呼べるように変更します。 ここでは DB 接続ようの環境変数を Amazon Aurora の Write を使用しているエンドポイントに変更します。 変更すると再デプロイが走ります。

セルフマネージド MySQL EC2インスタンス を停止する

セルフマネージド MySQL EC2インスタンス を停止します。 AWS App Runner の DB 接続先は Amazon Aurora に変わっているので、アプリケーションに影響がないことが確認できます。

AWS Migration Hub Refactor Space を使用した Strangler Fig パターンの実装の準備

ここでは AWS Migration Hub Refactor Space を使用して、レガシーアプリケーションの機能を置き換え、マイクロサービスにルーティングを置き換えることができるようにします。

インフラストラクチャーとアプリケーションとサービスを作成します。

インフラストラクチャーはワークショップ用にあらかじめ作成されていたものを使用しました。

次にサービスを作ります。

サービスはレガシーアプリケーション(AWS App Runner で動いているもの)を新しいマイクロサービスにルーティングできるように設定します。 アプリケーションプロキシが使用できるようになったので、フロントエンドの Web の API の URL を AWS App Runner のエンドポイントから Amazon API Gateway によって提供される URL に変更します。

まとめ

途中で退席する必要があったので、最後のアプリケーションプロキシから AWS Lambda + DynamoDB のマイクロサービスに変更したアプリへの移行を試すことができなかったのが残念です。 ある程度準備されてるとはいえ、AWS DMS や AWS Migration Hub Refactor Space を触れる貴重な機会だったのでもう一度チャレンジしてみたいです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.