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

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

strangler fig パターン

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

strangler fig パターン は、木の上部の枝に自生するある種のイチジクにインスパイアされた Martin Fowler が提案した人気の設計パターンです。既存の木は最初は新しいイチジクの支持構造になります。次に、イチジクは根を地面に送り、元の木を徐々に包み込み、新しい自立したイチジクだけをその場所に残します。

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

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

  • 変換 — レガシーアプリケーションと並行して移植または書き換えることにより、モダナイズされたコンポーネントを特定して作成します。

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

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

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

以下の表は、strangler fig パターンを使用する利点と欠点について説明します。

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

  • 更新バージョンへのリファクタリング中も、古いサービスをそのまま使用します。

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

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

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

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

  • バックエンドシステムへのリクエストをインターセプトおよびルーティングできないシステムでは使用できません。

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

  • 問題が発生した場合に、迅速かつ安全に古い方法に戻すために、リファクタリングされたサービスごとにロールバック計画が必要です。

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

strangler fig パターンを使用してモノリスをマイクロサービスに分解する