マルチテナント ソリューションのテナントに要求をマップする

Azure

要求がアプリケーションに到着するたびに、要求を行っている テナントであるテナント コンテキストを決定する必要があります。 異なる地理的リージョンでホストされる可能性があるテナント固有のインフラストラクチャがある場合は、テナントへの受信要求を照合する必要があります。 次に、次に示すように、そのテナントのリソースをホストする物理インフラストラクチャに要求を転送する必要があります。

多くのマルチテナント アプリケーションにも、ユーザー ベースのアクセス許可があります。 テナント マッピングは別のアクティビティです。 要求を行っているユーザーと、そのユーザーが作業しているテナントの両方を知っている必要があります。

この記事では、要求を適切なテナントにマップすることを検討できるアプローチと、そのアプローチに関連するトレードオフについて、技術的な意思決定者向けのガイダンスを提供します。

注

このページでは、ほとんどの場合、Web サイトや API などの HTTP ベースのアプリケーションについて説明します。 ただし、同じ基本原則の多くは、他の通信プロトコルを使用するマルチテナント アプリケーションに適用されます。

テナントを識別する方法

受信要求のテナントを識別するには、複数の方法があります。 各方法では、受信要求の一部の側面を調べる必要があります。

ドメイン名

テナント固有のドメイン名またはサブドメイン名を使用する場合、Host ヘッダー、X-Forwarded-Host ヘッダー、または各要求の元のホスト名を含む別の HTTP ヘッダーを使用して、要求をテナントに簡単にマップできる可能性があります。

ただし、次の点を考慮してください。

• サービスへのアクセスに使用するドメイン名をユーザーが知る方法
• ランディング ページやログイン ページなど、すべてのテナントが使用する中央のエントリ ポイントはありますか。 その場合、ユーザーは、使用しているテナントをどのように選択しますか?
• 承認トークンなど、テナントのリソースへのアクセスを確認するために使用しているその他の情報は何ですか? 承認トークンにはテナント固有のドメイン名が含まれていますか?

HTTP 要求のプロパティ

テナント固有のドメイン名を使用しない場合でも、HTTP 要求の側面を使用して、特定の要求の対象となるテナントを識別できる場合があります。 たとえば、テナント名を tailwindtradersとして識別する HTTP 要求があるとします。 これは、次のいずれかの方法を使用して伝達される場合があります。

• 。
• URL 内のクエリ文字列 (https://contoso.com/app?tenant=tailwindtradersなど)。
• 。

重要

カスタム HTTP 要求ヘッダーは、WEB ブラウザーから HTTP GET 要求が発行される場合や、要求が一部の種類の Web プロキシによって処理される場合には役立ちません。 GET 操作には、カスタム HTTP ヘッダーを使用する必要があるのは、API を構築している場合、または要求を発行するクライアントを制御していて、ヘッダーを変更または削除する可能性のある Web プロキシが要求処理チェーンに含まれていない場合のみです。

この方法を使用する場合は、次の質問を考慮する必要があります。

• ユーザーはサービスにアクセスする方法を知っていますか? たとえば、クエリ文字列を使用してテナントを識別する場合、中央のランディング ページでは、クエリ文字列を追加してユーザーを適切なテナントのページに誘導する必要がありますか。
• ランディング ページやログイン ページなど、すべてのテナントが使用する中央のエントリ ポイントはありますか? その場合、ユーザーはアクセスする必要があるテナントをどのように選択しますか?
• アプリケーションは API を提供していますか? たとえば、Web アプリケーションはシングルページ アプリケーション (SPA) か、API バックエンドを持つモバイル アプリケーションですか? その場合は、 API ゲートウェイ または リバース プロキシ を使用してテナント マッピングを実行できる場合があります。

トークン要求

多くのアプリケーションでは、OAuth 2.0 や SAML などのクレーム ベースの認証と承認プロトコルが使用されます。 これらのプロトコルは、クライアントに承認トークンを提供します。 トークン には、クライアント アプリケーションまたはユーザーに関する情報の一部であるクレームのセットが含まれています。 要求は、ユーザーのメール アドレスなどの情報を伝達するために使用できます。 その後、システムにユーザーのメール アドレスを含め、ユーザーからテナントへのマッピングを検索し、要求を適切なデプロイに転送できます。 または、ID システムにテナント マッピングを含め、テナント ID 要求をトークンに追加することもできます。

要求を使用して要求をテナントにマップする場合は、次の質問を考慮する必要があります。

• 要求を使用してテナントを識別しますか? どの要求を使用しますか?
• ユーザーを複数のテナントのメンバーにすることはできますか? これが可能な場合、ユーザーは特定の要求に対して操作するテナントをどのように選択しますか?
• すべてのテナントに対して中央認証と承認システムはありますか? そうでない場合、すべてのトークン機関が一貫したトークンと要求を発行するようにするにはどうすればよいですか?

API キー

多くのアプリケーションで API が公開されています。 これらは、組織内での内部使用、またはパートナーや顧客による外部使用の場合があります。 API の一般的な認証方法は、 API キーを使用することです。 API キーは各要求で提供されます。 キーが発行されたテナント ID を記録した場合は、キーが使用されたときにテナント ID を検索できます。

注

API キーは、手動で作成および管理する必要があり、有効期間が長く、頻繁に再利用されるため、およびクレームが含まれていないため、高レベルのセキュリティを提供しません。 より最新で安全な方法は、OAuth 2.0 や OpenID Connect などの有効期間の短いトークンでクレームベースの承認メカニズムを使用することです。

API キーは、いくつかの方法で生成できます。 2 つの一般的な方法を次に示します。

• 暗号化されたランダムな値を生成し、テナント ID と共に参照テーブルに格納します。 要求が受信されると、システムは参照テーブルで API キーを検索し、テナント ID と一致します。
• テナント ID を含む意味のある文字列を作成します。 HMAC などのアプローチを使用して、キーにデジタル署名します。 各要求を処理するときは、署名を確認し、テナント ID を抽出します。

次の質問について考えてみましょう。

• API キーを生成して発行する方法
• API クライアントが API キーを安全に受け取って格納する方法
• 一定期間後に API キーの有効期限が切れる必要がありますか? ダウンタイムを発生させることなく、クライアントの API キーをどのようにローテーションしますか?
• 顧客が生成した API キーは、API に適切なレベルのセキュリティを提供しますか?

注

API キーはパスワードと同じではありません。 API キーはシステムによって生成される必要があり、各 API キーを 1 つのテナントに一意にマップできるように、すべてのテナントで一意である必要があります。 Azure API Management などの API ゲートウェイでは、API キーの生成と管理、受信要求のキーの検証、個々の API サブスクライバーへのキーのマップを行うことができます。

[クライアント証明書]

クライアント証明書認証 (相互 TLS (mTLS) とも呼ばれる) は、サービス間通信や、認証されていないユーザーが使用する無人デバイスまたはキオスクでよく使用されます。 クライアント証明書は、クライアントを認証するための安全な方法を提供します。 トークンと要求と同様に、クライアント証明書は、テナントを決定するために使用できる 属性 を提供します。 たとえば、証明書の 件名 にユーザーの電子メール アドレスが含まれている場合があります。このアドレスを使用してテナントを検索できます。

テナント マッピングにクライアント証明書を使用する場合は、次の点を考慮してください。

• サービスによって信頼されているクライアント証明書を安全に発行して更新するにはどうすればよいですか? クライアント証明書は、証明書の管理と発行に特別なインフラストラクチャを必要とするため、操作が複雑になる場合があります。 不適切に処理された場合、これらの複雑さによって、セキュリティが増えるのではなく 、セキュリティが低下 する可能性があります。
• クライアント証明書は、最初のログイン要求にのみ使用されるか、サービスへのすべての要求にアタッチされますか?
• 多数のクライアントがある場合、証明書の発行と管理のプロセスは管理できなくなりますか?
• クライアント証明書とテナントの間のマッピングはどのように実装しますか?

リバース プロキシ

リバース プロキシ (アプリケーション プロキシとも呼ばれます) を使用して、HTTP 要求をルーティングできます。 リバース プロキシは、イングレス エンドポイントからの要求を受け入れ、多数のバックエンド エンドポイントのいずれかに要求を転送できます。 リバース プロキシは、要求情報の一部間のマッピングを実行し、アプリケーション インフラストラクチャからタスクをオフロードできるため、マルチテナント アプリケーションに役立ちます。

多くのリバース プロキシでは、要求のプロパティを使用して、テナントのルーティングに関する決定を行うことができます。 宛先ドメイン名、URL パス、クエリ文字列、HTTP ヘッダー、要求本文のトークンまたは一部内の要求を検査できます。

Azure では、次の一般的なリバース プロキシが使用されます。

• Azure Front Door は、グローバル ロード バランサーと Web アプリケーション ファイアウォールです。 Microsoft グローバル エッジ ネットワークを使用して、高速でセキュリティで保護された高度にスケーラブルな Web アプリケーションを作成します。 ルール セットを使用してテナント識別子を抽出し、要求の別の部分に配置できます。
• Azure Application Gateway は、バックエンド サービスと同じ物理リージョンにデプロイするマネージド Web トラフィック ロード バランサーです。
• Azure API Management は API トラフィック用に最適化されています。 Azure API Management には、要求からテナント情報を抽出するための柔軟性が高い包括的な ポリシー エンジン が用意されています。
• 商用およびオープンソースのテクノロジ (自分でホストする) には、nginx、Traefik、HAProxy が含まれます。

要求の検証

アプリケーションで、受信した要求がテナントに対して承認されていることを検証することが重要です。 たとえば、アプリケーションでカスタム ドメイン名を使用して要求をテナントにマップする場合、アプリケーションは、アプリケーションが受信した各要求がそのテナントに対して承認されていることを確認する必要があります。 要求にドメイン名またはその他のテナント識別子が含まれている場合でも、アクセス権を自動的に付与する必要があるわけではありません。 OAuth 2.0 を使用する場合は、 対象ユーザー と スコープ の要求を調べることで検証を実行します。

注

これは、Microsoft Azure Well-Architected Framework のゼロ トラスト セキュリティ設計原則の一部です。

要求の検証を実装する場合は、次の点を考慮する必要があります。

• アプリケーションに対するすべての要求をどのように承認しますか? 要求を物理インフラストラクチャにマップするために使用する方法に関係なく、要求を承認する必要があります。
• すべての検証ロジックを自分で実装する代わりに、信頼された、広く使用され、よく維持されている認証と承認フレームワークとミドルウェアを使用します。 たとえば、トークン署名検証ロジックやクライアント証明書暗号化ライブラリを構築しないでください。 代わりに、検証およびテストされたアプリケーション プラットフォーム (または既知の信頼済みパッケージ) の機能を使用してください。

[パフォーマンス]

テナント マッピング ロジックは、アプリケーションに対するすべての要求で実行される可能性があります。 ソリューションの拡大に合わせて、テナント マッピング プロセスがどの程度適切にスケーリングされるかを検討します。 たとえば、テナント マッピングの一部としてデータベース テーブルに対してクエリを実行した場合、データベースは大量の負荷をサポートしますか? テナント マッピングでトークンの暗号化を解除する必要がある場合、計算要件は時間の経過と同時に高くなりすぎますか? トラフィックが非常に控えめであれば、全体的なパフォーマンスに影響を与える可能性はありません。 ただし、大規模なアプリケーションがある場合、このマッピングに伴うオーバーヘッドが大きくなる可能性があります。

セッション Cookie

テナント マッピング ロジックのパフォーマンス オーバーヘッドを減らす方法の 1 つは、 セッション Cookie を使用することです。 すべての要求でマッピングを実行するのではなく、各セッションの最初の要求についてのみ情報を計算することを検討してください。 その後、アプリケーションはセッション Cookie をクライアントに提供します。 クライアントはセッション Cookie をサービスに渡し、そのセッション内の後続のすべてのクライアント要求を受け取ります。

注

Azure の多くのネットワークおよびアプリケーション サービスでは、セッション Cookie を発行できます。

次の質問について考えてみましょう。

• セッション Cookie を使用して、要求をテナントにマッピングするオーバーヘッドを減らすことができますか?
• 各テナントの物理デプロイに要求をルーティングするには、どのようなサービスを使用しますか? これらのサービスは Cookie ベースのセッションをサポートしていますか?

テナントの移行

テナントは、多くの場合、 テナントライフサイクルの一部として新しいインフラストラクチャに移動する必要があります。 テナントが新しいデプロイに移動されると、アクセスする HTTP エンドポイントが変更される可能性があります。 このような場合は、テナント マッピング プロセスを変更する必要があることを検討してください。 次の要因を考慮する必要がある場合があります。

• アプリケーションでマッピング要求にドメイン名を使用している場合は、移行時に DNS の変更が必要になる場合もあります。 DNS サービスの DNS エントリの有効期間 (TTL) によっては、DNS の変更がクライアントに反映されるまでに時間がかかる場合があります。
• 移行プロセス中に移行によってエンドポイントのアドレスが変更される場合は、テナントの要求を自動的に更新されるメンテナンス ページに一時的にリダイレクトすることを検討してください。

貢献者

この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。

主要な著者

• Daniel Scott-Raynsford |パートナー テクノロジ ストラテジスト

その他の共同作成者:

• John Downs | プリンシパル ソフトウェア エンジニア
• Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

マルチテナント アプリケーションでドメイン名を操作する場合の考慮事項について説明します。

要求がアプリケーションに到着するたびに、要求を行っている テナントであるテナント コンテキストを決定する必要があります。 異なる地理的リージョンでホストされる可能性があるテナント固有のインフラストラクチャがある場合は、テナントへの受信要求を照合する必要があります。 次に、次に示すように、そのテナントのリソースをホストする物理インフラストラクチャに要求を転送する必要があります。

多くのマルチテナント アプリケーションにも、ユーザー ベースのアクセス許可があります。 テナント マッピングは別のアクティビティです。 要求を行っているユーザーと、そのユーザーが作業しているテナントの両方を知っている必要があります。

この記事では、要求を適切なテナントにマップすることを検討できるアプローチと、そのアプローチに関連するトレードオフについて、技術的な意思決定者向けのガイダンスを提供します。

注

このページでは、ほとんどの場合、Web サイトや API などの HTTP ベースのアプリケーションについて説明します。 ただし、同じ基本原則の多くは、他の通信プロトコルを使用するマルチテナント アプリケーションに適用されます。

テナントを識別する方法

受信要求のテナントを識別するには、複数の方法があります。 各方法では、受信要求の一部の側面を調べる必要があります。

ドメイン名

テナント固有のドメイン名またはサブドメイン名を使用する場合、Host ヘッダー、X-Forwarded-Host ヘッダー、または各要求の元のホスト名を含む別の HTTP ヘッダーを使用して、要求をテナントに簡単にマップできる可能性があります。

ただし、次の点を考慮してください。

• サービスへのアクセスに使用するドメイン名をユーザーが知る方法
• ランディング ページやログイン ページなど、すべてのテナントが使用する中央のエントリ ポイントはありますか。 その場合、ユーザーは、使用しているテナントをどのように選択しますか?
• 承認トークンなど、テナントのリソースへのアクセスを確認するために使用しているその他の情報は何ですか? 承認トークンにはテナント固有のドメイン名が含まれていますか?

HTTP 要求のプロパティ

テナント固有のドメイン名を使用しない場合でも、HTTP 要求の側面を使用して、特定の要求の対象となるテナントを識別できる場合があります。 たとえば、テナント名を tailwindtradersとして識別する HTTP 要求があるとします。 これは、次のいずれかの方法を使用して伝達される場合があります。

• 。
• URL 内のクエリ文字列 (https://contoso.com/app?tenant=tailwindtradersなど)。
• 。

重要

カスタム HTTP 要求ヘッダーは、WEB ブラウザーから HTTP GET 要求が発行される場合や、要求が一部の種類の Web プロキシによって処理される場合には役立ちません。 GET 操作には、カスタム HTTP ヘッダーを使用する必要があるのは、API を構築している場合、または要求を発行するクライアントを制御していて、ヘッダーを変更または削除する可能性のある Web プロキシが要求処理チェーンに含まれていない場合のみです。

この方法を使用する場合は、次の質問を考慮する必要があります。

• ユーザーはサービスにアクセスする方法を知っていますか? たとえば、クエリ文字列を使用してテナントを識別する場合、中央のランディング ページでは、クエリ文字列を追加してユーザーを適切なテナントのページに誘導する必要がありますか。
• ランディング ページやログイン ページなど、すべてのテナントが使用する中央のエントリ ポイントはありますか? その場合、ユーザーはアクセスする必要があるテナントをどのように選択しますか?
• アプリケーションは API を提供していますか? たとえば、Web アプリケーションはシングルページ アプリケーション (SPA) か、API バックエンドを持つモバイル アプリケーションですか? その場合は、 API ゲートウェイ または リバース プロキシ を使用してテナント マッピングを実行できる場合があります。

トークン要求

多くのアプリケーションでは、OAuth 2.0 や SAML などのクレーム ベースの認証と承認プロトコルが使用されます。 これらのプロトコルは、クライアントに承認トークンを提供します。 トークン には、クライアント アプリケーションまたはユーザーに関する情報の一部であるクレームのセットが含まれています。 要求は、ユーザーのメール アドレスなどの情報を伝達するために使用できます。 その後、システムにユーザーのメール アドレスを含め、ユーザーからテナントへのマッピングを検索し、要求を適切なデプロイに転送できます。 または、ID システムにテナント マッピングを含め、テナント ID 要求をトークンに追加することもできます。

要求を使用して要求をテナントにマップする場合は、次の質問を考慮する必要があります。

• 要求を使用してテナントを識別しますか? どの要求を使用しますか?
• ユーザーを複数のテナントのメンバーにすることはできますか? これが可能な場合、ユーザーは特定の要求に対して操作するテナントをどのように選択しますか?
• すべてのテナントに対して中央認証と承認システムはありますか? そうでない場合、すべてのトークン機関が一貫したトークンと要求を発行するようにするにはどうすればよいですか?

API キー

多くのアプリケーションで API が公開されています。 これらは、組織内での内部使用、またはパートナーや顧客による外部使用の場合があります。 API の一般的な認証方法は、 API キーを使用することです。 API キーは各要求で提供されます。 キーが発行されたテナント ID を記録した場合は、キーが使用されたときにテナント ID を検索できます。

注

API キーは、手動で作成および管理する必要があり、有効期間が長く、頻繁に再利用されるため、およびクレームが含まれていないため、高レベルのセキュリティを提供しません。 より最新で安全な方法は、OAuth 2.0 や OpenID Connect などの有効期間の短いトークンでクレームベースの承認メカニズムを使用することです。

API キーは、いくつかの方法で生成できます。 2 つの一般的な方法を次に示します。

• 暗号化されたランダムな値を生成し、テナント ID と共に参照テーブルに格納します。 要求が受信されると、システムは参照テーブルで API キーを検索し、テナント ID と一致します。
• テナント ID を含む意味のある文字列を作成します。 HMAC などのアプローチを使用して、キーにデジタル署名します。 各要求を処理するときは、署名を確認し、テナント ID を抽出します。

次の質問について考えてみましょう。

• API キーを生成して発行する方法
• API クライアントが API キーを安全に受け取って格納する方法
• 一定期間後に API キーの有効期限が切れる必要がありますか? ダウンタイムを発生させることなく、クライアントの API キーをどのようにローテーションしますか?
• 顧客が生成した API キーは、API に適切なレベルのセキュリティを提供しますか?

注

API キーはパスワードと同じではありません。 API キーはシステムによって生成される必要があり、各 API キーを 1 つのテナントに一意にマップできるように、すべてのテナントで一意である必要があります。 Azure API Management などの API ゲートウェイでは、API キーの生成と管理、受信要求のキーの検証、個々の API サブスクライバーへのキーのマップを行うことができます。

[クライアント証明書]

クライアント証明書認証 (相互 TLS (mTLS) とも呼ばれる) は、サービス間通信や、認証されていないユーザーが使用する無人デバイスまたはキオスクでよく使用されます。 クライアント証明書は、クライアントを認証するための安全な方法を提供します。 トークンと要求と同様に、クライアント証明書は、テナントを決定するために使用できる 属性 を提供します。 たとえば、証明書の 件名 にユーザーの電子メール アドレスが含まれている場合があります。このアドレスを使用してテナントを検索できます。

テナント マッピングにクライアント証明書を使用する場合は、次の点を考慮してください。

• サービスによって信頼されているクライアント証明書を安全に発行して更新するにはどうすればよいですか? クライアント証明書は、証明書の管理と発行に特別なインフラストラクチャを必要とするため、操作が複雑になる場合があります。 不適切に処理された場合、これらの複雑さによって、セキュリティが増えるのではなく 、セキュリティが低下 する可能性があります。
• クライアント証明書は、最初のログイン要求にのみ使用されるか、サービスへのすべての要求にアタッチされますか?
• 多数のクライアントがある場合、証明書の発行と管理のプロセスは管理できなくなりますか?
• クライアント証明書とテナントの間のマッピングはどのように実装しますか?

リバース プロキシ

リバース プロキシ (アプリケーション プロキシとも呼ばれます) を使用して、HTTP 要求をルーティングできます。 リバース プロキシは、イングレス エンドポイントからの要求を受け入れ、多数のバックエンド エンドポイントのいずれかに要求を転送できます。 リバース プロキシは、要求情報の一部間のマッピングを実行し、アプリケーション インフラストラクチャからタスクをオフロードできるため、マルチテナント アプリケーションに役立ちます。

多くのリバース プロキシでは、要求のプロパティを使用して、テナントのルーティングに関する決定を行うことができます。 宛先ドメイン名、URL パス、クエリ文字列、HTTP ヘッダー、要求本文のトークンまたは一部内の要求を検査できます。

Azure では、次の一般的なリバース プロキシが使用されます。

• Azure Front Door は、グローバル ロード バランサーと Web アプリケーション ファイアウォールです。 Microsoft グローバル エッジ ネットワークを使用して、高速でセキュリティで保護された高度にスケーラブルな Web アプリケーションを作成します。 ルール セットを使用してテナント識別子を抽出し、要求の別の部分に配置できます。
• Azure Application Gateway は、バックエンド サービスと同じ物理リージョンにデプロイするマネージド Web トラフィック ロード バランサーです。
• Azure API Management は API トラフィック用に最適化されています。 Azure API Management には、要求からテナント情報を抽出するための柔軟性が高い包括的な ポリシー エンジン が用意されています。
• 商用およびオープンソースのテクノロジ (自分でホストする) には、nginx、Traefik、HAProxy が含まれます。

要求の検証

アプリケーションで、受信した要求がテナントに対して承認されていることを検証することが重要です。 たとえば、アプリケーションでカスタム ドメイン名を使用して要求をテナントにマップする場合、アプリケーションは、アプリケーションが受信した各要求がそのテナントに対して承認されていることを確認する必要があります。 要求にドメイン名またはその他のテナント識別子が含まれている場合でも、アクセス権を自動的に付与する必要があるわけではありません。 OAuth 2.0 を使用する場合は、 対象ユーザー と スコープ の要求を調べることで検証を実行します。

注

これは、Microsoft Azure Well-Architected Framework のゼロ トラスト セキュリティ設計原則の一部です。

要求の検証を実装する場合は、次の点を考慮する必要があります。

• アプリケーションに対するすべての要求をどのように承認しますか? 要求を物理インフラストラクチャにマップするために使用する方法に関係なく、要求を承認する必要があります。
• すべての検証ロジックを自分で実装する代わりに、信頼された、広く使用され、よく維持されている認証と承認フレームワークとミドルウェアを使用します。 たとえば、トークン署名検証ロジックやクライアント証明書暗号化ライブラリを構築しないでください。 代わりに、検証およびテストされたアプリケーション プラットフォーム (または既知の信頼済みパッケージ) の機能を使用してください。

[パフォーマンス]

テナント マッピング ロジックは、アプリケーションに対するすべての要求で実行される可能性があります。 ソリューションの拡大に合わせて、テナント マッピング プロセスがどの程度適切にスケーリングされるかを検討します。 たとえば、テナント マッピングの一部としてデータベース テーブルに対してクエリを実行した場合、データベースは大量の負荷をサポートしますか? テナント マッピングでトークンの暗号化を解除する必要がある場合、計算要件は時間の経過と同時に高くなりすぎますか? トラフィックが非常に控えめであれば、全体的なパフォーマンスに影響を与える可能性はありません。 ただし、大規模なアプリケーションがある場合、このマッピングに伴うオーバーヘッドが大きくなる可能性があります。

セッション Cookie

テナント マッピング ロジックのパフォーマンス オーバーヘッドを減らす方法の 1 つは、 セッション Cookie を使用することです。 すべての要求でマッピングを実行するのではなく、各セッションの最初の要求についてのみ情報を計算することを検討してください。 その後、アプリケーションはセッション Cookie をクライアントに提供します。 クライアントはセッション Cookie をサービスに渡し、そのセッション内の後続のすべてのクライアント要求を受け取ります。

注

Azure の多くのネットワークおよびアプリケーション サービスでは、セッション Cookie を発行できます。

次の質問について考えてみましょう。

• セッション Cookie を使用して、要求をテナントにマッピングするオーバーヘッドを減らすことができますか?
• 各テナントの物理デプロイに要求をルーティングするには、どのようなサービスを使用しますか? これらのサービスは Cookie ベースのセッションをサポートしていますか?

テナントの移行

テナントは、多くの場合、 テナントライフサイクルの一部として新しいインフラストラクチャに移動する必要があります。 テナントが新しいデプロイに移動されると、アクセスする HTTP エンドポイントが変更される可能性があります。 このような場合は、テナント マッピング プロセスを変更する必要があることを検討してください。 次の要因を考慮する必要がある場合があります。

• アプリケーションでマッピング要求にドメイン名を使用している場合は、移行時に DNS の変更が必要になる場合もあります。 DNS サービスの DNS エントリの有効期間 (TTL) によっては、DNS の変更がクライアントに反映されるまでに時間がかかる場合があります。
• 移行プロセス中に移行によってエンドポイントのアドレスが変更される場合は、テナントの要求を自動的に更新されるメンテナンス ページに一時的にリダイレクトすることを検討してください。

貢献者

この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。

主要な著者

• Daniel Scott-Raynsford |パートナー テクノロジ ストラテジスト

その他の共同作成者:

• John Downs | プリンシパル ソフトウェア エンジニア
• Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

マルチテナント アプリケーションでドメイン名を操作する場合の考慮事項について説明します。