[レポート]モノリシックなサービスをサーバレスに移行するハンズオン #SVS303 #reinvent

本ブログはAWS re:Invent 2019のワークショップ『Monolith to serverless SaaS: A hands-on service decomposition』のレポートです。

セッション概要

The move to a serverless model is especially appealing to SaaS providers. For many, this journey begins with transforming their legacy, single-tenant monolithic architecture into a multi-tenant serverless solution. In this workshop, we dive into the heart of this challenge, walking through the incremental steps required to map your monolithic application to a series of AWS Lambda-based microservices. We then use Lambda layers to add tenant-aware logging, metrics, and data access to your Lambda functions. Throughout, we expose the fundamental moving parts of this transformation, highlighting common considerations that can affect your serverless SaaS migration strategy.

サーバーレス・モデルへの移行は、SaaSプロバイダにとって特に魅力的です。多くのお客様にとって、この移行は、レガシーのシングルテナントのモノリシックアーキテクチャをマルチテナントのサーバーレス・ソリューションに変換することから始まります。このワークショップでは、モノリシックなアプリケーションを一連のAWS Lambdaベースのマイクロサービスへマッピングするために必要な、段階的なステップを順を追って説明します。次に、Lambda Layerを使用して、テナント対応ロギング、メトリック、Lambda関数へのデータアクセスを追加します。全体を通して、この変換の基本的な動作部分を公開し、サーバーレスSaaS移行戦略に影響を与える可能性のある一般的な考慮事項を示します。

ワークショップ資料

スライド

• SVS303: Monolith to serverless SaaS: A hands-on service decomposition

ワークショップ

※2019/12/18時点で、このワークショップはGitHubリポジトリの内容だけでは実施できません。あらかじめ準備された環境のあるAWSアカウントが必要です。

• aws-samples/aws-saas-factory-serverless-workshop

レポート

ワークショップのゴール

• モノリシックなサービスからサーバーレスサービスへの移行概要を示す
• サイロ化されたサービスとマルチテナントサービスをハイブリッドで実行するためのアーキテクチャ戦略を示す
• マルチテナント対応のサーバーレスマイクロサービスを導入する
• 各マイクロサービスへモノリスデータベースを移行する
• 開発者がマルチテナンシーであることを意識する領域を減らす戦略を考える
• モノリスのサービスをAWS Lambdaに移行する

ワークショップの流れ

ワークショップではあらかじめモノリシックなサービスが開発＆デプロイできているAWSアカウントが用意されてました。

そのAWSアカウントを使って、Lab 1〜Lab 4の演習を行いました。

• Lab 1: シングルテナントでモノリシックなサービスのデプロイと利用
• Lab 2: オンボーディング、アイデンティティ、モダンクライアント
• Lab 3: マルチテナントなサーバーレスマイクロサービスの実現
• Lab 4: 残っているサービスの抽出。Goodbye Monolith!

Lab 1: シングルテナントでモノリシックなサービスのデプロイと利用

Lab 1は、Javaで書かれたMVCモデルのモノリシックなWebサービスをデプロイしました。

開発環境はCloud9、ソースリポジトリはCodeCommit、CI/CD環境はCodePipelineであらかじめ構築されています。
Cloud9でプログラムを変更して git push したらもろもろ自動でデプロイされるといった感じです。

Lab 1の目的は、一連のデプロイフローを通じて、既存のモノリシックサービスがどのように構築されているかを理解することでした。

Lab 2: オンボーディング、アイデンティティ、モダンクライアント

Lab 2は、モノリシックなサービスにマルチテナント機能を導入しました。
また、サーバーサイドのWeb/アプリケーション層からクライアント部分を抽出し、ReactアプリケーションとしてS3に移行しました。

マルチテナントに対応するため、テナントIDを管理するメカニズムを導入しました。ただし、サーバーサイドはシングルテナントで動作させており、HTTPヘッダに付与したテナントIDによってALBの転送先を分けることでマルチテナントを実現しています。

テナントIDはCognitoで作成したユーザーに紐付けておき、ログインユーザーによってテナントの識別ができるようにしておきます。

テナントを追加する際には、サーバーサイドのAWSリソースを自動で作れるようにしておきます。

これらの構成によって、モノリシックアプリケーションに大きな変更を加えることなく、マルチテナントに対応することができます。

Lab 3: マルチテナントなサーバーレスマイクロサービスの実現

Lab 3で、モノリシックなサービスをマルチテナントマイクロサービスに分解していきました。

この戦略で重要な部分は、マイクロサービスとモノリスサービスの並列実行を可能にすることです。

まず最初にAPI Gatewayで受け、新しいOrderサービスにルーティングするか、モノリスアプリケーションにルーティングします。
新しいOrderサービスは共同のマルチテナントサービスとして構築し、すべてのテナントのリクエストを処理できるようにします。
一方、モノリスサービスはテナントごとの処理となるのでトラフィックを適切なアプリケーション層にルーティングするルールが必要になります。

Lab 3で実感いただきたい重要なことは、新しいマルチテナントなマイクロサービスとモノリスサービスを並行して稼働させることができ、段階的な移行が可能となる点です。

Lab 4: 残っているサービスの抽出。Goodbye Monolith!

Lab 4で、モノリシックなサービスの最後の部分である、Productサービスをサーバーレスマイクロサービスに移行しました。

また、マイクロサービスの共通的な処理を一元化するために、ロギングマネージャー、トークンマネージャー、メトリックスマネージャーのレイヤーを作成して共用する形に変更しました。

移行の完了により、モノリシックなサービスは不要となり、すべてがサーバーレスマイクロサービスとなりました。Goodbye Monolith!

感想

なかなかやりごたえのあるワークショップでした。

ひとつのモノリスサービスをサーバーレスサービスに移行する具体的なサンプルはそうないので、モノリシックなサービスをサーバーレスに移行したい場合にはとても参考になるワークショップだと思います。

作業量が多くてワークショップ時間内にすべてを終えることができなかったので、ぜひ機会があったら再チャレンジしたいです。