AWS Migration Hub Refactor Spaces

解決する課題

レガシーなモノリスをマイクロサービスへ作り替えるとき、一度に全部を置き換えるのは現実的ではありません。多くの場合、機能を一つずつ切り出して新サービスへ移し、徐々にモノリスを縮めていく「ストラングラー（締め殺し）」のアプローチを取ります。ところがこの方式を成立させるには、入口で流量を受け、移行済みの機能だけを新サービスへ、それ以外を従来のモノリスへ振り分けるルーティング基盤が必要で、API Gateway やロードバランサー、アカウントや VPC をまたぐ接続といった「配管」を自前で組み上げる手間が大きくなります。Refactor Spaces は、この配管を一括で構築・管理し、利用者がリファクタリングそのものに集中できるようにするサービスです。

• モノリスを止めずに機能単位で少しずつマイクロサービス化したい
• 移行済みの機能だけを新サービスへ振り向ける入口のルーティングを楽に用意したい
• API Gateway やロードバランサー、アカウント間・VPC 間の接続の配管を自分で組みたくない
• 複数チーム・複数アカウントにまたがる段階的なリファクタリングを統制したい

主要概念と用語

• 環境（Environment）: リファクタリングの作業空間となる最上位の単位。ルーティングの入口や、参加アカウント間をつなぐネットワークの土台がこの中に作られる
• アプリケーション（Application）: 環境内に作る、入口となる単位。流量を受けるための API Gateway やプロキシがここに紐づき、ルートに従って各サービスへ振り分ける
• サービス（Service）: 流量の振り向け先。既存モノリスや、新たに切り出したマイクロサービスを表し、宛先として URL のエンドポイントや Lambda 関数を指定できる
• ルート（Route）: どのパスやメソッドの流量をどのサービスへ送るかを定義する規則。移行済みの機能だけを新サービスへ向けるなど、振り分けの中心になる
• デフォルトルート: 明示的なルートに当てはまらない流量の既定の宛先。多くの場合、まだ切り出していないモノリスを指す
• 共有（リソース共有）: 環境を複数アカウントに展開する仕組み。チームごとにアカウントを分けつつ、同じ環境上でリファクタリングを進められる
• プロキシ / ネットワークブリッジ: 入口で受けた流量を、アカウントや VPC の境界を越えて宛先サービスへ届けるために自動構成される接続経路

仕様・制限・クォータ

• 構成は環境 → アプリケーション → サービス → ルートという階層で組み立て、入口のアプリケーションからルートに従って各サービスへ振り分ける
• 宛先のサービスは、URL エンドポイント（ロードバランサーや既存システムの URL など）または Lambda 関数を指定でき、モノリスと新サービスを同じ入口で扱える
• 環境は複数アカウントへ共有でき、アカウントをまたいだチーム横断の段階的リファクタリングを一つの基盤で進められる
• ルーティングや接続のために、API Gateway・ネットワークインターフェース・VPC をまたぐ接続などのリソースがサービスによって自動で作成・管理される
• 作成できる環境・アプリケーション・サービス・ルートの数や、各種の上限はサービス側で定められており、規模が大きい場合は上限の確認が必要

内部の仕組み

Refactor Spaces ではまず環境を作り、その中に流量の入口となるアプリケーションを定義します。アプリケーションには API Gateway やプロキシといった入口の仕組みが自動で構成され、外部からの流量をここで受け止めます。次に振り向け先となるサービスを、既存モノリスや新たに切り出したマイクロサービスとして登録し、URL エンドポイントまたは Lambda 関数として宛先を指定します。

流量の振り分けはルートで制御します。特定のパスやメソッドを新サービスへ向け、それ以外はデフォルトルートで従来のモノリスへ送ることで、移行済みの機能だけを少しずつ切り替えていけます。アプリケーションが別のアカウントや VPC にあるサービスへ流量を届けられるよう、サービスは境界を越える接続経路を自動で構成します。これにより、利用者はルーティングや配管を手で組むことなく、機能を一つずつ新サービスへ移す作業に集中できます。

設計パターン / ベストプラクティス

• デフォルトはモノリスに向ける: 最初はデフォルトルートを既存モノリスに設定し、切り出した機能のパスだけを順に新サービスへ向ける
• 小さく切り出して検証する: 一度に大きく動かさず、影響範囲の小さい機能から新サービス化し、ルート単位で挙動を確認しながら進める
• アカウントをまたぐ統制に使う: チームごとにアカウントを分けている場合は環境を共有し、各チームが自分のサービスを登録しつつ全体のルーティングを一元管理する
• 切り戻しをルートで考える: 問題が出たら該当ルートの宛先をモノリスへ戻せるよう、切替と切り戻しをルート操作で完結させる方針にしておく
• 入口の安定を保つ: 呼び出し側が依存する入口（アプリケーション）のインターフェースは安定させ、内部の宛先差し替えに留める

運用・監視

• 環境・アプリケーション・サービス・ルートの状態は、Migration Hub のコンソールや API で構成として確認でき、どの機能がどこへ向いているかを把握できる
• 入口で自動構成される API Gateway やネットワークのメトリクス・ログを通じて、流量や応答の状況を監視できる
• ルートの宛先を切り替える運用は、段階的なカットオーバーとして扱い、切替前後で挙動を比較する
• 接続が通らないときは、宛先サービスの到達性、アカウント間・VPC 間の経路、セキュリティ設定を順に切り分ける
• 移行が進んでモノリスが縮んだら、不要になったルートやサービス、ひいては環境を整理して構成と課金を見直す

コスト

• 入口や境界を越える接続のために自動作成されるリソース（API Gateway やネットワーク関連の構成要素）に応じた費用が発生し得る
• 振り向け先となる宛先サービス側の稼働コスト（ロードバランサー、コンテナ、Lambda など）は、それぞれの料金体系に従う
• アカウントや VPC をまたぐ流量では、データ転送に関わる費用も考慮する
• リファクタリングが完了して不要になった環境やルートは速やかに片付け、自動作成されたリソースの課金を止めるのが基本
• コストは「足場（Refactor Spaces が作る配管）」と「宛先サービスの実体」に分かれるため、両方を合わせて見積もる

セキュリティ

• 環境・アプリケーション・ルートの作成や変更の権限は IAM で管理し、リファクタリングに関わるチームへ最小権限で割り当てる
• アカウントをまたいで環境を共有する場合は、各アカウントに許す操作範囲を絞り、意図しないルート変更を防ぐ
• 入口で受けた流量を宛先へ届ける経路は VPC 内のプライベートな接続を基本とし、不要な公開を避ける
• 自動構成される入口や接続の設定変更は CloudTrail で監査し、誰がどのルートを切り替えたかを追えるようにする
• 宛先サービス側でも、認証・認可や転送時の暗号化といった保護を個別に設計する

関連サービス・比較

入口でリクエストを受けて振り分ける役割が重なる Amazon API Gateway とよく対比されます。API Gateway は API の公開・管理を担う汎用サービスである一方、Refactor Spaces はストラングラーパターンによる段階的リファクタリングに特化し、入口・ルーティング・アカウントや VPC をまたぐ接続までを一つの基盤としてまとめて構成する点が異なります。実際、Refactor Spaces は内部で API Gateway を活用しており、両者は競合というより役割が異なる関係です。

ハンズオン / CLI例

# リファクタリングの作業空間となる環境を作成
aws migration-hub-refactor-spaces create-environment \
  --name "order-refactor" \
  --network-fabric-type TRANSIT_GATEWAY \
  --description "受注システムの段階的リファクタリング"

# 入口となるアプリケーションを環境内に作成
aws migration-hub-refactor-spaces create-application \
  --environment-identifier env-0123456789abcdef \
  --name "order-app" \
  --proxy-type API_GATEWAY \
  --vpc-id vpc-0123456789abcdef0

# 環境内のサービス（宛先）一覧を確認
aws migration-hub-refactor-spaces list-services \
  --environment-identifier env-0123456789abcdef \
  --application-identifier app-0123456789abcdef

# 設定済みのルート（振り分け規則）一覧を確認
aws migration-hub-refactor-spaces list-routes \
  --environment-identifier env-0123456789abcdef \
  --application-identifier app-0123456789abcdef