編集

次の方法で共有


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

Azure Migrate

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

コンテキストと問題

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

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

解決策

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

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

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

問題と注意事項

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

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

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

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

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

ワークロード設計

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

重要な要素 このパターンが柱の目標をサポートする方法
信頼性設計の決定により、ワークロードが誤動作に対して復元力を持ち、障害発生後も完全に機能する状態に回復することができます。 このパターンの漸進的アプローチは、コンポーネントの移行時と大規模な体系的変更時のリスクを軽減するために役立ちます。

- RE:08 テスト
コスト最適化は、ワークロードの投資収益率の維持と改善に重点を置いています。 このアプローチの目標は、現在実行中のシステムにおける既存の投資を最大限に活用しながら、段階的に最新化することです。したがって、ROI の低い置き換えよりも先に、ROI の高い置き換えを実行できます。

- CO:07 コンポーネントコスト
- CO:08 環境コスト
オペレーショナルエクセレンス は、標準化されたプロセスとチームの結束によってワークロードの品質を提供します。 このパターンは継続的な改善アプローチを提供します。このアプローチでは、実装のリスクの高い大規模な体系的変更ではなく、時間をかけて小規模な変更を積み重ねる増分的な置き換えが推奨されます。

- OE:06 ワークロード開発
- OE:11 安全な配備の実践

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

次のステップ