【第02回】Deep Dive マルチテナントSaaS on AWS - 第2章振返り

はじめに

本記事では、「マルチテナント SaaS アーキテクチャの構築 ― 原則、ベストプラクティス、AWS アーキテクチャパターンの第 2 章「マルチテナントアーキテクチャの基礎」の内容を振り返り、自分なりに要点を整理していきます。

2 章では、多くのマルチテナント SaaS アーキテクチャの基本的な構造や概念が紹介されています(それらの概念の詳細は後続の各章で解説されます)。
特に、「(マルチ)テナント」という概念が SaaS アプリケーションに導入されることによってもたらされる影響と、その役割について説明されています。
この章を読むことで、自分達のマルチテナント SaaS アーキテクチャの全体像を定義する際に検討すべき一連のビルディングブロックを意識することが出来るようになります。

テナントを追加したアーキテクチャ

第 1 章でも述べたように、従来の(SaaS 以前の)ソフトウェアデリバリモデルでは、アプリケーションは顧客ごとに顧客の環境にインストールされ利用されていました。それ故アーキテクチャ自体は比較的シンプルに保つことが可能でした。
一方で、マルチテナント SaaS アーキテクチャはそうは行きません。複数の顧客(テナント)が単一のアプリケーションを共有するという構成は、アプリケーションのあらゆる領域 - 認証やルーティング、ロジックのコーディング方法等 - に影響を及ぼします。

また、アプリケーションの利用形態自体が変わったことで、その利用者を指し示す名称も、「顧客」から「テナント」に変わります。
アプリケーションを構成する単一の共有インフラストラクチャの一部を利用者に使わせるというマルチテナント SaaS のビジネスモデルが、さながら集合住宅の一画を利用者に貸し出す行為に通ずるものがあるためです。

この「テナント」という概念・情報が、マルチテナント SaaS アーキテクチャの様々な領域で必要になっていきます。

マルチテナント SaaS アーキテクチャの 2 大構成要素

ビジネスドメインや設計に関わらず、全ての SaaS に共通して必要とされる 2 つの構成要素して、「アプリケーションプレーン」と「コントロールプレーン」が挙げられています。

コントロールプレーンは、1 章で紹介されたような SaaS ビジネスの多くの原則を実践するための具体的な機能を提供するためのアプリケーションです。加えて、SaaS プロバイダが SaaS アプリケーションを管理・運用するための管理コンソールも、コントロールプレーンに実装されるべき機能です。
コントロールプレーン自体はマルチテナント向けのアプリケーションである必要が無い代わりに、SaaS アプリケーション上の全てのテナントにまたがった機能を提供する必要があります。
この書籍において重要なのは、マルチテナント SaaS アプリケーションの基礎はコントロールプレーンから始まるという点です。

アプリケーションプレーンはそのまま、SaaS 製品の特徴や機能を提供するためのアプリケーションです。アプリケーションプレーンのあらゆる領域で、マルチテナントの原則が適用されることから、アーキテクチャの設計、機能、セキュリティ、パフォーマンス等のあらゆる領域においてマルチテナントであるという点がどのような影響を与えるかを意識しなくてはいけません。

コントロールプレーンの構成要素

次に、前述したコントロールプレーンの具体的な構成要素について紹介し、それらについての理解を深めていきます。

※各構成要素の詳細は、後続の各章で解説されます。

オンボーディング

オンボーディングは、利用者が SaaS アプリケーションにサインアップした際に実行される一連の処理フローを意味します。例えばテナント識別子の割り当てや対応するリソースのプロビジョニング等です。

オンボーディングのプロセスは SaaS アプリケーションの基本的な要素であり、利用者にとっての SaaS 体験にも大きな影響を及ぼします。それ故、ビジネスの事業部門も積極的な関与が求められる領域となります。

アイデンティティ

マルチテナント SaaS アプリケーションでは、アプリケーションにサインインするユーザを認証するだけでなく、そのユーザがどのテナントに紐づいているかも把握出来なくてはいけません。言い換えれば、マルチテナント SaaS アプリケーションではユーザアイデンティティに加えてテナントアイデンティティも適切に管理し、両者を紐づける必要があります。

この紐づけの要件は結果的に、認証モデルの設計やアプリケーション全体を通したアイデンティティ体験に影響を及ぼします。

メトリクス

リソースを複数テナント間で共有するようなマルチテナント SaaS アプリケーションでは、テナントごとのリソースの利用状況やアクティビティを正確に把握することが困難になります。そのため、コントロールプレーンの機能の一部として、豊富且つ柔軟なメトリクスの収集及び分析機能を提供することが重要になります。
収集されたメトリクス情報は、アプリケーションのトラブルシューティングといった運用目的で利用されることもあれば、特定機能の利用状況の把握といったビジネス目的で利用されることもあり、その役割は多岐に渡ります。

テナントを中心としたメトリクスの収集と分析という要件は、アプリケーションの設計や実装に影響を及ぼします。

請求

請求機能は、コントロールプレーン内の他の機能と接点を持ちます。例えば請求情報の設定はテナントのオンボーディングプロセスと連動して行われることが多く、実際の請求金額の決定にはテナントのティアリング情報や実際のアクティビティ情報が参照されるといった具合です。
そのため、請求機能、或いは外部の請求システムとの連 k 寧機能自体もコントロールプレーン内に組み込まれるのが自然となります。

テナント管理

コントロールプレーンでは、SaaS アプリケーションの全テナントを一元管理出来る必要があります。各テナントのライフサイクルに関する全ての操作をサポートすると共に、これまで紹介した他の機能(請求やアイデンティティ等)の情報のトラッキングも含まれます。
この機能によって、一元化された体験でテナントを管理することが可能になります。

アプリケーションプレーンの共通概念

次に、多くのマルチテナント SaaS アプリケーションのアプリケーションプレーンで共通して登場する概念を紹介していきます。

テナントコンテキスト

マルチテナント SaaS アプリケーションは、常に特定のテナントコンテキストのもとで機能するという前提に立つ必要があります。
テナントコンテキストは多くの場合、JWT(Json Web Token)のようなトークン形式で表現され、ユーザ情報及びテナント情報を一つの構造にまとめ、アプリケーションのあらゆる領域に渡されます。
テナントコンテキストは、ルーティングやメトリクス、データアクセス制御といったアプリケーションの様々なロジックを左右する情報です。

そのため、マルチテナント SaaS アプリケーションのアーキテクトは、テナントコンテキストをアプリケーション全体でどのように適用し管理するかを常に意識する必要があります。

テナント分離

複数テナント(顧客)が単一のインフラストラクチャを共有するマルチテナント SaaS アーキテクチャでは、特定テナントのリソースが他のテナントから確実に保護される仕組み - テナント分離 - を実装することが必要です。

これは単にテナントごとのデータを個別のデータベースに保管すれば良い、という話ではありません。アプリケーションのロジックとして、アプリケーションの全ての領域にテナント分離の仕組みを実装する必要があります。

データパーティショニング

データパーティショニングは、テナントごとのデータをどこに、どのように保存すべきかの設計です。
この設計は、データの種類やサイズ、利用パターンやコンプライアンス要件等多くの要件によって左右されます。特にマルチテナント SaaS アプリケーションでは、データをテナントごとに専用のストレージで保管するか、共有のストレージに保管するかといった点もデータの特性に基づいて検討する必要があります。

テナントのルーティング

最も単純なマルチテナント SaaS アーキテクチャは、一組のインフラストラクチャを全てのテナントが共有するというものでしょう。しかし実際のアーキテクチャでは、様々な要因から下図のように共有モデルと占有モデルがアプリケーション内に混在することがあります。

このような状況下で、前述したテナントコンテキストを使用しながら、各テナントからのリクエストを適切なリソースへとルーティングする仕組みを実現することが必要になります。

マルチテナントアプリケーションのデプロイ

インフラストラクチャ及びアプリケーションのデプロイ方法を検討する際に、前述したような共有リソースと占有リソースとが混在する状況を考慮する必要があります。
例えば、テナントの状態を確認し、一部のマイクロサービスのみをデプロイする、といったより高度なデプロイ自動化の仕組みが必要になる可能性があります。

グレーエリア

ここまでコントロールプレーンとアプリケーションプレーンを構成する要素・概念を整理しました。それらに加えて、明確にどちらかのプレーンに当てはまるとは言い難い概念について紹介していきます。

ティアリング

SaaS 企業は、価格帯の異なる製品のプランを提示し、それによって、提供される機能や利用体験に差をつけるというティアリング戦略を取ります。
このティアリングの内容も、マルチテナント SaaS アプリケーションの多くの側面に影響を及ぼします。

ティアリングは請求やオンボーディングのプロセスと関連し、テナント情報と強く関係づけられるため、コントロールプレーンに実装するという考え方もあれば、ルーティング等のアプリケーションロジックにも様々な影響を及ぼすことから、アプリケーションプレーンに実装するという考え方も出来ます。

テナントユーザ、テナント管理者、システム管理者

マルチテナント SaaS アプリケーションでは、「ユーザ」という用語は複数の意味を持ち誤解を招きやすいものとされています。具体例としては下図のように、主に「テナントユーザ」「テナント管理者」「システム管理者」です。

• テナント管理者 : テナントがシステムにオンボーディングされる際の初期ユーザ。アプリケーションレベルの管理者権限が与えられ、テナントユーザの作成を含む自テナントの管理・運用が可能
• テナントユーザ : アプリケーションの利用者(管理機能にはアクセス不可)
• システム管理者 : SaaS アプリケーションをコントロールプレーンから管理する管理者

マルチテナント SaaS アプリケーションのアーキテクトは、これらの「ユーザ」の役割とライフサイクルを考慮したユーザ管理の仕組みを設計する必要があります。

システム管理者はコントロールプレーン上で管理出来る必要がある、という点は自明ですが、テナント管理者及びテナントユーザもコントロールプレーン上で管理出来るようにすべきか、それともアプリケーションプレーン上でのみ(テナント管理者でのみ)管理出来るようにすべきか、という点は議論の余地があります。

テナントのプロビジョニング

テナントのオンボーディングの過程で、何らかのリソースをアプリケーションプレーン内にプロビジョニングする必要があります。その際のテナントプロビジョニング機能はどちらのプレーンに実装すべきかも議論の余地があります。

終わりに

本記事ではマルチテナント SaaS アプリケーションを、アプリケーションプレーンとコントロールプレーンという構成要素に分解して、それらの構成要素や概念を整理していきました。
ここで紹介した概念は基本的にどのような SaaS アプリケーションでも検討すべき事項でありますが、絶対的な指針は無く、その結論は SaaS アプリケーションや企業の特性に基づいて各自が判断する必要があるという点を忘れないようにする必要があります。