Monolith から Microservices への移行：AWS でのシームレスな移行パターン

岩佐 孝浩

2024年1月28日

4 min read

Microservices

Monolith から Microservices へのパターンについて Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith に記載されている内容を紹介します。この本では、Monolith と Microservices のメリットとデメリットを比較しつつ、Microservices がすべての課題に対する万能な解決策 (銀の弾丸) ではないことを説明しています。

この投稿では、この本で議論されているいくつかのパターンを AWS 上でどのように実装するかについて説明します。

Strangler Fig Applicationパターンは、既存アプリケーションに大きな変更を加えることなく、機能を段階的に Microservices に移行することを可能にします。

Monolith 全体を一度に書き直すのではなく、既存のシステムを囲むように新しい Microservices を徐々に作成していきます。時間が経つにつれて、これらのサービスが Monolith の責務を引き継ぎ、最終的に Monolith を廃止できるようになります。

Application Load Balancer (ALB) を使用して、リクエストを Monolith または新しい Microservices にルーティングできます。ALB の パスベースのルーティング (path-based routing) 機能を利用します。

メッセージ処理アプリケーションの場合、AWS Lambda を使用してメッセージ内容を分析し、それを SQS を通じて Monolith または Microservices のどちらで処理するかを選択できます。

Parallel Run パターンを使用すると、Monolith と Microservices の両方を同時に呼び出し、その結果を個別に保存することができます。

このアプローチは、高リスクな移行や主要なシステム変更に特に有用で、最終移行の前に出力を比較する安全策を提供します。

Change Data Capture (CDC) パターンはもう一つの移行戦略ですが、重要な課題を伴います。本の著者が次のように指摘しているように：

In general, I try to keep the use of this pattern to a minimum because of the challenges around some of the implementations of this pattern.

AWS は、Database Migration Service (DMS) および DynamoDB Streams を介して CDC パターンをサポートしています。

このパターンにより、ソースデータベースでのデータ変更をリアクティブに処理できるため、移行中のデータ同期に最適です。

AWS で Monolith アーキテクチャから Microservices への移行には、慎重な計画と適切な戦略が必要です。Strangler Fig Application, Parallel Run, Change Data Capture といったパターンは、リスクを軽減しながら効果的に移行するためのロードマップを提供します。

各パターンの強みと制限を理解することで、アプリケーションのニーズに合ったより良いアーキテクチャ上の判断が可能になります。

Happy Coding! 🚀