はじめに
本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day2 の記事です。弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。
本日よりマルチテナントアーキテクチャについて解説を進めていきたいと思います！これを読んでいただいている読者には釈迦に説法かもしれませんが、改めてマルチテナントアーキテクチャとは何かを紹介していきます。
本日までは前提を揃えるために、やや座学的要素が強くなります。明日より個別具体の技術について、掘り下げていく予定なので、お楽しみを👋
マルチテナントの基本概念
マルチテナントアーキテクチャにおいて、各企業(顧客)のことを「テナント」と呼びます。1つのアプリケーションインスタンスを複数のテナントが共有する構成になっており、これが「マルチ(複数の)テナント」という名前の由来です。特に今回の一連の記事の文脈では、「複数の企業が1つのWebアプリケーションを利用する」というシナリオを中心に扱っていきます。これは狭義の意味で、本来であれば客体が「企業」でなくても、対象が「Webアプリケーション」でなくても良いと思います。しかし、本シリーズではB2B SaaSの文脈で議論を進めていくため、このような定義で統一したいと思います。
歴史的には、20年ほど前まではオンプレミスのように１企業１アプリケーションを提供する時代が主流でした。しかしながら、Salesforceなどを皮切りに、ハードウェア、ミドルウェア、実際のアプリケーションを複数の企業で共有するモデル、つまりマルチテナントSaaSを採用する企業が増加しました。
https://medium.com/@sudheer.sandu/multi-tenant-application-68c11cc68929
背景には、インターネットやブラウザの普及、クラウドの進化といったテクノロジー面における潮流はもちろんのこと、顧客が真に求めているものはアプリケーションによる課題解決のみであり、そのハードウェアの管理やメンテナンスコストを払わずにすむといった利点が非常に多くあります。
このメリットの反面、テナントごとに境界線を分ける必要性が生じ、我々エンジニアとしては考慮するべき点が増えていきます。このシリーズではエンジニアリングの面にフォーカスをして、マルチテナントのプラクティスを紹介していく予定です。
さて、弊社anyにおいても、QastというマルチテナントSaaSとしてWebアプリケーションを提供しています。
マルチテナントSaaSがよく分からない！という人は、こういった企業向けのサービスを想像していただければ良いと思います。国内で著名なB2BのマルチテナントSaaSで言えば、freee、SmartHR、Sansan、バクラクが挙げられるでしょう。
マルチテナントSaaSの2つのプレーン
本書の執筆において全体的に参考にさせていただいた『マルチテナントSaaSアーキテクチャの構築』においては、マルチテナントSaaSを設計・構築する上で、システムを2つの重要なプレーンに分けて考えることが非常に有効としています。
これらはコントロールプレーンとアプリケーションプレーンと呼ばれます。
とはいえ、日本のSaaS企業でこの区分を利用しているケースを個人的にはあまり見聞きしません(?) あくまでも整理の一環として見ていくことにしましょう。
アプリケーションプレーン
アプリケーションプレーンは、エンドユーザーが日常的に利用する機能を提供する部分です。B2B SaaSの文脈では、各企業のユーザーが実際の業務で使用する画面や機能がこれに該当します。アプリケーションプレーンは非常にイメージがつきやすいでしょう。マルチテナントやSaaSに限らず、ただのアプリケーションのことです。ひとつ特有のポイントがあるとすれば、各テナントのデータが論理的に分離されており、テナントAのユーザーがテナントBのデータにアクセスできないような仕組みが重要になることでしょう。
弊社プロダクトのQastであれば、下記のようにWebアプリケーション本体、モバイルアプリケーション本体が主に当てはまります。Qastでは、まずURLによってアプリケーションの入り口がテナントごとに分離されるようになっています。
Qastの画面
マルチテナント特有のアプリケーションプレーンでの論点は下記のものがあげられます。
- テナント分離にともなうデータストア選定（Day3, Day4）
- 各テナントごとの情報をいかに越境させないようにデータを分離するか、またトレードオフとしてパフォーマンスなどとのバランスを取る方法
- 認証・認可にかかわる選定や実装（Day5, Day6）
- 各企業ごとに認証方法が異なる課題をどのように抽象化するか、またマルチテナントにおける複雑化する認可（権限）問題の取り扱い方
- ノイジーネイバー問題への対応（Day 10）
- 1つの規模の大きいテナントにより他企業への影響をどのように対処できるか
上記の内容について、次回以降の記事で詳しく解説していきます。
コントロールプレーン
一方、コントロールプレーンは、SaaS全体を管理・運用するための機能を提供する部分です。主にSaaS事業者側が利用する管理機能や、テナント管理者が自社の設定を行うための機能がこれに該当します。
- テナントの作成・削除・管理
- サブスクリプション・請求管理
- 認証・認可の設定
- システム全体の監視・運用
- テナントごとの設定・カスタマイズ
コントロールプレーンは、アプリケーションプレーンとは異なり、テナントを横断した視点でのデータ管理が必要になることもあります。つまりサービス事業者側の社内のカスタマーサクセス部隊が利用するアプリケーションにおいて、顧客の契約を変更したことをアプリケーションに適用する処理が含まれます。
センシティブな内容も多いため、大部分は公開できませんが、弊社Qastにおいても、管理画面を用意しており、プランの管理やメンバー数の変更をできる画面を用意しています。
Qastにおける社内用の管理画面
焦点が当てられることは少ないのですが、このような領域こそ実務経験のリアルな視点をお届けしたく、下記の日程で紹介をする予定です。
- オンボーディング処理（Day 7）
- 企業が利用を始めるときの処理群について紹介
- 統廃合、解約にともなう処理（Day 8）
- 企業のM&A、サービス解約にともなう処理についての考察ポイントを紹介
- DevOpsを推進する社内運用ツール（Day 20）
- 上記ツールのように社内で運用するツールを一般論を交えながら紹介
マルチテナントSaaSの運用面について
マルチテナントSaaSにおいては、アプリケーションプレーンとコントロールプレーンという側面での整理ができますが、エンジニアリングのより泥臭い領域として、日々の運用があげられるでしょう。このシリーズでは運用面にも焦点を当てたく、シリーズ後半で重点的に解説していきたいと思います。
- Observabilityでの考慮（Day 19）
- マルチテナント特有ではありませんが、複雑なアプリケーションを構築するうえで、トレーサビリティなどの観点は非常に重要です。Qastの事例も紹介しつつ解説します
- セキュリティチェックや認証制度の諸問題（Day 21）
- 企業に導入してもらうときにはセキュリティチェックがほぼ必須になります。また特定の業界への導入や客観的なセキュリティの担保には外部認証制度を利用することもあります
- アラート対応やインシデント対応（Day 22）
- インシデント対応はソフトウェアの信頼性にかかわる重要な項目です。特にマルチテナントにおいては個社なのか全体への影響なのかの切り分けも重要になってきます
さいごに
本記事では、マルチテナントアーキテクチャの基本概念と、コントロールプレーン・アプリケーションプレーンという重要な設計思想について解説しました。
次回以降の記事では、データ分離の具体的なパターンや、各プレーンにおける実装方法、運用上の注意点について深掘りしていきたいと思います。マルチテナントSaaSの設計は、初期の意思決定が後々の運用に大きく影響します。自社のサービス特性や成長戦略を見据えて、適切なアーキテクチャを選択していきましょう！