翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ストラングラーフィグパターン
Intent
strangler fig パターンは、モノリシックアプリケーションをマイクロサービスアーキテクチャに段階的に移行するのに役立ちます。これにより、トランスフォーメーションリスクとビジネスの中断が軽減されます。
導入する理由
モノリシックアプリケーションは、1 つのプロセスまたはコンテナ内でほとんどの機能を提供するように開発されています。コードは緊密に結合されています。そのため、アプリケーションの変更には、リグレッションの問題を回避するための徹底的な再テストが必要です。変更は単独でテストできず、サイクル時間に影響します。アプリケーションがより多くの機能で強化されるため、複雑さが増すと、メンテナンスに費やす時間が長くなり、市場投入までの時間が長くなり、その結果、製品のイノベーションが遅くなる可能性があります。
アプリケーションのサイズが大きくなると、チームの認識的負荷が増加し、チームの所有権の境界が不明確になる可能性があります。負荷に基づいて個々の機能をスケーリングすることはできません。ピーク負荷をサポートするためにアプリケーション全体をスケーリングする必要があります。システムが古くなると、テクノロジーが古くなり、サポートコストが上昇する可能性があります。モノリシックでレガシーなアプリケーションは、開発時に利用可能だったベストプラクティスに従っており、配布するように設計されていません。
モノリシックアプリケーションをマイクロサービスアーキテクチャに移行すると、より小さなコンポーネントに分割できます。これらのコンポーネントは、個別にスケーリングでき、個別にリリースでき、個々のチームが所有することができます。これにより、変更がローカライズされ、迅速にテストおよびリリースできるため、変更の速度が向上します。コンポーネントは疎結合されており、個別にデプロイできるため、変更の影響範囲は小さくなります。
コードを書き換えたりリファクタリングしたりしてモノリスをマイクロサービスアプリケーションに完全に置き換えることは、多大な負担と大きなリスクです。モノリスが 1 回のオペレーションで移行される大規模な移行は、トランスフォーメーションリスクとビジネスの中断をもたらします。アプリケーションがリファクタリングされている間は、新機能を追加することは非常に困難または不可能です。
この問題を解決する 1 つの方法は、Martin Fowler によって導入された strangler fig パターンを使用することです。このパターンでは、機能を徐々に抽出し、既存のシステムを中心に新しいアプリケーションを作成することで、マイクロサービスに移行します。モノリスの機能は徐々にマイクロサービスに置き換えられ、アプリケーションユーザーは新しく移行された機能を徐々に使用できます。すべての機能が新しいシステムに移動されると、モノリシックアプリケーションを安全に廃止できます。
適用対象
以下の場合は、strangler fig パターンを使用します。
-
モノリシックアプリケーションをマイクロサービスアーキテクチャに徐々に移行したい。
-
モノリスのサイズと複雑さのため、大きなバング移行アプローチはリスクがあります。
-
企業は新機能を追加したいと考えているため、変換が完了するまで待つことはできません。
-
エンドユーザーは、変換中に最小限の影響を受けている必要があります。
問題点と考慮事項
-
コードベースアクセス： strangler fig パターンを実装するには、モノリスアプリケーションのコードベースにアクセスできる必要があります。機能がモノリスから移行されるため、コードの軽微な変更を行い、モノリス内に破損防止レイヤーを実装して、呼び出しを新しいマイクロサービスにルーティングする必要があります。コードベースアクセスなしで呼び出しを傍受することはできません。コードベースアクセスは受信リクエストのリダイレクトにも重要です。プロキシレイヤーが移行された機能の呼び出しを傍受してマイクロサービスにルーティングできるように、一部のコードリファクタリングが必要になる場合があります。
-
不明瞭なドメイン： 特にドメインが明確でなく、サービス境界が間違っている場合、システムの早期分解にはコストがかかる可能性があります。ドメイン駆動型設計 (DDD) はドメインを理解するためのメカニズムであり、イベントストーミングはドメインの境界を決定するための手法です。
-
マイクロサービスの識別： マイクロサービスを識別するための主要なツールDDDとして を使用できます。マイクロサービスを識別するには、サービスクラス間の自然な分割を探します。多くの サービスは独自のデータアクセスオブジェクトを所有し、簡単に分離できます。関連するビジネスロジックを持つサービスと、依存関係がない、またはほとんどないクラスは、マイクロサービスの候補として適しています。モノリスを分解する前にコードをリファクタリングして、密結合を防ぐことができます。また、コンプライアンス要件、リリース頻度、チームの地理的位置、スケーリングのニーズ、ユースケース駆動型のテクノロジーのニーズ、チームの認識的負荷も考慮する必要があります。
-
破損防止レイヤー： 移行プロセス中に、モノリス内の機能がマイクロサービスとして移行された機能を呼び出す必要がある場合は、各呼び出しを適切なマイクロサービスにルーティングする破損防止レイヤー (ACL) を実装する必要があります。モノリス内の既存の発信者を切り離して変更を防ぐために、 ACLは、呼び出しを新しいインターフェイスに変換するアダプターまたはファサードとして機能します。これは、このガイドの前半のACLパターンの実装セクションで詳しく説明されています。
-
プロキシレイヤーの障害： 移行中、プロキシレイヤーはモノリシックアプリケーションに送信されるリクエストをインターセプトし、レガシーシステムまたは新しいシステムにルーティングします。ただし、このプロキシレイヤーは単一障害点またはパフォーマンスのボトルネックになる可能性があります。
-
アプリケーションの複雑さ： 大きなモノリスは、strangler fig パターンから最もメリットがあります。完全なリファクタリングの複雑さが低い小規模なアプリケーションでは、移行するのではなく、マイクロサービスアーキテクチャでアプリケーションを書き換える方が効率的かもしれません。
-
サービスインタラクション： マイクロサービスは同期的にまたは非同期的に通信できます。同期通信が必要な場合は、タイムアウトによって接続またはスレッドプールが消費され、アプリケーションのパフォーマンスの問題が発生する可能性があるかどうかを検討してください。このような場合は、サーキットブレーカーパターンを使用して、長期間失敗する可能性が高いオペレーションの即時失敗を返します。非同期通信は、イベントとメッセージングキューを使用して実現できます。
-
データ集約： マイクロサービスアーキテクチャでは、データはデータベース全体に分散されます。データ集約が必要な場合は、フロントエンド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) でホストできます。ホスト名とパスを使用してアップストリームコンシューマーHTTPAPIsに公開する主な方法の詳細については、API「ルーティングパターン」セクションを参照してください。
AWS のサービスを使用した実装
Gateway をアプリケーションプロキシAPIとして使用する
次の図は、モノリシックアプリケーションの初期状態を示しています。戦略 AWS を使用して lift-and-shift に移行されたと仮定して、Amazon Elastic Compute Cloud (Amazon EC2）
次のアーキテクチャでは、 はモノリシックアプリケーションの前に Amazon API Gateway
ユーザーサービスは Lambda 関数に移行され、Amazon DynamoDB
次の図では、カートサービスもモノリスから Lambda 関数に移行されています。ルートとサービスエンドポイントがリファクタリングスペースに追加され、トラフィックは自動的に Cart Lambda 関数にカットオーバーされます。Lambda 関数のデータストアは Amazon ElastiCache
次の図では、最後のサービス (アカウント) がモノリスから Lambda 関数に移行されています。元の Amazon RDS データベースを引き続き使用します。新しいアーキテクチャでは、データベースが分離された 3 つのマイクロサービスが追加されました。各サービスは異なるタイプのデータベースを使用します。マイクロサービスの特定のニーズを満たすために専用データベースを使用するこの概念は、ポリグスロット永続性と呼ばれます。Lambda 関数は、ユースケースによって決定されるさまざまなプログラミング言語で実装することもできます。リファクタリング中、リファクタリングスペースは、トラフィックのカットオーバーと Lambda へのルーティングを自動化します。これにより、ビルダーがルーティングインフラストラクチャを設計、デプロイ、設定するために必要な時間を節約できます。
複数のアカウントの使用
前の実装では、モノリシックアプリケーションにプライベートサブネットとパブリックサブネットVPCを持つ単一の を使用し、シンプルにするために同じ AWS アカウント 内にマイクロサービスをデプロイしました。ただし、マイクロサービスがデプロイの独立性 AWS アカウント のために複数の にデプロイされることがよくある実際のシナリオでは、このようなケースはほとんどありません。マルチアカウント構造では、モノリスから異なるアカウントの新しいサービスへのトラフィックのルーティングを設定する必要があります。
リファクタリングスペースは、モノリシックアプリケーションからAPIコールをルーティングするための AWS インフラストラクチャの作成と設定に役立ちます。Refactor Spaces は、アプリケーションリソースの一部として、アカウント AWS 内の API Gateway
次の図に示すように、ユーザーサービスとカートサービスが 2 つの異なるアカウントにデプロイされていると仮定します。リファクタリングスペースを使用する場合は、サービスエンドポイントとルートを設定するだけで済みます。リファクタリングスペースは、APIGateway-Lambda 統合と Lambda リソースポリシーの作成を自動化するため、モノリスから安全にサービスをリファクタリングすることに集中できます。
リファクタリングスペースの使用に関するビデオチュートリアルについては、「 でのリファクタリングアプリの増分 AWS Migration Hub Refactor Spaces
ワークショップ
ブログの参考情報
関連情報
