Amazon Web Services ブログ
プレビュー – AWS Migration Hub Refactor Spaces がアプリケーションの段階的なリファクタリングをサポート
AWS Migration Hub の新機能である AWS Migration Hub Refactor Spaces のプレビューを発表します。この機能を使用することで、既存のアプリケーションを通常はマイクロサービスに基づいて分散アプリケーションにリファクタリングできます。
既存のアプリケーションをリファクタリングする理由は複数あります。その理由は、コードをよりモジュール化したり、最新のフレームワークを使用したり、異なるデータストレージを使用したりすることかもしれません。一般的に、リファクタリングを行う際の目的は、時間の経過に合わせて、アプリケーションのメンテナンスと進化をより容易にすることにあります。その他の利点としては、より大きなワークロードへの対応、耐障害性の向上、コストの削減などが含まれる場合があります。しかし、リファクタリングには困難を伴うということは認めざるを得ません。私はよく、リファクタリングを、乗客が満員の飛行機の飛行状態を保ちながら、それらの乗客が変更に気付かないようにしつつ、その飛行機のエンジン、キャビンの座席、エンターテイメントシステムを取り替えることに例えます。
これらのリファクタリングプロジェクトを成功させたお客様と話をしているうちに、当社は共通のパターンがあることに気付きました。それは Strangler Fig の設計パターンです。
Strangler Fig は、宿主である木のこずえから根を成長させ、最終的には宿主を包み込み、または宿主に取って代わる植物の集まりです。考案者である Martin Fowler 氏がこの用語を最初に生み出したのは、移行の設計パターンを表すためでした。そのアイデアは、「旧システムの末端を中心にして徐々に新しいシステムを作り、旧システムが strangled される (絞め殺される) まで数年かけてゆっくりと成長させる」ということです。
この植物の動きをアプリケーションの移行に適用する方法
この植物の集まりに触発されて、モノリシックアプリケーションから機能を抽出し、マイクロサービスとして書き直したいと考えることがあるかもしれません。その後、トラフィックを旧システムから新しいシステムへと段階的にルーティングします。十分な時間が経過すると、すべてのリクエストはマイクロサービスにルーティングされるようになり、既存のアプリケーションの使用は停止されます。
アプリケーションの変革に対するこのアプローチは効果的ですが、課題を生じさせるものでもあります。既存のアプリケーションとマイクロサービスを分離するために必要なインフラストラクチャを作成しなければなりません。AWS クラウドにおいては、これは複数の AWS アカウントの作成を伴うことが多いため、チームやサービスが独立して運用するのがより容易になることがあります。複数のアカウントを持つことは、チーム間で懸念事項や請求を切り分けるのに最も効率的な方法です。複数の AWS アカウントを扱う場合、既存のアプリケーションと新しいサービスを連携させるには、ネットワークインフラストラクチャを維持する必要があります。さらに、旧アプリケーションから異なるアカウントの新しいサービスにトラフィックを徐々にルーティングするルーティング制御システムを作成する必要があります。そのインフラストラクチャの大規模な作成および管理は複雑です。これは、リファクタリングプロジェクトに追加のリスクとコストを生じさせます。
Refactor Spaces を利用するメリット
AWS Migration Hub Refactor Spaces は、私のために手間のかかる作業を処理してくれます。まず、ネットワークインフラストラクチャを整備して、複数の AWS アカウント間の接続を可能にします。次に、レガシーアプリケーションから API コールをルーティングするメカニズムを作成して管理します。
リファクタリングしたいモノリシックなアプリケーションがあるとします。このアプリケーションは、ReactJS を使用したウェブベースのフロントエンドで構成されています。フロントエンドアプリケーションは Amazon Simple Storage Service (Amazon S3) でホストされ、Amazon CloudFront を通じて配布されます。フロントエンドは、NodeJS または Python で開発され、複数の EC2 インスタンスにデプロイされたモノリシックアプリケーションに対して API コールを実行します。API はリレーショナルデータベースを使用します。なぜなら、当社では会社設立当初からデータを保存する方法としてこの方法を用いてきたからです。
このアプリケーションのアーキテクチャを次の図に示します。
各 API には個別の URI があります。例えば、/cart API は買い物かごを処理し、/order API は注文システムを処理します。私は Strangler Fig パターンを適用し、/cart 機能を一連の新しいマイクロサービスに抽出することにしました。これらのマイクロサービス用に AWS アカウントを作成します。カート管理機能を実装するための一連の AWS Lambda 関数を開発およびデプロイしています。低レイテンシーを大規模に実現できるため、買い物かごのデータストレージに Amazon DynamoDB を利用することにしました。
新しいアーキテクチャのスキーマを次の図に示します。
ただし、ここで 2 つの課題があります。まず、フロントエンドアプリケーションによって実行された API コールを正しいバックエンド (モノリスまたは新しいマイクロサービスのいずれか) にルーティングするルーティングメカニズムを設計、コーディング、およびデプロイする必要があります。このサービスは、おそらく、別個の AWS アカウントにデプロイされることになるでしょう。その後、これらの複数の AWS アカウント間のネットワーク接続を設定する必要があります。
ここで Refactor Spaces の出番です。
AWS Migration Hub Refactor Spaces のご紹介
Refactor Spaces は、先ほど説明した 2 つの課題、すなわち API コールのルーティングと AWS アカウント間のネットワーク接続を処理することを通じて、アプリケーションのリファクタリングの管理を容易にします。環境、サービス、およびアプリケーションプロキシで構成されています。実際に機能しているところを見てみましょう。
AWS マネジメントコンソールを開き、AWS Migration Hub に移動して、[Refactor Spaces] を選択します。
最初に Refactor Spaces の環境を作成します。環境は、ピアリングされた VPC で構成されるマルチアカウントネットワークファブリックです。これにより、環境に追加されたサービス VPC 内の AWS リソースは、AWS アカウント間で直接通信できるようになります。また、アカウント全体のネットワークとサービスの統合ビューも提供します。
[Create environment] (環境を作成) で、自分の環境の [name] (名前) と [description] (説明) を入力し、[Next] (次へ) を選択します。
その後、自分のアプリケーションを定義します。アプリケーションの [name] (名前) を入力し、プロキシをデプロイする [VPC] を選択します。
アプリケーションはサービスコンテナです。ルートを定義するプロキシがあります。プロキシを使用すると、フロントエンドアプリケーションが 1 つのエンドポイントを使用して複数のサービスに接続できるようになります。すべてのトラフィックが 1 つのプロキシエンドポイントに到達し、その後にルールに基づいて複数のサービスに送信されます。
既に説明したように、複数の AWS アカウントを使用することもできます。通常、アプリケーションは、Refactor Spaces のアプリケーションプロキシをホストする 1 つの AWS アカウント、レガシーアプリケーションをホストする 1 つまたは複数の AWS アカウント、および最初のマイクロサービス用の 1 つの AWS アカウントで構成されます。そのため、この Refactor Spaces 環境に参加するよう他の AWS アカウントの所有者を招待します。AWS アカウントごとに 1 つのプリンシパルを追加します。Refactor Spaces は車輪を再発明するものではなく、AWS Resource Access Manager (RAM) を活用してそれを実現しています。
このステップはオプションです。Refactor Spaces は 1 つの AWS アカウント内でも機能する場合があります。後の段階で、他の AWS アカウントと環境を共有することができます。
AWS アカウント ID を [Principals] (プリンシパル) として入力し、[Next] (次へ) を選択します。
最後に、選択内容を確認し、[Create & share environment] (環境を作成および共有) を選択します (ここでは表示されていません)。
マイクロサービスが使用可能な状態にあると仮定して、次のステップは、それらを Refactor Spaces サービスとして登録することです。Refactor Spaces サービスは、ビジネス機能 (通常はマイクロサービス) を提供するエンティティです。これらのサービスは固有のエンドポイントを介して到達可能で、Refactor Spaces の環境のアカウント間で相互運用できます。この例では、4 つのサービスがあります。
- モノリシックアプリケーション。これは、Refactor Spaces がフロントエンドによって開始されたすべての API コールをルーティングするデフォルトのサービスです。
/cart機能を実装する 3 つのマイクロサービス。AddItem、RemoveItem、およびListItemsといった 3 つの異なるサービスでこの機能をリファクタリングすることにしました。
Refactor Spaces サービスは、EC2、AWS Fargate にデプロイされたコンテナ、Application Load Balancer、AWS Lambda 関数など、あらゆるコンピューティングリソースタイプをターゲットにすることができます。
左側のメニューから [Create service] (サービスを作成) を選択します。サービスの設定は 3 つの手順で行います。まず、このサービスを定義する Refactor Spaces の [Environment] (環境) と [Application] (アプリケーション) を選択します。次に、サービスの [name] (名前) と [description] (説明) を入力します。3 番目に、サービスの [endpoint] (エンドポイント) ([VPC] の HTTP/HTTPS URL または [Lambda function] (Lambda 関数) のいずれか) を選択します。
モノリシックアプリケーションは、別途指定されない限り、Refactor Spaces のアプリケーションプロキシがすべての API コールをルーティングするデフォルトルートです。[Source path] (ソースパス) として / と入力し、[Include child paths] (子パスを含める) を選択します。 その後、HTTP 動詞について [Match all] (すべて一致) が選択されていることを確認します。
完了したら、[Create service] (サービスを作成) を選択します。マイクロサービスごとにこのプロセスを繰り返します。このデモでは、合計で 4 つの Refactor Spaces サービスを作成します。
最後のステップでは、Refactor Spaces のアプリケーションプロキシのルーティングルールを定義します。設定すると、プロキシはフロントエンドアプリケーションの新しい API エンドポイントになります。フロントエンドアプリケーションで行わなければならない唯一の変更は、Refactor Spaces のアプリケーションプロキシの URI をポイントするようにすることです。プロキシは、ルート定義に従って API コールをサービスにルーティングします。アプリケーションプロキシは、パブリックまたはプライベートの可視性を備えたすべてのコンピューティングプラットフォームへのルーティングをサポートします。現時点では、プライベートエンドポイントは、パブリック DNS 名またはプライベート IP アドレスを通じて参照される必要があります。各 API コールは、プロキシで設定される一連のルートに対して実行されます。パスがルールに一致すると、そのパス用に設定されたターゲットサービスにリクエストが送信されます。プロキシには、リクエストがいずれのパスルールにも一致しない場合、そのリクエストをデフォルトサービスに転送するデフォルトルートがあります。
先ほど作成したサービスを選択します。その後、ルート [Source path] (ソースパス) と、サポートする HTTP [Verb] (動詞) を入力します。サービスがサブパス (/cart/123 など) を想定している場合は、確実に [Include child paths] (子パスを含める) も選択します。
GetItem および RemoveItem マイクロサービスについてこのプロセスを繰り返します。これらは異なる HTTP 動詞 (それぞれ GET と DELETE) について呼び出されます。
この設定に基づいて、Refactor Spaces は私のために次のようなアーキテクチャを作成および管理してくれます。Refactor Spaces のアプリケーションプロキシとネットワークファブリックは、別の AWS アカウントでデプロイされます。モノリシックアプリケーションやマイクロサービスのニーズに基づいて、Amazon API Gateway をさらに設定することもできます。
最後の変更は、アプリケーションのフロントエンドについてのものです。モノリスのエンドポイントではなく、Refactor Spaces のアプリケーションプロキシエンドポイントをポイントするように設定を変更します。今後、Refactor Spaces はデフォルトで API コールをモノリスにルーティングします。GET、POST、および DELETE 動詞の /cart コールを、Lambda 関数として実装された新しいマイクロサービスにルーティングします。
時間の経過とともに、このプロセスを繰り返して、旧モノリスが新しいマイクロサービスアーキテクチャに置き換えられるまで、他の機能をモノリシックアプリケーションから 1 つずつ移動します。
料金と利用可能なリージョン
AWS Migration Hub Refactor Spaces は、現在、米国東部 (バージニア北部)、米国西部 (オレゴン)、米国東部 (オハイオ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (アイルランド)、欧州 (フランクフルト)、欧州 (ロンドン)、および欧州 (ストックホルム) といった 10 の AWS リージョンでご利用いただけます。いつもどおり、将来的には他のリージョンに拡大していきたいと考えています。
この新機能はオープンプレビューとして今すぐ利用可能です。登録は不要です。本日よりご利用いただけます。プレビュー期間中の Refactor Space の使用には料金はかかりません。ただし、Amazon API Gateway、AWS Transit Gateway、およびネットワークロードバランサーといった、AWS アカウントにプロビジョンされるリソースの料金を請求される場合があります。料金の詳細については、AWS Migration Hub の料金ページをご覧ください。Refactor Spaces が一般的に利用可能になると、請求が開始されます。
原文はこちらです。