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

特定の機能を新しいアプリケーションやサービスに徐々に置き換えることで、レガシ システムを段階的に移行します。 レガシ システムの機能を置き換える場合、新しいシステムは最終的に古いシステムのすべての機能で構成されます。 この方法では、古いシステムを使用停止できるように抑制します。

コンテキストと問題

システムが古くなるにつれて、開発ツール、ホスティング テクノロジ、および構築されているシステム アーキテクチャが古くなる可能性があります。 新しい機能が追加されると、これらのアプリケーションはより複雑になり、保守や拡張が困難になる可能性があります。

複雑なシステム全体を置き換えるのは困難です。 代わりに、新しいシステムに段階的に移行し、古いシステムを使用して未移行の機能を使用できます。 ただし、アプリケーションの並列バージョンを実行する場合、クライアントは各機能を含むバージョンを追跡する必要があります。 機能またはサービスを移行する場合は、クライアントを新しい場所に移動する必要があります。 これらの課題に対処するには、増分移行をサポートし、クライアントの中断を最小限に抑えるアプローチを採用します。

解決策

新しい サービス境界を特定したら、増分プロセスを使用して、特定の機能を新しいアプリケーションとサービスに置き換えます。 お客様は引き続き同じインターフェイスを使用しており、移行が進行中であることを認識できません。

このアーキテクチャのVisio ファイルをダウンロードしてください。

ストラングラー Fig パターンは、最新化に対する制御された段階的なアプローチを提供します。 これにより、最新化作業中に既存のアプリケーションが引き続き機能できるようになります。 ファサード (プロキシ) は、バックエンド レガシ システムに送信される要求をインターセプトします。 ファサードは、これらの要求をレガシ アプリケーションまたは新しいサービスにルーティングします。

このパターンでは、プロジェクトの複雑さに合ったペースでチームが前進できるようにすることで、移行のリスクを軽減します。 新しいシステムに機能を移行すると、レガシ システムは廃止され、レガシ システムは使用停止になります。

1. Strangler Fig パターンは、クライアント アプリ、レガシ システム、および新しいシステムの間にファサード (プロキシ) を導入することから始まります。 ファサードは仲介役として機能します。 これにより、クライアント アプリはレガシ システムと新しいシステムと対話できます。 最初は、ファサードはほとんどの要求をレガシ システムにルーティングします。

2. 移行が進むにつれて、ファサードは要求をレガシ システムから新しいシステムに段階的にシフトします。 イテレーションのたびに、新しいシステムでより多くの機能を実装します。

   この増分アプローチにより、レガシ システムの責任が徐々に軽減され、新しいシステムの範囲が広がります。 プロセスは反復的です。 これにより、チームは管理しやすい段階で複雑さと依存関係に対処できます。 これらのステージは、システムが安定して機能し続けるのに役立ちます。

3. すべての機能を移行し、レガシ システムに依存関係がない場合は、レガシ システムを使用停止にすることができます。 ファサードは、すべての要求を新しいシステムのみにルーティングします。

4. ファサードを削除し、新しいシステムと直接通信するようにクライアント アプリを再構成します。 この手順では、移行の完了をマークします。

問題と考慮事項

このパターンを実装する方法を決定するときは、次の点を考慮してください。

• 新しいシステムとレガシ システムの両方で使用される可能性があるサービスとデータ ストアを処理する方法を検討してください。 両方のシステムがこれらのリソースに同時にアクセスできることを確認します。

• 将来のストラングラー フィグの移行で簡単に捕捉して置き換えることができるように、新しいアプリケーションとサービスを構築します。 たとえば、各部分を個別に移行できるように、ソリューションの各部分間に明確な境界を設定するよう努めます。

• 移行が完了したら、通常、ストラングラー フィグ ファサードを削除します。 または、新しいクライアントのコア システムを更新するときに、レガシ クライアントが使用するアダプターとしてファサードを維持することもできます。

  これを移行アーキテクチャとして概念化し、このアーキテクチャのリスク軽減の利点と一時的なインフラストラクチャ コストのバランスを取ります。

• ファサードが移行に対応していることを確認します。

• ファサードが単一障害点やパフォーマンスのボトルネックにならないようにします。

• システム間の依存関係を計画します。 移行中は、両方のシステムが共存して通信する必要があります。 たとえば、新しいシステムではレガシ システムから未承認の機能を呼び出す必要があり、未移行のレガシ コンポーネントは新しいシステムから移行された機能を呼び出す必要がある場合があります。 これらの呼び出しを管理するには、 破損防止レイヤー パターンを使用します。 破損防止レイヤーは、2 つのシステム間で要求を変換するアダプターとして機能します。 このレイヤーは、レガシ システムがコードを大幅に変更することなく新しいサービスに到達できるように、新しいシステムの設計をレガシ セマンティクスから保護します。 このアダプターがないと、システム間の依存関係によってコンポーネントが中断されたり、新しいシステムでレガシ規則が強制的に採用されたりする可能性があります。

このパターンを使用する場合

このパターンは次の状況で使用します。

• バックエンド アプリケーションを新しいアーキテクチャに徐々に移行します。特に、大規模なシステム、主要なコンポーネント、または複雑な機能を置き換えるとリスクが発生します。

• 元のシステムは、移行作業中に長期間存在し続けることができます。

このパターンは、次の場合に適さない場合があります。

• バックエンド システムへの要求をインターセプトすることはできません。

• レガシ システムのソース コードにアクセスすることはできません。 移行された機能を無効にし、内部呼び出しをリダイレクトするには、レガシ システムのソース コードを変更できる必要があります。

• 小規模なシステムを移行し、システム全体を置き換えるのは簡単です。

• 元のソリューションを迅速に完全に使用停止にする必要があります。

ワークロード設計

ワークロードの設計で Strangler Fig パターンを使用して 、Azure Well-Architected Framework の柱の目標と原則に対処する方法を評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。

このパターンが導入する可能性がある他の柱の目標に対するトレードオフを検討してください。

例

従来のシステムは、通常、複数のドメインに対応する一元化されたモノリシック データベースに依存します。 時間の経過と同時に、この共有データベースはドメイン間の依存関係のために管理と改善が困難になります。 この課題に対処するために、Strangler Fig パターンは、モノリシック データベースから分離ドメイン データベースにドメイン固有のテーブル、ストアド プロシージャ、および関連データを段階的に抽出します。 各データベースに含まれるドメインは 1 つだけです。 モノリシック データベースが完全に分解されるまで、抽出プロセスを繰り返します。

1. ドメインの要求の管理を開始する新しいシステム サービスを導入します。 新しいシステム サービスでは、ドメイン テーブルのモノリシック データベースの読み取りと書き込みが引き続き行われます。 レガシ システムは、引き続き他のすべてのドメインにサービスを提供します。

2. 新しいシステム用の分離ドメイン データベースを導入します。 抽出、変換、読み込み (ETL) プロセスを使用して、関連するドメイン テーブルとその履歴データを新しいデータベースに移行します。 変更データ キャプチャ (CDC) プロセスは、モノリシック データベースから新しいドメイン データベースにドメイン データを同期します。 このフェーズでは、レガシ システムはモノリシック データベースとの間で引き続き読み取りと書き込みを行い、新しいシステムは新しいドメイン データベースに書き込みます。 カットオーバーの前に、両方のデータベース間の整合性を検証します。

3. 検証後、新しいドメイン データベースはそのドメインのレコードシステムになります。 新しいシステムは、ドメイン データベースに対してすべての読み取りおよび書き込み操作を実行します。 対応するドメイン テーブル、ストアド プロシージャ、依存関係をモノリシック データベースから削除します。 モノリシック データベースが完全に分解されるまで、ドメインごとにこのプロセスを繰り返します。

   モノリシック データベースにドメイン テーブルと同期プロセスがまだ存在する場合は、フェーズ 2 とフェーズ 3 の開始時にモノリシック データベースにロールバックできます。 モノリシック データベースからドメイン テーブル、ストアド プロシージャ、および同期プロセスを削除した後でモノリシック データベースにロールバックするには、それらのオブジェクトを復元してデータ変更を再生する必要があります。 ただし、このプロセスにより、労力とリスクが大幅に増加します。 レガシ オブジェクトの削除は、各ドメインの意図的な最終手順として扱います。 新しいシステムが検証された後にのみ、レガシ オブジェクトを削除します。

貢献者達

Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。

主要な著者:

• アドナン・カーン |シニア クラウド ソリューション アーキテクト
• オヴァイス・メフブブ・アーメッド・カーン |シニア クラウド ソリューション アーキテクト

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• ストラングラー Fig パターン アプリケーションに関する Martin Fowler のブログ投稿を読む

関連するリソース

• メッセージング ブリッジ パターン
• アマゾン ウェブ サービスから Azure