移行とハイブリッド

AWS Migration Hub Refactor Spaces で実践するストラングラーフィグパターン - 段階的マイクロサービス化

Refactor Spaces によるストラングラーフィグパターンの実装、ルーティング制御、段階的な移行を解説します。

約 3 分で読めます

Refactor Spaces の概要

Refactor Spaces はモノリスアプリケーションからマイクロサービスへの段階的な移行を支援するサービスで、最大 50 のサービスと 100 のルートを管理できます。ストラングラーフィグパターンを実装するためのインフラ (API Gateway、NLB、Transit Gateway による VPC 間接続) を自動構築し、URL パスベースのルーティングで機能単位の段階的な移行を実現します。マルチアカウント構成にも対応し、AWS Organizations と統合して組織内のアカウントを環境メンバーとして自動検出します。環境の作成時にネットワークファブリック (Transit Gateway) が自動でプロビジョニングされ、異なる VPC やアカウントに配置されたサービス間の通信経路を手動で設定する必要がありません。

ストラングラーフィグパターンの実装

環境を作成すると API Gateway がプロキシとして構築され、全トラフィックがモノリスにルーティングされます。新しいマイクロサービスを開発したら、該当する URL パス (例: /api/orders) のルートを新サービスに切り替えます。残りのパスは引き続きモノリスにルーティングされます。段階的にルートを追加し、最終的に全パスが新サービスに移行したらモノリスを廃止します。問題が発生した場合はルートを削除するだけでモノリスに即座に戻せます。この方式の利点は、ユーザーから見て単一のエンドポイント (API Gateway の URL) が維持されるため、フロントエンドやクライアントアプリケーションの変更が不要な点です。移行はバックエンドのルーティング変更だけで完結し、移行期間中も中断なくサービスを継続できます。

ルーティングとマルチアカウント

Refactor Spaces のルートはデフォルトルート (モノリスへのフォールバック) とサービスルート (マイクロサービスへの振り分け) で構成されます。URL パスベースのルーティングで /api/orders は新しいマイクロサービスに、それ以外はモノリスにルーティングします。マルチアカウント構成で、モノリスとマイクロサービスを異なるアカウントに配置し、セキュリティ境界を分離できます。サービスエンドポイントは Lambda 関数と HTTP URL (ALB や NLB のエンドポイント) の 2 種類をサポートします。Lambda をターゲットにする場合はサーバーレスのマイクロサービスを直接統合でき、HTTP URL をターゲットにする場合は ECS や EKS で稼働するコンテナサービスを背後に配置できます。新しいマイクロサービスの追加はサービスとルートの作成だけで完了し、API Gateway の設定変更は Refactor Spaces が自動管理します。 Refactor Spaces の移行戦略を網羅的に学ぶなら、技術書 (Amazon)を参照してください。

Refactor Spaces の料金と制限

Refactor Spaces 自体に追加料金は発生しません。コストは自動構築される API Gateway、NLB、Transit Gateway のリソース料金に依存します。API Gateway のリクエスト料金が主要なコスト要因です。Transit Gateway のアタッチメント料金とデータ処理料金も、マルチアカウント構成でサービス数が増えると積み重なります。移行完了後にモノリスを廃止し、Refactor Spaces の環境を削除すると、プロキシのリソース料金も停止します。制限として、1 環境あたり最大 50 サービス・100 ルートの上限があるため、数百のマイクロサービスを持つ大規模システムでは複数環境に分割するか、移行完了後に環境を削除して API Gateway を直接管理する構成への移行を計画する必要があります。

他の移行アプローチとの比較

ストラングラーフィグパターンの実装には Refactor Spaces 以外にも方法があります。API Gateway を手動で構築し、ルーティングルールを自前で管理する方式はカスタマイズ性が高い反面、Transit Gateway や NLB の設定を手動で維持する運用負荷が発生します。ALB のパスベースルーティングでモノリスとマイクロサービスを振り分ける方式は単一 VPC・単一アカウントでの移行に適していますが、マルチアカウント分離には向きません。Service Mesh (App Mesh) を使ったトラフィック分割は、既に ECS や EKS でコンテナ化が進んでいる環境に適していますが、モノリスが VM 上で稼働している段階では導入障壁が高くなります。Refactor Spaces の価値はこれらのインフラ構築を自動化し、移行チームがルーティングの追加・削除だけに集中できる点にあります。

移行計画のベストプラクティス

Refactor Spaces で段階的移行を成功させるために、まずモノリスの機能を API パス単位で棚卸しし、依存関係の少ない境界から移行を開始します。最初の移行対象は読み取り専用の API (例: /api/products の GET) が安全です。書き込みを伴う API はトランザクション境界の設計に注意が必要で、モノリスとマイクロサービス間のデータ整合性を保つための Saga パターンやイベント駆動設計を検討します。移行中の監視として、API Gateway のレイテンシメトリクスと 5xx エラー率を CloudWatch で監視し、ルート切り替え後に異常を検出したら即座にルートを削除してモノリスに戻す体制を整えます。カナリアデプロイと組み合わせる場合は、API Gateway のステージ変数またはヘッダベースのルーティングで一部トラフィックのみを新サービスに流す段階を設けると、リスクをさらに低減できます。

まとめ

Refactor Spaces はストラングラーフィグパターンのインフラを自動構築し、モノリスからマイクロサービスへの段階的な移行を支援するサービスです。URL パスベースのルーティングで機能単位の移行を実現し、マルチアカウント構成でセキュリティ境界を分離します。Lambda と HTTP URL の両方をサービスエンドポイントとしてサポートし、移行中のロールバックもルート削除だけで即座に実行できます。他のアプローチと比較して運用負荷が低く、移行チームがアプリケーションの分離に集中できる環境を提供します。

関連するサービス

AWS Migration Hub Refactor Spacesモノリスアプリケーションをマイクロサービスに段階的にリファクタリングするためのネットワーク環境を提供するサービスAmazon API GatewayAPI の作成、公開、管理、監視を簡単に行えるフルマネージドサービスAWS Lambdaサーバー管理不要でコードを実行するサーバーレスコンピュートサービス

関連する記事

移行の一元管理 - AWS Migration Hub でクラウド移行の進捗を可視化するAWS Migration Hub を使ったクラウド移行の一元管理を解説。移行進捗の可視化、Application Discovery Service との統合、移行戦略の選択支援を紹介します。Amazon API Gateway の設計パターン - REST API と HTTP API の選定基準HTTP API と REST API の選定基準を明確にし、Cognito・Lambda オーソライザーの認証パターンとスロットリング設計の実践手法を紹介します。AWS Application Composer でサーバーレスアプリケーションをビジュアル設計 - IaC テンプレートの自動生成Application Composer によるサーバーレスアーキテクチャのビジュアル設計、SAM テンプレートの自動生成、VS Code 統合を解説します。

同じテーマの記事

データベース移行サービス - AWS DMS で実現する安全かつ効率的なデータベース移行AWS Database Migration Service (DMS) を活用したデータベース移行の手法を解説します。RDS との統合による同種・異種データベース間の移行と、継続的レプリケーションによるダウンタイム最小化の実践方法を紹介します。AWS DataSync で高速化するデータ転送 - オンプレミスから S3 ・ EFS への移行オンプレミスから S3・EFS への高速データ転送を自動化する。エージェントのデプロイ、タスクスケジューリング、転送データの整合性検証を紹介します。AWS Elastic Disaster Recovery で構築する災害復旧 - 継続的レプリケーションと復旧テスト継続的レプリケーションでオンプレミスサーバーを AWS に複製し、復旧ドリルで手順を検証する。フェイルバックまでの一連の流れを紹介します。メインフレーム移行 - AWS Mainframe Modernization でレガシーシステムをクラウド化するAWS Mainframe Modernization を使ったメインフレームのクラウド移行を解説。リプラットフォーム (Micro Focus) とリファクタリング (Blu Age) の 2 パターンと移行戦略を紹介します。AWS Mainframe Modernization でメインフレームを AWS に移行 - リプラットフォームとリファクタMainframe Modernization によるメインフレームアプリケーションの移行パターン、Blu Age と Micro Focus の使い分けを解説します。メインフレーム刷新を加速する - AWS Transform でレガシー COBOL を数か月でモダナイズAWS Transform for mainframe によるメインフレームモダナイゼーションを解説。COBOL コードの自動分析、Java への変換、段階的な移行戦略を紹介します。AWS MGN による大規模移行の計画と実行 - ウェーブ設計とカットオーバー自動化数百台規模のサーバー移行をウェーブ設計で計画し、カットオーバーの自動化スクリプトと移行後の最適化手法を紹介します。AWS Application Migration Service (MGN) によるリフト&シフト移行の実践エージェントのインストールからカットオーバーまでのリフト&シフト移行手順を実践的に紹介。設計上の注意点とネットワーク構成も解説します。

内容が近い記事・サービス

AWS Migration Hub複数の移行ツールの進捗を一元的に追跡・可視化するダッシュボードサービスで、Strategy Recommendations による移行戦略の評価や Refactor Spaces によるリファクタリング支援も提供する移行の一元管理 - AWS Migration Hub でクラウド移行の進捗を可視化するAWS Migration Hub を使ったクラウド移行の一元管理を解説。移行進捗の可視化、Application Discovery Service との統合、移行戦略の選択支援を紹介します。Amazon VPC Lattice によるサービスネットワーキング - マイクロサービス間通信の簡素化Envoy プロキシ不要の L7 サービスネットワーキングで、クロス VPC・クロスアカウントのマイクロサービス間通信を簡素化する。IAM 認証と App Mesh との使い分けを紹介します。AWS Transit Gateway で構築するハブ&スポークネットワーク - マルチ VPC 接続の設計ハブ&スポーク型で複数 VPC とオンプレミスを集約し、ルートテーブル分離でセキュリティ境界を確立する。ピアリングによるマルチリージョン接続も紹介します。