ストラングラーフィグパターンとは？システム全体を一括停止せずに置き換える段階移行の設計

ストラングラーフィグパターンとは、既存システムを稼働させながら、その周囲に新しい実装を加え、業務機能や振る舞い、データを小さな単位で段階的に移し、旧システムの廃止を目指すアプローチです。代表的な実装では、ファサードやプロキシなどの継ぎ目で呼び出しを傍受し、移行済みの範囲だけを新システムへ振り向けます。継ぎ目はHTTPの入口に限らず、メッセージング、内部API、データアクセスなどにも設けられます。利用者から見た入口を保てる構成では、移行中の影響を抑えながら置き換えを進められます。ただし、このパターンは個々の切り替えにおける無停止を保証するものではありません。一斉に切り替える方式と違い、投資と回収を一度の切り替え日に集中させず、段階に分けられる点が特徴です。その代わり、新旧が並走する期間に固有の設計課題が生まれます。

名前の由来と2004年の原文

Martin Fowlerは、2001年にクイーンズランドで見た絞め殺しの木（strangler fig）を、この比喩の出発点として2024年の回顧記事に書いています。 Fowlerの描写によれば、木のくぼみで発芽し、宿主から養分を得ながら根を地面まで伸ばして自立し、宿主が枯れることがあると、イチジクがその形をなぞるように残ります。この段階的な置き換えが同僚たちのレガシー刷新のやり方と重なって見えたと述べ、数年後の2004年6月29日に短い記事を公開しました。

2004年の記事の当初の題は「Strangler Application」でした。 Fowlerは、「strangler」の語だけが使われて由来が忘れられがちになり、暴力的な語感を懸念するようになったと書いています。そこで2019年に由来を強調する「Strangler Fig Application」へ変更したところ、新しい題が古い題を絞め殺した、と本人が脚注で説明しています。

ファサードを使う代表的な実装

MicrosoftのStrangler Fig patternは、ファサード（プロキシ）がレガシー宛てのリクエストを傍受し、レガシーと新サービスへ振り分ける構成として、移行を4段階に分けています。

ファサード導入：クライアントとレガシーの間にファサードを置き、当初は大半のリクエストをそのままレガシーへ流す
反復移行：反復のたびに新システムへ流す機能を増やし、レガシーの責務を減らしていく
レガシー廃止：依存がなくなった時点でレガシーを廃止し、ファサードは全リクエストを新システムへ流す
ファサード撤去：ファサードを外し、クライアントが新システムと直接通信して移行が完了する

AWSも同じパターンを、モノリスの分解における3つのステップとして説明しています。 transform（変換）で新コンポーネントを並行して用意し、coexist（共存）で切り戻し用にモノリスを残したまま境界にHTTPプロキシ（例：Amazon API Gateway）を置いて呼び出しを振り向け、eliminate（除去）で移り終えた機能を取り除きます。

外部リクエストを振り分けるファサードだけでは、新旧間の内部呼び出しを処理できません。 Microsoftは新旧双方の依存関係を計画し、必要に応じて腐敗防止層（Anti-Corruption Layer、ACL）をアダプターとして置き、異なる契約を変換する方法を示しています。 AWSも詳細な実装ガイドで、モノリス内部から移行済みサービスを呼ぶACLを設け、依存するサービスの移行後に撤去する構成を説明しています。

なぜリスクが分散するのか

Fowlerは、段階移行には分割のための継ぎ目（seam）をシステムのどこに入れるかを見極める作業が要ると述べています。よく設計されたシステムなら継ぎ目は初めから存在するはずだが、そのようなシステムはまず存在しない、という但し書き付きです。レガシーシステムが独立して置き換えられる部品でできていることはまれで、分解の方法を考えること自体に手間がかかるためです。 FowlerはLegacy Seamで、継ぎ目を、その箇所自体を編集せずにプログラムの振る舞いを変えられる場所というMichael Feathersの定義で説明しています。継ぎ目は単なるモジュール境界ではなく、依存を切る、観測点を置く、新しい実装へ処理を振り向けるといった用途を持ちます。そのうえで、継ぎ目で部品を切り離せれば、部品が小さいぶん投入のリスクは小さく、動き始めた部品から事業側が価値を得られて回収も早まり、置き換え方の学習も進むと説明しています。

新旧の共存を支えるため、移行を容易にするソフトウェア要素を導入し、完了後に削除することがあります。 Ian Cartwrightらはこれをtransitional architectureと呼びます。 Fowlerは、段階移行全体ではリスクの低減と価値の前倒しが移行用要素のコストを上回ると説明しています。一方、個々の移行用要素は、得られる価値とリスク低減を、構築、運用、撤去にかかる費用と比較して採否を決める必要があります。 Microsoftも同じ構成を移行期のアーキテクチャと位置づけ、投資対効果の高い置き換えを先に実施できる点を利点に挙げています。

ただしFowlerは、業務プロセスに深く組み込まれたシステムの置き換えが簡単になることはなく、この方式が変えるのは投資と回収が段階的かつ目に見える形で起きる点だと書いています。また、このアプローチを技術構成だけの問題とはしていません。レガシーを硬直化させた設計の考え方や組織プロセス、文化、リーダーシップを変えなければ、新システムも同じ状態になり得るとして、開発プラクティスと組織の変化も必要だと述べています。

Fowlerのこの説明が直接扱うのは主に移行用要素のコストで、並走期間の運用費はそれとは分けて見積もる必要があります。新旧が共存する間は、構成に応じて、旧システムの保守やライセンス、二重の基盤費、データ同期、ファサードの保守、両系にまたがるテストと監視の費用が発生します。モダナイゼーションの解説で挙げた、データ整合性、双方にまたがる依存関係、二重運用の費用という3つの負担は、このパターンを選んでも消えません。リスクを分散できる一方で、共存期間の追加コストも含めて採否を判断する必要があります。

並走期間のデータ整合と切り戻し

経路の切り替えに加え、新旧が同じ業務データを扱う期間の整合性も大きな課題です。 Microsoftは、双方が使う可能性のあるサービスとデータストアの扱いを検討し、両者が同時にアクセスできる状態の確保を求めています。同じ解説は、モノリシックなDBを分解する例として次の順序を示しています。

局面	データの持ち方	切り戻し時の条件
新サービス投入	新サービスも既存のモノリシックDBを読み書きする	新サービスへの経路を旧実装へ戻す
新DBへの複製	ETLで初期移行し、新システムが新DBへ書き込み、既存DBから新DBへCDCで同期して整合性を検証する	旧表と同期処理が残る間は可能
カットオーバー	新DBがそのドメインの正（system of record）になる	旧側オブジェクトの削除前なら可能で、削除後は復元と変更の再生が必要

Microsoftは、旧側の表、ストアドプロシージャ、同期処理を削除した後に戻すには、オブジェクトの復元とデータ変更の再生が必要で工数とリスクが大きく増えると説明しています。そのため、旧側の削除は各ドメインの意図的な最終ステップとして、検証後にのみ行います。

ルーティングを戻せることと、データを安全に戻せることは別です。新DB側の更新を旧DBへ反映しない構成では、切り替え後の更新を旧実装が参照できません。局面ごとの読み書き経路と正本、同期方向、切り戻し時の変更再生手順を明文化し、切り替え前に整合性を検証して、旧オブジェクトの削除を最後に置く必要があります。

使いどころと、適さない場面

Microsoftは、大規模なシステムや複雑な機能の置き換えがリスクを伴う場合の段階的な移行を使いどころとし、移行の期間中は元のシステムを長期にわたって存続させられることを条件に挙げています。

一方、同じ解説は次の場合には適さない可能性があるとしています。

バックエンドシステムへのリクエストを傍受できない
レガシーのソースコードを変更して再デプロイできない（移行済み機能の無効化と内部呼び出しのリダイレクトに変更が要るため）
小規模なシステムで、全体をまとめて置き換えるほうが単純である
元のシステムを短期間で完全に廃止する必要がある

AWSも、規模が小さく複雑さの低いシステムには向かず、リクエストを傍受してルーティングできないシステムでは使えないとしています。両者とも、プロキシまたはファサードの層が単一障害点や性能上のボトルネックになり得る点を挙げ、AWSは各サービスへの切り戻し計画を、Microsoftはファサードが移行に追随することを求めています。

MicrosoftとAWSが示すファサードとACLの構成では、リクエストを傍受し、レガシーのソースコードを変更できることが前提です。一方、FowlerのEvent Interceptionが扱う継ぎ目は、HTTPプロキシだけではありません。ソースコードを変更できなくても、対象トラフィックを外部の境界ですべて傍受できる構成なら、旧コードを変えずに新実装と共存させられる場合があります。反対に、傍受できない内部経路が残る場合は、別の継ぎ目を設けるか、段階移行以外の選択肢を検討します。直すか作り直すかの判断軸はリファクタリングとリライトの違い、システム単位の仕分けはモダナイゼーションの解説で扱っています。

最初の移行単位と境界の決め方

Fowlerは、段階移行を固定された順序の手順とはせず、刷新で実現したい成果を明確にして、関係者の認識をそろえる必要があると述べています。 Fowlerは、システムが複数の業務ニーズをどう支えているかを把握し、個々のニーズを新しいコンポーネントとして抽出する方法が有用な場合が多いとしています。実務上は、変更要求が続いていて移行の効果を早く検証できる範囲や、依存が比較的少なく、データ境界と切り戻し条件を観測しやすい範囲が最初の候補になります。

ファサードを使う場合は、対象のリクエストを確実に傍受できる位置へ置きます。 AWSはモノリスの境界にHTTPプロキシを置く例を示していますが、旧システムの内部APIやDBへ直接つなぐ経路が残っていれば、そこは傍受の外側になります。

旧システムを停止するだけでは、移行は完了しません。 Microsoftの4段階では、レガシーを廃止し、最後にファサードを外してクライアントが新システムと直接通信した時点が完了とされ、レガシークライアント向けのアダプタとして残す選択肢も示されています。どちらを採るかを決めないまま終えると、使われない旧経路や移行用の要素が残りやすくなります。