翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ストラングラーフィグパターン
目的
strangler figパターンは、モノリシックなアプリケーションをマイクロサービスアーキテクチャに段階的に移行するのに役立ち、トランスフォーメーションリスクとビジネス中断を軽減します。
モチベーション
モノリシック・アプリケーションは、ほとんどの機能を単一のプロセスまたはコンテナ内で実現するように開発されています。コードは緊密に結合されています。そのため、アプリケーションの変更では、リグレッションの問題を避けるために徹底的な再テストが必要になります。変更を単独でテストすることはできず、サイクルタイムに影響します。アプリケーションがより多くの機能で強化されるにつれて、複雑さが増すと、メンテナンスに費やされる時間が増え、市場投入までの時間が長くなり、その結果、製品のイノベーションが遅くなる可能性があります。
アプリケーションの規模が大きくなると、チームの認知的負荷が増大し、チームの所有権の境界が不明確になる可能性があります。負荷に基づいて個々の機能をスケーリングすることはできません。ピーク時の負荷に対応するようにアプリケーション全体をスケーリングする必要があります。システムが古くなると、テクノロジーが時代遅れになり、サポートコストが高くなる可能性があります。モノリシックなレガシーアプリケーションは、開発当時は利用可能で、配布するようには設計されていなかったベストプラクティスに従っています。
モノリシックアプリケーションをマイクロサービスアーキテクチャに移行すると、より小さなコンポーネントに分割できます。これらのコンポーネントは個別に拡張でき、個別にリリースでき、個々のチームが所有できます。その結果、変更がローカライズされ、テストやリリースが迅速に行えるため、変更の速度が速くなります。コンポーネントは緩く結合されており、個別に展開できるため、変更の影響範囲は小さくなります。
コードを書き直したりリファクタリングしたりして、モノリスを完全にマイクロサービスアプリケーションに置き換えるのは大変な作業であり、大きなリスクを伴います。モノリスを一度の操作で移行するビッグバン移行は、変革リスクと事業中断を招きます。アプリケーションがリファクタリングされている間は、新しい機能を追加するのは非常に難しく、不可能ですらあります。
この問題を解決する 1 つの方法は、マーティン・ファウラーによって導入されたストラングラー・フィグ・パターンを使用することです。このパターンでは、徐々に特徴を抽出し、既存のシステムを中心に新しいアプリケーションを作成することで、マイクロサービスに移行します。モノリスの機能は徐々にマイクロサービスに置き換えられ、アプリケーションユーザーは新しく移行された機能を徐々に使用できるようになります。すべての機能を新しいシステムに移行すれば、モノリシックなアプリケーションを安全に廃止できます。
適用性
ストラングラー・フィグ・パターンは次の場合に使用します。
-
モノリシックアプリケーションを徐々にマイクロサービスアーキテクチャに移行したい。
-
モノリスはその規模と複雑さゆえに、ビッグバン移行アプローチにはリスクが伴います。
-
企業は新しい機能の追加を望んでおり、変革が完了するのが待ちきれません。
-
変革中のエンドユーザーへの影響を最小限に抑える必要があります。
問題と考慮事項
-
コードベースへのアクセス:strangler fig パターンを実装するには、monolith アプリケーションのコードベースにアクセスできる必要があります。機能がモノリスから移行されると、コードを少し変更し、モノリス内に破損防止レイヤーを実装して、呼び出しを新しいマイクロサービスにルーティングする必要があります。コードベースにアクセスできなければ、呼び出しをインターセプトすることはできません。コードベースアクセスは、受信リクエストをリダイレクトするためにも重要です。移行された機能の呼び出しをプロキシレイヤーがインターセプトしてマイクロサービスにルーティングできるように、コードのリファクタリングが必要になる場合があります。
-
不明瞭なドメイン:システムの早期の分解は、特にドメインが明確でない場合はコストがかかり、サービスの境界を間違える可能性があります。ドメイン駆動設計 (DDD) はドメインを理解するためのメカニズムであり、イベントストーミングはドメイン境界を決定する手法です。
-
マイクロサービスの識別:DDD はマイクロサービスを識別するための重要なツールとして使用できます。マイクロサービスを識別するには、サービスクラス間の自然な区分を探してください。多くのサービスは独自のデータアクセスオブジェクトを所有しているため、簡単に切り離すことができます。関連するビジネスロジックを持つサービスや、依存関係がまったくない、またはほとんどないクラスは、マイクロサービスの有力な候補です。モノリスを分解する前にコードをリファクタリングして、緊密な結合を防ぐことができます。また、コンプライアンス要件、リリース間隔、チームの地理的位置、スケーリングニーズ、ユースケース主導型のテクノロジーニーズ、チームの認知的負荷についても考慮する必要があります。
-
腐敗防止層:移行プロセス中に、モノリス内の機能がマイクロサービスとして移行された機能を呼び出す必要がある場合は、各呼び出しを適切なマイクロサービスにルーティングする腐敗防止層 (ACL) を実装する必要があります。モノリス内の既存の呼び出し元を切り離して変更を防ぐため、ACL は呼び出しを新しいインターフェースに変換するアダプターまたはファサードとして機能します。これについては、このガイドの前半の ACL パターンの「実装」セクションで詳しく説明しています。
-
プロキシレイヤーの障害:移行中、プロキシレイヤーはモノリシックアプリケーションに送られるリクエストをインターセプトし、レガシーシステムまたは新しいシステムにルーティングします。ただし、このプロキシレイヤーは単一障害点になったり、パフォーマンスのボトルネックになったりする可能性があります。
-
アプリケーションの複雑さ:ストラングラー・フィグ・パターンは、大きなモノリスに最大のメリットをもたらします。完全なリファクタリングの複雑さが低い小規模なアプリケーションでは、アプリケーションを移行するよりもマイクロサービスアーキテクチャで書き直す方が効率的かもしれません。
-
サービスインタラクション:マイクロサービスは同期または非同期で通信できます。同期通信が必要な場合は、タイムアウトによって接続やスレッドプールの消費が生じ、その結果、アプリケーションのパフォーマンスに問題が生じる可能性があるかどうかを検討してください。このような場合は、サーキットブレーカーパターンを使用して、長期間失敗する可能性が高い操作をただちにエラーを返します。非同期通信は、イベントとメッセージキューを使用することで実現できます。
-
データ集約:マイクロサービスアーキテクチャでは、データはデータベース全体に分散されます。データ集約が必要な場合は、フロントエンドで使用するか、AWS AppSync
バックエンドでコマンドクエリ責任分離 (CQRS) パターンを使用できます。 -
データの一貫性:マイクロサービスは独自のデータストアを所有しており、モノリシックなアプリケーションでもこのデータを使用できる可能性があります。共有を有効にするには、キューとエージェントを使用して、新しいマイクロサービスのデータストアをモノリシックアプリケーションのデータベースと同期できます。ただし、これによって 2 つのデータストア間でデータの冗長性が生じ、最終的に整合性が保たれる可能性があるため、データレイクなどの長期的なソリューションを確立できるようになるまでは、戦術的なソリューションとして扱うことをお勧めします。
実装
strangler figパターンでは、特定の機能を新しいサービスまたはアプリケーションに置き換えます。コンポーネントは1つずつです。プロキシ層は、モノリシックアプリケーションに送られる要求をインターセプトし、レガシーシステムまたは新しいシステムのいずれかにルーティングします。プロキシレイヤーはユーザーを正しいアプリケーションにルーティングするので、モノリスが機能し続けることを保証しながら、新しいシステムに機能を追加できます。新しいシステムでは、最終的に古いシステムのすべての機能が置き換えられ、使用を停止することができます。
高レベルのアーキテクチャ
以下の図では、モノリシックアプリケーションには、ユーザーサービス、カートサービス、アカウントサービスの 3 つのサービスがあります。カートサービスはユーザーサービスによって異なり、アプリケーションはモノリシックリレーショナルデータベースを使用します。
最初のステップは、ストアフロントUIとモノリシックアプリケーションの間にプロキシレイヤーを追加することです。最初に、プロキシはすべてのトラフィックをモノリシックアプリケーションにルーティングします。
アプリケーションに新しい機能を追加したいときは、既存のモノリスに機能を追加するのではなく、新しいマイクロサービスとして実装します。ただし、アプリケーションの安定性を確保するために、引き続きモノリスのバグを修正します。以下の図では、プロキシ層は API URL に基づいて呼び出しをモノリスまたは新しいマイクロサービスにルーティングします。
腐敗防止レイヤーの追加
以下のアーキテクチャでは、ユーザーサービスはマイクロサービスに移行されています。カートサービスはユーザーサービスを呼び出しますが、その実装はモノリス内では利用できなくなりました。また、新しく移行されたサービスのインターフェースは、モノリシックアプリケーション内の以前のインターフェースと一致しない場合があります。これらの変更に対処するには、ACL を実装します。移行プロセス中に、モノリス内の機能がマイクロサービスとして移行された機能を呼び出す必要がある場合、ACL は呼び出しを新しいインターフェースに変換し、適切なマイクロサービスにルーティングします。
ACL は、移行されたサービスに固有のクラスとしてモノリシックアプリケーション内に実装できます (例:、)。UserServiceFacade UserServiceAdapter依存するサービスをすべてマイクロサービスアーキテクチャに移行したら、ACL を廃止する必要があります。
ACL を使用しても、カートサービスはモノリス内のユーザーサービスを呼び出し、ユーザーサービスはその呼び出しを ACL を介してマイクロサービスにリダイレクトします。カートサービスは依然として、マイクロサービスの移行を意識せずにユーザーサービスを呼び出す必要があります。このような緩やかな結合は、リグレッションや事業の中断を減らすために必要です。
データ同期の処理
ベストプラクティスとして、マイクロサービスはデータを所有する必要があります。ユーザーサービスは独自のデータストアにデータを保存します。レポートなどの依存関係を処理したり、まだマイクロサービスに直接アクセスする準備ができていないダウンストリームのアプリケーションをサポートしたりするために、モノリシックデータベースとデータを同期する必要がある場合があります。モノリシックアプリケーションでは、まだマイクロサービスに移行されていない他の機能やコンポーネントのデータが必要になる場合もあります。そのため、新しいマイクロサービスとモノリスの間でデータを同期する必要があります。データを同期するには、次の図に示すように、ユーザーマイクロサービスとモノリシックデータベースの間に同期エージェントを導入できます。ユーザーマイクロサービスは、データベースが更新されるたびにキューにイベントを送信します。同期エージェントはキューを監視し、モノリシックデータベースを継続的に更新します。モノリシックデータベース内のデータは、最終的に同期されるデータと一致します。
追加サービスの移行
カートサービスがモノリシックアプリケーションから移行されると、新しいサービスを直接呼び出すようにコードが修正され、ACL はそれらの呼び出しをルーティングしなくなります。このアーキテクチャを以下に図で示します。
以下の図は、すべてのサービスがモノリスから移行され、モノリスのスケルトンのみが残るという最終状態を示しています。履歴データは、個々のサービスが所有するデータストアに移行できます。ACL は削除可能で、この段階でモノリスを廃止する準備ができています。
次の図は、モノリシックアプリケーションが廃止された後の最終的なアーキテクチャを示しています。アプリケーションの要件に応じて、リソースベースの URL (などhttp://www.storefront.com/user) または独自のドメイン (など) を使用して個々のマイクロサービスをホストできます。http://user.storefront.comホスト名とパスを使用して HTTP API を上流のコンシューマーに公開する主な方法の詳細については、「API ルーティングパターン」セクションを参照してください。
AWSサービスを使った実装
API Gateway をアプリケーションプロキシとして使用
次の図は、モノリシックアプリケーションの初期状態を示しています。 lift-and-shift ストラテジーを使用してに移行されたと仮定してAWS、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で実行され、Amazon
次のアーキテクチャでは、モノリシックアプリケーションの前に Amazon API Gateway AWS Migration Hub Refactor Spaces
ユーザーサービスは Lambda 関数に移行され、Amazon DynamoDB
以下の図では、カートサービスもモノリスから Lambda 関数に移行されています。ルートとサービスエンドポイントがリファクタリングスペースに追加され、トラフィックは自動的に Cart Lambda 関数に切り替わります。Lambda 関数のデータストアは Amazon によって管理されています。 ElastiCache
次の図では、最後のサービス (アカウント) がモノリスから Lambda 関数に移行されます。元の Amazon RDS データベースを引き続き使用します。現在、新しいアーキテクチャには、別々のデータベースを持つ 3 つのマイクロサービスがあります。各サービスは異なる種類のデータベースを使用します。マイクロサービスの特定のニーズを満たすために専用のデータベースを使用するというこの概念は、ポリグロットパーシスタンスと呼ばれます。Lambda 関数は、ユースケースに応じてさまざまなプログラミング言語で実装することもできます。リファクタリング中、Refactor Spaces はトラフィックのカットオーバーと Lambda へのルーティングを自動化します。これにより、ビルダーはルーティングインフラストラクチャの設計、デプロイ、設定に必要な時間を節約できます。
複数のアカウントを使用する
以前の実装では、モノリシックアプリケーションにプライベートサブネットとパブリックサブネットを持つ単一の VPC を使用し、AWS アカウント簡単にするためにマイクロサービスを同じ内部にデプロイしました。ただし、実際のシナリオではそうなることはほとんどありません。デプロイの独立性を保つため、マイクロサービスが複数にデプロイされることがよくあります。AWS アカウントマルチアカウント構造では、モノリスから新しいサービスへのトラフィックのルーティングを異なるアカウントで設定する必要があります。
Refactor Spaces は、モノリシックなアプリケーションから離れて API AWS 呼び出しをルーティングするためのインフラストラクチャーの作成と設定に役立ちます。Refactor Spacesは、アプリケーションリソースの一部として、AWSアカウント内のAPI Gateway
次の図に示すように、ユーザーサービスとカートサービスが 2 つの異なるアカウントにデプロイされていると仮定します。Refactor Spaces を使用する場合は、サービスエンドポイントとルートを設定するだけで済みます。Refactor Spaces は API Gateway と Lambda の統合と Lambda リソースポリシーの作成を自動化するため、モノリス以外のサービスを安全にリファクタリングすることに集中できます。
リファクタリングスペースの使用に関するビデオチュートリアルについては、「を使用してアプリを段階的にリファクタリングする
ワークショップ
ブログリファレンス
関連情報
