Share via

マルチテナント ソリューションでのネットワークのアーキテクチャに関するアプローチ

  • [アーティクル]

Azure にデプロイされたすべてのソリューションには、何らかのネットワークが必要です。 ソリューションの設計とワークロードによっては、Azure のネットワーク サービスとの対話方法が異なる場合があります。 この記事では、Azure でのマルチテナント ソリューションのネットワーク アスペクトに関する考慮事項とガイダンスを提供します。 低レベルのネットワーク コンポーネント (仮想ネットワークなど) から、高レベルのアプリケーション層のアプローチに関する情報まで含まれています。

Note

Azure 自体はマルチテナント環境であり、Azure のネットワーク コンポーネントはマルチテナント向けに設計されています。 独自のソリューションを設計するために詳細を理解する必要はありませんが、Azure が他の顧客のトラフィックから仮想ネットワーク トラフィックを分離する方法について詳しく知ることができます。

主な考慮事項と要件

インフラストラクチャとプラットフォームのサービス

ネットワーク コンポーネントに関する考慮事項は、使用するサービスのカテゴリによって異なります。

インフラストラクチャ サービス

仮想マシンや Azure Kubernetes Service などのインフラストラクチャ サービスを使用する場合は常に、サービスの接続の基盤となる仮想ネットワークもしくは VNet を考慮して設計する必要があります。 また、設計に組み込む必要があるセキュリティと分離の他のレイヤーも考慮する必要があります。 ネットワーク レイヤー コントロールだけに依存することを回避してください。

プラットフォーム サービス

App Service、Azure Cosmos DB、Azure SQL Database などの Azure のプラットフォーム サービスを使用する場合、使用する特定のアーキテクチャによって、必要なネットワークサービスが決まります。

インターネットからプラットフォーム サービスを分離する必要がある場合は、VNet を使用する必要があります。 使用する特定のサービスによっては、プライベート エンドポイントや Application Gateway などの VNet 統合リソースを使用する可能性があります。 ただし、お使いのプラットフォーム サービスをパブリック IP アドレスで利用できるようにし、ファイアウォールや ID コントロールなどのサービス独自の保護を使用することもできます。 このような状況では、VNet は必要ない場合があります。

プラットフォーム サービスに VNet を使用するかどうかは、次の要因を含む多くの要件に基づいて決定されます。

  • コンプライアンス要件: 特定のコンプライアンス標準を満たすことが必要になる場合があります。 一部の標準では、特定の方法で Azure 環境を構成する必要があります。
  • テナントの要件: 組織によっては、ネットワーク レイヤーの分離やコントロールに関する特定の要件がない場合でも、テナントにはある可能性があります。 テナントがソリューションにアクセスする方法と、ネットワーク設計について何らかの想定があるかどうかを明確に理解していることを確認します。
  • 複雑さ: 仮想ネットワークを理解して使用することは、より複雑な場合があります。 チームが関連する原則を明確に理解していることを確認しないと、セキュリティで保護されていない環境をデプロイする可能性があります。

プライベート ネットワークを使用する場合の影響を理解していることを確認してください。

サブネットのサイズ変更

VNet をデプロイする必要がある場合は、VNet 全体と VNet 内のサブネットのサイズ設定とアドレス空間を慎重に検討することが重要です。

VNet への Azure リソースのデプロイ方法と、各リソースが使用する IP アドレスの数を明確に理解していることを確認します。 テナント固有の計算ノード、データベース サーバー、またはその他のリソースをデプロイする場合は、予想されるテナントの拡張と、リソースの水平方向の自動スケーリングのために十分な大きさのサブネットを作成してください。

同様に、管理サービスを使用する場合は、IP アドレスがどのように使用されるか理解することが重要です。 たとえば、Azure Kubernetes Service を Azure Container Networking Interface (Azure CNI) と共に使用する場合、サブネットから使用される IP アドレスの数は、ノードの数、水平方向にスケーリングする方法、使用するサービスのデプロイ プロセスなどの要因に基づいて決まります。 VNet 統合で Azure App Service と Azure Functions を使用する場合、使用される IP アドレスの数は、プラン インスタンスの数に基づきます。

サブネットを計画するときにサブネットのセグメント化ガイダンスを確認します。

パブリックまたはプライベート アクセス

テナントがインターネットまたはプライベート IP アドレスのどちらを経由してサービスにアクセスするかを検討します。

インターネットベース (パブリック) でアクセスする場合、ファイアウォール規則、IP アドレス 許可リストと拒否リスト、共有シークレットとキー、および ID ベースのコントロールを使用してサービスをセキュリティで保護できます。

プライベート IP アドレスを使用してサービスへの接続を有効にする必要がある場合は、Azure Private Link サービスまたはクロステナントの仮想ネットワーク ピアリングを使用することを検討してください。 一部の限られたシナリオでは、Azure ExpressRoute または Azure VPN Gateway を使用してソリューションへのプライベート アクセスを有効にすることも検討してください。 テナントの数が少なく、テナントごとに専用の VNet をデプロイする場合にのみ、この方法を使用することをお勧めします。

テナントのエンドポイントへのアクセス

Azure の内部または外部で、テナントのネットワーク内のエンドポイントにデータを送信する必要があるかどうかを検討します。 たとえば、顧客から提供された Webhook を呼び出す必要がありますか？また、テナントにリアルタイム メッセージを送信する必要がありますか？

テナントのエンドポイントにデータを送信する必要がある場合は、次の一般的な方法を検討してください。

  • インターネット経由でソリューションからテナントのエンドポイントへの接続を開始します。 接続が静的 IP アドレスから発信される必要があるかどうかを検討します。 使用する Azure サービスによっては、 NAT Gateway、ファイアウォール、またはロード バランサーのデプロイが必要になる場合があります。
  • どこに配置されているかに関わりなく、Azure でホストされるサービスと顧客のネットワークの間の接続を可能にするために、エージェントをデプロイします。
  • 一方向メッセージングの場合は、イベント ドメインの有無にかかわらず、Azure Event Grid などのサービスを使用することを検討してください。

考慮すべきアプローチとパターン

このセクションでは、マルチテナント ソリューションで考慮できるいくつかの主要なネットワーク アプローチについて説明します。 まず、コア ネットワーク コンポーネントの低レベルのアプローチについて説明した後、HTTP およびその他のアプリケーション レイヤーの問題について検討できる方法に従います。

サービス プロバイダーで選択された IP アドレスを使用したテナント固有の VNet

場合によっては、テナントに代わって、VNet に接続された専用リソースを Azure で実行する必要があります。 たとえば、テナントごとに仮想マシンを実行する場合や、テナント固有のデータベースにアクセスするためにプライベート エンドポイントを使用する必要がある場合があります。

コントロールする IP アドレス空間を使用して、テナントごとに VNet をデプロイすることを検討してください。 この方法を使用すると、トラフィックのイングレスとエグレスを一元的にコントロールするハブとスポークのトポロジを確立する必要がある場合など、独自の目的に合わせて VNet をピアリングすることができます。

ただし、作成した VNet にテナントが直接接続する必要がある場合 (VNet ピアリングを使用する場合など)、サービス プロバイダーが選択した IP アドレスは適切ではありません。 選択したアドレス空間は、独自のアドレス空間と互換性がない可能性があります。

テナントが選択した IP アドレスを使用したテナント固有の VNet

テナントが、自分の VNet とあなたが代わりに管理する VNet をピアリングする必要がある場合、テナントが選択した IP アドレス空間でテナント固有の VNet をデプロイすることを検討してください。 この方式を採用すると、システムの VNet に含まれる IP アドレスの範囲と各テナント独自の VNet との重複を確実に避けられます。 重複しない IP アドレスの範囲を使用すると、ネットワークをピアリングに確実に対応させることができます。

ただし、この方法では、テナントの VNet をまとめてピアリングしたり、ハブ アンド スポーク トポロジを導入したりすることはほとんどありません。これは、異なるテナントの VNet 間で IP アドレスの範囲が重複している可能性があるためです。

ハブとスポークのトポロジ

ハブアンドスポークの VNet トポロジを使用すると、一元化されたハブ VNet と複数のスポーク VNet をピアリングできます。 VNet のトラフィックのイングレスとエグレスを一元的にコントロールし、各スポークの VNet のリソースが相互に通信できるかどうかをコントロールできます。 また、各スポーク VNet は、Azure Firewall などの共有コンポーネントにアクセスでき、Azure DDoS Protection のようなサービスを使用できる場合があります。

ハブ アンド スポーク トポロジを使用する場合は、ピアリングされた VNet の最大数などの制限を回避する計画をし、各テナントの VNet に重複するアドレス空間を使用しないようにしてください。

ハブ アンド スポーク トポロジは、選択した IP アドレスを使用してテナント固有の VNet をデプロイするときに役立ちます。 各テナントの VNet がスポークになり、ハブ VNet で共通のリソースを共有できるようになります。 また、スケールを目的として複数の VNet 間で共有リソースをスケーリングする場合や、デプロイ スタンプ パターンを使用する場合に、ハブ アンド スポーク トポロジを使用することもできます。

ヒント

ソリューションを複数の地理的リージョンにわたって実行する場合は、通常、各リージョンに個別のハブとハブ リソースをデプロイすることをお勧めします。 この方法ではリソース コストが高くなりますが、複数の Azure リージョンを不必要に経由するトラフィックを回避できます。これにより、要求の待機時間が増加し、グローバル ピアリング料金が発生する可能性があります。

静的 IP アドレス

受信トラフィック、送信トラフィック、またはその両方に対して、テナントで静的パブリック IP アドレスを使用するためのサービスが必要かどうかを検討します。 さまざまな Azure サービスによって、静的 IP アドレスがさまざまな方法で有効になります。

仮想マシンおよびその他のインフラストラクチャ コンポーネントを操作する場合は、受信と送信の両方の静的 IP アドレスのためにロード バランサーまたはファイアウォールを使用することを検討してください。 送信トラフィックの IP アドレスをコントロールするには、NAT Gateway を使用することを検討してください。 マルチテナント ソリューションで NAT Gateway を使用することについて詳しくは、「マルチテナント機能に関する Azure NAT Gateway の考慮事項」を参照してください。

プラットフォーム サービスを使用する場合、使用する特定のサービスによって、IP アドレスをコントロールするかどうかそしてその方法が決まります。 リソースを VNet にデプロイしたり、NAT Gateway やファイアウォールを使用したりして、リソースを特定の方法で構成することが必要になる場合があります。 または、サービスが送信トラフィックに使用する IP アドレスの現在のセットを要求できます。 たとえば、App Service は、アプリケーションの現在の送信 IP アドレスを取得するための API と Web インターフェイスを提供します。

エージェント

ソリューションによって開始されたメッセージをテナントが受信できるようにする必要がある場合、またはテナントのネットワーク内に存在するデータにアクセスする必要がある場合は、ネットワーク内にデプロイできるエージェント ( オンプレミス ゲートウェイと呼ばれることもあります) を提供することを検討してください。 このアプローチは、テナントのネットワークが Azure、別のクラウド プロバイダー、またはオンプレミスのいずれにある場合でも機能します。

エージェントは、指定しコントロールするエンドポイントへの送信接続を開始し、長時間実行されている接続を維持するか、断続的にポーリングします。 Azure Relay を使用して、エージェントからサービスへの接続を確立し管理することを検討してください。 エージェントは接続を確立すると、サービスが正しいテナントに接続をマップできるように、テナント識別子に関する情報を認証して含めます。

通常、エージェントはテナントのセキュリティ構成を簡略化します。 特にオンプレミスの環境では、受信ポートを開くことは複雑でリスクが高い場合があります。 エージェントは、テナントがこのリスクを冒す必要性を回避します。

テナントのネットワークに接続するためのエージェントを提供する Microsoft サービスの例を次に示します。

Azure Private Link サービス は、テナントの Azure 環境からソリューションへのプライベート接続を提供します。 テナントは、独自の VNet で Private Link サービスを使用して、オンプレミス環境からサービスにアクセスできます。 Azure は、プライベート IP アドレスを使用してサービスにトラフィックを安全にルーティングします。

Private Link とマルチテナント機能の詳細については、「マルチテナント機能と Azure Private Link」を参照してください。

ドメイン名、サブドメイン、および TLS

マルチテナント ソリューションでドメイン名とトランスポート レイヤー セキュリティ (TLS) を使用する場合は、いくつかの考慮事項があります。 マルチテナントとドメイン名に関する考慮事項を確認します。

ゲートウェイ ルーティングとゲートウェイ オフロード パターン

ゲートウェイ ルーティング パターン とゲートウェイ オフロード パターン には、レイヤー 7 リバース プロキシまたはゲートウェイのデプロイが含まれます。 ゲートウェイは、次の機能を含むマルチテナント アプリケーションのコア サービスを提供するために役立ちます。

  • テナント固有のバックエンドまたはデプロイ スタンプへの要求のルーティング。
  • テナント固有のドメイン名と TLS 証明書の処理。
  • Web アプリケーション ファイアウォール (WAF) を使用して、セキュリティの脅威への要求を検査します。
  • パフォーマンスを向上させるために応答をキャッシュする。

Azure は、Azure Front Door、Azure Application Gateway、Azure API Management など、これらの目標の一部またはすべてが達成するために使用できるいくつかのサービスを提供します。 NGINX や HAProxy のようなソフトウェアを使用して、独自のカスタム ソリューションをデプロイすることもできます。

ソリューションのゲートウェイをデプロイするプランがある場合は、最初に必要なすべての機能を含む完全なプロトタイプをビルドし、アプリケーション コンポーネントが期待した通り機能し続けることを確認することをお勧めします。 また、トラフィックとテナントの拡張をサポートするためにゲートウェイ コンポーネントがどのようにスケーリングされるのかを理解する必要もあります。

静的コンテンツ ホスティング パターン

静的コンテンツ ホスティング パターンは、クラウド ネイティブ ストレージ サービスからの Web コンテンツを提供し、コンテンツ配信ネットワーク (CDN) を使用してコンテンツをキャッシュします。

Azure Front Door または別の CDN を、シングル ページ JavaScript アプリケーションなどのソリューションの静的コンポーネント、そしてイメージ ファイルやドキュメントなどの静的コンテンツに使用できます。

ソリューションの設計方法によっては、テナント固有のファイルまたはデータ (JSON 形式の API 応答など) を CDN 内にキャッシュできることもあります。 この方法は、ソリューションのパフォーマンスとスケーラビリティを向上させるのに役立ちますが、テナント間でデータが漏えいしないように、テナント固有のデータが十分に分離されているかどうかを考慮することが重要です。 データが更新された場合や新しいアプリケーション バージョンがデプロイされた場合など、テナント固有のコンテンツをキャッシュから消去する方法を検討してください。 URL パスにテナント識別子を含めることで、特定のファイル、特定のテナントに関連付けられているすべてのファイル、またはすべてのテナントのすべてのファイルを消去するかどうかをコントロールできます。

回避すべきアンチパターン

VNet 接続の計画に失敗する

VNet にリソースをデプロイすることで、ソリューションのコンポーネントを通過するトラフィック フローを十分にコントロールできます。 ただし、VNet 統合では、さらに複雑さ、コスト、および考慮する必要があるその他の要因ももたらされます。 この効果は、サービスとしてのプラットフォーム (PaaS) コンポーネントでは特に当てはまります。

運用環境で実装する前に問題を明らかにするために、ネットワーク戦略をテストして計画することが重要です。

制限を計画しない

Azure では、ネットワーク リソースに影響を与える多数の制限が適用されます。 これらの制限には、Azure リソースの制限 と、基本的なプロトコルとプラットフォームの制限が含まれます。 たとえば、Azure App Service や Azure Functions などのプラットフォーム サービスで高スケールのマルチテナント ソリューションをビルドする場合は、TCP 接続と SNAT ポートの数を考慮する必要がある場合があります。 仮想マシンとロード バランサーを使用する場合は、送信規則 と SNAT ポートの制限も考慮する必要があります。

小さなサブネット

デプロイするリソースまたはリソースのインスタンスの数に対応できるように各サブネットのサイズを考慮することは、スケーリングすることを考えると特に重要です。 サービス としてのプラットフォーム (PaaS) リソースを使用する場合は、リソースの構成とスケールがサブネットに必要な IP アドレスの数に与える影響を理解してください。

ネットワークの不適切なセグメント化

ソリューションに仮想ネットワークが必要な場合は、受信と送信 (北 - 南) のトラフィック フローと、ソリューション内のフロー (東 - 西) をコントロールできるようにするために、ネットワークのセグメント化を構成する方法を考慮してください。 テナントに独自の VNet を設定するか、または共有 VNet に共有リソースをデプロイするかどうかを決定します。 アプローチの変更は困難な場合があります。そのため、すべての要件を考慮してから、今後の拡張目標のために有効なアプローチを選択してください。

ネットワーク レイヤー セキュリティ コントロールにのみ依存する

最新のソリューションでは、ネットワーク レイヤーのセキュリティを他のセキュリティ コントロールと組み合わせることが重要であり、ファイアウォールやネットワークのセグメント化のみに依存すべきではありません。 これは場合により、ゼロ トラスト ネットワークと呼ばれます。 ID ベースのコントロールを使用して、ソリューションのすべてのレイヤーでクライアント、呼び出し元、またはユーザーを確認します。 保護層を追加できるサービスの使用を検討してください。 使用できるオプションは、使用する Azure サービスによって異なります。 AKS では、相互 TLS 認証にサービス メッシュを使用し、ネットワーク ポリシーを使用して東西のトラフィックをコントロールします。 この App Service では、認証と承認の組み込みのサポートとアクセスの制限を使用することを検討してください。

テストなしでホスト ヘッダーを書き換える

ゲートウェイ オフロード パターンを使用する場合は、HTTP 要求の Host ヘッダーの書き換えを検討してください。 この方法では、カスタム ドメインと TLS 管理をゲートウェイにオフロードすることで、バックエンド Web アプリケーション サービスの構成を簡略化できます。

ただし、ヘッダー Host の書き換えによって、一部のバックエンド サービスで問題が発生する可能性があります。 アプリケーションが HTTP リダイレクトまたは Cookie を発行すると、ホスト名の不一致によってアプリケーションの機能が破損する可能性があります。 特に、この問題は、Azure App Service、Azure Functions、Azure Spring Apps など、それ自体がマルチテナントであるバックエンド サービスを使用する場合に発生する可能性があります。 詳細については、ホスト名を維持するためのベスト プラクティスに関するページを参照してください。

使用する予定のゲートウェイ構成を使用して、アプリケーションの動作をテストしてください。

共同作成者

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

プリンシパル作成者:

  • John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア

その他の共同作成者:

  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Joshua Waddell | FastTrack for Azure のシニア カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ