サービスとしてのソフトウェア (SaaS) は、考慮すべき点の多い複雑なトピックです。 Azure で SaaS ソリューションを構築する独立系ソフトウェア ベンダー (ISV) は、問題を解決し、次のような意思決定を行う必要があります。
- どの テナント モデル を使用する必要があるか?
- マルチテナント アーキテクチャで使用する ID ソリューションをどのように設定するか?
- 新しい顧客のオンボードはどのように進めるか?
このアーキテクチャは、これらの質問の一部に回答し、SaaS の世界への出発点を提供することを目的としています。 このアーキテクチャは、幅広いシナリオに適応させることができます。
考えられるユース ケース
このアーキテクチャを使用できるユース ケースの例を次に示します。
- SaaS ベースのビジネス モデルへの移行の一環として、完全なマルチテナントをサポートするように既存のアプリケーションを最新化する。
- まったく新しい SaaS オファリングを開発する。
- SaaS オファリングを他のクラウド サービスから Azure に移行する。
アーキテクチャ
このアーキテクチャの PowerPoint ファイル をダウンロードします。
用語
次の表では、この記事に記載されている用語について説明します。
| 期間 | 説明 | 例 |
|---|---|---|
| SaaS ベンダーまたは ISV | SaaS アプリケーションとコードを所有し、SaaS 製品を販売するエンティティ。 | Contoso Inc が販売する SaaS アプリケーション: Contoso Tickets。 |
| Tenant | SaaS ベンダーから購入した SaaS アプリケーションのインスタンス。 | Fourth Coffee Shop。 |
| SaaS 顧客管理者 | アプリケーション テナントを購入または管理するユーザー。 | Fourth Coffee Shop のオーナー、Joe。 |
| SaaS 顧客ユーザー | アプリケーション テナントを管理せずに利用するユーザーで、通常は SaaS 顧客管理者と同じ会社またはグループに属しています。 | Fourth Coffee Shop のイベント マネージャー Jill と、Fourth Coffee Shop の顧客である Susan。 |
| エンド ユーザー | SaaS 顧客管理者、SaaS 顧客ユーザー、または導入対象となるその他のユーザー タイプ。 これは、アプリケーションにサインインするユーザーを表す一般的な用語です。 | Joe、Jill、および Susan はすべてエンド ユーザーです (ISV の観点から)。 |
| フロントエンド アプリケーション | 任意のフロントエンド アプリケーション。 | オンボード & 管理アプリと SaaS アプリはどちらもフロントエンド アプリケーションです。 |
ワークフロー
SaaS 顧客管理者 は、 オンボード & 管理アプリでホストされているサイトに進みます。
"SaaS 顧客管理者" は、 ユーザー サインイン ワークフローを使用してサインインします。
"SaaS 顧客管理者" が、 オンボード フローを完了します。
SaaS 顧客管理者 が、 オンボード & 管理アプリ のテナント管理領域に移動し、新しく作成されたテナントに SaaS 顧客ユーザーを追加 します。
"SaaS 顧客ユーザー" は、"SaaS アプリケーション アプリ" に移動して、SaaS アプリケーションを利用します。
ユーザーのサインイン
ユーザーのサインイン ワークフローは次のステップで構成されています。
エンド ユーザー が フロントエンド アプリケーション に移動し、[ログイン] ボタンを選択します。
フロントエンド アプリケーション は、 ID プロバイダー によってホストされているサインイン ページに エンド ユーザーをリダイレクトします。
エンド ユーザー はアカウント情報を入力し、サインイン フォームを ID プロバイダーに送信します。
ID プロバイダーは、 エンド ユーザーの電子メール アドレスとオブジェクト ID を使用してPOST 要求を発行 して、アクセス許可とロールを取得します。
アクセス許可データ API は、 アクセス許可データ ストレージ内の エンド ユーザー の情報を検索し、その エンド ユーザーに割り当てられているアクセス許可とロールの一覧を返します。
ID プロバイダー が、アクセス許可とロールを JSON Web トークン (JWT) である ID トークンにカスタム要求として追加します。
ID プロバイダー は、 エンド ユーザー に ID トークンを返し、 フロントエンド アプリケーションへのリダイレクトを開始します。
エンド ユーザー は、 フロントエンド アプリケーション のサインイン エンドポイントにリダイレクトされ、ID トークンを提示します。
フロントエンド アプリケーション は、提示された ID トークンを検証します。
フロントエンド アプリケーション から正常なサインイン ページが返され、 エンド ユーザー がサインインするようになりました。
このサインイン フローのしくみに関する詳細については、 OpenID Connect プロトコルに関する記事を参照してください。
新しいテナントをオンボードする
テナントのオンボード ワークフローは、次の手順で構成されています。
SaaS 顧客管理者 は、 オンボード & 管理アプリ に移動し、サインアップ フォームを完了させます。
オンボード & 管理アプリ で、新しいテナントを作成するため テナント データ API に POST 要求が発行されます。
"テナント データ API" により、テナント データ ストレージに新しいテナントが作成されます。
"テナント データ API" により "アクセス許可データ API" に POST 要求が発行され、新しく作成されたテナントに "SaaS 顧客管理者" のアクセス許可が付与されます。
"アクセス許可データ API" により、"アクセス許可データ ストレージ" に新しいアクセス許可レコードが作成されます。
"アクセス許可データ API" が正常に返されます。
"テナント データ API" が正常に返されます。
オンボード & 管理アプリ で、 SaaS 顧客管理者に "テナント作成済み" のメール メッセージを送信するための POST 要求が メール通知プロバイダー に対して発行されます。
"メール通知プロバイダー" がメールを送信します。
"メール通知プロバイダー" が正常に返します。
オンボード & 管理アプリ で、新しく作成されたテナントへの JWT 要求が含まれるように SaaS 顧客管理者の ID トークンを更新する要求が ID プロバイダー に対して発行されます。
"ID プロバイダー" が、"SaaS 顧客管理者" のメール アドレスとオブジェクト ID を使用して POST 要求を発行 し、アクセス許可とロールを取得します。
"アクセス許可データ API" によって、"アクセス許可データ ストレージ" 内の "SaaS 顧客管理者" の情報が検索され、その "SaaS 顧客管理者" に割り当てられているアクセス許可とロールの一覧が返されます。
"ID プロバイダー" が、アクセス許可とロールを ID トークンにカスタム要求として追加します。
ID プロバイダー が、ID トークンを オンボード & 管理アプリに返します。
オンボード & 管理アプリ は、成功メッセージと新しい ID トークンを SaaS 顧客管理者に返します。
ユーザーをテナントに追加する
ユーザーのテナントへの追加ワークフローは、次のステップで構成されています。
SaaS 顧客管理者 は、オンボード & 管理アプリのテナント管理領域からテナントの一覧表示を要求します。
オンボード & 管理アプリ で、 SaaS 顧客管理者 のテナント一覧を取得するための GET 要求が テナント データ API に対して発行されます。
"テナント データ API" により、"SaaS 顧客管理者" が表示権限を持つテナントの一覧を取得するための GET 要求が "アクセス許可データ API" に対して発行されます。
"アクセス許可データ API" によって、テナントのアクセス許可の一覧が返されます。
"テナント データ API" により、テナント データ ストレージ内のテナント情報が検索され、受け取ったテナントのアクセス許可の一覧に基づいてテナント データの一覧が返されます。
オンボード & 管理アプリ は、テナント データの一覧を SaaS 顧客管理者に返します。
"SaaS 顧客管理者" は、一覧からテナントを選択して "SaaS 顧客ユーザー" を追加し、"SaaS 顧客ユーザー" のメール アドレスを入力します。
オンボード & 管理アプリ で、指定のテナントに SaaS 顧客ユーザー のアクセス許可を追加するための POST 要求が テナント データ API に対して発行されます。
"テナント データ API" により、"SaaS 顧客管理者" が指定のテナントに対する有効な JWT 要求を持ち、それに対するユーザーの書き込みアクセス許可を持っているかどうかの検証が行われます。
"テナント データ API" により、指定のテナントに "SaaS 顧客ユーザー" のアクセス許可を追加するための POST 要求が "アクセス許可データ API" に対して発行されます。
"アクセス許可データ API" により、指定のメール アドレスで "SaaS 顧客ユーザー" を検索するための GET 要求が "ID プロバイダー" に対して発行されます。
"ID プロバイダー" が、"SaaS 顧客ユーザー" のオブジェクト ID を返します。
"アクセス許可データ API" により、そのオブジェクト ID を使用して、指定のテナントの "SaaS 顧客ユーザー" の "アクセス許可データ ストレージ" にアクセス許可レコードが追加されます。
"アクセス許可データ API" が正常に返されます。
"テナント データ API" が正常に返されます。
オンボード & 管理アプリ で正常に返されます。
コンポーネント
このアーキテクチャでは、次の Azure サービスを使用します。
App Service を使用すると、インフラストラクチャを管理することなく、任意のプログラミング言語で Web アプリと API アプリを構築してホスティングすることができます。
Azure Active Directory B2C を使用すると、エンド ユーザー アプリケーションの ID とアクセスの管理を容易に行うことができます。
Azure SQL Database は、リレーショナル データ、空間データ、JSON、XML をサポートする汎用リレーショナル データベース マネージド サービスです。
Azure Logic Apps を使用すると、簡単な GUI ツールを使用して強力な統合をすばやく構築できます。
代替
代替選択肢の有効性は、SaaS アプリケーションでサポートする予定の テナント モデル によって大きく異なります。 このソリューションを実装する際に踏むことのできる代替アプローチの例を次に示します。
現在のソリューションでは、ID プロバイダーとして Azure Active Directory B2C を使用しています。 代わりに Microsoft Entra ID などの他の ID プロバイダーを使うこともできます。
セキュリティおよびコンプライアンスの要件を厳格化するため、サービス間通信にプライベート ネットワークを実装することも可能です。
サービス間で REST 呼び出しを使用する代わりに、サービス間メッセージング用の イベントドリブン アーキテクチャ スタイル を実装することができます。
考慮事項
これらの考慮事項は、ワークロードの品質を向上させるために従うことのできる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
このソリューションは、セキュリティ パラダイムとしての ID に依存しています。 Web アプリと API の認証と認可は、ユーザー ID トークン (JWT) の発行と検証の役割を担う Microsoft ID プラットフォームによって管理されます。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、 コスト最適化の柱の概要に関する記事をご覧ください。
このソリューションのコンポーネントは、その運用に多少のコストがかかりますが、ほとんどの Web アプリケーションと SaaS ソリューションで発生するコストはわずかです。 また、次のリソース設定を管理してコストをコントロールすることもできます。
アプリケーションを実行する App Service プランを、必要なスループットに合わせてスケーリングできます。 さらに、より高いスループットが必要な場合は、個別のプランで各アプリを実行できますが、結果として高いコストが発生することになります。 詳細については、「Azure App Service プランの概要」を参照してください。
Azure AD B2C には、Premium P1 と Premium P2 の 2 つの SKU が用意されています。 どちらの SKU にも、月間アクティブ ユーザー (MAU) の数に対する無料許容量が含まれますが、ユース ケースに必要な方を判断するには、各 SKU が提供する機能を評価する必要があります。 詳細については、「Microsoft Entra 外部 ID の価格」を参照してください。
Azure SQL には、自動スケーリング機能など、幅広いユース ケースに適合する購入モデルがいくつかあります。 データベースのサイズを正しく設定するには、独自のデータベースの使用状況を評価する必要があります。 詳細については、「Azure SQL Database の仮想コアと DTU ベースの購入モデルの比較」を参照してください。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
このアーキテクチャは、ほとんどの中規模から大規模なワークロードに容易に対応できるようスケーリングできる必要があります。 このアーキテクチャは主に Azure のプラットフォーム (PaaS) サービスを利用するものであるため、要件や負荷に応じてソリューションのスケールを調整するオプションが多く用意されています。
このシナリオのデプロイ
このシナリオをデプロイする場合は、GitHub の Azure SaaS 開発キット に関するページを参照してください。 これは、このアーキテクチャのデプロイ可能な参照実装です。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Landon Pierce | カスタマー エンジニア
その他の共同作成者:
- Chris Ayers | シニア カスタマー エンジニア
- John Downs | シニア カスタマー エンジニア
- LaBrina Loving | プリンシパル SVC エンジニアリング マネージャー
- Gary Moore | プログラマー/ライター
- Nick Pinheiro | シニア コンサルタント
- William Salazar | シニア カスタマー エンジニア
- Ali Sanjabi | シニア カスタマー エンジニア
- Arsen Vladimirskiy | プリンシパル カスタマー エンジニア
- Jason Young |プリンシパル SVC エンジニアリング マネージャー
次の手順
Azure で SaaS アプリケーションを構築するためのその他の推奨リソースを次に示します。
- Azure でのマルチテナント ソリューションの設計 - ベスト プラクティスについて説明します。
- Azure ランディング ゾーンの ISV に関する考慮事項
- Microsoft Azure Well-Architected Framework
- WingTips Tickets SaaS アプリケーション - データベース レイヤー内のさまざまなテナント モデル間のトレードオフの詳細を提供します。