IT 技書の森

Strangler Fig パターン

レガシーシステムを段階的に新システムへ移行する設計パターン

マイクロサービス設計パターン

Strangler Fig パターンとは

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

なぜ一括移行ではダメか

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

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

移行の流れ

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) でデータ変換を挟む
  • 移行の長期化: 「旧システムでも動いているから」と移行が停滞し、新旧の並行運用コストが膨らむ
  • ルーティングの複雑化: パスベースの振り分けルールが増えすぎると管理が困難になる

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

関連用語