ゲートウェイを単なる中継役として使うのはやめましょう：実際の役割とは

By Mirko Peters · 2026-08-28

ポッドキャストのブログ版へようこそ。Power BIのデータセット更新がのろのろと進み、くるくる回る読み込みマークを見つめたことがあるなら、あるいは経営陣が最も必要としているタイミングで社内ダッシュボードがいつもタイムアウトするなら、原因の見当違いな方向を探している可能性があります。多くのアーキテクトや管理者は、Power Platform Data Gateway を単純な配管のように扱っています。オンプレミスのデータベースとクラウドの間でデータを行き来させるだけの、受け身の「ただの土管」だと考えているのです。しかし、それは事実とはまったく異なります。

Automatically translated with AI from the original post. Read the English original

ポッドキャストのブログ版へようこそ。Power BIのデータセット更新がのろのろと進み、くるくる回る読み込みマークを見つめたことがあるなら、あるいは経営陣が最も必要としているタイミングで社内ダッシュボードがいつもタイムアウトするなら、原因の見当違いな方向を探している可能性があります。多くのアーキテクトや管理者は、Power Platform Data Gateway を単純な配管のように扱っています。オンプレミスのデータベースとクラウドの間でデータを行き来させるだけの、受け身の「ただの土管」だと考えているのです。しかし、それは事実とはまったく異なります。

本記事では、ゲートウェイの設計上の実態を詳しく掘り下げます。ゲートウェイがどのように重量級の処理エンジンとして機能するのか、そしてその構成を無視するとレポートのパフォーマンスがどれほど損なわれるのかを解説します。これらのアーキテクチャの概念をさらに深く理解し、実際のトラブルシューティング事例を聞きたい方は、関連するポッドキャストのエピソードConfigure the Power Platform Data Gateway for Reliable Connectivityもぜひお聴きください。

ゲートウェイが実際にどのように動作しているのかを見ていきましょう。そのうえで、ゲートウェイをボトルネックから高速道路へと変えるための具体的な手順を紹介します。

誤解されがちな仲介役：ゲートウェイの実際の役割

ゲートウェイのパフォーマンスを改善するには、まずクラウドサービスがオンプレミスのデータソースにリクエストを送ったときに、内部で何が起きているのかを理解する必要があります。紙の上でのデータの流れは一見単純です。Power BI サービスがゲートウェイクラスターと通信し、ゲートウェイクラスターがホストマシンと通信し、ホストマシンがデータソースに対してクエリを実行して、その結果を逆方向にたどって返します。しかし、これは受け身の中継ではありません。

ゲートウェイは、各ホップで多くの重い処理を担っています。認証のハンドシェイクを処理し、Transport Layer Security（TLS）暗号化を終端して再確立し、クエリのペイロードを変換し、大容量のメモリバッファーを管理します。暗号化、クエリの変換、一時ファイルのバッファリングを行うため、ゲートウェイマシンは十分に機能する処理エンジンです。これを軽量なミドルウェアのように扱うのは、大きなトラブルを招く原因になります。

デプロイモードも慎重に確認する必要があります。Personal Mode のゲートウェイは単一ユーザーのシナリオ専用に設計されており、共有の企業向けレポートには決して使用すべきではありません。本番環境のワークロードには Standard Data Gateway を導入する必要があります。理想的には、高可用性と負荷分散を確保するために、2 つ以上のノードによるクラスター構成にしてください。さらに、最新のアーキテクチャでは Azure VNet Data Gateway を活用することで、受信側の露出をゼロにできます。セキュリティチームの懸念を抑えながら、堅牢なパフォーマンスを実現できます。

既定の設定と見えにくいパフォーマンスの阻害要因

Power Platform Data Gateway を新規にインストールすると、インストーラーはほぼすべてのハードウェアですぐに動作するように設計された、保守的な既定設定を適用します。残念ながら、これらの既定設定はエンタープライズ環境では、気づきにくいパフォーマンスの阻害要因として働いてしまいます。

たとえば同時実行性です。既定の状態では、ゲートウェイは並列クエリの実行数を抑える、控えめなキューで動作することがよくあります。強力なハードウェアを持っているのに、更新が順番待ちで滞っているなら、リソースを無駄にしています。並列クエリの上限を、ホストの実際の処理能力に合わせて引き上げる必要があります。

バッファーのサイズ設定も大きな落とし穴です。バッファーが小さすぎると、ゲートウェイはデータをディスクに書き出すことを余儀なくされ、大きな I/O ボトルネックが生じます。RAM には余裕を持たせてください。さらに、セキュリティチームのアンチウイルスソフトに適切な除外設定が行われているかも確認してください。ゲートウェイのインストール先、キャッシュ、ログのパスに対してリアルタイムスキャンが有効だと、すべての一時ファイルが厳重に検査されるため、クエリ処理が大きく停滞することがあります。

StreamBeforeRequestCompletes の設定についても触れておく必要があります。この設定は低遅延のローカルエリアネットワークではパフォーマンスを大きく向上させられる一方、遅延の大きい VPN 経由では深刻なリスクをもたらします。最後に、更新後に設定が消える問題にも注意してください。ゲートウェイのソフトウェアを更新するたびに既定の構成に戻り、独自に行ったチューニングが消えることがあります。ゲートウェイをアップグレードしたら、必ず直ちにパフォーマンスの調整を再適用してください。

ネットワークの影響: ルーティング、遅延、そしてコールドポテト型の現実

データゲートウェイのホストに最高価格のハードウェアを用意しても、ネットワークのルーティングに根本的な問題があれば、パフォーマンスは低いままです。遅延はネットワークのホップごとに積み重なり、不適切なルーティングは他のあらゆる最適化の効果を完全に打ち消してしまいます。

多くの組織は、「統制のため」にすべてのトラフィックを企業 VPN と集中型の Web プロキシ経由に迂回させる罠に陥っています。しかし実際には、この不要な迂回によって物理的な距離が数百マイルも加わり、ネットワークホップが増え、リソースを消費する TLS インスペクションによる遅延も発生します。代わりに、トラフィックができるだけ早く最寄りの Microsoft エッジ Point of Presence (POP) から直接出ていくようにしてください。トラフィックがエッジ POP に到達すると、そこからは最適化された Microsoft のグローバルバックボーンネットワークを通って宛先に到達します。

機密性が高く対話的な分析では、最上位のパフォーマンスを確保するために Microsoft ネットワークのルーティング設定を構成してください。標準のインターネットルーティングは、大量で優先度の低いデータ転送にのみ使用してください。レポートの更新時間を改善するうえで、多くの場合、企業 VPN の迂回を解消することが組織にとって最も効果の大きい変更です。

ハードウェアとホスティング: 実用的なゲートウェイホストの構築方法

ゲートウェイは負荷の大きい処理エンジンであるため、リソースが過剰にコミットされた非力な共有仮想マシン上で動かすと、障害を招くことになります。ゲートウェイホストは、ティア 1 のエンタープライズ基盤として扱う必要があります。

ハードウェアの観点では、最低でも 16 GB の RAM、8 コア以上の物理 CPU、そしてキャッシュとログファイル用の高速な SSD または NVMe ストレージを基準構成としてください。仮想マシンでも問題ありませんが、CPU とメモリのリソースは必ず確実に予約し、過剰にコミットしないようにしてください。

単一障害点を排除し、スループットを拡張するために、少なくとも 2 ノードからなるゲートウェイクラスターを展開してください。クラスター内のすべてのノードでバージョン番号が同一であり、構成も一致していることが極めて重要です。ハードウェアの適切なサイジングを検証するには、組み込みの Gateway Performance レポートと、CPU 使用率、RAM 消費量、プライベートバイト、クエリ実行時間を追跡する Windows パフォーマンスモニター (PerfMon) のカウンターを併用し、実際に重要な指標を測定してください。

予防的な最適化と保守のベストプラクティス

インフラストラクチャには継続的な手入れが必要であり、データゲートウェイも例外ではありません。最も一般的な管理上のミスの一つは、本番環境のゲートウェイで自動更新を有効にすることです。検証されていないソフトウェアの突然の更新は、構成ファイルを変更したり、業務上重要なレポートを壊す互換性の問題を引き起こしたりする可能性があります。

代わりに、本番環境に適用する前に更新をテストするステージング環境を用意してください。クラスターとデータソースの設定は常に維持し、バックアップを取っておくことで、問題が起きた場合にも迅速に復旧できます。更新の急増とスケジュールの関係を把握できる週次のヘルスダッシュボードを作成し、リソースを大量に消費するワークロードを時間帯に均等に分散できるようにしてください。

PowerShell スクリプトを活用して、サービスの状態、ソフトウェアのバージョン、キューの深さを監視する自動ヘルスチェックを実行し、業務時間外に計画的かつ穏やかなサービス再起動を実装してください。OS のビルド、.NET Framework のバージョン、開放されているポート、ウイルス対策の除外設定を文書化してください。ゲートウェイを実際のインフラとして扱うということは、日々の運用に規律ある IT ガバナンスを適用することを意味します。

安定した接続のための実装チェックリスト

これらの考え方をすぐに実践に移せるよう、チームでコピー、貼り付け、レビューに使える簡潔で実行可能なチェックリストをご用意しました。

• モードの確認: 必ず標準ゲートウェイ（Personal は不可）で実行され、少なくとも 2 ノードでクラスター化されていることを確認してください。
• 同時実行数の調整: データソースとノードごとの並列クエリ数を引き上げ、RAM 使用量を監視しながらバッファーサイズを拡大してください。
• ストレージの最適化: ゲートウェイのキャッシュとログを高速な SSD または NVMe ドライブに配置し、包括的なウイルス対策の除外設定を構成してください。
• ストリーミングを評価する: 実際のネットワーク遅延に基づいて、StreamBeforeRequestCompletes の設定を確認してください。
• ルーティングを修正する: Microsoft 365 および Power Platform のエンドポイントについては、トラフィックをローカルで出口させ、不要な VPN やプロキシを迂回させてください。
• トラフィックを優先する: 分析用トラフィックに対して Microsoft ネットワークのルーティング設定が有効になっていることを確認してください。
• ハードウェアを適切なサイズにする: ホストに 16 GB 以上の RAM と 8 個以上の物理コアがあることを確認し、仮想化している場合はリソースを予約してください。
• パフォーマンスを監視する: ゲートウェイのパフォーマンス レポートを有効にし、PerfMon カウンターを接続してください。
• 正常性チェックを自動化する: PowerShell による正常性チェックと、計画的かつ安全なサービスの再起動をスケジュールに組み込んでください。
• 更新を統制する: ソフトウェアの更新はセカンダリ ノードで段階的に適用し、構成のバックアップを保持して、運用上の基準を文書化してください。

まとめ

Power Platform データ ゲートウェイは、単なる橋渡し役や単純な通り道以上の存在です。ハイブリッド分析アーキテクチャの中核に位置する、高度な処理エンジンといえます。既定の設定から離れ、Microsoft のグローバル バックボーンを活用するようにネットワーク ルーティングを最適化し、適切なホスト ハードウェアに投資し、厳格な運用習慣を維持することで、更新時のボトルネックを完全に解消し、組織が求める迅速なレポートを実現できます。

これらのアーキテクチャの原則についてさらに詳しく知り、更新時間を数分単位で短縮する実践的なヒントを得たい方は、ポッドキャスト エピソード Configure the Power Platform Data Gateway for Reliable Connectivity をぜひご覧ください。ぜひお聴きいただき、購読のうえ、今日からエンタープライズ接続を自らの手で管理しましょう。