はじめに
本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day8 の記事です。弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。
マルチテナントSaaSにおいては、当然のことながら、顧客の企業活動にも影響を受けます。社名変更のような軽微な対応から、企業のM&Aや倒産にともなう処理などもSaaSの設計における考慮事項のひとつになりえます。Azureの マルチテナントSaaSの考慮事項という記事のなかでは、オンボーディングも含めて、「テナントライフサイクル」という言葉が用いられており、この言葉を使っていこうと思います👍
テナントのライフサイクルに対応する
先ほど述べたように社名変更、組織改変、企業買収や合併、分社化など顧客企業の事情に合わせてテナントのライフサイクルに応じた処理をサービス側で実行する必要があります。特にこれまでデータ分離の設計やオンボーディングをある意味、 静的な対象 として取り扱ってきましたが、実は企業自体がこういった活動が行われる以上は、動的な対象 としてテナントの設定を変更する必要があります。
https://www.hybridgtm.com/p/plg-self-service-series-tenant-lifecycle
例えば「とある顧客２社の企業が１社に統合され、アプリケーションも統合したい」という要望がきた場合にはどうなるでしょうか。
-
片方の企業のテナントにもう一方のデータをインポートする
- 片方のテナントにデータを移行、古いテナントを削除する
-
新テナントを作成するような企業を統合する仕組みを導入する
- 両テナントから取り込んで統一テナントを導入する
また当然ながら顧客の事象だけでなく、SaaSが評価されたことでアップセル（ID数増加など）やクロスセル（別プロダクトや機能の追加での契約）も容易に発生し得ます。
解約処理（オフボード）
企業の倒産やSaaS自体の解約にともなう処理も地味ながら核となる処理になります。 インフラをプロビジョニングしている場合は、オンボーディングと逆の操作をしなければなりません。
さらに重要になる点は、解約した企業については、 契約・規約で定められた保管期間に従い、データを確実に削除する必要 があります。企業向けアプリケーションにかぎらず、個人情報保護法やISMSなど法令や各種の認証制度での要件となっていることも多いです。
特にマルチテナントSaaSにおいては、企業間のデータでNDAを結ぶ必要がある場合も発生するなど、実際は企業の機微な情報を取り扱っているでしょう。
ちなみに弊社では、解約処理は社内専用の管理画面でのみ実行できるようになっており、操作は社内メンバーに限定しています。この画面に解約処理を一任することで、解約処理の関心ごとを集約するようにしています。
Qastの管理画面から解約処理が可能
まとめ
マルチテナントSaaSの運用において、「テナントライフサイクル」の考慮は避けて通れない要件です。オンボーディング（解約前）の設計や実装は比較的注目されやすいですが、企業の統廃合や解約処理といったライフサイクルの中盤～後期におけるシステム要件については見逃されがちなので、今回簡単ではありますが紹介してみました。
明日からはまたアプリケーションプレーンの話に戻って解説を進めていきます！