Strangler Fig パターン

Strangler Fig パターンとは

Strangler Fig パターンは、Martin Fowler が 2004 年に提唱した、レガシーシステムを段階的に新システムへ置き換える移行戦略である。熱帯の絞め殺しの木 (Strangler Fig) が宿主の木を徐々に覆い尽くすように、旧システムの機能を 1 つずつ新システムに移行し、最終的に旧システムを廃止する。

なぜ一括移行ではダメか

なぜ一括移行ではダメかを以下にまとめる。

移行方式	リスク	期間	ビジネス影響
ビッグバン (一括)	極めて高い	長期間停止	全機能が同時に切り替わる
Strangler Fig (段階的)	低い	段階的に移行	機能単位で切り替え

ビッグバン移行は「全部できるまで何も出せない」状態が続き、途中で頓挫するリスクが高い。Strangler Fig は移行途中でも新旧が共存し、いつでも旧システムにフォールバックできる。

移行の流れ

まず旧モノリスの前段にルーター (API Gateway) を配置し、全トラフィックをモノリスに転送する。次に機能を 1 つずつ新サービスに移行し、ルーターで該当パスを新サービスに振り向ける。最終的にモノリスへのトラフィックがゼロになったら、モノリスを廃止する。

Phase 1: ルーター (API Gateway) を前段に配置
  [クライアント] → [API Gateway] → [旧モノリス]

Phase 2: 機能 A を新サービスに移行
  [クライアント] → [API Gateway] → /api/a → [新サービス A]
                                  → /api/* → [旧モノリス]

Phase 3: 機能 B, C も移行
  [クライアント] → [API Gateway] → /api/a → [新サービス A]
                                  → /api/b → [新サービス B]
                                  → /api/* → [旧モノリス]

Phase N: 旧モノリスを廃止
  [クライアント] → [API Gateway] → [新サービス群]

AWS での実装

API Gateway のパスベースルーティングで新旧を振り分ける。

コンポーネント	AWS サービス
ルーター	API Gateway / CloudFront
新サービス	Lambda / ECS
旧システム	EC2 / オンプレミス
データ同期	DynamoDB Streams / CDC

CloudFront のオリジングループを使えば、新サービスがエラーを返した場合に旧システムへフォールバックする構成も可能。

移行の判断基準

どの機能から移行するかは、ビジネス価値と技術的リスクのバランスで決める。変更頻度が高い機能、障害が多い機能、ビジネス上の優先度が高い機能から着手するのが定石。データベースの分離が難しい機能は後回しにする。

落とし穴

データの二重管理: 新旧で同じデータを参照する場合、整合性の維持が難しい。腐敗防止層 (ACL) でデータ変換を挟む
移行の長期化: 「旧システムでも動いているから」と移行が停滞し、新旧の並行運用コストが膨らむ
ルーティングの複雑化: パスベースの振り分けルールが増えすぎると管理が困難になる

マイクロサービス移行の実践書も参考になる。