Power BI の実装計画: データ ゲートウェイ

Note

この記事は、Power BI 実装計画 シリーズの記事の一部です。 このシリーズでは、主に Microsoft Fabric 内での Power BI のエクスペリエンスに焦点を当てます。 シリーズの概要については、「Power BI 実装計画」を参照してください。

この記事は、Microsoft Fabric のオンプレミス データ ゲートウェイと仮想ネットワーク (VNet) データ ゲートウェイを、計画し実装する際に役立ちます。 主な対象者は次のとおりです。

• Fabric 管理者: 組織の Fabric 監視を担当する管理者。 Fabric 管理者は、Power Platform 管理者、データベース管理者、情報セキュリティ チーム、ネットワーク チーム、その他の関連チームとの共同作業を必要とする場合があります。
• ゲートウェイ管理者: ゲートウェイとそのデータ ソース接続の実装、管理、監視を担当する個人。
• ゲートウェイ共同作成者: ゲートウェイのデータ ソース接続の追加と管理を担当する、集約的ではないチームおよび個人。
• センター オブ エクセレンス (COE)、IT、BI チーム: データへのアクセス、接続、更新を行う必要があるユーザーをサポートするチーム。
• コンテンツの所有者と作成者: ゲートウェイを使用してデータ ソースに接続し、Fabric データ項目を更新するチームと個人。

Power BI セマンティック モデル、データフロー、その他の Fabric データ項目のソース データにアクセスするには、データ ゲートウェイが必要となることがあります。 データ ゲートウェイ は、プライベート ネットワークまたはオンプレミスのデータ ソースと、Fabric を含むクラウド サービスの間で、データを安全に転送します。

Note

この記事では、ゲートウェイの概要について説明します。 ここでは、Fabric のコンテンツをサポートするための、ゲートウェイの計画と実装に関する主な考慮事項とアクションに重点を置いています。

ゲートウェイのしくみの詳細については、以下を参照してください。

• オンプレミス データ ゲートウェイとは
• オンプレミス ゲートウェイのアーキテクチャ
• 仮想ネットワーク データ ゲートウェイのアーキテクチャ
• ビジネスクリティカルなゲートウェイ ソリューションの計画、スケーリング、保守

主要な決定事項を計画する

多くの場合、Power BI と Fabric の実装を成功させるためには、ゲートウェイが不可欠です。 一部の組織では非集約的なチームを使用してゲートウェイを管理しますが、通常は、COE または中央のデータおよび BI チームがゲートウェイを計画し、一元的に管理します。 将来の中断とガバナンス リスクの可能性を軽減するには、ゲートウェイを使用する方法と時期を慎重に計画することが重要です。

通常、ゲートウェイの実装は 2 つの異なる段階で計画されます。

• テナントのセットアップ: Fabric の実装、またはそれへの移行を準備する場合は、いずれかのデータ ソースでゲートウェイが必要とされるかどうかを評価します。 ゲートウェイを計画する作業は、セキュリティ、ワークスペース、監査と 監視のテナント レベルの計画策定とも関係しています。
• BI ソリューションの計画: 新しい BI ソリューションを計画する際には、新しいソリューションの技術的な要件を収集 しながら、そのソリューションにゲートウェイが必要かどうかを評価する必要があります。 また、既存のソリューションに新しいデータ ソースを追加する場合にも、ゲートウェイが必要となることがあります。

ゲートウェイ実装の計画は、ゲートウェイが必要かどうかをはじめとした、重要な諸事項の決定により開始されます。

ヒント

まず、データ ソースのインベントリを作成します。 各データ ソースについて、次の重要な決定事項を評価する必要があります。 結果をドキュメント化し、コミュニケーション ハブや一元化されたポータルなど、簡単にアクセスできる中心的な場所に、それらを保存するようにします。

ゲートウェイが必要かどうかを特定します

一般に、次の場合は、データ ソース用にゲートウェイが必要です。

• データ ソースがオンプレミスにある。
• データ ソースがプライベート ネットワーク内にある。
• コネクタ ソフトウェアのホストが必要。
• 特定のコネクタまたは機能のために、セキュリティの分離が必要。

このようなシチュエーションでは、次の目的でゲートウェイが必要です。

• Fabric ポータルでのデータ更新。 このシナリオは、ゲートウェイを必要とするデータ ソースの Power BI サービスで、コンテンツの作成者がデータ更新を設定する場合に適用されます。
• Fabric ポータル内でのコンテンツ作成。 このシナリオは、ゲートウェイを必要とする Power BI サービス内で、コンテンツ作成者がデータ項目 (セマンティック モデルやデータフローなど) を作成または変更する場合に適用されます。
• DirectQuery 接続のサポート。 このシナリオは、コンテンツ作成者が DirectQuery (または Dual) ストレージ モード テーブルを含むセマンティック モデルを発行し、それらのテーブルのデータ ソースでゲートウェイが必要な場合に適用されます。 この使用シナリオには、データ ソースで定義されたデータアクセス許可を、ユーザーごとに適用する機能も含まれます。 たとえば、SQL Server データベースでは行レベル セキュリティ (RLS) を適用でき、Power BI ではシングル サインオン (SSO) 接続を管理できます。 詳細については、「コンシューマーの ID に基づいてデータ セキュリティを適用する」を参照してください。
• SQL Server Analysis Services へのライブ接続。 このシナリオは、SQL Server Analysis Services (SSAS) データベースへのライブ接続を使用するレポートを、コンテンツ作成者が公開する場合に適用されます。

次のセクションでは、ゲートウェイが必要な場合について説明します。

オンプレミス データ ソース

Fabric ポータルからオンプレミスのデータ ソースに接続するには、ゲートウェイが必要です。 ゲートウェイはブリッジとして機能し、ゲートウェイ マシン上のクエリ式の評価と、オンプレミス データのクラウドへの安全な転送を行ないます。

このシナリオは、以下に対し接続する場合に関係があります。

• オンプレミスのマシン上に存在するデータ ソース。
• ローカル ディレクトリに保存されているファイル。
• 単一クエリ内で結び付けられている、クラウドとオンプレミスのデータ ソース。
• クラウドベースの仮想マシン (VM)、いわゆる、サービスとしてのインフラストラクチャつまり IaaS。

プライベート ネットワーク データ ソース

Azure Virtual Network (Azure VNet) などのプライベート ネットワーク内に置かれたデータ ソースに接続するには、ゲートウェイが必要です。 仮想ネットワーク (VNet) とは、ネットワークの論理的に隔離されたセグメントであり、トラフィックをパブリック インターネットから分離します。 VNet により、強化されたネットワーク セキュリティが提供されます。

このシナリオと関係があるのは、データ ソースが次の状態のときです。

• 組織ネットワーク (またはファイアウォールの内側) など、プライベート ネットワーク内のデータ センターに存在する。
• VNet 内のクラウドベースの VM (サービスとしてのインフラストラクチャつまり IaaS) である。
• VNet 内にあるクラウドベースのデータベース サービス (サービスとしてのプラットフォームつまり PaaS) である。

Note

クラウドのデータ ソースにゲートウェイは必要ないというのは、一般的に見られる誤解です。 クラウドのデータ ソースがプライベートな組織ネットワーク内に存在するのであれば、ゲートウェイが必要です。

ホスト コネクタ ソフトウェア

場合によると、データ ソースへの接続に必要なサポート アイテムをホストするために、ゲートウェイが必要になることがあります。 このソフトウェアには、ゲートウェイ マシン上にインストールするカスタム データ コネクタ、ドライバー、またはライブラリなどが含まれます。 クラウドのデータ ソースに接続している場合でも、Power BI サービスはこのソフトウェアにアクセスできないため、このサービスを使用するデータ ソースの更新を、ゲートウェイに依存せずに実行することはできません。

このシナリオは、次のようなコネクタを使用してデータ ソースに接続する場合に関係します。

• ドライバー。 公式コネクタでは、前提条件としてドライバーのインストールが必要な場合があります。 たとえば、Oracle データベースに接続する場合は、Oracle Data Access Client ソフトウェアが必要になります。
• カスタム コネクタ。 一部のデータ ソースでは、カスタム コネクタまたはサード パーティ製のコネクタが必要になります。 たとえば、レガシ システムまたは専用システムに接続する際に、カスタム コネクタが必要となることがあります。
• クライアント ライブラリ。 一部のデータ ソースでは、クライアント ツールからの接続を可能にするために、サポート ライブラリを必要とします。 たとえば、Analysis Services データベースに接続する場合には、クライアント ライブラリのインストールが必須です。
• ODBC または OLE DB コネクタ。 公式コネクタには、ODBC ドライバーまたは OLE DB プロバイダーが必要な場合があります。 たとえば、SAP HANA に接続する場合は、ODBC ドライバーが必要となります。

重要

コンテンツ作成者が Power BI Desktop などのクライアント ツールを使用し、そのソリューションがドライバー、コネクタ、またはプロバイダーに依存している場合は、コンテンツ作成者のマシンにインストールされているのと同じコンポーネントをゲートウェイ マシンにインストールする必要があります。 作成者のマシンとデータ ゲートウェイの間で、コンポーネントが見つからない、一致しないなどは、公開されたコンテンツのデータ更新に失敗する一般的な理由となっています。 詳細については、「ユーザーのツールとデバイス」を参照してください。

セキュリティ分離

Web コネクタや Web.BrowserContents 関数など、特定の Power Query コネクタまたは関数を使用するには、ゲートウェイが必要です。 これらのコネクタと関数では、セキュリティの分離などのさまざまな理由で、ゲートウェイを必要とします。

ヒント

Web ページのデータ ソースに接続する場合は、次の代替手段を検討してください。

• Web.Contents 関数: ブラウザー経由でアクセスする必要のない Web コンテンツに接続する場合は、Web.Contents 関数の使用を検討してください。 この関数ではブラウザー コントロールを使用しないため、ゲートウェイが必要になりません。
• Notebooks: Fabric 容量がある場合は、Fabric ノートブック を使用して データを変換することを検討してください。 Notebooks は Web ページ データ用のゲートウェイを必要とせず、Power Query と比較して、Web ページ情報を取得する際のパフォーマンスが向上します。

このシナリオは、次のようなコネクタとドライバーを使用して、データ ソースに接続する場合に関係します。

• Web コネクタを使用するクエリ。
• Web.Page または Web.BrowserContents 関数を使用するクエリ。
• Access データベース エンジン (ACE) ドライバーを使用する接続。

必要なゲートウェイの種類を決定する

ゲートウェイが必要であることを確認したら、次にインストールするゲートウェイの種類を決定する必要があります。 ゲートウェイには 3 つの種類があります。

• オンプレミス データ ゲートウェイ (標準モード)
• 個人用ゲートウェイとも呼ばれる、オンプレミス データ ゲートウェイ (個人用モード)
• 仮想ネットワーク (VNet) ゲートウェイ サービス

選択するゲートウェイの種類は、実際の要件とデータ ソースによって異なります。 次のセクションでは、3 種類のゲートウェイについて個々に説明します。

オンプレミス データ ゲートウェイ (標準モード)

オンプレミス データ ゲートウェイ (標準モード) では、複数のユーザーが 1 つの共有ゲートウェイを介してデータ ソースに接続することが可能です。 通常、標準モード ゲートウェイは、常時稼働の VM 上に一元的にインストール、管理されます。 標準モード ゲートウェイを使用すると、Fabric、Power BI、その他の Power Platform サービスなど、複数のサービスからデータに接続できます。

次の図に、標準モード ゲートウェイの概要を示します。

重要

この図では、オンプレミス データ ゲートウェイのアーキテクチャは示されていません。

この図は、次の概念を示しています。

Item	説明
	オンプレミス データ ゲートウェイ (標準モード) は、オンプレミスのデータ ソースからクラウド サービスにデータを安全に転送します。
	特定の (前のセクションで説明した) シナリオのクラウド データ ソースには、標準モードのデータ ゲートウェイが必要です。
	標準モードのデータ ゲートウェイは、常時稼働の VM にインストールされます。 管理者は、VM とデータ ゲートウェイを一元的に管理します。 ゲートウェイ管理者は、必要に応じて、データ ソース接続に必要なソフトウェアをインストールします。
	複数のユーザーが、データ ゲートウェイのデータ ソースに接続できます。
	ユーザーは、セマンティック モデル、データフロー、パイプライン、改ページ対応レポートなど、Fabric ワークスペースに発行されたアイテムに対して、データ ゲートウェイを使用できます。
	ユーザーは、Power Platform データフローなど、他の Power Platform クラウド サービスに対して、データ ゲートウェイを使用できます。

次の特定の状況では、標準モードのゲートウェイが必要になります。

• さまざまな Microsoft クラウド サービス (Power Apps や Fabric など) や Fabric データ アイテム (データフローなど) で、オンプレミスのデータ ソース (またはゲートウェイを必要とするクラウド データ ソース) に対するクエリの実行が必要。
• 改ページ対応レポートで、オンプレミスのデータ ソース (またはゲートウェイを必要とするクラウド データ ソース) に対するクエリの実行が必要。
• セマンティック モデルで、オンプレミスのデータ ソース (またはゲートウェイを必要とするクラウド データ ソース) への接続が必要な、DirectQuery ストレージ モードを使用。
• SSAS ライブ接続。
• データ ソースは、カスタム データ コネクタ、ドライバー、またはライブラリに依存します。
• ゲートウェイを再配置または移行する必要性が予想される場合。

Personal Gateway

一般に個人用ゲートウェイとも呼ばれる、オンプレミス ゲートウェイ (個人用モード) を使用すると、ユーザーは同じマシン上にあるオンプレミスのデータ ソースに接続できます。 通常、ユーザーは自分のマシンから、個人用ゲートウェイをインストールして管理します。 個人用ゲートウェイでは、ユーザーは他の Power Platform サービスからのデータに接続できません。 また、ゲートウェイあるいは接続を、他のユーザーと共有することもできません。

個人用ゲートウェイは、1 人の人物による、限定的かつ個人向けの使用を目的としています。 通常はコンテンツ作成者が、個人 BI を遂行するために、これらのゲートウェイをインストールして使用します。 これらのゲートウェイは共有できないため、個人 BI に制限されます。 さらに、パーソナル ゲートウェイでは、パーソナル ゲートウェイ ソフトウェアをダウンロードしてインストールするために、ユーザーがマシンの権限とポリシーによる承認を保持している必要があります。

ヒント

チーム、部門、 エンタープライズ BI ソリューションでは、 個人用ゲートウェイを使用しないでください。

オンプレミス データに接続するほとんどのシナリオでは、ゲートウェイを標準モードで使用する必要があります (前のセクションで説明済み)。 これは、標準モード ゲートウェイは複数のユーザーと共有が可能で、DirectQuery のクエリとライブ接続をサポートしており、ゲートウェイのガバナンスと管理を一元化するためのより多くのオプションを用意しているためです。

注意

通常、個人用ゲートウェイはユーザーのマシンにインストールされるため、管理と統制がより難しくなります。 個人用ゲートウェイを使用する必要がある場合は、サービス アカウントを使用している一元管理の VM に、ゲートウェイを移行することを検討してください。 このアプローチは、ゲートウェイの可用性が (オフになる可能性がある) ユーザー マシンに依存しないことを保証し、ゲートウェイのガバナンスと管理を向上します。

次の図に、個人用ゲートウェイの概要を示します。

重要

この図では、オンプレミス データ ゲートウェイのアーキテクチャは示されていません。

この図は、次の概念を示しています。

Item	説明
	個人用ゲートウェイは通常、ユーザーのマシンにインストールされます。
	個人用ゲートウェイは、ユーザー マシン上のローカル データ ソースからクラウド サービスに、データを安全に転送します。
	通常、個人用ゲートウェイは、インストールしたユーザーによって管理されます。
	1 人のユーザーが限られた個人的な目的に、個人用ゲートウェイを使用します。 個人用モードのゲートウェイを共有することはできません。
	個人用ゲートウェイは、セマンティック モデルや Power BI データフローなど、Power BI ワークスペースに発行されたアイテムに対してのみ使用できます。

繰り返しになりますが、個人用ゲートウェイは、1 人の人物による制限付きの個人的な使用を目的としています。 ただし、個人用ゲートウェイの使用が必須な、特定のシナリオが 2 つ存在します。

• セルフサービス コンテンツ作成者は、自分のマシンまたはその他のオンプレミス データ ソース上のローカル データ ソースに接続されている、発行済みのコンテンツを更新する必要があります。
• セマンティック モデルでは、Power Query で Python または R コード を使用します。

ヒント

可能な限り、個人用ゲートウェイの使用は避けてください。 代わりに、次の代替手段を検討してください。

• SharePoint: 職場用もしくは学校用として、ローカル ファイルに接続する必要がある場合は、代わりに SharePoint または OneDrive にそれらのファイルをアップロードすることを検討してください。 これらのファイルには、ゲートウェイを必要としない SharePoint フォルダー コネクタを使用して接続できます。
• OneLake: ローカル ファイルに接続する必要があり、Fabric 容量がある場合は、OneLake ファイル エクスプローラーを使用して、ファイルをレイクハウスにアップロードしたり同期させたりもできます。 Fabric のレイクハウスへの接続には、ゲートウェイは必要ありません。
• Notebooks: Python または R を使用してデータを変換する必要があり、Fabric の容量がある場合は、Fabric のノートブックを使用して変換したデータを、OneLake に保存されているテーブルに書き込むことを検討してください。 Notebooks では、Python または R コードを実行するためのゲートウェイは必要ありません。 また、ノートブックで使用できるパフォーマンス強化と追加機能のメリットも得られます。

VNet ゲートウェイ

VNet ゲートウェイは、プライベート エンドポイントを使用するデータ ソースなど、プライベート ネットワークで保護されたデータ ソースに複数のユーザーが接続することを可能にします。 VNet ゲートウェイを使用すると、複数のサービスを使用してデータに接続でき、また、ゲートウェイまたは接続を複数のユーザーと共有できます。

VNet ゲートウェイは、Microsoft 管理サービスです。 プライベート ネットワークを使用している組織のユーザーには、VNet ゲートウェイが必要です。

重要

VNet ゲートウェイ サービスの使用を検討している場合は、ネットワークとセキュリティを担当する IT チームと、その点について話し合ってください。 これらのチームは、プライベート エンドポイント (存在する場合) やゲートウェイ通信などの設定が完了していることを、確認する際の助けになります。

VNet ゲートウェイは、Power BI Fabric または Premium 容量でのみサポートされます。 VNet ゲートウェイは、その容量に対する追加の Premium インフラストラクチャ料金 として課金されます。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。 現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。 新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

次の図に、VNet ゲートウェイの概要を示します。

重要

この図では、VNet データ ゲートウェイのアーキテクチャを示していません。

この図は、次の概念を示しています。

Item	説明
	仮想ネットワーク (VNet) ゲートウェイは、Azure VNet 内のデータ ソースと同様に、非公開ネットワーク上のデータ ソースに接続するために使用します。
	VNet データ ゲートウェイは、Microsoft 管理サービスです。 VNet データ ゲートウェイは、Azure portal と Power Platform 管理ポータルから一元的に管理します。
	複数のユーザーが VNet データ ゲートウェイを使用できます。
	ユーザーは、セマンティック モデルなどの Fabric ワークスペースに発行されたアイテムに対して VNet データ ゲートウェイを使用できます。
	VNet データ ゲートウェイは、Power Platform データフローなど、他の Power Platform サービスに対しても使用することができます。

警告

VNet ゲートウェイにはいくつかの 制限があり、すべてのデータ ソースまたはシナリオをサポートしているわけではありません。 VNet ゲートウェイの実装とソリューションの計画に進む前に、データ ソースとシナリオがサポートの対象であることを確認し、よく寄せられる質問を参照してください。

ゲートウェイの数を決定する

ゲートウェイが必要であることを確認し、必要なゲートウェイの種類を判断したら、次に必要なゲートウェイの数を決定する必要があります。

ニーズによっては、複数のゲートウェイが必要になる場合があります。 インストールして使用するゲートウェイの数を決定する際には、次の要因を考慮してください。

可用性とパフォーマンス

ゲートウェイには、更新またはクエリの遅延が原因で起こる中断を回避するために、高い可用性があることが重要です。 ゲートウェイの可用性を保証する 1 つの方法は、高可用性のゲートウェイ クラスターに複数のゲートウェイをインストールすることです。 ゲートウェイ クラスターは、異なる VM にインストールされており、論理的に 1 つの機能ユニット (クラスター) として関連付けられているゲートウェイのコレクションです。 しばしば、各ゲートウェイ マシンはノードと呼ばれます。

ゲートウェイ クラスターを使用することの利点を次に示します。

• 単一障害点を回避する: Failover プライマリ ゲートウェイ マシンが使用できなくなった場合の単一障害点を回避します。 このマシンが使用できなくなった場合には、クエリがクラスター内の別のノードに送信されます。 複数のマシンのクラスターを使用することで、リスクを軽減します。 また、アップタイムも増加するので、高可用性とディザスター リカバリーの要件を満たすために役立ちます。
• パフォーマンスの向上: 負荷の分散 同時使用量が多い場合のパフォーマンスが向上します。 負荷分散は、クラスター内の他のノードにクエリを送信することで、ワークロードを分散します。 これは、プライマリ ゲートウェイがビジー状態のときや、単一の操作 (長いデータ更新など) が多くのリソースを消費している場合に役立ちます。
• ダウンタイムの回避: ゲートウェイ ソフトウェア更新プログラムをインストールするときは、一度ごとに、クラスターの 1 つのノードでインストールを実行します。 そうすることで、クラスター全体をオフラインにすることを回避できます。

重要

ビジネス クリティカルなワークロードには、ゲートウェイ クラスターの使用を強くお勧めします。

ゲートウェイ クラスターの設定の詳細情報とガイダンスについては、「ビジネスクリティカルなゲートウェイ ソリューションの計画、スケーリング、保守」を参照してください。

環境

通常、コンテンツの作成者は、開発、テスト、運用などのビジネスクリティカルなソリューションを開発および管理するために、分離された環境を使用しています。 使用する環境の数とその使用方法によっては、環境ごとに個別のゲートウェイ クラスターが必要になる場合があります。

ゲートウェイ クラスターを異なる環境に分離することは、次を可能にします。

• 開発とテストのアクティビティによって発生する中断を隔離し、それを最小限に抑えます。
• 運用ワークロードの可用性とパフォーマンスを向上しす。
• ゲートウェイ ソフトウェア更新プログラムをインストールおよびテストするための、安全な環境を提供します。

重要

運用ワークロード用には、分離されたゲートウェイ クラスターを用意することをお勧めします。 すべての環境に 1 つのゲートウェイ クラスターを使用した場合、新たなリスクが生じる可能性があります。 コストと管理の労力を最小限に抑えるため、一般に、より少ない (メモリや CPU などの) リソースが、開発用のゲートウェイ クラスターに割り当てられます。

リージョン

データ更新の良好なパフォーマンスを確保するには、データ ソース、ゲートウェイ、およびユーザーが存在している場所を考慮に入れることが重要です。 待機時間を短縮するには、可能な限りデータ ソースの近くに、ゲートウェイをインストールする必要があります。 このため、異なるリージョンやテナントをサポートするために、複数のゲートウェイ クラスターのインストールが必要になる場合があります。

注意

ゲートウェイのインストールが、自分の組織でのデータ所在地要件に準拠していることを確認します。

重要

待機時間を最小限に抑えるために、データ ソースと同じリージョンにあるマシンにゲートウェイをインストールすることをお勧めします。 さらに、VNet ゲートウェイでは、ゲートウェイとデータ ソースは同じサブネット上にある必要があります。

チェックリスト - ゲートウェイの実装を計画する際の、主な決定事項とアクションは次のとおりです。

• データ ソースのインベントリの作成: データ ソースのインベントリにより、ゲートウェイが必要なデータ ソースを検証およびドキュメント化できるようになります。
• ゲートウェイが必要な状況の判断: コンテンツ作成者とコンシューマーがどのような作業を行なうのかを検討します。 ゲートウェイが必要とされる状況を、よく理解しておきます。 ユーザー コミュニティのために、ドキュメントとトレーニングを作成します。
• 必要なゲートウェイの種類の決定: 想定される事項を検証し、考えられる制限事項を評価して、選択したゲートウェイの種類が要件を満たしていることに確信が持てるようにします。
• 個人用ゲートウェイを避ける: 代わりに、標準モードでゲートウェイを使用することを検討します。 リダイレクトして標準モード ゲートウェイを使用するようにできる、個人用ゲートウェイのデータ ソースがあるかどうかを判断します (これにより、使用するのが 1 人の個人に限定されないようにします)。
• ゲートウェイ クラスターが必要かどうかの決定: ビジネス クリティカルなソリューションには、ゲートウェイ クラスターを使用します。 ゲートウェイ クラスターでは、高可用性と負荷分散が提供されます。 これらはまた、単一障害点を回避し、同時使用度が高い期間中のパフォーマンスの向上にも役立ちます。
• 必要なゲートウェイ数の決定: 中断を回避するために、異なる環境用に個別のゲートウェイ クラスターを検討します。 使用状況やリージョンなど、他の要因も考慮に入れます。

ゲートウェイのインストール

この時点で、必要なゲートウェイの種類と数が把握されています。 次に、ゲートウェイのインストールを計画する必要があります。 通常、ゲートウェイは、専用の目的を持つ VM (多くの場合、ゲートウェイ マシンと呼ばれます) にインストールされます。 ユーザー アクティビティとデータ更新操作を継続的にサポートするには、ゲートウェイ クラスター内の各マシンが常にオンになっている必要があります。

Note

VNet ゲートウェイは管理サービスであるため、ダウンロードしてインストールすることはありません。 代わりに、Azure portal で VNet ゲートウェイをプロビジョニングおよび設定し、それを Fabric または Power BI Premium 容量にバインドします。 詳細情報については、「仮想ネットワーク データ ゲートウェイの作成」を参照してください。

ゲートウェイの所有者とインストーラを特定する

ゲートウェイをインストールする前に、ゲートウェイをインストールして所有するユーザーを特定します。

ゲートウェイの所有者

通常、ゲートウェイの所有者とは、ゲートウェイをインストール、所有、管理する技術担当者のことです。 ゲートウェイの所有者は、さまざまなアクティビティを担当します。

• 計画: 前出の説明の通りに主要な事項を決定し、初期のシステム リソースなど、ゲートウェイ マシンの技術仕様を定義します。 また、ゲートウェイの所有者は、サポート プランを確実に配置する必要もあります。
• インストール: ゲートウェイ ソフトウェアをインストールするための適切なマシンを選択して、初回インストールとセットアップを実行します。
• 管理: 最適化のためのゲートウェイの設定または優先事項 (データ のスプールではなくストリーミングの構成など)、または監視の目的 (パフォーマンス ログの構成など) を変更します。 また、ゲートウェイの所有者は、スケールアップ (ゲートウェイ マシンへのリソースの追加)、またはスケールアウト (クラスターへのゲートウェイの追加インストール) を行なう時期についても決定します。
• テスト: 初回セットアップ時にゲートウェイの使用状況を検証し、十分なリソースをゲートウェイ マシンが使用可能であることを確認します。 ゲートウェイの所有者は、毎月の更新をインストールする前に、それらをテストする必要もあります。
• 更新: ゲートウェイ ソフトウェアとサポート アイテム (コネクタ ソフトウェアなど) を適時、更新してインストールします。
• Monitoring: Monitor ゲートウェイ アップタイムと正常性 (問題と異常なアクティビティの監視を可能にする ゲートウェイ ログ ファイルのコレクションを含む 。
• 移行: 広範なチームによるアクセスが可能で安全な場所に、回復キー を保存します。 ゲートウェイの所有者は、これらのキーを使用したゲートウェイの移行、復元、または再配置を、必要に応じて行うユーザーでもあります。

重要

ゲートウェイ所有者は、これらの責任を認識し、それに同意する必要があります。 ゲートウェイの所有者がゲートウェイを管理する準備ができていない場合、これはすぐに、コンテンツの所有者と作成者をブロックする依存関係になり得ます。 さらに、ゲートウェイのインストールと管理の方法をゲートウェイの所有者が理解しているかどうかや、そうでない場合は、それを行うために所有者をトレーニングする方法を特定します。

ヒント

一部の組織では、ビジネス ユニットと部門内でゲートウェイの所有権を適切に許可している一方で、一元化された (IT などの) チームが、ゲートウェイの所有権を保有している組織もあります。 これに対処する方法の 1 つは、IT がゲートウェイ クラスター ノードを管理し、ビジネス ユニットがデータ ソース接続を管理するようなパートナーシップを形成することです。

ゲートウェイの所有権には重要な責任があるため、組織内でゲートウェイをインストールできるユーザーは、明確に定義される必要があります。

ゲートウェイ インストーラ

管理オーバーヘッドを減らしガバナンス上のリスクを軽減するには、組織内のアクティブなゲートウェイの数を制限することが重要です。 これを達成するためには、ゲートウェイをインストールできるユーザーの数を制限することが推奨されます。

警告

ゲートウェイの所有者は、自身が管理するゲートウェイの完全な制御権を保持します。 つまり、悪意のあるゲートウェイ所有者であれば、情報がオンプレミス データ ゲートウェイを通過する際に、それを傍受することが可能だということです。 このため、ゲートウェイをインストールする能力は、信頼されたユーザーに制限することが不可欠です。

標準モード ゲートウェイでは、Fabric ポータルまたは Power Platform 管理センターから、ゲートウェイ インストーラを管理します。 また、ゲートウェイのインストーラ設定を使用して、VNet データ ゲートウェイを作成できるユーザーを管理します。

• ファブリック接続とゲートウェイ ページ: Fabric ポータルの [接続とゲートウェイ] ページ内からゲートウェイ インストーラを管理できます。
• Power Platform 管理センター: また、Power Platform 管理センターから、ゲートウェイ インストーラを管理することもできます。 設定に対するここでの変更の内容は、Fabric から使用するゲートウェイに影響を与えます。

また、オンプレミスのゲートウェイ管理用の PowerShell コマンドレットを使用して、ゲートウェイ インストーラをプログラムで管理することもできます。 個人用ゲートウェイと標準モード ゲートウェイの場合は、これらのコマンドレットを使用して、ゲートウェイ テナントのポリシーを設定できます。 PowerShell を使用してゲートウェイ テナント ポリシーを設定することは、テナントに個人用ゲートウェイをインストールできるユーザーを管理するための唯一の方法です。

重要

個人用ゲートウェイをインストールできるユーザーを厳密に規制し、インストールと使用を有効かつ承認を受けたビジネス ケースに制限することをお勧めします。

ゲートウェイのインストールを準備する

ゲートウェイをインストールして所有するユーザーを特定したら、ゲートウェイのインストールを準備する必要があります。 次のことを行う必要があります。

• ゲートウェイをインストールする場所を特定します。
• ゲートウェイ マシンに必要なリソースを決定します。
• ゲートウェイのインストール時における、ゲートウェイの名前の付与方法に同意します。

次のセクションでは、ゲートウェイのインストールを計画するために重要な、これらの考慮事項について説明します。

ゲートウェイをインストールする場所を特定する

通常、ゲートウェイは、常時オン状態の VM (ゲートウェイ マシンとも呼ばれます) にインストールします。 マシン上には、それぞれの種類 (個人用モードまたは標準モード) のゲートウェイを 1 つだけインストールできます。

ゲートウェイをインストールする場所を決定するための、主な要因を次に示します。

• 場所: 通常、待機時間を最小限に抑えるために、ゲートウェイ マシンはデータ ソースの近くに配置されます。 通常、標準ゲートウェイは、既定のデータ リージョンにインストールされます。 ただし、Premium 容量の場所がテナントの既定のデータ リージョンと異なる場合は、データ所在地の要件を満たすためのオプションとして、Azure Relay の使用についても調査してください。
• サポート アイテム: ゲートウェイ マシンにインストールする必要があるコネクタ、ドライバー、ライブラリを決定します。
• ドメイン: ゲートウェイ マシンとターゲット ドメインに、どのような関係性があるかを決定します。 VM は、ターゲット ドメインとの信頼関係を持つ、ドメイン参加済みのマシンである必要があります。 これをドメイン コントローラーにすることはできません。

ヒント

リソースの競合を回避するために、ゲートウェイ マシンには無関連のソフトウェアをインストールしないでください。 ゲートウェイ マシンは、完全にオンプレミス データ ゲートウェイのホスティング専用である必要があります。

ゲートウェイ マシンのリソースを決定する

ゲートウェイ マシンには、予想されるクエリ ワークロードを処理するための、十分なリソースが必要です。

ゲートウェイ マシンのリソースを決定するための主な要因を次に示します。

• 使用法: ゲートウェイを使用するアイテムの数と種類、およびクエリが (多くのユーザーから) どのように同時実行されるのかを決定します。 使用率が高い場合は、より多くのリソースを持つゲートウェイ マシンが必要です。
• 接続の種類: Power BI セマンティック モデルはデータをインポートするのか、DirectQuery を使用するのか、ライブ接続を使用するのかを決定します。 インポート セマンティック モデルの場合は、ゲートウェイ リソースのニーズ (RAM など) を見積もるために、データ更新の数を確認することが重要です。 DirectQuery またはライブ接続の場合は、リソースのニーズ (CPU など) を見積もるために、レポート コンシューマーの数を評価する必要があります。

ヒント

ロード テストを実行して、ゲートウェイ マシンのリソースを検証します。 この種類のテストは、データセットの更新実行時にゲートウェイ マシンの正常性を監視することと、DirectQuery またはライブ接続レポートでの高い同時使用度をシミュレートすることで実施できます。

名前付け規則に同意する

ゲートウェイとそのデータ ソース接続に、どのように名前を指定するのかは重要です。 名前は、接続する対象をコンテンツ作成者が単刀直入に把握できるようにします。 ゲートウェイとデータ ソース接続に明瞭な名前を付けるためには、論理的な名前付け規則を使用する必要があります。

名前付け規則を定義する際には、次の点を考慮します。

• 監査、ログ記録、トラブルシューティングの目的でゲートウェイを識別するには、名前に Gateway または DataGW を変形して含めます。
• 特定の Fabric アイテム、操作、リージョン、またはビジネス領域をサポートする場合は、そのゲートウェイの具体的な目的を含めます。
• ゲートウェイが特定の環境をサポートしている場合は、名前に Dev、 Test、または Prod を変化させたものを使用します。
• ゲートウェイには、それが属するクラスターの名前に沿った名前を付けます。 たとえば、クラスター内の各ゲートウェイ マシンに、Node1、Node2 と続くような、一意の名前をそれぞれ付けます。

いくつかの論理ゲートウェイの名前の例を次に示します。

• DataGW-Prod-Node1
• Gateway-DevTest-Node1
• Gateway-FinanceTeam-Prod-Node1

ゲートウェイのインストールと設定

主要な事項を決定し準備を行った後、ゲートウェイの所有者はゲートウェイをインストールし、初回のセットアップを実行します。

Note

ゲートウェイをダウンロードしてインストールする方法については、以下を参照してください。

• 標準モード ゲートウェイをダウンロードおよびインストールする
• 個人用モード ゲートウェイをダウンロードおよびインストールする

ゲートウェイのインストールと設定を行なう際には、次の要因を考慮してください。

• インストール場所: ゲートウェイを既定のインストール パス以外の場所にインストールしたい場合は、インストール場所を変更できます。
• 回復キー: 既存のゲートウェイを移行、復元、または引き継ぐ場合は、ゲートウェイの回復キーを使用する必要があります。 回復キーは、他のゲートウェイ管理者がアクセスできる安全で保護された場所に、適切に保管してください。
• データ センター リージョン: リージョンを登録済みサービスのテナントとは異なる場所にしたい場合は、データ センター リージョンを変更できます。
• Azure Relay: 既定のリレーの代わりに独自のリレーを使用したい場合は、独自のリレーの詳細を指定できます。
• プロキシ設定: ご使用の作業環境において、ゲートウェイが Fabric ポータルに接続するためにプロキシ サーバーを経由す必要がある場合は、プロキシを設定する必要があります。
• ゲートウェイ サービス アカウント: 明示的なドメイン アカウントを使用する場合は、ゲートウェイ サービス アカウントを既定の PBIEgwService から変更できます。
• 通信設定: 送信接続がファイアウォールによりブロックされる場合、セキュリティチームとネットワーク チームは、ゲートウェイから関連付けられた Azure リージョンへの送信接続を許可するように、ファイアウォールを設定できます。
• テナントの登録: どの時点で、データ流出を防ぐために、オンプレミスのデータ ゲートウェイ アプリケーションを登録することが許可されたテナントを制限するか。
• 統合テナントの設定: ゲートウェイがシングル サインオン (SSO) で (たとえば、Microsoft Entra ID ベースの認証を使用して)、意図した方法通りに動作していることを、どの時点で確認するか。

重要

テナントの登録は、組織内のテナントのみに制限することをお勧めします。 既定の設定ではテナントの登録先に制限がないため、この手順はゲートウェイのセキュリティを向上するのに役立ちます。

チェックリスト - ゲートウェイを準備およびインストール際の、主な決定事項とアクションは次のとおりです。

• ゲートウェイの所有者とインストーラの特定: ゲートウェイの所有者が各自の責任を認識していることを確認します。 ゲートウェイのインストールを適切なユーザーに制限します。
• トレーニングの実施: ゲートウェイを効果的にインストール、管理、サポートするために、必要に応じて、ゲートウェイの所有者とインストーラーをトレーニングします。 必要な場合には、バックアップのためのクロストレーニングを実施します。
• 名前付け規則の作成: 目的、環境、クラスター ノード、サポートされているユース ケース、または実行する操作に対応して、ゲートウェイの名前付け規則を作成します。
• リソースのニーズを考慮する: 初期リソース (メモリや CPU など) を決定するために、ワークロードと使用状態がどうなるのかを確認します。
• 統合テナントの設定: 統合テナントの設定を レビューおよび指定し、ゲートウェイがシングル サインオン (SSO) で、意図した方法通りに動作するようにします。
• ゲートウェイ マシンのプロビジョニング: ゲートウェイ操作をサポートするのに十分なリソースを備えた、常時オン状態の VM を設定します。
• ゲートウェイのインストール: ゲートウェイ マシンでゲートウェイの初回セットアップを実行します。
• サポート アイテムのインストール: 対象のシナリオをサポートするために、カスタム データ コネクタまたは依存するソフトウェアをインストールします。

ゲートウェイを管理する

ゲートウェイをインストールした後は、データ ソース接続を追加します。 これらの接続を追加するときには、ゲートウェイとその接続へのアクセスをどのように管理するのかも、計画する必要があります。

データ ソース接続:を追加する

ゲートウェイを使用する前に、初期データ ソース接続を追加する必要があります。 接続の追加は、Power BI サービスまたは Power Platform 管理センターから手動で、または Power BI REST API を 使用してプログラムで行ないます。

接続を追加する際には、次の点を考慮してください。

• 保存された資格情報: データ ソースへの接続に、どの資格情報を使用するかを検討します。 接続を追加する場合、そのデータ ソースの資格情報を指定する必要があります (匿名認証がサポートされている場合を除く)。 この決定は重要です。データ ゲートウェイの Microsoft Entra シングル サインオン (SSO) を使用していない限り、データ ソースに対するすべてのクエリは、これらの資格情報を使用して実行されるためです。
• 名前付け規則: ゲートウェイと同様、接続においても、論理的かつ一貫性のある名前付け規則を使用する必要があります。 接続の名前は、データ ソースの名前に対応させます。 たとえば、 FinanceDB-Prod は、データ ソースを示す論理的な名前です。
• シングル サインオン: DirectQuery で (Active Directory SSO または Microsoft Entra SSO を使用して) シングル サインオン (SSO) を使用する場合は、Fabric の管理者設定で、ゲートウェイ の Microsoft Entra シングル サインオン (SSO) オプションを有効にする必要があります。 レポート ユーザー ID に基づいて、データ ソース システムでデータ セキュリティを適用する場合は、SSO を使用する必要があります。
• プライバシー レベル: データ ソース接続のインポート用に、プライバシー レベルを設定する必要があります。 データ ソースを適切に分離するためには、必要に応じて、適切なプライバシー レベルを選択する必要があります。 Power BI Desktop で設定されたプライバシー レベルは、ゲートウェイでは歓迎されないと理解しておくことが重要です。

Note

データ ソース名は後で変更できますが、サーバー名とデータベース名は、セットアップした後で変更することはできません。 エラーを回避するには、データ ソース情報が確実に Power BI Desktop で使用される情報と一致するようにします。

ヒント

効率と精度を向上させるには、Power BI REST API を使用してデータ ソース接続の作成を自動化することを検討してください。 この場合、接続を作成または更新するそれぞれの要求を自動的に処理するだけではなく、レビューと承認のプロセスを含めることをお勧めします。

ゲートウェイ アクセスをプロビジョニングする

初期データ ソース接続を追加した後は、ゲートウェイとその接続の両方へのアクセスを管理する方法を決定します。

コンテンツ作成者は、データ ソースに正常に接続するためにゲートウェイ接続にアクセスする必要があります。 ゲートウェイ接続へのユーザー アクセスは接続ごとに行われるので、各ゲートウェイ接続へのアクセスを必要とするユーザーと、そのアクセスを管理する方法を検討します。 ゲートウェイと接続の両方に対し、セキュリティ ロールを使用してアクセスを管理する必要があります。

ゲートウェイのロール

ゲートウェイ ロールにより、ゲートウェイとそのデータ ソース接続を管理できるユーザーを制御できます。 これらのロールはワークスペース ロールと同様に機能し、ロールに応じて異なるアクセスを許可します。 ロールを使用すると、ゲートウェイ アクセスをより効果的に管理できます。

ヒント

セキュリティ グループを使用して、個々のアカウントではなくロールのメンバーシップを管理することをお勧めします。 この方法により、特に複数のゲートウェイ間でユーザーを管理することが簡単になります。 同じセキュリティ グループで、行レベル セキュリティ ロールのメンバーシップやアプリ対象ユーザーのメンバーシップなど、異なるアクセス制御を管理できます。

重要

データ ソースへの接続のためだけにゲートウェイを使用する必要があるユーザーは、ゲートウェイ ロールに属している必要はありません。 この場合には、ユーザー接続ロールのみを使用します。

オンプレミスの標準ゲートウェイの管理用としては、3 つのゲートウェイ ロールが存在します。

• 管理者: このロールのメンバーは、ゲートウェイを管理および更新できます。 通常、ゲートウェイの所有者はゲートウェイ管理者ですが、1 つのゲートウェイに複数の管理者が存在する場合もあります。 ゲートウェイ管理者は、Fabric の管理者であるか、COE または中央 BI チームのメンバーである必要があります。 管理者の役割は、ゲートウェイ所有者と同じです。
• 共有を使用する接続作成者: このロールのメンバーは、ゲートウェイ接続の作成、ゲートウェイの状態のテスト、他のユーザーとのゲートウェイの共有を行うことができます。 このロールでは、ゲートウェイからユーザーを削除することはできません。 ビジネス ユニットの非集約型チームなどで、分析ソリューションのサブセットを担当する場合には、このロールにユーザーを追加することを検討してください。 このロールを担うユーザーの役割には次が含まれます。
  • 新しい接続の設定とテスト。
  • 資格情報の設定など、自身が所有する接続の管理。
  • 必要とする他のユーザーとのゲートウェイの共有。
  • ゲートウェイへのアクセス権を持つユーザーを定期的にレビューし、ゲートウェイをまだ必要としているかどうかを検証し、不要である場合は削除します。
• 接続作成者: このロールのメンバーは、ゲートウェイ上で接続を作成し、その状態をテストできます。 接続作成者は、ゲートウェイを使用するための正しい接続を適切に設定できる、コンテンツ所有者である必要があります。 接続作成者ロールの役割は、ゲートウェイへのアクセスを共有できない点を除いて、共有を使用する接続作成者ロールと同じです。

Note

VNet ゲートウェイでは、管理者のゲートウェイ ロールのみがサポートされます。

データ ソース接続ロール

データ ソース接続ロールでは、接続を使用、管理、共有できるユーザーを制御できます。 接続ロールを担うユーザーは、ゲートウェイ ロールに属す必要はありません。

データ ソース接続には 3 つのロールがあります。

• 所有者: このロールのメンバーは接続を管理し、不要な場合にはそれを削除することができます。 所有者は、他の接続の所有者を追加することを含め、接続ロールを管理できます。 また通常、所有者は接続の作成者でもあります。 誰かがデータ ソースのスチュワードまたは管理者であるか、データ ソースとその内容に関して顕著な知識を持っている場合は、その人物を接続所有者にすることを検討してください。 所有者の役割には次が含まれます。
  • 資格情報の更新など、必要に応じた接続の管理。
  • 不要になった場合の接続の削除。
  • Power Platform 管理センターからの接続ロールの管理。
• 共有を使用するユーザー: このロールのメンバーは、他のユーザーを追加することで、データ ソースを使用および共有できます。 誰かがユーザー コミュニティで重要な役割を果たしている場合は、その人物をこのロールに追加することを検討してください。 チャンピオンは、この役割に適した候補だと言えます。 このロールを担うユーザーの役割には次が含まれます。
  • それを必要とする他のユーザーとの接続の共有。
  • 接続にアクセスできるユーザーの定期的なレビュー、まだ接続を必要としているかどうかの確認、および不要な場合の削除。
• ユーザー: このロールのメンバーは、Power BI レポートと Power BI データフロー内でデータ ソースを使用できます。 ユーザーの役割は、ワークロードとクライアント ツールからのデータに対してクエリを実行することのみです。

ヒント

過剰な共有からのガバナンス リスクを防止するには、ゲートウェイと接続の共有ができるユーザーを、このタスクを効果的かつ責任を持って実行できる特定の個人に制限する必要があります。

ゲートウェイと接続をドキュメント化する

ゲートウェイ クラスターを設定したら、そのドキュメント化を行なう必要があります。 コンテンツ作成者には見つけやすく、ゲートウェイ管理者には管理しやすくするために、ゲートウェイのドキュメントを作成します。 ゲートウェイドキュメントは、関連する実践コミュニティの一元化されたポータルのような、アクセス可能な場所に保存することを考慮します。

ドキュメント化では以下の情報を考慮に入れます。

• ゲートウェイ名と GUID
• ゲートウェイ マシン名 (およびそれぞれの識別子)
• ゲートウェイ所有者
• ソフトウェアの最終更新日 (ゲートウェイ のバージョン)
• ゲートウェイ クラスターの目的 (環境、リージョン、ビジネス領域など)
• ゲートウェイで維持する必要があるデータ ソース接続
• ゲートウェイが、ユーザー ID と保存された資格情報のどちらを使用するか
• アクセス管理ポリシー (ゲートウェイ ロールと接続ロールをどのように使用するか)

重要

標準モード ゲートウェイのゲートウェイ 回復キー を、確実にドキュメント化するようにします。 これらの回復キーは、ゲートウェイを回復または再配置する必要がある場合に必要となります。 この情報は、中央チーム内の信頼できる複数のユーザーがアクセス可能な、安全かつ保護された場所に保管してください。 組織にパスワード コンテナーがある場合は、その場所が理想的です。

ゲートウェイを更新

ゲートウェイの機能性と良好なパフォーマンスを維持するには、いくつかのタスクを実行する必要があります。

• Windows 更新プログラムをインストールし、他のサーバー メンテナンスを実行します。
• ゲートウェイ ソフトウェアを更新します。 ゲートウェイ ソフトウェアは毎月更新され、オンプレミス ゲートウェイについて Microsoft は、最後の 6 つのリリースのみをサポートします。
• 必要に応じて、カスタム データ コネクタ、ドライバー、ライブラリを更新します。

Note

ゲートウェイ所有者は、各ゲートウェイに対し、ゲートウェイの更新を手動で適用する必要があります。 このため、ゲートウェイを一定期間ごとに更新するよう、プロセスを計画することが重要です。

ヒント

Power Query Online 環境を使用して作業する場合、Power Query エンジンは、利用可能な最新バージョンの Power Query を使用します。 ただし、ゲートウェイを使用して変換を適用する場合は、ゲートウェイ マシンにインストールされているバージョンが使用されます。 一貫性のあるユーザー エクスペリエンスを保証するには、ゲートウェイ マシンを最新の状態に保つことが重要です。

このセクションの残りの部分では、ゲートウェイ ソフトウェアを更新する方法について説明します。

開発用またはテスト用ゲートウェイに更新内容をインストールする

予期しない中断を回避し、最新の機能強化の恩恵を受けるためにも、ゲートウェイを最新の状態に保つことは重要です。 とはいえ、更新によって、ゲートウェイのパフォーマンスと機能に予期しない結果が生じる可能性があります。 ビジネスクリティカルなソリューションに影響を与えないようにするには、まず (運用環境をサポートするゲートウェイに適用する前に)、ゲートウェイのソフトウェア更新プログラムを開発ゲートウェイまたはテスト ゲートウェイにインストールしてみる必要があります。

更新プログラムを確認する

ゲートウェイのテストは、最初に、開発とテストの環境をサポートするゲートウェイに更新プログラムを適用することで行ないます。

ゲートウェイの更新を確認する際には、次の点を考慮に入れてください。

• 反復可能なテスト条件の定義: すべての関連するゲートウェイ操作とデータ ソースを確実にテストできるように、反復可能なテスト条件のリストを定義します。 たとえば、重要と見なされ検証が必要なレポートとセマンティック モデルを、特定することが考えられます。 また、反復可能なテスト条件として適格な、コンプライアンス要件を満たす必要がある場合もあります。
• テスト レポート セットの使用: ゲートウェイが更新されるたびの機能テストに、一連のレポートが使用されるよう維持します。 これらのレポートは、反復可能なテスト条件をすばやく検証するのに役立ちます。 多くの場合、これらのテスト レポートは合計とカウントのみを示します。 目標とするのは、次についてのアクセス、レンダリング、更新を確実にテストすることです。
  • 共通で使用される各データ ソース。
  • 最もクリティカルなセマンティック モデルなど、データ項目の各キーの種類。
  • インポートや DirectQuery など、さまざまなストレージ モード。
• ビジネスクリティカルなレポートの特定: 新しい更新内容をテストできる、ビジネスクリティカルなレポートにアクセス (またはそのコピーを取得) します。 これらのレポートは、データを更新できることと、DirectQuery レポートが期待どおりに動作していることを、確認するのに役立ちます。
• テスト プロセスの自動化: Power BI REST API を使用して、インポート データ項目のデータ更新をテストし、DAX クエリを評価します。 更新の失敗やクエリ エラーをキャッチしてログに記録できることを確認します。

重要

ゲートウェイの更新内容は、運用環境に適用する前に、開発用クラスターやテスト用クラスターでテストすることを強くお勧めします。 更新プログラムにはロールバックのプロセスがないため、テストは重要です。 別の方法として、更新を開始する前に、マシン上のファイル システム構造とデータの完全なコピーである、VM イメージを作成することもできます。

運用環境に更新内容をインストールする

ゲートウェイの更新を検証した後は、運用環境をサポートするすべてのゲートウェイに、その更新プログラムを適用します。 更新中のゲートウェイは利用不可となるため、ゲートウェイ を更新するタイミングと方法には、一貫性を持つ必要があります。

ゲートウェイの更新については、次の点を考慮してください。

• 一元化されたポータルで、ゲートウェイの現在のバージョンをドキュメントします。
• 履歴上、ゲートウェイ使用率が低い期間中に、更新プログラムを適用します。
• 更新内容をテストおよび適用する時期には、一貫性のあるスケジュールを使用します。 毎月の更新が頻繁すぎる場合は、少なくとも四半期ごとにゲートウェイが更新されることを保証してください。
• ゲートウェイ クラスター マシンは、一度に 1 つ更新します。 各マシンをローテーションさせることで、ダウンタイムを回避できます。

資格情報の更新

保存された資格情報を必要とするデータ ソース接続の場合は、資格情報を定期的にローテーションすることが必要になる場合があります。 たとえば、組織のポリシーで、頻繁なパスワードのリセットを要求している場合があります。 この方法は、主要なチーム メンバーが組織を離れる場合にも有益です。 効率を向上させるため、資格情報の更新に Power BI REST API を使用できます。

チェックリスト - データ ゲートウェイを管理する場合の主な決定事項とアクションには、次が含まれます。

• データ ソース接続の作成: 組織で共通したデータ ソースの、データ ソース接続を設定します。 その接続は、明確で一貫性のある名前付け規則に従っていることを確認します。
• ゲートウェイとデータ ソースをドキュメント化する: ゲートウェイと接続に関する簡潔なドキュメントを作成します。 このドキュメントには、ゲートウェイの所有者と管理者向けの一元化されたポータルから、簡単にアクセスできるようにします。
• 接続要求の処理: 接続要求を収集および管理するプロセスを作成します。 接続要求に承認プロセスが必要かどうかを判断します。 Power BI REST API を使用してプロセスを自動化することを検討します。
• ゲートウェイ ロールのプロビジョニング: 最小特権の原則を使用して、ゲートウェイ ロールに個人を割り当てます。 接続作成者または共有を使用する接続作成者が接続管理に貢献できるようにするため、これらのユーザーにデータ ソース スチュワードを追加することを検討してください。
• 接続ロールのプロビジョニング: コンテンツ作成者 (および該当する場合はコンシューマー) を接続ロールに割り当てて、ゲートウェイを使用できるようにします。 これらのユーザーに共有を制限し、責任を持って接続を共有し、アクセスを定期的にレビューおよび管理します。
• 簡潔なユーザー ドキュメントの作成: コンテンツ作成者がゲートウェイとその接続を検索して使用するための、主だった重要な項目をドキュメント化します。 このドキュメントは、たとえば一元化されたポータルや SharePoint のサポート サイトなど、ユーザー コミュニティが簡単にアクセスできる一元的な場所に配置します。
• 回復キーの慎重なドキュメント化と保存: 回復キーは、複数のチーム メンバーがアクセスできる、安全で保護された場所に保存します。 ゲートウェイを回復する必要がある場合に、それらを簡単に見つけられるようにします。
• 更新をインストールするプロセスの作成: ゲートウェイ ソフトウェア更新プログラムをインストールする頻度と、従うべきプロセスを決定します。 更新のリリース後、1 か月から 3 か月以内にゲートウェイを更新することを目指します。
• 最初にゲートウェイの更新を開発およびテスト向けにインストールする: 運用前に開発およびテスト向けゲートウェイが更新され、初期テストに使用されていることを確認します。
• 運用ゲートウェイに適用する前にゲートウェイの更新をテストする: 繰り返しが可能なテスト条件と項目を使用して、毎月のゲートウェイ更新をテストするプロセスを設定します。
• 運用時はゲートウェイの更新を迅速かつ定期的にインストールする: 運用ゲートウェイは、確実に最新の状態に保たれているようにします。
• 接続資格情報の更新: 必要に応じて、保存されている資格情報を接続で使用するように更新します。

ゲートウェイの監視、監査、最適化

ゲートウェイは、Fabric データ統合にとって極めて重要な部分です。 中断を回避しリスクを軽減するには、定期的にテナント内のゲートウェイを監査し、監視を行なう必要があります。

ゲートウェイの監視は、次のことに役立ちます。

• ガバナンス リスクの軽減。
• 問題の回避。
• パフォーマンスの問題やデータ更新での失敗など、インシデントの調査。

次の表に、データ ゲートウェイ クラスターを管理するときに発生する可能性がある一般的な問題の概要と、問題を監視および調査する方法を示します。

可能性のある問題	問題の種類	問題を監視および調査する方法
多すぎるゲートウェイ数	ガバナンス	• Power Platform 管理センター • ゲートウェイ PowerShell コマンドレット • Power BI REST API
ゲートウェイの過剰共有	ガバナンス	• Power Platform 管理センター • ゲートウェイ PowerShell コマンドレット • Power BI REST API • Power BI アクティビティ ログ
ゲートウェイがオフライン	パフォーマンスと可用性	• Power Platform 管理センター • ゲートウェイ マシンの監視 • ゲートウェイ ログ
ゲートウェイのエラー	パフォーマンスと可用性	• ゲートウェイ ログ
クエリの失敗	パフォーマンスと可用性	• ゲートウェイ ログ • ゲートウェイ ログ (追加ログ)
低速な更新またはクエリ	パフォーマンスと可用性	• ゲートウェイ マシンの監視 • Windows イベント ログ • Windows パフォーマンス カウンター • ゲートウェイ ログ • ゲートウェイ ログ (追加ログ) • サーバー監視ツール

Note

ゲートウェイの監査と監視の詳細情報については、以下を参照してください。

• オンプレミス データ ゲートウェイのパフォーマンスの監視と最適化
• Power BI の実装計画: データレベルの監査
• Power BI の実装計画: テナントレベルの監査

ヒント

Fabric 容量を使用する場合は、Fabric のツールが、組織のゲートウェイ監視ソリューションをビルドおよび調整するのに最適なコンポーネントを提供できます。 たとえば、次のことができます。

• Data Factory を使用してゲートウェイ ログをコピーし、OneLake に配置します。
• ノートブックを使用して、Power BI REST API を使用してゲートウェイ情報をプログラムで収集し、ゲートウェイ ログ ファイルをテーブルに変換します。
• Power BI を使用してセマンティック モデルを作成し、ゲートウェイの正常性に関するレポートを作成します。
• Fabric Activator を使用して、異常や中断が発生したときにゲートウェイの所有者と管理者にアラートを送信します。

ゲートウェイの監視

テナントにインストールされているゲートウェイの数と、だれがインストールしたかを、定期的にレビューする必要があります。 Fabric ポータルの [接続とゲートウェイ] ページ、および Power Platform 管理センターから、ゲートウェイがどの程度行き渡っているかを監視できます。 どちらのビューも、アクセスできるすべてのゲートウェイについて、簡潔かつ機能的な概要を提供します。 管理者は、この情報を定期的にレビューする必要があります。

Note

また、PowerShell コマンドレット を使用するか、Power BI REST API を使用して、ゲートウェイの一覧をプログラムで取得することもできます。 さらに、アクティビティ ログを使用して、ゲートウェイのインストール イベントを識別することもできます。

この情報を、ゲートウェイ データ ソースの数と種類に関する集計分析と組み合わせることも考慮してください。 この情報は、テナント全体のガバナンスまたは監査および監視に関する、統合されたレポート内に示すことができます。

ゲートウェイの普及度合いを監視する場合は、次のメトリックに注目してください。

• 上昇しているゲートウェイまたはインストーラーの数: 予期していない新規のゲートウェイまたはインストーラーは、調査する必要があります。
• ゲートウェイ間の接続の冗長性: ゲートウェイの余分なメンテナンス作業を回避するために、接続を統合することを試します。
• 予期しないインストーラーまたはゲートウェイ: 新しいインストーラーまたはゲートウェイがインストールされる前に、それらの承認プロセスが完了していることを確認します。
• 予期しないゲートウェイ マシン、接続、または構成: ユーザー マシンにインストールされているゲートウェイやローカル ファイルへの接続など、異常なゲートウェイ プロパティは特定しておく必要があります。 また、プライバシー レベルの無視など、リスクを生み出す設定内容も特定します。

ゲートウェイ ログの収集と分析

各ゲートウェイ マシンは、問題の特定と解決に使用できる詳細な ログ を生成します。 これらのログは、詳細な技術ファイルのコレクションであり、ゲートウェイ マシンに格納されます。 また、オンプレミス ゲートウェイ アプリからの追加ログを一時的に有効にして、クエリとそのタイミングについての、より詳細な情報を収集することもできます。

ネットワークの遅延が引き起こされないようにするために、ゲートウェイ ログは、ローカル ゲートウェイ マシンに書き込めるようにすることをお勧めします。 ただし、ログが書き込まれるパスを、ゲートウェイ構成ファイルを使用して変更することもできます。 また、ログを保持する期間の長さも変更できます。 構成ファイルを編集する際は、必ず事前にコピーを作成してください。

データを分析できるように、各ゲートウェイ マシンからログ ファイルを収集して統合する、データ統合ソリューションを作成します。 理想的には、すべてのゲートウェイを簡単に表示し異常を特定できるように、このプロセスを自動化し分析レポートに出力させる必要があります。

ヒント

ゲートウェイと接続の異常なアクティビティについての通知を、データ アラートを使用して、ゲートウェイ管理者とデータ ソース接続作成者に、それぞれ送ることを検討します。 それにより、これらのユーザーは直ちに修正アクションを講じることができます。

ゲートウェイ マシンの正常性を監視する

ゲートウェイの正常性は、そのサーバーの正常性に依存します。 中断を回避するには、ゲートウェイ マシンを監視して、マシンのパフォーマンスが良好でない、あるいはオフラインになったことを検出する必要があります。

ヒント

サーバーの監視に組織が使用している企業向け監視ツールに、対象のゲートウェイ マシンが追加されていることを確認します。

ゲートウェイを最適化しトラブルシューティングする

ゲートウェイで問題が発生した場合は、その問題を調査および特定する必要が生じます。 通常、トラブルシューティングでは、前出のセクションで説明したゲートウェイ ログを調査し、さまざまな最適化をテストして問題が解決されるかどうかを確認します。

一般的なゲートウェイの最適化を次に示します。

• スプーリングからストリーミングへの変更: ゲートウェイの既定では、クエリを評価する際、ゲートウェイ マシンにデータをスプールします。 その結果、クラウドに転送される前にデータが一時的に保存されます。 スプーリングは、代替方法の (データが直接転送される) ストリーミングより低速になることがあります。 この設定は、ゲートウェイ構成ファイルで変更できます。
• ウイルス対策スキャン: ゲートウェイ コンピューター上のウイルス対策スキャンから 特定のフォルダーを除外すると、ファイル レベルのウイルス対策ソフトウェアを使用する場合のパフォーマンスが向上します。
• スケールアップまたはスケールアウトの計画: どの場合に、ゲートウェイ マシンにリソースを追加してゲートウェイ クラスターをスケールアップするのか、または別のゲートウェイを別のマシンに追加してクラスターをスケールアウトするのかを検討します。

重要

VNet ゲートウェイは、スケーリングや変更ができない、単一のハードウェア構成を使用します。

Note

ゲートウェイの最適化とトラブルシューティングの詳細情報については、以下を参照してください。

• オンプレミス データ ゲートウェイのトラブルシューティング
• 仮想ネットワーク データ ゲートウェイのトラブルシューティング
• ビジネスクリティカルなゲートウェイ ソリューションの計画、スケーリング、保守

チェックリスト – ゲートウェイを監視する際の主な決定事項とアクションには、次が含まれます。

• ゲートウェイ マシンの監視: 企業の監視ソリューションによって監視されているマシンに、ゲートウェイがインストールされていることを確認します。 それ以外の場合は、これらのマシンのパフォーマンスが良好でないときに、それを検出できる必要があります。
• ゲートウェイの普及度を測定する: 時間の経過に伴いテナントにインストールされているゲートウェイの数が、どのように発展しているかを監視します。
• ゲートウェイ ログの収集と分析: さまざまなゲートウェイ マシンからのログ ファイルを、自動的に収集して結合するソリューションを作成します。 これらのファイルを分析して、有意義な情報を抽出します。 次の 2 種類の分析監視ソリューションを設定することを検討してください。1 つはアラートとアクション用、もう 1 つは問題発生時の調査的根本原因分析用です。
• 役割と責任の検証: 監視、最適化、トラブルシューティングのために、ロールと責任が定義されていることを確認します。

関連するコンテンツ

Power BI の実装の決定に役立つ考慮事項、アクション、意思決定基準、推奨事項について詳しくは、「Power BI 実装計画」をご覧ください。