# 定義
AWS Well-Architected フレームワークは、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化という 5 本の柱を基本としています。SaaS によって、このそれぞれの柱に新しい検討事項が追加されます。SaaS アプリケーションのマルチテナントという性質上、アーキテクトは、SaaS 環境のセキュリティ、オペレーション効率、安定性、俊敏性を確保する方法をよく検討する必要があります。このセクションでは、このドキュメント全体で扱う SaaS の概念の概要を説明します。SaaS アーキテクチャを構築する際は、検討すべき 10 の領域があります。
**Topics**
+ [テナント](tenant.md)
+ [サイロモデル、プールモデル、ブリッジモデル](silo-pool-and-bridge-models.md)
+ [SaaS アイデンティティ](saas-identity.md)
+ [テナントの分離](tenant-isolation.md)
+ [データのパーティション化](data-partitioning.md)
+ [他のテナントによる影響](noisy-neighbor.md)
+ [テナントのオンボーディング](tenant-onboarding.md)
+ [テナントの階層](tenant-tiers.md)
+ [テナントのアクティビティと消費](tenant-activity-and-consumption.md)
+ [テナント対応オペレーション](tenant-aware-operations.md)
# テナント
テナントとは、SaaS 環境における最も基本的な構造です。SaaS プロバイダーがアプリケーションを構築すると、このアプリケーションは顧客が利用できるように公開されます。この環境を利用するために登録している顧客は、システムのテナントとして表されます。例えば、あなたの組織が会計サービスを作成し、別の企業がそのサービスを使ってビジネスを管理できるようにするとします。このような企業はすべて、提供するシステムにとってのテナントと見なされます。
テナントは通常、登録時にテナント管理者のユーザー情報を提供します。このテナント管理者は、システムにログインしたうえで、自社のニーズに基づいた設定を行います。これには、テナント環境にユーザーを追加する機能などが含まれます。
このようなモデルで提供されるソフトウェアは、マルチテナント SaaS システムと呼ばれます。これは、このサービスの各テナントが、統合機能を通じてテナントのニーズをサポートする 1 つの共有システムを使用していることによります。例えば、このようなシステムのアップデートは、システムを使うすべてのテナントに適用されます。
# サイロモデル、プールモデル、ブリッジモデル
SaaS アプリケーションを構築するアーキテクチャモデルには、さまざまな種類があります。規制、競争力、戦略、コスト効率、マーケットごとの検討事項など、すべてが SaaS アーキテクチャの形になんらかの影響を与えます。これと同時に、SaaS アプリケーションの規模の定義には、戦略やパターンがあります。このパターンには「サイロ、ブリッジ、プール」の 3 つのカテゴリがあります。
まず**サイロモデル**とは、テナントに専用リソースが提供されるアーキテクチャです。SaaS 環境で、システムの各テナントが完全に独立したインフラストラクチャスタックを所有している状況を想像してください。または、システムの各テナントがそれぞれ別のデータベースを持っているとしましょう。テナントのリソースの一部または全部が、このように専用のリソースとしてデプロイされている場合、これをサイロモデルと呼びます。サイロ環境は専用のリソースを有しますが、アイデンティティ、オンボーディング、オペレーションが共有に依存することは同じであり、すべてのテナントは共有構造で管理およびデプロイされるという点に注意する必要があります。これが SaaS がマネージド型サービスモデルとは異なる点です。後者では、顧客は個別のオンボーディング、管理、オペレーション機能を使い、独自バージョンのシステムを実行する場合もあります。
これと反対に、SaaS の**プールモデル**とは、テナントがリソースを共有しているシナリオを指します。これはマルチテナントの古い概念で、テナントはスケールメリット、管理のしやすさ、俊敏性などの理由で、共有のスケーラブルなインフラストラクチャに依存しています。このような共有リソースは、コンピューティング、ストレージ、メッセージングなど、SaaS アーキテクチャの一部または全部の要素に適用できます。
最後のパターンは**ブリッジモデル**です。*ブリッジ*とは、SaaS ビジネスは必ずしもサイロまたはプールのどちらかに分類されるわけではないということを表しています。むしろ多くのシステムでは、混合モードにして、サイロモデルとプールモデルのシステムを併用しています。例えば、アーキテクチャにおける一部のマイクロサービスの実装にサイロを使用し、その他のサービスにプールを使用するような場合があります。サービスデータの規制のプロファイルと他のテナントによる影響の可能性は、マイクロサービスにサイロモデルを採用する理由になる場合があります。その一方で、俊敏性、アクセスパターン、コストプロファイルの課題などは、プールモデルを選択する理由になるでしょう。
# SaaS アイデンティティ
ほとんどのシステムは、すでにアイデンティティプロバイダーを利用して認証を行っています。SaaS の世界では、アイデンティティの概念を拡大し、アイデンティティの定義にテナントの概念を組み込む必要があります。これは、ユーザーの認証後に、そのユーザーが誰なのか、どのテナントに関連付けられているのかを把握する必要があるということです。このユーザーアイデンティティをテナントのアイデンティティと結合したものを、SaaS アイデンティティと呼んでいます。この概念は SaaS アーキテクチャの基本要素であり、SaaS アプリケーションの一部であり基盤でもあるマルチテナントポリシーと戦略を適用する際に使用されるテナントコンテキストを提供します。
# テナントの分離
テナントの分離は、すべての SaaS プロバイダーが取り組む必要のある基本的なトピックの 1 つです。独立系ソフトウェアベンダー (ISV) が、SaaS にシフトし、共有インフラストラクチャモデルを採用してコスト効率および運用効率を達成する際には、マルチテナント環境において、テナントが他のテナントのリソースにアクセスできないようにする方法を決定するという課題にも取り組む必要があります。SaaS ビジネスにとって、どのような形でもテナントの境界線を超えることは、重大かつ回復不能に至る可能性のあるイベントに相当します。
テナントの分離は SaaS プロバイダーにとって不可欠と考えられますが、この分離を達成するための戦略およびアプローチは一様ではありません。SaaS 環境でテナントの分離を実現する方法には、非常に多くの要素が影響を与えます。ドメイン、コンプライアンス、デプロイモデル、AWS サービスの選択など、すべてがテナント分離の方法にそれぞれの検討事項として関わってきます。
分離を実行する方法にかかわらず、各 SaaS アーキテクチャはテナントのリソースを効率的に分離するために必要な構造を必ず備えている必要があります。
# データのパーティション化
データの構成方法は、マルチテナントデータを表すさまざまなアーキテクチャパターンを見て決定する必要があります。データは個別のデータベースに保管するのがよいでしょうか。それとも、共有構造に一緒に保存するのがよいでしょうか。 このようなマルチテナントのデータ保管のメカニズムおよびパターンは、一般的にデータのパーティション化といいます。
# 他のテナントによる影響
「他のテナントによる影響」というのは基本的なアーキテクチャのパターンおよび戦略においてよく使われる用語です。この背景には、システムのユーザーのワークロードがシステムのリソースに負荷を与え、同じシステムの他のユーザーに悪影響を与える可能性があるという考え方があります。これによって、1 人のユーザーが他のユーザーのパフォーマンスを低下させてしまう結果となることもあります。
テナントが共有リソースを使い切ってしまう可能性のあるマルチテナント環境では、この考え方の重要性は増します。これをさらに複雑化させるのは、マルチテナント環境におけるワークロードは予測が難しいという点です。これによって、SaaS アーキテクチャにおいて「うるさいテナント」による影響の可能性を管理およびできるだけ軽減できる独自の戦略を実行する必要性はさらに高まります。
# テナントのオンボーディング
SaaS アプリケーションでは、SaaS 環境に新しいテナントを迎え入れる際に、フリクションレスモデルを利用します。このときには、新しいテナントの作成に必要なすべての要素を正常にプロビジョニングして構成するために、数多くのコンポーネントを調整して配置する必要があります。SaaS アーキテクチャでは、このプロセスをテナントのオンボーディングと呼びます。テナントのオンボーディングは、テナントが直接開始する場合と、プロバイダーが管理するプロセスの一部として開始される場合がある点に注意してください。
# テナントの階層
SaaS アプリケーションは広い範囲のマーケットセグメントをサポートするように設計されていることが多く、顧客のプロファイルのタイプに合わせた価格体系や機能を提供しています。このようなプロファイルは、よく階層と呼ばれます。さまざまな階層の多様なニーズをサポートするということは、それぞれに合わせて機能をカスタマイズできるような設計構造を導入するということです。これらの階層モデルは、SaaS ソリューションのコスト、オペレーション、管理、信頼性の規模に影響する可能性があります。
# テナントのアクティビティと消費
SaaS のマルチテナント環境では、テナントによるアプリケーションの使用状況と、それがシステムのアーキテクチャにかけている負荷の状況を可視化することが重要です。テナントレベルでこのような情報をトラッキングすることにより、システムの効率的にスケーリングを行う能力と、システム環境に加わる、常に進化を続けるワークロードをサポートする能力を評価できます。SaaS システムから取得されるこのメトリクスおよびインサイトは「テナントのアクティビティと消費」と呼ばれています。
## 計測と課金
SaaS 製品は従量課金制で提供されることがほとんどで、製品のコストは顧客の消費プロファイルに基づき決定されます。これにより、価値と SaaS システムにかかる負荷に密接に結びついた料金体系モデルを顧客に提供できます。このモードでは、消費量の計測メカニズムの定義および導入を SaaS プロバイダーが行います。この計測データは通常、課金情報を集約して請求書を生成する請求システムに送信されます。消費量ベースの料金体系は、追加料金 (サブスクリプションなど) と組み合わせる課金モデルとして提示されます。
# テナント対応オペレーション
SaaS 環境におけるオペレーション体制では、テナント対応オペレーションのオプショナルビューを表示できるオペレーションビューを作成するためのメカニズムおよびツールが必要になります。これは、SaaS プロバイダーがシステムアクティビティと健全性を、個別テナントおよびテナントの階層のレベルで表示する必要があるという考えに基づきます。このような仕組みは、個別テナントのアクティビティおよび消費のトレンドやパターンを診断したり評価したりするために必須となります。