こんにちは。AI・IoTサービス開発部でマネージャをしている和田です。
今回の記事では、社内でも良く話題に挙がる、SaaSサービスのマルチテナントとOEM（ホワイトラベル）についてご紹介します。
ASP（シングルテナント）とSaaS（マルチテナント）
ASPとSaaSとの違いに明確な定義はないものの、「SaaSはマルチテナント」というのは一般的によく挙げられる定義だと感じます（最近はASPという呼び名はあまり聞かなくなり、クラウドサービスの専用サーバープランが近しいかもしれません）。
BtoBのSaaSサービスのマルチテナントでの設計留意点として、「どのテナント（ユーザ企業や契約）にアクセスしているか」の切り分けが挙げられます。
たとえば、Microsoft Teamsのようなコミュニケーションサービスでは、自社テナント以外に、他社テナントにも招待されて参加するような使い方は一般的です。またカスタマーサポートのために、サポート提供側が一定の条件下で顧客テナントを参照・操作するようなユースケースも想定されます。
「どのテナントにアクセスしているか」を切り分ける方法はいくつか考えられます。
- テナントID入力方式
- ログイン時に、テナントID（企業コードなど） + ログインID（メールアドレスなど） + パスワードを指定する
- 個別URL方式
- テナントごとに異なるURLを提供し、アクセスされたURLで判断する
- パスを分ける（
サービス名.com/hogenoge）方式も考えられますが、ドメインを分ける方式( ex.hogehoge.slack.comhogehoge.sharepoint.comhogehoge.daetadoghq.com)が一般的でしょうか。独自ドメインの持ち込み（ユーザ側で保有しているドメインを適用）のニーズがあることも、ドメインを分ける方式が一般的である理由なのかもしれません。
- テナント切り替え方式
- ログイン後に、テナントを切り替えて利用する
「1. テナントID入力方式」「2. 個別URL方式」は組み合わせて提供されるケースも多いです。Optimal Bizでも、ログイン画面では企業コード + ログインID + パスワードを入力しますが、テナント用の個別URLにアクセスするとログインID + パスワードのみを入力する仕様になっています。
また「2. 個別URL方式」のケースでも、ネイティブアプリではURLを分けることができないため、カスタムドメインの hogehoge 部分を入力後にログインID + パスワードを入力することになり、「1. テナントID入力方式」と「2. 個別URL方式」はおおよそシンタックスシュガーであるとも言えそうです。
また「3. テナント切り替え方式」はMicrosoft Teamsなどが挙げられます。
こちらも「2. 個別URL方式」と組み合わせて提供されるサービスも散見されます（メニューからテナントを選択すると、当該テナントの個別URLにredirectされる）。
この辺りは、単純な操作の簡便さだけではなく、今どのテナントで操作しているのかを、ユーザにどれだけ意識的に切り替えてもらうべきかも意識して設計する必要があります。
興味持っていただけた方は、普段使われているSaaSサービスのマルチテナント設計を（ネイティブアプリの挙動含めて）確認してみるとおもしろいと思います！
OEM（ホワイトラベル）
OPTiMは数多くのSaaSサービスを提供していますが、OEM提供にも積極的に取り組んでいることが一つの特色になっています。例えば、OPTiMの屋台骨であるモバイルデバイス管理サービス「Optimal Biz」は、KDDI様の「KDDI Smart Mobile Safety Manager」などにOEM提供しています。
販売代理店モデルでは通常 利用許諾はベンダーと利用者の間で締結されます。販売代理店経由で契約したSaaSサービスでも、利用規約はベンダーの規約に同意しますよね。
一方で、OEM提供においては、サービス提供主体（利用許諾をユーザと締結する主体）がOEM先となります。
そのため、OEM提供では、少なくとも利用規約やプライバシーポリシーなどは、切り替えが必要になります。ブランディングの観点から、サービス名やロゴなども変更するケースが多いと思います（powered by OPTiM のような形でベンダーをオープンにするケースもあります）。
サービス提供主体が異なるため、ネイティブアプリは、通常はOEM先ごとに提供する必要がある（AppStoreやGoogle Play Storeには、OEM先ごとのデベロッパー契約の元でそれぞれアプリを申請して並べる必要がある）ことも留意必要です。
設計上の留意点としては、OEM先ごとに設定可能な範囲を定めて環境変数や管理コンソールからの設定項目などに切り出しておくことで、OEM先ごとのソースコード差分をなくし、構成管理をシンプルに保つことが挙げられます。
- サービス名/ロゴ画像/favicon/アイコン画像など
- ブランドカラーの切り替え（ヘッダの背景色などを切り替えられるようにするなど）
- 利用規約やプライバシーポリシーの出し分け
- その他メニューやリンク先（マニュアル、OEM先企業情報、サービス紹介ページなど）、サービスログアウト時の遷移先
- OEM先ごとのドメイン対応
- 自動送信メール（メール送信元や、タイトル/本文など）
- ユーザへのお知らせ機能、ユーザからの問い合わせ受付方法
- 入力欄のplaceholder文言（「オプティム太郎」のような、サービス提供主体を想起させる文言を使用しがちなので留意）
- （決済機能を有する場合）決済代行会社との接続設定
- ネイティブアプリの設定ファイル群の管理
もちろん、、、OEM先ごとに個別カスタマイズが免れないことも少なくありません。その場合は、feature flag（環境変数、データベースのデータ）で仕様差分を管理する、プラグイン的な仕組みを導入する、共通ライブラリの外側は個別実装とする、フォークして別々の道を歩むなど、さまざまな選択肢が考えられます。が、サービスの将来の方向性も想像して大きな設計判断になります。
サービス提供主体のマルチテナント（OEM先のマルチテナント）
SaaSサービスをOEM提供する際は、OEM先ごとに専用の環境を立てつけるケースが一般的と想像します。上記のようなOEM先ごとの設定差分を扱う上でも環境を分ける方がシンプルですし、システムのキャパシティやランニング費用もOEM先ごとに設計できる方が柔軟性が高いです。
一方で、OEM先ごとに専用の環境を立てつけることは、インフラ費用や保守運用の工数も含めて、サービス提供のオーバーヘッドは小さくありません。
一つのサービスを多数のOEM先に提供するようなケース自体がレアではありますが、そのようなケースにおいては、複数のOEM先を単一のクラウド環境で運用できれば、ミニマムフットプリントのコストを複数社でシェアすることができます。それによって、より小さいライセンス数からOEM提供が可能になり、ビジネスのスケーラビリティも拡張できます。
オプティムが提供するサービスでは、たとえば、法人向けのマーケットプレイス「OPTiM Store」 で、このOEM先のマルチテナントを実現しています。
OEM先のマルチテナントにおいては、上記のようなOEM先ごとの設定差分は、データベースなどでマスタ管理し、アクセスされたURLなどからOEM先を判定して動的に切り替えることになります。なお、アーキテクチャ的には、データベースや共通サービスは共通化し、フロントエンドはOEM先ごとに異なるバージョンをデプロイするなどのハイブリッドな方式も想定されます。
サービス提供主体からユーザへのお知らせ機能、利用規約更新などで次回ログイン時に表示する機能などを有している場合、OEM先ごとに異なるタイミングで更新されるお知らせを表示するため、そのステータス管理は複雑になります。
さいごに
「OEM先のマルチテナント」あたりは、私の文章力不足で伝わりづらい部分もあったかと思いますが、ご容赦ください。
オプティムでは、よりスケーラブルなビジネスモデルとアーキテクチャを目指して、SaaSサービスのマルチテナント化のようなテーマを一緒に議論して作り上げる仲間を募集しています。
