SaaS 開発用のスターター Web アプリ
サービスとしてのソフトウェア (SaaS) は、考慮すべき点の多い複雑なトピックです。 Azure で SaaS ソリューションを構築する独立系ソフトウェア ベンダー (ISV) は、問題を解決し、次のような意思決定を行う必要があります。
- どの テナント モデル を使用する必要がありますか?
- マルチテナント アーキテクチャで使用する ID ソリューションをどのように設定するか?
- 新しい顧客のオンボードはどのように進めるか?
このアーキテクチャは、これらの質問の一部に回答し、SaaS の世界への出発点を提供することを目的としています。 このアーキテクチャは、幅広いシナリオに適応させることができます。
考えられるユース ケース
このアーキテクチャを使用できるユース ケースの例を次に示します。
- SaaS ベースのビジネス モデルへの移行の一環として、完全なマルチテナントをサポートするように既存のアプリケーションを最新化する。
- まったく新しい SaaS オファリングを開発する。
- SaaS オファリングを他のクラウド サービスから Azure に移行する。
アーキテクチャ
このアーキテクチャの PowerPoint ファイル をダウンロードします。
用語
次の表では、この記事に記載されている用語について説明します。
| 期間 | 説明 | 例 |
|---|---|---|
| SaaS ベンダーまたは ISV | SaaS アプリケーションとコードを所有し、SaaS 製品を販売するエンティティ。 | Contoso Inc が販売する SaaS アプリケーション: Contoso Tickets。 |
| テナント | 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 要求を発行して、アクセス許可とロールを取得します。
Permission データ API は、アクセス許可データ ストレージ内のエンド ユーザーの情報を検索し、そのエンド ユーザーに割り当てられているアクセス許可とロールの一覧を返します。
ID プロバイダーは、アクセス許可とロールをカスタム要求として、JSON Web トークン (JWT) である ID トークンに追加します。
ID プロバイダーは、エンド ユーザーに ID トークンを返し、フロントエンド アプリケーションへのリダイレクトを開始します。
エンド ユーザーは、フロントエンド アプリケーションのサインイン エンドポイントにリダイレクトされ、ID トークンを提示します。
フロントエンド アプリケーションは、提示された ID トークンを検証します。
フロントエンド アプリケーションから正常なサインイン ページが返され、エンド ユーザーがサインインするようになりました。
このサインイン フローのしくみの詳細については、「 OpenID Connect プロトコル」を参照してください。
新しいテナントをオンボードする
テナントのオンボード ワークフローは、次の手順で構成されています。
SaaS 顧客管理者は、オンボードと管理アプリに移動し、サインアップ フォームを完了します。
オンボードおよび管理アプリは、テナント データ API に POST 要求を発行して新しいテナントを作成します。
テナント データ API は、テナント データ ストレージに新しいテナントを作成します。
テナント データ API は、アクセス許可データ API に POST 要求を発行して、新しく作成されたテナントに SaaS 顧客の管理者アクセス許可を付与します。
Permission データ API は、Permission データ ストレージに新しいアクセス許可レコードを作成します。
"アクセス許可データ API" が正常に返されます。
テナント データ API が正常に返されます。
オンボードおよび管理アプリは、"テナントが作成した" 電子メール メッセージを SaaS 顧客管理者に送信するために、電子メール通知プロバイダーに POST 要求を発行します。
電子メール通知プロバイダーが電子メールを送信します。
"メール通知プロバイダー" が正常に返します。
オンボードおよび管理アプリは、新しく作成されたテナントへの JWT 要求が含まれるように、SaaS 顧客管理者の ID トークンを更新するための要求を ID プロバイダーに発行します。
ID プロバイダーは、SaaS 顧客管理者の電子メール アドレスとオブジェクト ID を使用して POST 要求を発行して、アクセス許可とロールを取得します。
アクセス許可データ API は、アクセス許可データ ストレージで SaaS 顧客管理者の情報を検索し、SaaS 顧客管理者に割り当てられたアクセス許可とロールの一覧を返します。
ID プロバイダーは、アクセス許可とロールをカスタム要求として ID トークンに追加します。
ID プロバイダーは、ID トークンをオンボードおよび管理アプリに返します。
オンボード管理アプリは、成功メッセージと新しい ID トークンを SaaS 顧客管理者に返します。
ユーザーをテナントに追加する
ユーザーのテナントへの追加ワークフローは、次のステップで構成されています。
SaaS 顧客管理者は、オンボーディング & 管理アプリのテナント管理領域からテナントの一覧を表示するように要求します。
オンボードおよび管理アプリは、テナント データ API に GET 要求を発行して、SaaS 顧客管理者のテナントの一覧を取得します。
テナント データ API は、アクセス許可データ API に GET 要求を発行して、SaaS 顧客管理者が表示するアクセス権を持つテナントの一覧を取得します。
アクセス許可データ API は、テナントのアクセス許可の一覧を返します。
"テナント データ API" により、テナント データ ストレージ内のテナント情報が検索され、受け取ったテナントのアクセス許可の一覧に基づいてテナント データの一覧が返されます。
オンボードと管理アプリは、テナント データの一覧を SaaS 顧客管理者に返します。
SaaS 顧客管理者は、一覧からテナントを選択して SaaS 顧客ユーザーを追加し、SaaS 顧客ユーザーのメール アドレスを入力します。
オンボードおよび管理アプリは、テナント データ API に POST 要求を発行して、指定されたテナントの SaaS 顧客ユーザーのアクセス許可を追加します。
テナント データ API は、SaaS 顧客管理者が指定されたテナントに対する有効な JWT 要求を持ち、それに対するユーザーの書き込みアクセス許可を持っていることを確認します。
テナント データ API は、アクセス許可データ API に POST 要求を発行して、指定されたテナントの SaaS 顧客ユーザーのアクセス許可を追加します。
アクセス許可データ API は、指定された電子メール アドレスで SaaS 顧客ユーザーを検索する GET 要求を ID プロバイダーに発行します。
ID プロバイダーは、SaaS 顧客ユーザーのオブジェクト ID を返します。
Permission データ 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 の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「 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 External ID の価格に関するページを参照してください。
Azure SQL には、自動スケーリング機能など、幅広いユース ケースに適合する購入モデルがいくつかあります。 データベースのサイズを正しく設定するには、独自のデータベースの使用状況を評価する必要があります。 詳細については、「 Azure SQL Database の仮想コアと DTU ベースの購入モデルの比較」を参照してください。
パフォーマンス効率
パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、 パフォーマンス効率のデザイン レビュー チェックリストを参照してください。
このアーキテクチャは、ほとんどの中規模から大規模なワークロードに容易に対応できるようスケーリングできる必要があります。 このアーキテクチャは主に Azure のプラットフォーム (Platform as a Service (PaaS)) サービスを利用するものであるため、要件や負荷に応じてソリューションのスケールを調整するオプションが多く用意されています。
このシナリオのデプロイ
このシナリオをデプロイする場合は、GitHub の Azure SaaS Dev Kit を参照してください。 これは、このアーキテクチャのデプロイ可能な参照実装です。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- ランドン・ピアース |カスタマー エンジニア
その他の共同作成者:
- Chris Ayers |シニア カスタマー エンジニア
- ジョン・ダウンズ |シニア カスタマー エンジニア
- ラブリナ愛 | プリンシパル SVC エンジニアリング マネージャー
- ゲイリー・ムーア |プログラマ/ライター
- ニック・ピニェイロ |シニア コンサルタント
- ウィリアム・サラザール |シニア カスタマー エンジニア
- アリ・サンジャビ |シニア カスタマー エンジニア
- アルセン・ウラジミルスキー |プリンシパル カスタマー エンジニア
- ジェイソン・ヤング |プリンシパル SVC エンジニアリング マネージャー
次の手順
Azure で SaaS アプリケーションを構築するためのその他の推奨リソースを次に示します。
- Azure でマルチテナント ソリューションを設計する - ベスト プラクティスについて説明します。
- Azure ランディング ゾーンの ISV に関する考慮事項
- Microsoft Azure Well-Architected Framework
- WingTips Tickets SaaS アプリケーション - データベース レイヤー内のさまざまなテナント モデル間のトレードオフに関する詳細を提供します。