AWS におけるモノリスからマイクロサービスへの移行 - モノリス分割パターン
約3年前に Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith を読みましたが、とても面白かったことを覚えています。 こちらの書籍は、モノリスとマイクロサービスの良い点と悪い点を比較して紹介しており、マイクロサービスを銀の弾丸として扱っていないことが好印象でした。
この投稿では、書籍で紹介されているパターンの一部を AWS でどのように適用するのか紹介します。
Strangler Fig Application
Strangler Fig Application パターンは、既存のアプリケーションに変更を加えることなく、新しいマイクロサービスに機能を段階的に移行できるようにします。
ALB 利用
移行が完了したら、 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).
SQS 利用
メッセージ処理アプリケーションがある場合、 Lambda でメッセージの内容を解析し、それらをモノリスまたはマイクロサービスのいずれかで処理するようキューイングできます。
Parallel Run
Parallel Run パターンでは、モノリスとマイクロサービスの両方を呼び出し、結果をそれぞれ保存します。 このアプローチは、移行がアプリケーションに大きな変更とリスクをもたらす場合に有用で、後で結果を比較することを可能にします。
Change Data Capture
本の著者は、 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 パターンを使用することで、ソースデータストアで生じたデータの変更に対して、リアクティブに処理できます。