いわさです。
AWS re:Invent 2023 でワークショップ「Building a multi-tenant SaaS control plane: An inside look」に参加しました。
マルチテナント SaaS アプリケーションにはアプリケーションプレーンとコントロールプレーンという概念がよく登場します。
顧客へ提供する SaaS アプリケーションのメインの機能がアプリケーションプレーンで、マルチテナントを包括的に管理・制御する機能がコントロールプレーンです。
アプリケーションプレーンはほぼ標準的な機能要件に基づくため開発しやすいですが、コントロールプレーンはほぼマルチテナント SaaS モデルの基礎的な部分となりその独自のノウハウが必要となります。
このワークショップではコントロールプレーンの設計・構築する方法を学ぶことができます。
会場の雰囲気
SaaS ワークショップの隣の部屋で Amazon Q のセッションがとんでもない大行列を作っていましたが、SaaS ワークショップは予約しなくても入れる感じでした。
リピートワークショップだったこともあり収容率は半分くらいだったと思います。
ワークショップの概要
re:Invent 2023 公式サイトのワークショップ概要を Amazon Translate で翻訳した内容が以下となります。
コントロールプレーンは、あらゆる SaaS ソリューションの中心です。テナントのオンボーディング、請求、ID、指標、階層化、および一般的な環境管理を可能にするために使用されるすべての基本サービスを提供します。 このワークショップでは、コントロールプレーンの中に入り、サービスの主要コンポーネントを構築し、堅牢な SaaS コントロールプレーンの構築に伴う主要なアーキテクチャと設計上の考慮事項を探ります。 また、ID を管理する方法、独自の管理コンソールを導入する方法、環境の運用ビューを作成する方法についても説明します。
スピーカー
- Babak Parvizi
- Michael Beardsley
LEVEL
400
ワークショップの内容
サーバーレス REST API の構築
このワークショップでは、まずはコントロールプレーンをマイクロサービス API として構築しました。
ここではテナントサービスとティアサービスを作成し、データストアに保存する仕組みを構築します。
ワークショップでは API Gateway、Lambda、DynamoDB を使った構築を行います。
このワークショップ内のコントロールプレーンで管理されるデータは、ただのテナント情報であり、高度な機能の実装はされていません。
実際にはこの情報を使ってアプリケーションプレーンから参照して動作が変わったり、あるいはテナントの自動オンボーディング時のサイジング、あるいは請求などの仕組みで利用されます。
ワークショップ内ではあくまでも管理 API を作るよ。というだけですね。
手順に従ってササッと構築することができました。
まずここではシンプルなコントロールプレーンのはじめの機能として、テナントとティアを管理する API を作成しました。これらは実際のマルチテナント SaaS で利用する際にもほぼ必須の機能となります。
テナントオンボーディング
つづいて、コントロールプレーンでの基本的な機能のひとつである「テナントオンボーディング」部分に関する実装を行いました。
テナントオンボーディングというのは、新しいテナントの作成がリクエストされ使えるようになるまでの準備を含めた処理プロセスです。
このワークショップでは実際に新しいテナントインフラストラクチャをプロビジョニングするわけではないのですが、コントロールプレーンでオンボーディング用の API を作成し、リクエストが処理された後になんらかの方法でテナントがオンボーディングされ、アプリケーションプレーン側のプロビジョニング完了イベントを受ける流れを実装しています。
テナントオンボーディングはコントロールプレーンのみで完結せずにアプリケーションプレーンも巻き込んで連携する必要がありますが、このワークショップでは EventBridge を使って連携を行っています。なるほど、という感じです。
管理者 UI と ID
ここまででコントロールプレーンの代表的な機能を備えた簡易的なコントロールプレーン API を作成しました。
ワークショップでは次に、実際にコントロールプレーンを操作出来る管理 UI も作成しました。
また、ここではコントロールプレーンを操作するシステムユーザーと、アプリケーションプレーンのユーザーも管理します。
ワークショップの手順に従ってデプロイされた管理 UI は SaaS Boost のものでした。
CloudFront + S3 でフロントエンドをホスティングし、先程のコントロールプレーン API を通してシステムユーザーとテナントユーザーを管理しています。
システムユーザーは Cognito で管理されているようでした。
テナントユーザーは属性の管理などは行うのですが、IdP としての機能をコントロールプレーンが備えているわけではありませんでした。そのあたりは切り離す感じみたいですね。勉強になりました。
メトリクスとコントロールプレーンとの通信
最後に、コントロールプレーンがアプリケーションプレーンからメトリクスを受信出来るようにします。
次のようにクロスアカウントアクセスポリシーで、アプリケーションプレーンからコントロールプレーン側のシークレットを取得し、コントロールプレーン API へアクセスしています。
また、メトリクスの場合は大量のトランザクションが生成される可能性があるので、メトリクスデータの取り込みは SQS でバッファリングしたのちにコントロールプレーン側の CloudWatch へ取り込まれています。
作成されるコンポーネント自体はワークショップで用意されている手順に従ってスクリプト実行するだけで構築出来るので、簡単に構築することができます。
かなりわかりにくいのですが、コントロールプレーン側に取り込まれたメトリクスは次のような形になりました。
わかりにくいどころではないのですが、テナントごとのカスタムメトリクスが生成されています。
このようにコントロールプレーンでマルチテナントなメトリクスを受信し、一元的に複数のテナントアクティビティをダッシュボードで閲覧出来る仕組みを体験することができます。
さいごに
本日は「Building a multi-tenant SaaS control plane: An inside look」に参加したので、どのようなワークショップ内容なのか紹介させて頂きました。
アプリケーションプレーンはテナント分離要件など様々な非機能要件によってバラバラだと思うのですが、コントロールプレーンに求められる要件はどの場合でも同じです。
このワークショップでコントロールプレーンの基本的な実装方法を習得出来ると思います。ワークショップスタジオなどで利用可能になった際は是非使ってみてください。
7
