翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
strangler fig パターン
このガイドでこれまでに説明した設計パターンは、グリーンフィールドプロジェクトのアプリケーションを分解する場合にも当てはまります。大規模でモノリシックなアプリケーションを含むブラウンフィールドプロジェクトについてはどうでしょうか。以前の設計パターンをそれらに適用するのは難しいでしょう。なぜなら、実際に使われている間にそれらを細かく分割するのは大変な作業だからです。
strangler fig パターン
このパターンは、特定の機能を新しいサービスに置き換えることで、モノリシックなアプリケーションをマイクロサービスに段階的に変換する場合によく使用されます。目標は、レガシーバージョンと新しいモダナイズされたバージョンの両方を共存させることです。新しいシステムは当初、既存のシステムによってサポートされ、既存のシステムを補完します。このサポートにより、新しいシステムが拡張され、古いシステムを完全に置き換えることができるようになります。
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 パターンを使用する利点と欠点について説明します。
利点 | 欠点 |
---|---|
|
|
次の図は、strangler fig パターンをアプリケーションアーキテクチャに適用することでモノリスをマイクロサービスに分割する方法を示しています。どちらのシステムも並行して機能しますが、モノリスコードベースの外に機能を移動し、新しい機能で機能を強化することになります。これらの新機能により、ニーズに最適な方法でマイクロサービスをアーキテクトできるようになります。すべてがマイクロサービスに置き換えられるまで、モノリスから機能を取り除き続けることになります。この時点で、モノリスアプリケーションを排除することができます。ここで注意すべき重要な点は、モノリスとマイクロサービスの両方が一定期間共存するということです。