こんにちは、AWSグループの藤岡（@fuji_kol_ry）です。
突然ですが、皆さんはSoftware as a Service（SaaS）の開発で、テナント管理や認証認可、オンボーディングなど、無いと困るけど有ったところで大きな競合優位性を付けにくい機能の提供で、想定以上に時間を掛けてしまった経験はないでしょうか。（私はあります）
一般機能（コントロールプレーン）の開発が負担となって、競合優位性となる中核（アプリケーションプレーン）の開発に注力しにくくなるのが、SaaS開発の大きなジレンマです。
そういった課題に対して、AWSから SaaS Builder Toolkit (SBT) が提供されています。
SBTは、マルチテナントSaaSを開発するための基盤を提供し、開発者がアプリケーションの本質的な部分に集中できることを目的としています。実際にSBTリポジトリを見てみると、認証や請求といった基本機能が用意されているようで、これをそのまま活用/一部修正することによって、SaaS開発のハードルを大きく下げられるかもしれません。
そこで本記事では、実際にSBTを使ってSaaS基盤を構築して、SBTの使い勝手や強み・弱みをご紹介したいと思います。
なお、今回は内容が多いため、記事を分割してお届けいたします。
- No. 1、導入編：SBTの概要、アーキテクチャの説明
- No. 2、実践編①：リソース構築、動作確認（テナント作成、ユーザー登録）
- No. 3、実践編②：認証を使ったCRUD操作、まとめ
対象読者
以下の方に向けて記載してます。
- SaaS開発に興味がある方
- SaaS開発経験があり、より効率的な開発を模索している方
そのため、「SaaSって何？」といった前提や、マルチテナントやコントロールプレーン・アプリケーションプレーンのあり方など、SaaSの基本知識や設計思想については取り扱いません。
もし上記について知りたい方は、AWS公式のbuilders.flashの以下ページをオススメします！（第1回から始まり、計10記事ありますので、詳細で非常に読み応えがあります。）
SaaS Builder Toolkit(SBT)とは
AWSが提供する SaaS Builder Toolkit (SBT) は、マルチテナント型SaaSを効率よく構築するためのツールキットです。
SaaS開発では、以下のような標準機能に当たるコントロールプレーンの開発が必要です。
| 機能 | 役割 |
|---|---|
| 認証・認可 | テナントごとのユーザー管理、アクセス制御 |
| テナント分離 | データの隔離、セキュリティ確保 |
| 課金・サブスクリプション管理 | テナント/ユーザーごとのプラン管理、プランに応じた請求処理 |
| メータリング | 利用量の計測とそれに応じた請求等への反映 |
SBTライブラリを活用することによって、最低限の設定・実装によって以下のようなAWSサービスを構築して、上記機能を素提供することができます。
| 機能 | 使用されるAWSサービス |
|---|---|
| 認証・認可 | Amazon Cognito ユーザープール |
| テナント分離 | Amazon DynamoDB テーブル |
| 課金・サブスクリプション管理 | Amazon API Gateway, AWS Lambda, Amazon DynamoDB |
| メータリング | Amazon Data Firehose（旧 Kinesis Firehose） |
そのためエンジニアは、コントロールプレーンをゼロから実装する手間を省くことができるため、アプリケーションロジックに集中できます。
SBTのアーキテクチャ
まずは以下のSBTの概念図を見て、イメージを掴みましょう。 （今後のリポジトリ確認やデプロイ結果で、このイメージを元に捉えることになるので、ぜひ頭に留めておいてください）
SBTを使用したアーキテクチャは、一般的にSaaSで採用される、コントロールプレーン（テナント管理や請求などの一般機能）とアプリケーションプレーン（SaaS固有のビジネスロジック）の２つのプレーンによって構成されます。
またイメージ図の中心にはEventBridgeが配置されています。つまり、それぞれのプレーンのやり取りはEventBridgeを使用したイベントパターンによって行われます。
慌ただしい初期リリース時は、機能提供を優先して、モノリスな構成をとってしまうことがあると思います。
上記のようなケースに対して、後々の変更やスケーリングで苦しむことが多くあります。そういった課題に対して、イベントを用いる疎結合なアーキテクチャをとるSBTは有効なツールと言えそうです。
SBTリポジトリを深掘り
ここからは、SBTリポジトリを深掘りしながら、具体的なSBTの機能について説明します。
※大枠で機能を把握するには動画視聴が有効ですが、実装するにあたっては、ライブラリを直接確認することがおすすめです。（READMEだけでは分かりにくいところもあって、コードを見るのが結果的に近道だった経緯があります。）
ソースコードの多いSBTリポジトリの中で、特に有用と私が感じた以下3つをピックアップしてお伝えします。
1. コントロールプレーンの構成
URL：https://github.com/awslabs/sbt-aws/tree/main/src/control-plane
コントロールプレーンの各機能を構成するリソースが、AWS CDKで定義されています。ここのファイル単位とその中身を確認することで、基本機能を用意するためにはライブラリのどこを呼び出しすれば良いかが分かります。
なおSBTは、全体を通して、リソースはCDK（TypeScript）で、ロジックはPythonで実装されているため、CDKとPythonの知識が必要になります。
2. コントロールプレーンのロジック
URL：https://github.com/awslabs/sbt-aws/tree/main/resources/functions
コントロールプレーンの各機能が具体的にどういった処理を行なっているのかを把握できます。
例えばこのテナント登録処理を見ることで、テナント登録をする際には"tenantRegistrationData"をリクエストボディに指定することで、任意の形式でテナントを登録できることが分かります。
ライブラリを活用した最低限の修正によってやりたいことを達成するには、このロジック部分の確認が非常に重要になります。
3. ライブラリの使い方サイト
URL：https://github.com/awslabs/sbt-aws/tree/main/website
ライブラリをローカルにクローンして、以下URLにてサイトを立ち上げることで、SBTの使い方や機能についてのドキュメントを確認できます。
READMEだけでは分かりにくい部分もありますので、ここで見れるサイトを活用するのも有効です。
（もう少し情報を統一してくれると、分かりやすさ・使いやすさがUPすると思うので、今後に期待ですね...）
まとめ
マルチテナントSaaSの開発を効率化させる SaaS Builder Toolkit (SBT) を取り上げ、その概要やアーキテクチャについて紹介しました。
標準機能であるコントロールプレーンの構築にSBTを活用することで、開発工数を大幅に削減しつつ、疎結合なアーキテクチャを実現できる というメリットがあることが分かりました。
ただし、詳細な機能を把握するにはライブラリのコードを直接確認する必要があり、導入時には一定の学習コストがかかる 点には注意が必要です。
ここまでを総括すると、SBTは以下のような人におすすめかと思います。
✅ SaaS開発で、テナント管理や認証などの共通機能の開発負担を減らしたい人
✅ SaaSのアーキテクチャ設計において、疎結合な構成を意識したい人
逆に、「SaaSのアーキテクチャをゼロベースで設計したい」 という場合は、まず基本設計を固めた上で、必要に応じて部分的にSBTを活用するのが良さそうです。
次回は実践編として、SBTを実際に構築し、テナント作成・ユーザー登録を行う流れ をご紹介します。 SBTがどれほど実用的なのか、実践を通して深掘りしていきますので、お楽しみに！
