Azure App Service とは、強力な Web アプリケーション ホスティング プラットフォームです。 App Service インフラストラクチャ上に構築された Azure Functions を使用すると、サーバーレスおよびイベント駆動型のコンピューティング ワークロードを簡単に構築できます。 マルチテナント ソリューションでは、両方のサービスが頻繁に使用されています。
マルチテナント機能をサポートする Azure App Service と Azure Functions の機能
Azure App Service と Azure Functions には、マルチテナント機能をサポートする多くの機能が含まれています。
カスタム ドメイン名
Azure App Service を使用すると、ワイルドカード DNS の使用と、独自のワイルドカード TLS 証明書の追加が可能になります。 テナント固有のサブドメインを使用しているときに、ワイルドカード DNS 証明書と TLS 証明書を使用すると、多数のテナントに簡単にソリューションをスケーリングできます。このとき、新しいテナントごとに手動で再構成する必要はありません。
テナント固有のカスタム ドメイン名を使用すると、アプリへの追加が必要になるカスタム ドメイン名が多数になることがあります。 特に個別の TLS 証明書が必要になるときには、多数のカスタム ドメイン名を管理することが面倒になる可能性があります。 App Service では マネージド TLS 証明書を使用できます。これにより、カスタム ドメインを使用するときに必要な作業が削減されます。 ただし、1 つのアプリに適用できるカスタム ドメインの数など、考慮すべき制限があります。
Azure Front Door との統合
App Service と Azure Functions は、Azure Front Door と統合することで、ソリューションのインターネットに接合するコンポーネントとして機能します。 Azure Front Door を使用すると、Web アプリケーション ファイアウォール (WAF) とエッジ キャッシュを追加できるようになります。また、その他のパフォーマンス最適化が提供されます。 トラフィック フローは、ビジネス要件や技術的要件の変化に応じて、さまざまなバックエンドにトラフィックが転送されるように簡単に再構成できます。
マルチテナント アプリに使用している Azure Front Door は、カスタム ドメイン名の管理と TLS 接続の終端に使用できます。 App Service アプリケーションは、単一のホスト名で構成されるようになり、すべてのトラフィックは、そのアプリケーションを通過するようになります。これにより、複数の場所でカスタム ドメイン名を管理することを回避できるようになります。
上記の例に示すように、Azure Front Door は要求の Host ヘッダーを変更するように構成できます。 クライアントから送信された元の Host ヘッダーは、X-Forwarded-Host ヘッダーによって伝達されます。アプリケーション コードでは、このヘッダーを使用することで適切なテナントに要求をマップできるようになります。
警告
アプリケーションが Cookie またはリダイレクト応答を送信する場合は、特別な配慮が必要です。 要求の Host ヘッダーの変更により、そうした応答が無効になることがあります。 詳細については、ホスト名を維持するためのベスト プラクティスに関するページを参照してください。
プライベート エンドポイントまたは App Service アクセス制限を使用すると、トラフィックはアプリに到達する前に確実に Front Door を通過するようになります。
マルチテナント ソリューションで Azure Front Door を使用する方法については、「マルチテナント ソリューションで Azure Front Door を使用する」をご覧ください。
認証と権限承認
Azure App Service では、アプリの代理として認証トークンを検証できます。 App Service が要求を受信すると、次の各条件が満たされているかどうかが確認されます。
- 要求にトークンが含まれている
- トークンが有効である。
- 要求が承認されている
いずれの条件も満たされていない場合は、App Service から要求をブロックしたり、ユーザーを ID プロバイダーにリダイレクトしてサインインできるようにすることができます。
テナントが ID システムとして Microsoft Entra ID を使っている場合は、/common エンドポイントを使ってユーザー トークンを検証するように Azure App Service を構成できます。 こうすると、ユーザーの Microsoft Entra テナントとは関係なく、それらのトークンが検証され、承認されます。
Azure App Service は、コンシューマーの認証のために、Azure AD B2C と統合することもできます。
詳細情報:
アクセスの制限
アプリへのトラフィックは、アクセス制限を使用することで制限できます。 これは、アプリへの接続を許可する IP アドレスの範囲や仮想ネットワークを指定するために使用できます。
マルチテナント ソリューションの取扱い時には、アクセス制限ルールの最大数に注意してください。 たとえば、すべてのテナントに対するアクセス制限ルールを作成する必要がある場合は、許容されているルールの最大数を超過する可能性があります。 多数のルールが必要な場合は、Azure Front Door のようなリバース プロキシのデプロイを検討してください。
分離モデル
Azure App Service または Azure Functions を使用したマルチテナント システムの取扱い時には、使用する分離のレベルについて決定する必要があります。 マルチテナント ソリューションに対して考慮されるテナント モデルと、マルチテナント ソリューションでのコンピューティングに対するアーキテクチャ アプローチに示されたガイダンスを参考にして、目的のシナリオに最適な分離モデルを選択してください。
Azure App Service と Azure Functions の取扱い時には、次の主要概念について注意する必要があります。
- Azure App Service では、プランはホスティング インフラストラクチャを表します。 アプリは、そのインフラストラクチャで実行される単一のアプリケーションを表します。 単一のプランに複数のアプリをデプロイできます。
- Azure Functions では、ホスティングとアプリケーションの分離もされますが、Azure Functions にスケーリングの管理を任せるエラスティック ホスティングには追加のホスティング オプションを使用できます。 わかりやすくするために、この記事全体を通じてホスティング インフラストラクチャをプランと呼ぶことにします。これは、ここで説明する原則が、どのホスティング モデルを使用するかに関係なく、App Service と Azure Functions の両方に当てはまるからです。
次の表に、Azure App Service と Azure Functions の主なテナント分離モデル間の相違点を要約します。
| 考慮事項 | 共有アプリ | 共有プランによるテナントごとのアプリ | テナントごとのプラン |
|---|---|---|---|
| 構成の分離 | 低 | 中。 アプリ レベルの設定はテナント専用、プラン レベルの設定は共有される | 高。 各テナントは独自の構成を持つことができる |
| パフォーマンスの分離 | 低 | 低から中。 近隣の騒音問題の影響を受ける可能性がある | 高 |
| デプロイの複雑性 | 低 | Medium | 高 |
| 操作の複雑さ | 低 | 高 | 高 |
| リソース コスト | 低 | アプリケーションに応じて低から高 | 高 |
| シナリオ例 | 共有アプリケーション層を備えた大規模なマルチテナント ソリューション | テナントを意識していないアプリケーションを Azure に移行し、ある程度のコスト効率を得ることができる | シングルテナント アプリケーション層 |
共有アプリ
1 つのプランに共有アプリケーションをデプロイし、すべてのテナントに共有アプリケーションを使用することができます。
このオプションは、最もコスト効果が高くなる傾向があり、管理するリソースが少なくなるために必要な運用オーバーヘッドが最小になります。 負荷や需要に基づいてプラン全体をスケーリングできます。また、プランを共有するすべてのテナントは、許容量の増加による利益を得られるようになります。
App Service のクオータと制限 (単一のアプリに追加できるカスタム ドメインの最大数やプランにプロビジョニングできるインスタンスの最大数など) に注意することが重要です。
このモデルを使用できるようにするために、アプリケーション コードはマルチテナント対応にする必要があります。
共有プランによるテナントごとのアプリ
複数のテナント間でプランを共有するようにしながら、テナントごとに個別のアプリをデプロイすることもできます。 これにより、テナントごとの論理分離が提供されます。このアプローチには、次の利点があります。
- コスト効果: ホスティング インフラストラクチャを共有することで、一般にテナントごとの全体的なコストを低減できます。
- 構成の分離: テナントごとのアプリには、それ専用のドメイン名、TLS 証明書、アクセス制限、および適用されるトークン承認ポリシーを割り当てることができます。
- アップグレードの分離: テナントごとのアプリケーション バイナリは、同じプランの別のアプリとは無関係にアップグレードできます。
ただし、プランのコンピューティング リソースが共有されているため、アプリはノイジー ネイバー問題にさらされる可能性があります。 さらに、単一のプランにデプロイ可能なアプリの数は制限されています。
Note
異なるテナントにデプロイ スロットを使用しないでください。 スロットは、リソースの分離を実現しません。 これは、ブルーグリーン デプロイやカナリア ロールアウト戦略など、短期間に複数バージョンのアプリを実行する必要があるときのデプロイ シナリオに向けたものです。
テナントごとのプラン
最強の分離レベルは、テナントごとに専用のプランをデプロイすることです。 この専用プランでは、テナントは、そのプランに割り当てられたすべてのサーバー リソースを確保します。
このアプローチによって、テナントごとにパフォーマンスの分離を実現するようにソリューションをスケーリングできるようになり、ノイジー ネイバー問題を回避できるようになります。 ただし、複数のテナントでリソースが共有されないためにコストも高くなります。 さらに、単一の Azure リソース グループにデプロイ可能なプランの最大数についても考慮する必要があります。
API のホスト
API は Azure App Service と Azure Functions の両方でホストできます。 プラットフォームの選択は、必要になる特定の機能セットとスケーリング オプションによって異なります。
どのプラットフォームを API のホストに使用するにしても、API アプリケーションの前面で Azure API Management を使用することを検討してください。 API Management には、マルチテナント ソリューションに役立てられる多数の機能があります。たとえば、次の機能が含まれています。
- すべての認証に対応する一元化されたポイント。 これには、トークン要求などの要求メタデータからのテナント ID の判別が含まれることがあります。
- 異なる API バックエンドへの要求のルーティング。要求のテナント ID に基づいて実行できます。 これは、独自の独立した API アプリケーションがあり、すべての要求に対応する単一の API URL が必要な場合に、複数のデプロイ スタンプをホストするときに役立ちます。
ネットワークとマルチテナント機能
IP アドレス
マルチテナント アプリケーションの多くは、データを送信するためにテナントのオンプレミス ネットワークに接続する必要があります。
既知の静的 IP アドレスまたは既知の静的 IP アドレスのセットからの送信トラフィックを送信する必要がある場合は、NAT Gateway の使用について検討してください。 マルチテナント ソリューションで NAT ゲートウェイを使用する方法について詳しくは、「マルチテナント機能に関する Azure NAT Gateway の考慮事項」をご覧ください。 App Service では、NAT Gateway との統合方法に関するガイダンスを提供しています。
静的な送信 IP アドレスが不要でも、送信トラフィックにアプリケーションが使用する IP アドレスの確認が必要になるときがある場合は、App Service デプロイの現在の IP アドレスをクエリすることができます。
Quotas (クォータ)
App Service 自体がマルチテナント サービスであるため、共有リソースの使用方法について注意する必要があります。 ネットワークは、特に注意が必要な領域です。これは、アプリケーションが送信および受信のネットワーク接続を操作する方法に影響を与える制限があるためです。たとえば、送信元ネットワーク アドレス変換 (SNAT) や TCP ポートの制限などがあります。
アプリケーションが多数のデータベースや外部サービスに接続する場合、そのアプリは SNAT ポート不足の危険にさらされることがあります。 一般に、SNAT ポート不足は、コードで TCP 接続が適切に再利用されていないことを示しています。マルチテナント ソリューションであっても接続の再利用に対して推奨されるプラクティスに従っていることが必要です。
ただし、一部のマルチテナント ソリューションでは、適切なコーディング プラクティスに従っていたとしても、個別の IP アドレスへの送信接続の数によって SNAT ポート不足が発生することがあります。 これらのシナリオでは、次のいずれかのオプションを検討してください。
- NAT Gateway をデプロイして、アプリケーションで使用できる SNAT ポートの数を増やします。 マルチテナント ソリューションで NAT ゲートウェイを使用する方法について詳しくは、「マルチテナント機能に関する Azure NAT Gateway の考慮事項」をご覧ください。
- ロード バランサーの制限をバイパスするには、Azure サービスに接続するときにサービス エンドポイントを使用します。
こうしたコントロールを実施していたとしても、多数のテナントによる制限に達することがあるため、追加の App Service プランまたはデプロイ スタンプにスケーリングすることを計画する必要があります。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア
その他の共同作成者:
- Thiago Almeida | プリンシパル プログラム マネージャー、Azure Functions
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
「マルチテナント ソリューションの設計者と開発者向けのリソース」を確認します。