SaaS 開発用のスターター Web アプリ

Azure App Service
Microsoft Entra 外部 ID
Azure SQL データベース
Azure Logic Apps
Azure Resource Manager

サービスとしてのソフトウェア (SaaS) は、考慮すべき点の多い複雑なトピックです。 Azure で SaaS ソリューションを構築する独立系ソフトウェア ベンダー (ISV) は、問題を解決し、次のような意思決定を行う必要があります。

  • どのテナント モデルを使用する必要があるか?
  • マルチテナント アーキテクチャで使用する ID ソリューションをどのように設定するか?
  • 新しい顧客のオンボードはどのように進めるか?

このアーキテクチャは、これらの質問の一部に回答し、SaaS の世界への出発点を提供することを目的としています。 このアーキテクチャは、幅広いシナリオに適応させることができます。

考えられるユース ケース

このアーキテクチャを使用できるユース ケースの例を次に示します。

  • SaaS ベースのビジネス モデルへの移行の一環として、完全なマルチテナントをサポートするように既存のアプリケーションを最新化する。
  • まったく新しい SaaS オファリングを開発する。
  • SaaS オファリングを他のクラウド サービスから Azure に移行する。

アーキテクチャ

Architecture diagram that shows the control plane, identity framework, and end-user S a a S application.

このアーキテクチャの 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 アプリはどちらもフロントエンド アプリケーションです。

Workflow

  1. SaaS 顧客管理者は、オンボードと管理アプリでホストされているサイトに進みます。

  2. "SaaS 顧客管理者" は、ユーザー サインイン ワークフローを使用してサインインします。

  3. "SaaS 顧客管理者" が、オンボード フローを完了します。

  4. SaaS 顧客管理者が、オンボードと管理アプリ のテナント管理領域に移動し、新しく作成されたテナントに SaaS 顧客ユーザー を追加します

  5. "SaaS 顧客ユーザー" は、"SaaS アプリケーション アプリ" に移動して、SaaS アプリケーションを利用します。

ユーザーのサインイン

ユーザーのサインイン ワークフローは次のステップで構成されています。

Sequence diagram that shows the sign-in process for a user.

  1. エンド ユーザーフロントエンド アプリケーションに移動し、[ログイン] ボタンを選択します。

  2. フロントエンド アプリケーションは、ID プロバイダーによってホストされているサインイン ページにエンド ユーザーをリダイレクトします。

  3. エンド ユーザーはアカウント情報を入力し、サインイン フォームを ID プロバイダーに送信します。

  4. ID プロバイダーは、エンド ユーザーの電子メール アドレスとオブジェクト ID を使用して POST 要求を発行して、アクセス許可とロールを取得します。

  5. アクセス許可データ API は、アクセス許可データ ストレージ内のエンド ユーザーの情報を検索し、そのエンド ユーザーに割り当てられているアクセス許可とロールの一覧を返します。

  6. ID プロバイダー が、アクセス許可とロールを JSON Web トークン (JWT) である ID トークンにカスタム要求として追加します。

  7. ID プロバイダーは、エンド ユーザーに ID トークンを返し、フロントエンド アプリケーションへのリダイレクトを開始します。

  8. エンド ユーザーは、フロントエンド アプリケーションのサインイン エンドポイントにリダイレクトされ、ID トークンを提示します。

  9. フロントエンド アプリケーションは、提示された ID トークンを検証します。

  10. フロントエンド アプリケーションから正常なサインイン ページが返され、エンド ユーザーがサインインするようになりました。

このサインイン フローのしくみに関する詳細については、OpenID Connect プロトコルに関する記事を参照してください。

新しいテナントをオンボードする

テナントのオンボード ワークフローは、次の手順で構成されています。

Sequence diagram that shows the process for tenant onboarding.

  1. SaaS 顧客管理者は、オンボードと管理アプリに移動し、サインアップ フォームを完了させます。

  2. オンボードと管理アプリで、新しいテナントを作成するためテナント データ API に POST 要求が発行されます。

  3. "テナント データ API" により、テナント データ ストレージに新しいテナントが作成されます。

  4. "テナント データ API" により "アクセス許可データ API" に POST 要求が発行され、新しく作成されたテナントに "SaaS 顧客管理者" のアクセス許可が付与されます。

  5. "アクセス許可データ API" により、"アクセス許可データ ストレージ" に新しいアクセス許可レコードが作成されます。

  6. "アクセス許可データ API" が正常に返されます。

  7. "テナント データ API" が正常に返されます。

  8. オンボードと管理アプリ で、SaaS 顧客管理者に "テナント作成済み" のメール メッセージを送信するための POST 要求がメール通知プロバイダーに対して発行されます。

  9. "メール通知プロバイダー" がメールを送信します。

  10. "メール通知プロバイダー" が正常に返します。

  11. オンボードと管理アプリで、新しく作成されたテナントへの JWT 要求が含まれるように SaaS 顧客管理者の ID トークンを更新する要求が ID プロバイダー に対して発行されます。

  12. "ID プロバイダー" が、"SaaS 顧客管理者" のメール アドレスとオブジェクト ID を使用して POST 要求を発行し、アクセス許可とロールを取得します。

  13. "アクセス許可データ API" によって、"アクセス許可データ ストレージ" 内の "SaaS 顧客管理者" の情報が検索され、その "SaaS 顧客管理者" に割り当てられているアクセス許可とロールの一覧が返されます。

  14. "ID プロバイダー" が、アクセス許可とロールを ID トークンにカスタム要求として追加します。

  15. ID プロバイダー が、ID トークンをオンボードと管理アプリに返します。

  16. オンボードと管理アプリは、成功メッセージと新しい ID トークンを SaaS 顧客管理者に返します。

ユーザーをテナントに追加する

ユーザーのテナントへの追加ワークフローは、次のステップで構成されています。

Sequence diagram that shows the addition of a new user to a tenant.

  1. SaaS 顧客管理者は、オンボードと管理アプリのテナント管理領域からテナントの一覧表示を要求します。

  2. オンボードと管理アプリで、SaaS 顧客管理者のテナント一覧を取得するための GET 要求がテナント データ API に対して発行されます。

  3. "テナント データ API" により、"SaaS 顧客管理者" が表示権限を持つテナントの一覧を取得するための GET 要求が "アクセス許可データ API" に対して発行されます。

  4. "アクセス許可データ API" によって、テナントのアクセス許可の一覧が返されます。

  5. "テナント データ API" により、テナント データ ストレージ内のテナント情報が検索され、受け取ったテナントのアクセス許可の一覧に基づいてテナント データの一覧が返されます。

  6. オンボードと管理アプリは、テナント データの一覧を SaaS 顧客管理者に返します。

  7. "SaaS 顧客管理者" は、一覧からテナントを選択して "SaaS 顧客ユーザー" を追加し、"SaaS 顧客ユーザー" のメール アドレスを入力します。

  8. オンボードと管理アプリで、指定のテナントに SaaS 顧客ユーザーのアクセス許可を追加するための POST 要求がテナント データ API に対して発行されます。

  9. "テナント データ API" により、"SaaS 顧客管理者" が指定のテナントに対する有効な JWT 要求を持ち、それに対するユーザーの書き込みアクセス許可を持っているかどうかの検証が行われます。

  10. "テナント データ API" により、指定のテナントに "SaaS 顧客ユーザー" のアクセス許可を追加するための POST 要求が "アクセス許可データ API" に対して発行されます。

  11. "アクセス許可データ API" により、指定のメール アドレスで "SaaS 顧客ユーザー" を検索するための GET 要求が "ID プロバイダー" に対して発行されます。

  12. "ID プロバイダー" が、"SaaS 顧客ユーザー" のオブジェクト ID を返します。

  13. "アクセス許可データ API" により、そのオブジェクト ID を使用して、指定のテナントの "SaaS 顧客ユーザー" の "アクセス許可データ ストレージ" にアクセス許可レコードが追加されます。

  14. "アクセス許可データ API" が正常に返されます。

  15. "テナント データ API" が正常に返されます。

  16. オンボードと管理アプリ で正常に返されます。

コンポーネント

このアーキテクチャでは、次の 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 によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

その他の共同作成者:

次の手順

Azure で SaaS アプリケーションを構築するためのその他の推奨リソースを次に示します。