strangler fig パターン - AWS の規範的ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

strangler fig パターン

このガイドでこれまでに説明した設計パターンは、グリーンフィールドプロジェクトの分解アプリケーションにも当てはまります。大規模なモノリシック・アプリケーションを含むブラウンフィールド・プロジェクトについてはどうでしょうか。以前のデザインパターンを適用するのは難しいでしょう。積極的に使っている間に細かく分割するのは大変な作業だからです。

ストラングラーイチジク柄は、木の上部の枝に種をまくある種のイチジクにインスパイアされたマーティン・ファウラーが紹介した人気のデザインパターンです。既存のツリーは、最初に新しいフィグのサポート構造になります。 その後、イチジクはその根を地面に送り、元の木を徐々に包み込み、代わりに新しい自立したイチジクだけを残します。

このパターンは、特定の機能を新しいサービスに置き換えることで、モノリシックアプリケーションをマイクロサービスに段階的に変換する場合によく使用されます。目標は、レガシーバージョンと新しいモダナイズバージョンを共存させることです。新しいシステムは、最初は既存のシステムによってサポートされ、既存のシステムによってサポートされます。このサポートにより、新しいシステムを拡張したり、古いシステムを完全に置き換えたりする時間を確保できます。

strangler fig パターンを実装してモノリシックアプリケーションからマイクロサービスに移行するプロセスは、変換、共存、削除の 3 つのステップで構成されます。

  • トランスフォーメーション — レガシーアプリケーションとparallel 移植または書き換えを行うことで、最新化されたコンポーネントを特定して作成します。

  • 共存 — モノリスアプリケーションをロールバックしてもかまいません。モノリスの境界に HTTP プロキシ (Amazon API Gateway など) を組み込んで外部のシステムコールをインターセプトし、トラフィックを最新バージョンにリダイレクトします。これにより、機能を段階的に実装できます。

  • 排除 — トラフィックがレガシーモノリスから最新のサービスにリダイレクトされるので、モノリスから古い機能を廃止します。

AWS Migration Hub Refactor SpacesAWSマイクロサービスへの段階的なアプリケーションリファクタリングの出発点です。Refactor Spaces には、インクリメンタルリファクタリング用の strangler fig パターンをモデル化するアプリケーションがあります。Refactor Spaces アプリケーションは API Gateway、Network Load Balancer、およびリソースベースAWS Identity and Access Management (IAM) ポリシーをオーケストレーションして、新しいサービスを外部 HTTP エンドポイントに透過的に追加できるようにします。

次の表は、ストラングラーフィグパターンを使用する場合の利点と欠点を説明しています。

利点 欠点
  • 1 つのサービスから 1 つ以上の代替サービスへの正常な移行を可能にします。

  • 更新されたバージョンにリファクタリングしている間、古いサービスをそのまま使用し続けます。

  • 古いサービスをリファクタリングしながら、新しいサービスや機能を追加できます。

  • このパターンは API のバージョン管理に使用できます。

  • このパターンは、アップグレードされていない、またはアップグレードされないソリューションのレガシーインタラクションに使用できます。

  • 複雑さが低くサイズが小さい小規模システムには適していません。

  • バックエンドシステムへのリクエストを傍受してルーティングできないシステムでは使用できません。

  • プロキシまたはファサードレイヤーは、適切に設計されていないと、単一障害点になったり、パフォーマンスのボトルネックになったりする可能性があります。

  • 問題が発生した場合に迅速かつ安全に処理を行うために、リファクタリングされた各サービスのロールバック計画が必要です。

次の図は、strangler fig パターンをアプリケーションアーキテクチャに適用することで、モノリスをマイクロサービスに分割する方法を示しています。どちらのシステムもparallel 機能しますが、モノリス・コード・ベースの外部に機能を移動して、新しい機能を追加して拡張することになります。これらの新機能により、ニーズに最適な方法でマイクロサービスを設計する機会が得られます。すべてがマイクロサービスに置き換えられるまで、モノリスから機能を取り除き続けることになります。この時点で、モノリスアプリケーションを削除できます。ここで注意すべき重要な点は、モノリスとマイクロサービスの両方が一定期間共存するということです。


        strangler fig パターンによるモノリスのマイクロサービスへの分解