いわさです。
AWS re:Invent 2023 のワークショップである「DAT402: Build a multi-tenant SaaS solution using AWS purpose-built databases」に参加してきました。
AWS には SaaS on AWS というカテゴリがありまして、主にマルチテナントを考慮してアーキテクチャーを最適化する必要があります。
その中ではアプリケーションだけでなく、データストアに対しても様々な要件からテナント分離性を高めることがあります。
この記事ではワークショップを通して体験出来ることをイメージしてもらうために、学んだや行ったことなどを共有したいと思います。
ワークショップの概要
re:Invent 2023 公式サイトのワークショップ概要を Amazon Translate で翻訳した内容が以下となります。
- マルチテナントアーキテクチャは、すべてのテナントのデータストレージリソースを共有することで、俊敏性と運用コストの削減を実現します。このような環境では、テナントデータを分離することは SaaS プロバイダーにとって基本的な責任です。リスクは高いため、テナントの統合によって得られる俊敏性を維持しつつ、効果的なデータ分離モデルを実装することが重要です。
- SaaS アーキテクトと開発者を対象としたこのワークショップでは、Amazon Aurora、Amazon DynamoDB、AWS DMS、および Amazon QuickSight を使用して、テナント用の共有データベースと、一元的な隔離措置の両方のメリットを実現する方法を学びます。
- テナントの分離、パーティショニング、コードとしてのインフラストラクチャを使用した DB 運用、テナントポータビリティに関するベストプラクティスをご覧ください。
スピーカー
- Aditya Samant
- Leonid Koren
LEVEL
- 400
ワークショップ内容
このワークショップでは、次のようなアーキテクチャーで構成されるマルチテナント SaaS アプリケーションが開始点でした。
開始時のワークロードは、フロントエンドとバックエンドのインフラが分離されており、大部分でサーバーレスコンポーネントを採用しています。
ただし、一部のコンポーネント（アプリケーションやデータベース）がモノリスな状態となっていました。
そして、このワークロードに課せられている要件に対してパフォーマンスやテナント分離性など、要件を満たしきれていないという課題を抱えている。というシチュエーションとなっています。
これらの課題を解決するために、このワークショップは主に以下の変更を行います。
- プール型の Aurora MySQL をサイロ型へ分離し、分離性を高める
- 高頻度の書き込みが発生する一部のテーブルは Aurora MySQL ではなく DynamoDB へ移行する
ワークショップ内ではこのアーキテクチャーへ移行するために AWS DMS (Database Migration Service) を使っています。
稼働環境のアーキテクチャー変更にも DMS を使うパターンもあるのだなぁと改めて認識しました。
Aurora からの分割
まずはテナントごとに Aurora MySQL のデータを移行します。
以下を見て頂くとわかるのですが、移行前のデータはprovider_name列を使って同一テーブル内で複数テナントデータ混在している状態です。
Aurora テナント分離
テナント分離性を高めるために PostgreSQL であれば RLS を使うことが有効ですが、MySQL には RLS がありません。 そのためかテナントのデータを複数の Aurora インスタンスへ分割しています。
テナントごとに用意した Aurora インスタンスへ AWS DMS を使ってデータの移行を行います。
ワークショップのデータベースには 3 つのテナントのデータが混在しているので、DMS のタスクをテナントごとに作成しています。
ちょっとおもしろいと思ったのが、DMS タスクのマッピングルールを使って対象テナントの情報のみを抽出して移行する手法を使っていました。
なるほど、これは良いですね。ただ抽出して移行するだけじゃなくて移行対象をフィルタリングして、フィルター条件を変えたタスクを組み合わせることでデータベースの分離が可能になるのですね。
DMS タスクの実行後、移行後の Aurora インスタンスごとに次のようにデータ分離されていることが確認出来ました。
使用量データを DynamoDB へ移行
また、使用量データについてもはパフォーマンス問題を改善するために移行先を DynamoDB としていました。
DynamoDB への移行についても AWS DMS を使ったタスクで移行することが出来ます。
上記 3 つのタスクが実行されるのですが、こちらもテナントごとにテーブルを作成する形となります。
顧客と DB のマッピング情報の追加
データを分散させることが出来ましたが、このままだと対象の利用者がどのデータベースのデータを参照するべきなのかがわかりません。
そこで、顧客 ID とデータベースの関係性をレコード登録するだけの DB マッピング情報も作成します。
アプリケーションのデータベース使用方法を改修する
データベースの構成を変更しました。
そこで次はデータベースを参照するアプリケーション側にも変更を行います。
コードに、ユーザーのテナント（このワークショップでは「プロバイダー」を指す）を取得する処理を追加します。
このワークショップではこのあたりの関数コードの変更もワークショップの範囲内です。ただし、どういうように変更すべきかの回答が用意されていましたので、アプリケーションが得意ではない方でもワークショップを前に進めることは出来ますのでご安心ください。
このワークロードではモノリス Lambda ではありますが、API ゲートウェイパターンで構成されているので、フロントエンドのエンドポイントや対象リソースを変更せずにバックエンドアプリケーションの切り替えが可能です。
API Gateway のルートごとに統合の再アタッチを行って変更した Lambda 関数を関連付けます。
これで API Gateway 側の切り替えも完了しました。
クライアントから受信したリクエストをトリガーに、改修した Lambda 関数が実行され、分離したデータベースの参照・書き込みが行われる形となります。
移行前から比べるとパフォーマンスとテナント分離性が単純に改善され、ユーザーは従来の操作性を失うことなく引き続き SaaS アプリケーションを利用することが出来ます。
おまけで QuickSight を使った可視化
このワークショップのゴールであるパフォーマンスやテナント分離性を高めるために、アプリケーションとデータベースの構成を変更しました。
このワークショップでは、おまけとして QuickSight による使用量データの可視化ラボが用意されています。
DynamoDB へ移行したために RDBMS よりも分析処理がしやすくなったために、日次で集計処理を実行して、可視化に必要な最低ラインを満たすレベルで事前に集計レコードを用意します。
これによって低コストで可視化しやすいデータを用意することが出来ます。
実際に作成したダッシュボード（分析）がこちらになります。
日次や週次の粒度で分析が必要な場合は今回の日次集計を使うことで、パフォーマンス改善やテナント分離性向上により発生したデメリットを補うことが出来ていますね。 冗長な手順はスクリプトで自動化されているのがテンポ良い。
さいごに
本日は マルチテナント要件を達成するためのデータストアの分割方法を学ぶ「Build a multi-tenant SaaS solution using AWS purpose-built databases」のワークショップを、レポートとして紹介させて頂きました。
このワークショップを通して主にデータストアに関する分離性や実装方法について触れることが出来ます。
レベル 400 か？というと想像するよりおそらくかなり簡単だと思います。
冗長なリソースの作成・更新操作については事前に一括実行スクリプトが用意されているなど手厚いコンテンツでした。
利用可能になった際は是非こちらのワークショップもお試しください。
2
