翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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 エンドポイントに透過的に追加できるようにします。
次の表は、ストラングラーフィグパターンを使用する場合の利点と欠点を説明しています。
利点 | 欠点 |
---|---|
|
|
次の図は、strangler fig パターンをアプリケーションアーキテクチャに適用することで、モノリスをマイクロサービスに分割する方法を示しています。どちらのシステムもparallel 機能しますが、モノリス・コード・ベースの外部に機能を移動して、新しい機能を追加して拡張することになります。これらの新機能により、ニーズに最適な方法でマイクロサービスを設計する機会が得られます。すべてがマイクロサービスに置き換えられるまで、モノリスから機能を取り除き続けることになります。この時点で、モノリスアプリケーションを削除できます。ここで注意すべき重要な点は、モノリスとマイクロサービスの両方が一定期間共存するということです。
