AWS におけるモノリスからマイクロサービスへの移行 - モノリス分割パターン

Takahiro Iwasa (岩佐 孝浩)

2024年1月28日

3 min read

Microservices

約3年前に Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith を読みましたが、とても面白かったことを覚えています。こちらの書籍は、モノリスとマイクロサービスの良い点と悪い点を比較して紹介しており、マイクロサービスを銀の弾丸として扱っていないことが好印象でした。

この投稿では、書籍で紹介されているパターンの一部を AWS でどのように適用するのか紹介します。

Strangler Fig Application パターンは、既存のアプリケーションに変更を加えることなく、新しいマイクロサービスに機能を段階的に移行できるようにします。

移行が完了したら、 Application Load Balancer を利用して、リクエストを新しいマイクロサービスにリダイレクトできます。

特定のルートだけをリダイレクトしたい場合は、パスベースルーティングを利用できます。

You can use path conditions to define rules that route requests based on the URL in the request (also known as path-based routing).

メッセージ処理アプリケーションがある場合、 Lambda でメッセージの内容を解析し、それらをモノリスまたはマイクロサービスのいずれかで処理するようキューイングできます。

Parallel Run パターンでは、モノリスとマイクロサービスの両方を呼び出し、結果をそれぞれ保存します。このアプローチは、移行がアプリケーションに大きな変更とリスクをもたらす場合に有用で、後で結果を比較することを可能にします。

本の著者は、 Change Data Capture パターンを以下のとおり推奨していません。

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 で CDC を提供しています。

You can create an AWS DMS task that captures ongoing changes from the source data store.

CDC パターンを使用することで、ソースデータストアで生じたデータの変更に対して、リアクティブに処理できます。