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

『Monolith to Microservices』に触発され、AWSにおけるモノリスからマイクロサービスへの移行パターンを解説します。

Takahiro Iwasa

2024-01-28

5 min read

モノリスからマイクロサービスへの移行には決まった正解がなく、Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith で紹介されている複数のパターンを、AWSのサービスにどう当てはめられるか整理してみます。

Strangler Fig Application

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

モノリス全体を一気に書き直すのではなく、既存システムの周囲に新しいマイクロサービスを少しずつ作成していきます。時間の経過とともに、これらのサービスがモノリスの責務を引き継いでいき、最終的にモノリスを廃止できるようになります。

AWS ALBによる実装

Application Load Balancer (ALB) を使うと、リクエストをモノリストと新しいマイクロサービスのどちらにもルーティングできます。ALBのパスベースルーティング機能がこのルーティングを実現します。

Strangler Fig with ALB

SQSによる実装

メッセージ処理を行うアプリケーションでは、AWS Lambdaがメッセージ内容を解析し、SQS経由でモノリスまたはマイクロサービスによる処理のためにキューへ投入することができます。

Strangler Fig with SQS

Parallel Run

Parallel Run パターンでは、モノリスとマイクロサービスの両方を同時に呼び出し、それぞれの結果を別々に保存します。

このアプローチはリスクの高い移行や大規模なシステム変更に特に有用で、最終的な移行を行う前に出力を比較するためのセーフティネットとして機能します。

Parallel Run Pattern

Change Data Capture (CDC)

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パターンをサポートしています。

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

Change Data Capture Pattern

まとめ

Strangler Fig、Parallel Run、Change Data CaptureをAWSサービスに当てはめてみると、それぞれのパターンがモノリスからマイクロサービスへの移行のどの部分をカバーするかが見えてきます。この3つのパターンは互いに競合するものではなく、同じ移行の異なるフェーズを扱っています。Strangler FigはALBのパスベースルーティングやSQSを使ってモノリスからトラフィックを徐々に切り離していくルーティングの問題を、Parallel Runは切り替え前に新サービスの出力を検証する信頼性の問題を、CDCは両者が共存している間データを整合させ続けるデータの問題を、それぞれ扱います。著者自身のCDCに対する慎重な姿勢は真剣に受け止める価値があります。3つのパターンの中でも、CDCは実装の詳細が運用上の思わぬ落とし穴を最も表面化させやすいものなので、よりシンプルなパターンだけでは不十分だと分かってから、DMSやDynamoDB Streamsに手を伸ばすのがよいでしょう。

記事一覧に戻る