はじめに
本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day7 の記事です。弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。
今回はマルチテナントSaaSのアプリケーションのオンボーディング処理に関するまとめになります。
オンボーディング処理の概要
オンボーディングってなに？
オンボーディング処理とは、つまるところ企業が最初にそのSaaSに登録する一連の処理のことを指します。Day 2で言及したときにアプリケーションプレーンと、コントロールプレーンの話をしましたが、いわゆるコントロールプレーン側の処理に該当します。
下記はAWS Well-Architected SaaS Lensから引用した図ですが、構成する技術要素はなにであれど、これまでデータ分離や認証の設計をした アプリケーション分離の粒度 に応じたリソースの作成が必要になります。
例えば、データベースをSiloモデル（テナントごとに専用のリソースを作ること）でデータ分離したとしましょう。その場合は、企業がそのSaaSに登録した時点で、新しくデータベースを作成するという処理が必要になります。
オンボーディング処理で必要な処理については、下記の図をもとに4つの観点で整理をしてみましょう。
オンボーディング処理の一連の流れ
上記の図の番号と対応させて解説をしていきます。1️⃣はテナント作成のトリガーで、本質的な処理の一部ではないため割愛します。
2️⃣ Tenant Management（テナント管理）
- テナント情報（社名、業種、サイズなど）の登録と管理
- テナント固有の設定やポリシー（言語設定、タイムゾーン、規制要件など）のメタデータ管理
- オンボーディング進捗のステータス管理（pending → active → suspended など）
- 他のコンポーネントへの入力情報（テナントID、初期スキーマ設定など）の生成
テナント管理では登録するテナントの基礎情報を登録します。この情報をもとに後続の処理も変化します。 フリーミアムから始める場合であれば一般的な登録フォームから始まる場合もあるでしょう。一方で、顧客側とは契約のやり取りのみで、社内でアクティベートする場合もあるでしょう。いずれにしても、データ分離の設計に応じた分離レベルをインフラ環境にプロビジョニングする必要があります。
3️⃣ User Management（ユーザ管理）
- テナント管理者をはじめとする初期ユーザーアカウントの作成
- 作成されたリソースへの初期アクセス権限の設定
- Identity Providerとの連携によるSSO（Single Sign-On）やSAML/OIDCベースの認証統合
Day 5の「ID管理と認証」の記事で記載したように、ユーザ管理の側面では顧客によってログイン方法が異なることがほとんどでしょう。中小企業であれば、メール/パスワード認証になるでしょうし、大企業であれば、AD連携を中心としたIdP側でのシングルサインオンが中心になるイメージです。
4️⃣ Tenant Provisioning（テナントプロビジョニング）
- 専有リソースの作成
- テナント専用のデータベース、ストレージ、キャッシュレイヤーの作成
- テナント間のネットワーク分離、VPC/サブネットの設定
- コスト配分やリソース管理のためのリソースタグ付け
- Infrastructure as Code（Terraform、CloudFormationなど）による自動化
2️⃣や3️⃣で設定した顧客の初期状態を実際にプロビジョニング（インフラに適用）するフェーズです。テナントプロビジョニングを迅速に実施できれば、利用開始までのリードタイムを短縮できるためプロダクトの競争力にもつながります。
また「Tier管理」と呼ばれる処理も事実上この部分になるでしょう。例えばプレミアムの顧客であれば、データベースを分離し、そうでない顧客は共有データベースを利用するなどの分岐が必要になることもあります。
5️⃣ Billing Integration（請求管理）
- テナントへの契約プラン（料金体系）の割り当て
- 支払方法、請求先住所、税率設定などの請求先情報管理
- テナントの利用状況（API呼び出し、ストレージ使用量など）のメーター化と従量課金の準備
- Stripe、Chargebee、Zuoraといった外部の決済・請求サービスとの連携
そしてSaaSにおいては、請求管理に関する処理も忘れてはなりません。地味ながらもこの請求管理の観点だけでも記事にできてしまえるほどです。請求管理もビジネスモデルや企業によるでしょう。
実装上のポイント
何で作るか？
マルチテナントSaaSのオンボーディング処理は、データ分離の設計に依存するところが多く、ほとんどの企業が内製で開発していることが多いと思います。そもそも世の中に情報が出てこないことも多いため、各社の実態まで把握しきれていないのが筆者の正直な感想です。
とはいえ、テナント管理自体はそのアプリケーション固有の登録情報が必要のため自作、ユーザ管理はDay 5で述べたように一部IDaaS、テナントプロビジョニングはTerraformなりCloud Formationなりで自作、請求管理はコア機能についてはStripeなどに移譲しつつ、導線の画面は自作...といった複合的な選択肢をとっている企業が多いのではないでしょうか。
Qastでの事例
弊社anyのプロダクトQastにおける事例も紹介しておきましょう。Qastには、フリープランがあるため、下記のようなアカウント登録画面からテナントを作成することができます。この段階では管理者として登録されるため、ユーザ管理の種類に問わず、アカウントがひとつ作成されます。
Qastのアカウント登録
テナントプロビジョニングに関する処理は複数行っていますが、一つ例をあげるとこのアカウント作成を実行した段階で論理分離されたデータベースが作成されるようになっています。
そして作成後は社内から利用できる管理画面よりユーザ数の設定、プランの設定などを行うことができるようになっています。現時点ではこの画面とバックエンドは内製された実装になっています。
Qastの管理画面
まとめ
マルチテナントSaaSのオンボーディング処理は、コントロールプレーン側で最も重要な処理の一つでありながら、汎用的に使えるベストプラクティスはあまり出回っていません。アプリケーションに強く依存する領域で、 個社ごとに性質が異なり正解のオンボーディング処理はない ということを前提に検討を進めてみてください。