このパターンでは、特定の機能を新しいアプリケーションやサービスに徐々に置き換えることで、レガシ システムを段階的に移行します。 レガシ システムの機能を置き換える場合、新しいシステムは最終的に古いシステムのすべての機能で構成されます。 この方法では、古いシステムを使用停止できるように抑制します。
コンテキストと問題
システムが古くなるにつれて、開発ツール、ホスティング テクノロジ、および構築されているシステム アーキテクチャが古くなる可能性があります。 新しい機能が追加されると、これらのアプリケーションはより複雑になり、保守や拡張が困難になる可能性があります。
複雑なシステム全体を置き換えることは大きな取り組みです。 代わりに、多くのチームは新しいシステムに徐々に移行し、未承認の機能を処理するために古いシステムを維持することを好みます。 ただし、アプリケーションの 2 つの異なるバージョンを実行すると、クライアントは個々の機能を持つバージョンを追跡する必要があります。 チームは、機能またはサービスを移行するたびに、クライアントを新しい場所に誘導する必要があります。 これらの課題を克服するために、増分移行をサポートし、クライアントの中断を最小限に抑えるアプローチを採用できます。
解決策
増分プロセスを使用して、特定の機能を新しいアプリケーションとサービスに置き換えます。 お客様は、この移行が行われていることに気づかずに、同じインターフェイスを引き続き使用できます。
ストラングラー Fig パターンは、最新化に対する制御された段階的なアプローチを提供します。 これにより、最新化作業中に既存のアプリケーションが引き続き機能できるようになります。 ファサード (プロキシ) は、バックエンド レガシ システムに送信される要求をインターセプトします。 ファサードは、これらの要求をレガシ アプリケーションまたは新しいサービスにルーティングします。
このパターンでは、プロジェクトの複雑さに合ったペースでチームが前進できるようにすることで、移行のリスクを軽減します。 新しいシステムに機能を移行すると、レガシ システムは廃止され、レガシ システムは使用停止になります。
Strangler Fig パターンは、クライアント アプリ、レガシ システム、および新しいシステムの間にファサード (プロキシ) を導入することから始まります。 ファサードは仲介役として機能します。 これにより、クライアント アプリはレガシ システムと新しいシステムと対話できます。 最初は、ファサードはほとんどの要求をレガシ システムにルーティングします。
移行が進むにつれて、ファサードは要求をレガシ システムから新しいシステムに段階的にシフトします。 イテレーションのたびに、新しいシステムでより多くの機能を実装します。
この増分アプローチにより、レガシ システムの責任が徐々に軽減され、新しいシステムの範囲が広がります。 プロセスは反復的です。 これにより、チームは管理しやすい段階で複雑さと依存関係に対処できます。 これらのステージは、システムが安定して機能し続けるのに役立ちます。
すべての機能を移行し、レガシ システムに依存関係がない場合は、レガシ システムを使用停止にすることができます。 ファサードは、すべての要求を新しいシステムのみにルーティングします。
ファサードを削除し、新しいシステムと直接通信するようにクライアント アプリを再構成します。 この手順では、移行の完了をマークします。
問題と考慮事項
このパターンを実装する方法を決定するときは、次の点を考慮してください。
新しいシステムとレガシ システムの両方で使用される可能性があるサービスとデータ ストアを処理する方法を検討してください。 両方のシステムがこれらのリソースに同時にアクセスできることを確認します。
将来のストラングラー フィグの移行で簡単に捕捉して置き換えることができるように、新しいアプリケーションとサービスを構築します。 たとえば、各部分を個別に移行できるように、ソリューションの各部分間に明確な境界を設定するよう努めます。
移行が完了したら、通常、ストラングラー フィグ ファサードを削除します。 または、新しいクライアントのコア システムを更新するときに、レガシ クライアントが使用するアダプターとしてファサードを維持することもできます。
ファサードが移行に対応していることを確認します。
ファサードが単一障害点やパフォーマンスのボトルネックにならないようにします。
このパターンを使用する場合
このパターンは次の状況で使用します。
バックエンド アプリケーションを新しいアーキテクチャに徐々に移行します。特に、大規模なシステム、主要なコンポーネント、または複雑な機能を置き換えるとリスクが発生します。
元のシステムは、移行作業中に長期間存在し続けることができます。
このパターンは、次の場合に適さない場合があります。
バックエンド システムへの要求をインターセプトすることはできません。
小規模なシステムを移行し、システム全体を置き換えるのは簡単です。
元のソリューションを迅速に完全に使用停止にする必要があります。
ワークロード設計
ワークロードの設計で Strangler Fig パターンを使用して 、Azure Well-Architected Framework の柱の目標と原則に対処する方法を評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。
| 柱 | このパターンが柱の目標をサポートする方法 |
|---|---|
| 信頼性設計の決定により、ワークロードが誤動作に対して復元力を持ち、障害発生後も完全に機能する状態に回復することができます。 | このパターンの増分アプローチは、一度に大規模な全身変更を行うのと比較して、コンポーネントの移行中のリスクを軽減するのに役立ちます。 - RE:08 テスト |
| コストの最適化では、ワークロードの投資収益率 (ROI) の維持と向上に重点を置いています。 | このアプローチの目的は、現在実行中のシステムで既存の投資を最大限に活用しながら、段階的に最新化することです。 これにより、ROI が低い置換の前に、高 ROI の置換を実行できます。 - CO:07 コンポーネントコスト - CO:08 環境コスト |
| オペレーショナルエクセレンス は、標準化されたプロセスとチームの結束によってワークロードの品質を提供します。 | このパターンは、継続的な改善アプローチを提供します。 時間の経過に伴って小さな変更を行う増分置換は、実装するリスクの高い大規模な全身変更よりも望ましいです。 - OE:06 ワークロード開発のためのサプライ チェーン - OE:11 安全な配備の実践 |
このパターンが導入する可能性がある他の柱の目標に対するトレードオフを検討してください。
例
従来のシステムは、通常、一元化されたデータベースに依存します。 時間が経つにつれて、一元化されたデータベースは、多くの依存関係のために管理と進化が困難になる可能性があります。 これらの課題に対処するために、さまざまなデータベース パターンによって、このようなレガシ システムからの移行が容易になります。 ストラングラー Fig パターンは、これらのパターンの 1 つです。 従来のシステムから新しいシステムに段階的に移行し、中断を最小限に抑えるための段階的なアプローチとして、ストラングラー Fig パターンを適用します。
新しいシステムを導入すると、新しいシステムがクライアント アプリからの要求の処理を開始します。 ただし、新しいシステムは引き続き、すべての読み取り操作と書き込み操作のレガシ データベースに依存します。 従来のシステムは引き続き運用可能であり、即時の構造変更なしでスムーズな移行を容易にします。
次のフェーズでは、新しいデータベースを導入します。 抽出、変換、読み込み (ETL) プロセスを使用して、データ読み込み履歴を新しいデータベースに移行します。 ETL プロセスは、新しいデータベースをレガシ データベースと同期します。 このフェーズでは、新しいシステムがシャドウ書き込みを実行します。 新しいシステムでは、両方のデータベースが並列で更新されます。 新しいシステムは、一貫性を検証するために、レガシ データベースから引き続き読み取ります。
最後に、新しいデータベースがレコードのシステムになります。 新しいデータベースは、すべての読み取り操作と書き込み操作を引き継ぎます。 レガシ データベースとレガシ システムの非推奨化を開始できます。 新しいデータベースを検証したら、レガシ データベースを廃止できます。 この廃止により、中断を最小限に抑えながら移行プロセスが完了します。
次のステップ
ストラングラー Fig パターン アプリケーションに関する Martin Fowler のブログ投稿をお読みください。