Microsoft Power Platform で使用する ExpressRoute のデプロイを計画する
ExpressRoute for Microsoft Power Platform の使用することを決定した後は、ニーズや環境に合わせて導入計画を立てることが重要です。
ExpressRoute の前提条件
ExpressRoute を設定するには、いくつかの前提条件を考慮して設定する必要があります。 これらは予期せぬコストや活動につながる可能性があるため、計画されてい場合は、プロジェクトや他のサービスの継続運営に影響を与える可能性があります。
外部の前提条件
ExpressRoute は物理的な接続そのものを提供するのではなく、すでに確立されている物理的な接続を介してプライベート接続を提供します。 物理的な接続性を確保するには、まず接続性プロバイダーによる設定がされている必要があります。 この接続を既存の ExpressRoute パートナーと確立する方法はいくつかあります。 ExpressRoute のドキュメントでは、オプションや現在利用可能なパートナーについて詳しく説明されています。
計画の一環として、次のことを考慮する必要があります:
地理: 後で詳しく説明しますが、1つ以上の接続をどこから行う必要があるかを地理的に理解することは、全体的な計画に影響します。
コスト: プライベート接続を確立するには、接続プロバイダーから料金が発生します。 必要な接続の種類と数によって、かなりの費用が発生する場合があります。
セットアップ時間: 場合によっては、物理的なハードウェアをセットアップする必要があります。 この設定時間は、実装スケジュールに組み込んでおく必要があります。
構成 スキル とリソース: 構成の複雑さのほとんどは、ネットワーク内の内部ルーティングの設定にあります。 そのためには、熟練した人材を確保することが不可欠です。
Microsoft 前提条件
物理的な接続が確立された後は、ExpressRoute の接続自体の設定へと進みます。 次が必要となります:
ExpressRoute 回路のプロビジョニングと請求を行う Azure サブスクリプション。
ExpressRoute 回路の Azure サブスクリプション内での構成。これは Azure ツールを介して行います。
ExpressRoute を介した Microsoft Power Platform トラフィックのルーティング構成を計画する
Microsoft Power Platform トラフィックのルーティングを計画する際には、Microsoft Power Platform の構成や使用方法によって異なる様々なタイプのトラフィックを考慮する必要があります。
ExpressRoute for Microsoft Power Platform の設定方法を理解するには、利用するサービスや機能によって異なる Microsoft Power Platform との用途や接続方法を考える必要があります。
ルーティング構成
ルーティングの構成は、提供される接続タイプに応じて、接続プロバイダーまたは顧客のいずれかが行います。
ExpressRoute の接続自体はデータセンター間のものですが、実際のネットワーク接続は、ユーザーのクライアントデバイス (銀行の支店が分散しているなど、より広い WAN に分散していることが多い) からのものがほとんどです。 つまり、接続は、クライアント機器の所在地から WAN を経由してデータセンターに向かい、そこから ExpressRoute 回線を経由して行われます。 これには慎重に構成をする必要があります。 WAN は、次のように設定する必要があります:
ネットワーク サブネットを介したルートは、ExpressRoute 用に構成されています。
or
フェイルオーバー回線は、公衆インターネット接続よりも優先して Microsoft Power Platform が選択されます。
そのため、ネットワーク内のどのサブネットをメインおよびフォールバックの Border Gateway Protocol (BGP) セッション接続の対象とするかを特定し、Microsoft Power Platform の接頭辞がそのルートを優先するように設定することが重要です。 この構成は、この接続を介して IP サブネット/接頭辞を公示することで行われるため、両エンドでサービスを特別に構成する必要はありません。 要求が開始されると、ルーティング アルゴリズムは、そのダイレクト BGP 接続を、ExpressRoute 回線に接続されたサブネットへのトラフィックの優先ルートと見なし、トラフィックをのように転送します。
分散ユーザーベース用の ExpressRoute の構成
ExpressRouteは、共有 から Microsoft ネットワークへのプライベートで専用の、したがって予測可能な接続を提供するように設計されています。 接続プロバイダーを介して Microsoft への専用の直接接続を確立すると、接続プロバイダーのネットワークを介して確立した接続で他のトラフィックと競合する可能性が軽減されます。 接続プロバイダーを介してこの品質の接続を実現するために、ExpressRoute を使用する必要はありませんが、それを保証するための方法です。
以下の例では、ブランチ ロケーションにいるユーザーの接続が WAN 経由で顧客データセンターの接続にルーティングされ、ExpressRoute に接続されています。
全国/地域に分散した支社のネットワークなど、顧客が高度に分散したユーザーのネットワークを持っている場合、ネットワーク トラフィックは、高度に地理的に分散した複数の場所から効率的に接続する必要があります。 その典型的なパターンは、以下の画像のように、WAN を経由して ExpressRoute に接続されたローカルネ ットワークにルーティングすることです。
クライアントと ExpressRoute 間の接続が不十分であったり、飽和状態であったり、その他の方法で非効率であったりした場合、ExpressRoute はこれを解決できません。ExpressRoute のエントリー ポイントに到達する際の接続の問題は、依然としてユーザー エクスペリエンスに影響を与えるためです。 このような場合は、ExpressRoute Directの使用を検討してください。これにより、 Microsoft のグローバル ネットワークに直接 接続 できるようになります。
クラウドサービスに接続する際、困難な WAN 接続に制約されている場合、ローカル ブランチからローカル インターネット ブレークアウトを確立することが有益な場合があります。 これにより、低速の WAN 接続を避け、接続プロバイダーのリーチを活用して、クラウドサービスへのより直接的な接続を実現します。
次の図のように、複数の拠点からExpressRoute回路を設定することができ、さらにローカルのインターネット ブレイクアウトを介して個々のブランチ拠点にも接続することができます。
通常、ブランチ オフィスをWAN経由で中央データ センターに接続し、顧客とデータ センターの間にExpressRoute回線を確立する方法は、各ブランチ オフィスからExpressRoute接続を確立するよりも好ましく、より実用的です。 Microsoft これが多くの場所で必要とされる場合、設定や維持には比較的コストがかかり、複雑になります。
別の方法としては、すべてのブランチ オフィスと顧客データ センターを同じIP VPN上に 接続 し、IP VPNサービス プロバイダーをExpressRouteの場所に 接続 Microsoft 配置するという方法があります。
ローカルの WAN 接続に問題がある場合は、各拠点からExpressRoute接続を確立するよりも、帯域幅の追加やルーティングの最適化などの方法で最適化する方が一般的です。
高域に分散しているネットワークでは、ExpressRoute に接続された複数のハブを持つことで、必要な ExpressRoute の接続数を最小限に抑えつつ、各ユーザーにローカルな接続ポイントを提供することができる場合があります。 この場合、各 ExpressRoute 回線を介して固有のパブリック IP が公開されるようにすることが重要です。これらのサブネットはそれぞれ異なるものでなければならず、ExpressRoute の接続数と同数のパブリックに面したサブネットを用意する必要があります。
これは、異なる運用エリアが地理的に大きく異なるエリアに位置している場合や、エリア間のネットワーク接続が制限されていて、各エリアに対してより直接的な接続を確立できる場合に特に有益です。 Microsoft
また、地域によってプライバシー要件が異なる可能性もあり、ある地域が ExpressRoute を使用している場合でも、すべての地域が ExpressRoute を使用する必要はありません。 次の図に示すように、ある接続はインターネットを直接経由し、他の接続は ExpressRoute を経由するという可能性もあります。
ExpressRoute (標準) は、特定の地域内でのみ接続を提供します。単一の ExpressRoute 接続ポイントから複数の地域アクセスを提供するには、ExpressRoute Premium が必要です。 これはたとえば、顧客が米国のオフィスとヨーロッパのオフィスを持っていて、すべてのオフィスで単一の Microsoft Power Platform 環境を使用している場合に関係します。 顧客の Microsoft Power Platform テナントが米国で展開されている場合、欧州の ExpressRoute 回線は Premium SKU である必要があります。 Microsoft Power Platform のテナントが欧州にある場合、米国の回線は Premium にする必要があります。
非対称ルーティングの回避
注意すべき課題の1つは、非対称ルーティングです。これは、顧客ネットワーク内のルーティング構成によってトラフィックがインターネット経由で直接データセンターにルーティングされますが、その後、戻りトラフィックによって、応答をExpressRoute回線経由でルーティングする必要があることが決定されます。 Microsoft これは、リクエスト パケットを送信していない場合でも応答パケットを受信してしまうため、ファイアウォールがトラフィックを拒否するトリガーとなる場合が多くあります。
これは、クライアントのローカル ネットワークで、クラウド サービスへの最も効率的なルーティングは、WAN経由でプライベートExpressRoute回線経由ではなく、パブリック インターネット経由であると判断された場合に発生する可能性があります。 Microsoft しかし、クライアントの IP アドレスがパブリック IP アドレスであったり、NAT マッピングによって ExpressRoute で公示されているパブリック IP アドレスに変換されている場合、その IP に戻る最も効率的なルートは、ExpressRoute 上の BGP セッションを経由するルートである可能性があります。 インターネットのエッジと ExpressRoute のエッジで異なる NAT IP を使用できます。 明確なソース アドレスがあれば、リターントラフィックは明確に同じエッジに戻ってきます。
この現象は、同じ顧客向けに複数の ExpressRoute 回路が設定されており、アウトバウンド トラフィックのある回路を経由しているが、リターン ルーティングは別の回路を経由しており、ファイアウォール チェックによってリターン パスを経由するトラフィックがブロックされている場合にも発生します。 アウトバウンド パスとインバウンド パスで異なる ExpressRoute サーキットを経由する非対称ルーティングを避けるには、各サーキットでユニークなパブリック IP が公開されるようにすることが重要です。
ご覧のとおり、WAN内でルーティングがどのように管理されるかを決定し、クラウド サービスとの間のパスを慎重に検討することが重要です。 Microsoft
Microsoft Power Platform から/への外部接続
顧客の拠点から Microsoft Power Platform に接続する際には、複数のトラフィック タイプを考慮する必要があります。 これにより、 Microsoft ピアリング タイプとプライベート ピアリングの両方が可能になり、次の図に示すように、これらのピアリング タイプに同じExpressRoute回線を使用できます。
Microsoft Power Platform サービスと外部ネットワークの間には、さまざまな接続タイプがあります。 たとえば、サーバー側同期を使用したExchange Webサービス接続では、ExpressRouteを使用して、ネットワーク トラフィックを Microsoft ネットワークから顧客ネットワークに渡します。 Webサービス接続では、ネットワークへの受信トラフィックと送信トラフィックの両方にExpressRouteが使用されます。 Microsoft HTTPSクライアントの場合、顧客ネットワークからネットワークへのアクセスにはExpressRoute接続が使用されます。 Microsoft 次の画像では、これらの例を示しています。
アウトバウンド トラフィック (Microsoft Power Platform サービスからのトラフィック)
いくつかのタイプのアウトバウンド トラフィックが、Microsoft Power Platform サービスから顧客サービスに直接発生する場合があります。 それぞれについて、カスタマーサービスは、Microsoft Power Platform サービスがパブリック DNS で解決可能なパブリック IP でアドレスを公開する必要があることが重要です。
このIPアドレスは、ExpressRoute経由でアドバタイズされる必要もあります。これにより、サービス内の内部ネットワーク ルーティングが、そのIPアドレスをExpressRoute接続経由でルーティングすることを認識できるようになります。 Microsoft Microsoft Power Platform
Microsoft Power Platform サービスでは、どのサービス インスタンスやお客様の組織がどの IP アドレスにリクエストを出せるかを指定することはできません。 そのため、企業ネットワークに入ってくるリクエストは、インターネットからのものと同様にあつかいい、セキュリティを確保することが重要です。
次の表は、Microsoft Power Platform サービスからのアウトバウンドのトラフィックを示しています。
| 内容 | トラフィックの種類と方向 | ピアリング タイプ | パーパス |
|---|---|---|---|
| Web サービス | Microsoft Power Platform サービスからの HTTPS アウトバウンド | Microsoft ピアリング ExpressRoute で設定されたサブネット内のパブリック IP アドレスで Web サービスを公開する |
カスタム プラグインやワークフロー アクティビティでは、外部サービスに Web サービス リクエストを送信できます |
| Exchange 統合: ハイブリッド モード | Microsoft Power Platform サービスからの HTTPS アウトバウンド | Microsoft ピアリング Web サービスは、ExpressRoute で設定されたサブネット内のパブリック IP アドレスで公開する必要があります |
ハイブリッド展開 (Microsoft Power Platform サービス、オンプレミスの Exchange) におけるサーバー側同期からの Exchange Web Services リクエスト |
| コネクタ | Microsoft Power Platform サービスからの HTTPS インバウンド | Microsoft ピアリング | オンプレミスのデータゲートウェイを使用したコネクタを介して、Azure API Management サービスを介した Microsoft Power Platform サービスからのリクエスト |
| Azure Relay | Microsoft Power Platform サービスからの HTTPS アウトバウンド | Microsoft ピアリング ExpressRoute で設定されたサブネット内のパブリック IP アドレスで Web サービスを公開する |
Power Automate クラウド フローとデスクトップ フロー間のダイレクト接続 |
インバウンド トラフィック (Microsoft Power Platform サービスへのトラフィック)
顧客のネットワークから Microsoft Power Platform サービスには以下のようなインバウンド トラフィックが考えられます。
| 内容 | トラフィックの種類と方向 | ピアリング タイプ | パーパス |
|---|---|---|---|
| クライアントの接続性 | Microsoft Power Platform サービスへの HTTPS インバウンド | Microsoft ピアリング Azure Content Delivery Network が提供する静的コンテンツに使用する直接インターネット接続 |
Microsoft Power Platform サービスの UI に対するクライアントの要望 |
| Web サービス | Microsoft Power Platform サービスへの HTTPS インバウンド | Microsoft ピアリング | Web サービス API (SOAP、Web API) を介した Microsoft Power Platform サービスへのリクエスト。 標準、またはカスタム クライアント アプリケーションから |
| コネクタ | Microsoft Power Platform サービスへの HTTPS インバウンド | Microsoft ピアリング | オンプレミスのデータゲートウェイを利用したコネクタを介して、APIM を介して Microsoft Power Platform サービスに応答を返す |
Microsoft Power Platform サービスの内部クラウド接続
Microsoft Power Platform サービスは、 Microsoft およびAzureの両方でホストされている他のいくつかのオンライン サービスを使用し、統合します。 Microsoft 365
| 内容 | トラフィックの種類と方向 | 目的 |
|---|---|---|
| Exchange の統合 | Microsoft 365 への HTTPS アウトバウンド | サーバー側同期から Exchange Online への Web サービス リクエストの交換 |
| SharePoint 統合 | Microsoft 365 への HTTPS アウトバウンド | Microsoft Power Platform サービスから SharePoint オンラインへの SharePoint web サービス リクエスト |
| サービス バス | Azure Service Bus への HTTPS アウトバウンド | 標準的なイベント登録、またはカスタム プラグインやワークフロー アクティビティから、Azure Service Bus にイベントをプッシュします |
| データの同期 | Azure からの HTTPS インバウンド | 検索/オフライン/顧客インサイトを含む、データサービスの同期のためのインバウンド変更追跡要求 |
| 認証 | Microsoft Entra への HTTPS アウトバウンド | ほとんどの認証は、パッシブ リダイレクトと要求トークンによって行われますが、一部のデータは直接 Microsoft Entra ID に同期されます |
| データフロー | Azure Data Lake Storage への HTTPS アウトバウンド | 分析機能を提供し、分析から得られる分析情報に加えて、Microsoft Power Platform サービスやその他のソースからのデータを組み込んだビッグ データ ソリューションへのアクセスを可能にします。 |
| コネクタ | Azure PaaS サービスへの HTTPS アウトバウンド | さまざまな Azure PaaS サービスへの接続 |
| Desktop フロー | Azure Relay への HTTPS 送信 | デスクトップ用 Power Automate で作成された Power Automate クラウド フローとデスクトップ フロー間のダイレクト接続 |
Microsoft または顧客のAzureサブスクリプションでホストされているこれらのサービス間の実際の接続は、によって処理されます Microsoft。 ExpressRoute は、これらのサービスとの接続には適用されません。
イベントがサービス バスにプッシュされる場合、Microsoft Power Platform サービスと Azure との接続は内部で処理されます。 別途、顧客はService Busにリクエストを送信して情報を取得できます。これは、 Microsoft ピアリングを通じて管理できます。
Microsoft Power Platform サービスとの間の顧客のパブリック クラウド接続、およびプライベート クラウド接続
Microsoft Power Platform サービスでは、パブリックまたはプライベートの Azure リソースと直接統合することもできます:
外部ソースから、Microsoft Dataverse Web サービス API を使用します。
行われた Web サービス要求を使用して、外部ソースに送信します。
コネクタを使用して、外部ソースに接続します。
ExpressRoute のルーティングでは、この影響を考慮する必要があります。
| 内容 | トラフィックの種類と方向 | ピアリング タイプ | 目的 |
|---|---|---|---|
| ポータル | Azure への HTTPS インバウンド | コンテンツ配信ネットワークを使用する静的コンテンツを除いた、データセンターの内部。 (コンテンツ配信ネットワークは ExpressRoute でサポートされていないため、静的コンテンツはパブリック インターネット上を移動します。) | 公開サービスをホストします。 内部の従業員がこれらのリソースにアクセスするシナリオもあるため、トラフィックは公共のインターネットではなく、ExpressRoute を経由させたい場合があります |
| 学習パス | Azure への HTTPS インバウンド | ExpressRoute ではサポートされていないコンテンツ配信ネットワークを使用しているため、コンテンツは公共のインターネットを経由します | これは、個人的な顧客データを含まないため、公共性の高いサービスでホストされています。 予測可能性を高めるには、ExpressRoute でルーティングするシナリオが考えられます |
| サービス バス | Azure Service Bus への HTTPS インバウンド | データセンターの内部 | 標準的なイベント登録、またはカスタム プラグインやワークフロー アクティビティによって Azure Service Bus に配置されたイベントをプルします |
| Web サービス要求 | Azure IaaS / PaaS からのインバウンド | データセンターの内部 | 顧客は Azure でカスタム アプリケーションをホストし、Microsoft Power Platform の Web サービスにリクエストできます |
| Web サービス要求 | Azure IaaS/PaaS へのアウトバウンド | データセンターの内部 | 顧客は、Azure ホストサービスを要求するカスタム プラグインやワークフロー アクティビティを実装することができます |
| データフロー | Azure Data Lake Storage へのデータ接続 | データセンターの内部 | 分析機能を提供し、解析から得られる分析情報に加えて、Microsoft Power Platform サービスと他のソースの両方からのデータを組み込んだビッグデータ ソリューションへのアクセスを可能にします。 |
| Azure Data Lake | Azure Data Lake Storage へのデータ接続 | データセンターの内部 | 分析機能を提供し、解析から得られる分析情報に加えて、Microsoft Power Platform サービスとその他のソースの両方からのデータを組み込んだビッグデータ ソリューションへのアクセスを可能にします。 |
| Azure SQL | Azure SQL サービスへのデータ接続 | データセンターの内部 | Export to Data Warehouseなどの機能により、レポートやレプリケーション目的で Microsoft Dataverse データのレプリカを保持する Azure SQL インスタンスの使用が増加します。 ExpressRoute を介してこれらのリソースへの接続を保護する価値があるかもしれません。 |
将来的には、Azure の他の機能を利用して、データセンターに内部接続する他のパブリック サービスが登場する可能性があります。