2 章 要約
2.1 テナントを追加したアーキテクチャ
リソースは特定の利用者専用に提供されるのではなく、すべての利用者によって共有される共有インフラストラクチャである。 テナントは、システムがどのように利用されるのかを説明する新しい用語。
- 顧客：利用者独自の環境に提供されるシステムの利用者を表す
- テナント：共有インフラストラクチャの利用者
テナントという用語は、顧客が SaaS 環境を利用していることを的確に表現する。
2.2 あらゆる SaaS アーキテクチャの 2 つの要素
- コントロールプレーン
マルチテナントの SaaS 環境の基盤となる要件を網羅するすべての共通コンポーネント、サービス、機能を配置する場所。 SaaS プロバイダーが SaaS 環境を構成、管理、運用するための機能。 マルチテナントサービスとして構築・設計されていない。 SaaS アーキテクチャの基礎はコントロールプレーンから始まる。
- アプリケーションプレーン
SaaS 製品の機能を具体化する。一般的に適用されるマルチテナントの原則がすべて具体化される。 単一の設計、アーキテクチャは存在しない。各テナントの要件に左右される。
2.3 コントロールプレーンの内部
2.3.1 オンボーディング
新しいテナントを SaaS 環境に導入するために必要なすべての手順を管理・統合する。 一意の識別子をテナントに割り当てる。 コントロールプレーンがアプリケーションプレーンと連動し、各テナントに必要なリソースをプロビジョニング・構成する。 テナント、ユーザー、アイデンティティ、アプリケーションリソースなどのマルチテナント環境の最も基本的な要素を構築し、連動させる中心的な役割を担う。
2.3.2 アイデンティティ
- ユーザーアイデンティ
ユーザーのメールアドレス、氏名など。
- テナントアイデンティティ
一意の識別子、テナント名など。
認証・認可の役割を担う。
2.3.3 メトリクス
テナントのアクティビティを収集し集約するための統合ハブを構築して、個々のテナントの用途や利用状況を監視・分析する。 これらのデータを活用して、SaaS 製品のビジネス、運用、技術的な成功を推進する。
2.3.4 請求
新しいテナントのオンボーディングと連動し、請求プランや請求に関する属性情報の設定を行う。
2.3.5 テナント管理
すべてのテナントを一元管理し、設定する。テナントの作成と状態の管理に必要なすべての機能を提供する。テナントに関連付ける一意の識別子、請求プラン、セキュリティポリシー、アイデンティティ設定、アクティブ/非アクティブの状況といった主要な属性のトラッキング。
2.4 アプリケーションプレーンの内部
2.4.1 テナントコンテキスト
テナントのすべての属性をパッケージ化したもの。例：JWT など。 テナントコンテキストは、テナントのリクエストを処理する方法に直接影響する。ルーティング、ログ、メトリクス、データアクセスなど駅用を与える。 作成するすべてのマイクロサービスはテナントコンテキストを使用する。 複雑さを抑え、俊敏性を高めるための技術戦略の検討が必要。
2.4.2 テナント分離
共有インフラストラクチャ上で各テナントのリソースに対し、他のテナントからのアクセスを保護する必要がある。
2.4.3 データパーティショニング
データの種類・サイズ、コンプライアンス要件、利用パターンなどに応じてストレージモデルの設計をデータパーティショニングという。データの特性にテナントデータを分割する。 専用・共有いずれもありうる。
2.4.4 テナントのルーティング
SaaS アーキテクチャは共有モデル（または共有マイクロサービス）と専用モデル（または専用マイクロサービス）を組み合わせて利用する。そのためにテナントごとに適切なルーティングが必要。
2.4.5 マルチテナントアプリケーションのデプロイ
マルチテナント構成を可視化できるデプロイ自動化コードが必要。
2.5 グレーエリア
2.5.1 ティアリング
ティアリングはプライシング戦略やパッケージ戦略だけでなく、より柔軟性の高い SaaS アーキテクチャを構築することで可能になる。 これによりビジネスに新たな価値の境界線を設定する機会が生まれ、これまで実現できなかった価値の提供が可能になる。
2.5.2 テナント、テナント管理、システム管理者
- テナントユーザー
管理機能なしでアプリケーションを利用するユーザー
- テナント管理者
システムにオンボーディングされたテナントの初期ユーザー。通常、管理者権限が与えられ、アプリケーションレベルの構造を構成、管理、保守する。テナントユーザーを作成する権限が与えられる。
- システム管理者
SaaSプロバイダーに紐づけられ、コントロールプレーンにアクセスして、SaaS環境の状態とアクティビティを管理、運用、分析する。
ユーザー管理をコントロールプレーン、アプリケーションプレーンのどちらで行うかが議論になる。著者はアイデンティティはコントロールプレーンで行うべきだと考える。 一方で、テナントユーザーのアイデンティティはアプリケーションプレーンで行う方法もある。 アイデンティティをどこに組み込むかは慎重な議論が必要。
2.5.4 テナントのプロビジョニング
プロビジョニングはコントロールプレーン、アプリケーションプレーンのどちらで行うべきか。 著者は、リソースの記述と構成を管理するプロビジョニングをできるだけリソースに近い場所に配置すべきであるため、アプリケーションプレーンで行うべきだと考える。これによりアプリケーションプレーンの変更によりコントロールプレーンの変更が発生することを避けることができる。このデメリットは、コントロールプレーンはより分散されたオンボーディング体験をサポートしなければならないこと。そのためには2者間のメッセージングを使用してプロビジョニングの状況を把握する必要がある。 重要なのは、プロビジョニングはオンボーディング体験の独立した一部であること。
2.6 コントロールプレーンとアプリケーションプレーンの統合
両者は最終的には統合する必要があるが、どの程度分離すべきか。 絶対的な基準はない。特定のドメインやアプリケーション、環境のニーズに合わせて決定する。
- 強い分離：イベント駆動型やメッセージ駆動型の疎結合モデル
- 弱い分離：コントロールプレーンがアプリケーションプレーンのリソースを直接的に制御できるネイティブな統合
2.7 自社のプレーンに最適な技術を選ぶ
コントロールプレーンとアプリケーションプレーンは利用状況やパフォーマンス特性が一致するとは限らないため、技術要件を個別に考え選択する。
2.8 絶対的なものを避ける
各プレーンで絶対的な決まりがあるわけではない。 責任の分担を明確にし要件を満たすアーキテクチャを構築する。
2.9 まとめ
本章の概念はどのSaaS環境にも当てはまり、すべてのチームがSaaSアーキテクチャに取り組む際のメンタルモデルになる。