ストラングラー フィグ パターン

機能の特定の部分を新しいアプリケーションやサービスに徐々に置き換えることで、レガシ システムを段階的に移行します。 レガシ システムからの機能が置き換えられていくと、新しいシステムは最終的に古いシステムの機能すべてを置き換え、古いシステムを抑圧して使用停止できるようにします。

コンテキストと問題

システムが古くなるにつれ、このシステムが構築された開発ツール、ホスティング テクノロジ、システム アーキテクチャも徐々に使われなくなっていきます。 新機能が追加されると、これらのアプリケーションも大幅に複雑化し、メンテナンスや新機能の追加が難しくなっていきます。

複雑なシステムを完全に置き換えるには、膨大な作業が発生することがあります。 多くの場合、まだ移行されていない機能を古いシステムで処理し続けながら、新しいシステムに段階的に移行する必要があります。 ただし、2 つの異なるバージョンのアプリケーションを実行している場合、クライアントが特定の機能の場所を把握している必要があることになります。 機能またはサービスが移行されるたびに、クライアントを更新して、新しい場所が示されるようにする必要があります。

解決策

段階的に、機能の特定の部分を新しいアプリケーションやサービスに置き換えます。 バックエンド レガシ システムに送信される要求をインターセプトするファサードを作成します。 ファサードは、これらの要求をレガシ アプリケーションまたは新しいサービスにルーティングします。 既存の機能は段階的に新しいシステムに移行でき、コンシューマーは、移行が行われていることに気付くことなく、同じインターフェイスを引き続き使用できます。

このパターンは、移行によるリスクを最小化し、長期にわたって開発を分散させるのに役立ちます。 ファサードを使用すると、ユーザーを正しいアプリケーションに安全にルーティングし、レガシ アプリケーションが引き続き機能するようにしながら、任意のペースで新しいシステムに機能を追加できます。 時間の経過とともに、機能が新しいシステムに移行されると、レガシ システムは最終的に "抑圧" されて、必要なくなります。 このプロセスが完了すると、レガシ システムを安全に廃止できます。

問題と注意事項

• 新旧両方のシステムで使用される可能性のあるサービスとデータ ストアを処理する方法を検討してください。 両方が並列でこれらのリソースにアクセスできるようにしてください。
• 新しいアプリケーションおよびサービスを、これらのインターセプトと将来のストラングラー フィグ移行による置き換えが簡単になるように構成します。
• ある時点で、移行が完了すると、ストラングラー フィグ ファサードは消失するか、レガシ クライアントのアダプターに進化します。
• ファサードが移行に対して古くならないようにしてください。
• ファサードが単一障害点やパフォーマンスのボトルネックとならないようにしてください。

このパターンを使用する状況

バックエンド アプリケーションを新しいアーキテクチャに段階的に移行する場合に、このパターンを使用します。

このパターンは、次の場合には適切でない可能性があります。

• バックエンド システムへの要求がインターセプトされない場合。
• システム全体の置き換えの複雑さが少ない、小規模なシステムの場合。

ワークロード設計

設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、ワークロードの設計でどのようにストラングラー フィグ パターンを使用できるかを評価する必要があります。 次に例を示します。

設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。

次のステップ

• StranglerFigApplication に関する Martin Fowler のブログ記事

関連リソース

• メッセージング ブリッジ パターン