次の方法で共有

ビジネスクリティカルなゲートウェイ ソリューションの計画、スケーリング、保守

  • [アーティクル]

この記事は、ビジネスクリティカルなシナリオでオンプレミスのデータ ゲートウェイの展開を計画しているすべてのユーザーを対象としています。 オンプレミスのデータ ゲートウェイは、ビジネスの通常の運用に不可欠で、ビジネスクリティカルなデータを処理する場合は、ビジネスクリティカルになります。

ビジネスクリティカルなゲートウェイが適切に管理されていない場合、クエリが失敗したり、パフォーマンスが低下したりするおそれがあります。 ビジネスクリティカルなゲートウェイ ソリューションを適切に計画、スケーリング、保守すると、ビジネスに影響を与える問題が発生する可能性を最小限に抑えることができます。

用語

この記事では、次の重要な用語が使用されています。

  • ゲートウェイ: コンピューターにインストールされるオンプレミスのデータ ゲートウェイ アプリケーション。
  • ゲートウェイ サーバー: オンプレミス データ ゲートウェイ アプリケーションがインストールされている Windows コンピューター (仮想マシンまたは物理コンピューター/サーバー)。
  • ゲートウェイ クラスター: 連動する (および負荷分散されている可能性がある) ゲートウェイのセット。
  • ゲートウェイ メンバー: ゲートウェイ クラスターの一部であるゲートウェイ。

次の画像は、上記で定義されている概念間の関係を示しています。

3 つのゲートウェイ サーバーの一部としてのゲートウェイ クラスターの画像。それぞれに個別のゲートウェイが含まれています

ビジネスクリティカルなゲートウェイに関する推奨事項

ビジネスクリティカルなゲートウェイの場合、高可用性、優れたパフォーマンス、保守可能なスケーラビリティを確保するために、ゲートウェイを適切に展開し管理する必要があります。 ゲートウェイを正しく展開しないと、パフォーマンスが低下し、クエリが失敗し、潜在的な問題の診断が困難になる場合があります。 また、使用量の増加に応じてゲートウェイをスケールアップおよびスケールアウトする機能が損なわれるおそれもあります。

最適なスケーラビリティ、パフォーマンス、スループットを確保するには、次のセクションの推奨事項に従います。

すべてのゲートウェイ回復キーを知っている

すべてのゲートウェイ回復キーがわかっていて安全な場所に保管されていることを確認します。 回復キーがないと、ゲートウェイを回復またはダウングレードできません。 この制限は仕様です。 回復キーを紛失した場合は、新しいゲートウェイを作成してデータ ソースを再作成するしかありません。 また、回復キーがないと、クラスターに新しいゲートウェイを追加できません。これにより、今後のスケーラビリティが制限されます。

回復キーは、管理者資格情報を保存するのと同じように権限のある管理者のみがアクセスできるパスワード セーフなどの安全な場所に保存します。

現在、すべてのゲートウェイ回復キーを把握していない場合、これは重大なビジネス リスクになります。 すぐに新しいゲートウェイ クラスターを作成し、ワークロードのゲートウェイ クラスターへの移行を開始してください。

開発ワークロードとビジネスクリティカルなワークロード

以下に説明するように、1 つ以上の開発ゲートウェイ クラスターと 1 つ以上の運用ゲートウェイ クラスターを設定して、開発ワークロードをビジネスクリティカルなワークロードから分離します。

3 つのゲートウェイを備えた開発およびテスト ゲートウェイ クラスターと、3 つのゲートウェイを備えた別の運用クラスターの画像

開発ゲートウェイ クラスターを使用して、新しいセマンティック モデル、レポート、クエリなどをテストします。 新しいワークロードが検証されたら、それをビジネスクリティカルなゲートウェイ クラスターに移行します。 このプロセスは、新しい、テストされていない、または実験的なワークロードにより、運用ワークロードのパフォーマンスに影響が生じるのを防ぎます。

また、開発ゲートウェイ クラスターを使用して、ビジネスクリティカルなゲートウェイ クラスターに更新を適用する前に、新しいゲートウェイの更新をテストします。 新しいゲートウェイの更新プログラムは、ビジネスクリティカルなゲートウェイ クラスターで使用する前に、開発ゲートウェイ クラスターに少なくともで 24 時間展開する必要があります。

複数のゲートウェイ クラスターを使用する

組織内の多数のユーザーのためにゲートウェイ クラスターを作成する場合は、ビジネス ユニット以下の単位に基づいて複数のゲートウェイ クラスターを作成し、パフォーマンスへの潜在的影響をユーザーの小さなサブセットに制限する必要があります。

会社全体で単一のビジネスクリティカルなゲートウェイ クラスターを使用することはお勧めしません (会社が小規模な場合を除く)。 単一のゲートウェイ クラスターのシナリオでは、1 人のユーザーがクエリを送信しただけで、ゲートウェイ全体のすべてのトラフィックに重大なパフォーマンスの影響が生じることがあります。 ゲートウェイが会社全体で使用されている場合、パフォーマンスへの影響が会社全体に及ぶおそれがあります。 また、ゲートウェイ クラスターが会社全体で使用されている場合、ゲートウェイ パフォーマンス モニターを使用しているときに、パフォーマンスの問題の原因となったクエリを特定しにくくなることがあります。

エンタープライズ BI とアプリ、財務部門、マーケティング部門、および個人の BI とアプリ用に個別のゲートウェイ クラスターを備えた組織例の画像。

ゲートウェイの高可用性および負荷分散機能を使用する

ビジネスクリティカルなゲートウェイ クラスターには、常にゲートウェイの高可用性と負荷分散機能を使用してください。

  • 高可用性: 単一障害点を排除します。
  • 負荷分散: クラスター内のすべてのゲートウェイ サーバーにワークロードを自動的に分散します。

何らかの理由でゲートウェイがオフラインになった場合に備えて、ゲートウェイ クラスターごとに少なくとも 2 つのゲートウェイを設定します。 この設定により、単一のゲートウェイに障害が発生しても、ゲートウェイ クラスター全体に障害が発生することはありません。 さらに、ゲートウェイ クラスター全体で負荷をより適切に分散するには、ゲートウェイで CPU、メモリ、接続制限を有効にする必要があります。

ゲートウェイ クラスターのスケーラビリティを計画および保守する

推奨されるハードウェアおよびソフトウェアのガイドラインを使用してゲートウェイ クラスターを設定すると、クラスターの良好なパフォーマンスが確保されます。 ゲートウェイが適切にスケーリングされていない場合、パフォーマンスが低下することがあります。 ゲートウェイ クラスターで優れたパフォーマンスを発揮するには、考慮すべき要素がたくさんあります。

ゲートウェイ サーバーのハードウェア仕様を決定する

ゲートウェイ サーバーの仕様 (CPU、メモリ、ディスクなど) は重要な要素であり、ほとんどの場合、Power Query 変換がゲートウェイ サーバー上のデータに適用されます。 そのため、ゲートウェイ サーバーには、すべてのデータ変換を処理するのに十分なリソース、メモリ、処理能力が必要です。

サーバー サイズを選択する必要がある場合、最も重要な 2 つのメトリックはメモリと CPU です。 ゲートウェイでの Power Query データ変換手順を処理するには、十分なメモリと CPU パワーの両方が必要です。 ゲートウェイ サーバーのパワーが、現在の最も高いワークロードの処理に十分であることが重要です。 ゲートウェイ サーバーがワークロードを処理できない場合、直接クエリまたはデータ更新は失敗します。 同時に実行されるクエリ件数を理解することも重要です。

これらの異なるクエリ オプションは、ゲートウェイ サーバーに異なる影響をもたらします。

クエリの種類 制限係数
インポート メモリ
DirectQuery CPU
LiveConnect CPU

インポート中に、データのセット全体をクエリして処理する必要があります。これは、メモリの負荷の高いタスクです。 多くの場合、このインポートには時間もかかります。 DirectQueries と LiveConnections は、通常 CPU に高い負荷がかかります。 ほとんどの場合、データのごく一部のみを処理するために、直接クエリが何度も実行されます。 データのごく一部のみが処理されるため、これらの直接クエリは通常、メモリ負荷の高いタスクにはなりません。 しかし、クエリはオンデマンドで何度も実行されるため、CPU に高い負荷がかかる場合があります。

ワークロードに応じて、ゲートウェイ サーバーをメモリまたは CPU 用に最適化することを検討してください。

ゲートウェイ クラスターをスケーリングするタイミング

スケーリングは、ビジネスクリティカルなゲートウェイ クラスターの重要な側面です。 ゲートウェイ クラスターでの使用が増えるにつれて、ゲートウェイ クラスターをスケールアップまたはスケールアウトして、優れたパフォーマンスを確保する必要があります。 以前にクラスター内のゲートウェイをスケールアップしたことがある場合は、ゲートウェイ クラスターのスケールアウトを開始することをお勧めします。

クラスター内の個々のノード間におけるトラフィックの負荷のスケーリングと分散は、個々のシナリオによって異なる複雑なプロセスです。 すべてのゲートウェイ トラフィックが予測可能な方法で処理されるようにするための明確なモデルはありませんが、以下に示す制限はスケーリングの必要性を示しています。 一般に、スケールアップ (個々のノードの CPU、RAM、またはディスク領域の増加) にはスケールアウト (クラスターへのノードの追加) を優先的に行うことをお勧めします。 スケールアウトでは、システム全体の余分なトラフィックを処理する能力が全般的に向上する傾向があります。 スケールアウトは、クラスターが処理できる帯域幅の合計にもプラスの影響を与えます。一方、スケールアップには通常そのような影響はありません。 1 つ以上のゲートウェイ ノードが以下で説明するしきい値に達したことを示している場合は、クラスターのスケールアウトを強く検討する必要があります。

  • CPU: CPU が長期間にわたって 80% を超えているが、たまに CPU の上限に達する短い (5 分以下の) スパイクが発生することが異常ではない。

  • RAM: 使用可能なメモリが定期的に 20% 未満に低下する。

  • ディスク: ディスクの空き領域が頻繁に 5 GB を下回る。 このディップは、キャッシュまたはスプーリング ディレクトリをより戦略的に構成する必要があることを示している場合もあります。

  • コンカレンシー: 1 つのノードで 40 を超えるクエリを同時に実行している。

ゲートウェイ ノード間で分散される更新とクエリのプロファイルは大きく異なる可能性があるため、実行時間の長いジョブやメモリを集中的に使用するジョブに対して追加の調査を行うこともお勧めします。 このような場合のクエリの最適化は、個々のレポートや更新だけでなく、システム全体のパフォーマンスとスケーラビリティに大きな影響を与える可能性があります。 問題となっている更新を 1 つの専用ゲートウェイ クラスターに分離してパフォーマンス特性を評価し、クエリ プランの診断、フォールディング インジケーター、その他すべての公開されたパフォーマンスに関する推奨事項を使用して最適化を実行することをお勧めします。 この分離により、取得されるデータの量と、必要な後処理の量が最小限に抑えられます。 この分離は、実行時間の長い ETL ジョブを専用のゲートウェイ クラスターに隔離して、組織全体にわたる他の一般的な更新との競合を減らすための、長期的な戦略としても使用できます。

ゲートウェイ クラスターのスケールアップ

メモリが 5 GB のゲートウェイを 2 つ備えたゲートウェイ クラスターを使用した場合のクエリの失敗と、メモリが 7 GB のゲートウェイを 1 つ備えたクラスターを使用した場合のクエリの成功の画像

スケールアップとは、ゲートウェイ サーバーの仕様 (CPU、メモリ、ディスクなど) を増やすことです。

ゲートウェイが 1 つ以上のクエリを実行するときに、最大 CPU またはメモリに達した時点で、スケールアップが必要になることがあります。 クエリは 1 つのゲートウェイ サーバーでのみ実行できます。そのため、ゲートウェイ サーバーには、クエリ全体と結果のデータを処理するための十分なリソースが必要です。

ゲートウェイ クラスターのスケール アウト

それぞれのメモリが 5 GB のゲートウェイを 2 つ備えたクラスターを使用した場合のクエリの失敗と、それぞれのメモリが 5 GB のゲートウェイを 3 つ備えたクラスターを使用した場合のクエリの成功の画像

ゲートウェイ サーバーが既にハイ スペックの場合 (つまり、ゲートウェイ サーバーが既にスケール アップされている場合)、または実行する同時クエリの数が多いために単一のゲートウェイ サーバーで管理できる上限に達している場合は、スケール アウトが必要です。 ゲートウェイ メンバー セット全体にわたる広範な負荷増加は、ノードの追加によるクラスターのスケーリングが適切なアクションであることを示しています。 「ゲートウェイ クラスターをスケーリングするタイミング」に、スケーリングすべきタイミングを示す具体的なしきい値が記載されています。 スケール アウトの詳細については、「ゲートウェイの高可用性および負荷分散機能を使用する」を参照してください。

新しいゲートウェイ クラスターを作成してスケーリングする

ゲートウェイ クラスターのリソース使用率が高い場合、または多数のユーザーがゲートウェイ クラスターに依存している場合は、新しいゲートウェイ クラスターを作成できます。 その後、ワークロードのサブセットを新しいゲートウェイ クラスターに移行できます。 多数のユーザーが単一のゲートウェイ クラスターに依存している場合、ゲートウェイ クラスター全体のパフォーマンスに大きな影響を及ぼすクエリをユーザーが送信できる可能性が大幅に高まります。

単一のゲートウェイ クラスターに依存しているユーザーが非常に多いということは、新しいゲートウェイ クラスターを作成する必要があるということです。

ゲートウェイ パフォーマンスの監視とトラブルシューティング

ゲートウェイ パフォーマンス モニター機能を使って、ビジネスクリティカルなゲートウェイの全体的パフォーマンスを監視することが重要です。 この機能を使用すると、パフォーマンスの問題のトラブルシューティング、ボトルネックの特定、ゲートウェイ全体のパフォーマンスに影響を与えているクエリも特定できます。 この機能は、ゲートウェイ クラスターをいつスケーリングするかを決定するのに役立つ重要なツールでもあります。

クエリがゲートウェイに大きな影響を及ぼし、全体的なパフォーマンスが低下していると特定された場合は、クエリを再生性して効率を高め、パフォーマンスへの影響を最小限に抑えることができる可能性があります。

Microsoft が、過負荷の Power BI Premium 容量など、ゲートウェイ関連のコンポーネントによって引き起こされたパフォーマンスの低下を特定した場合、負荷をスケーリングまたは削減して過負荷のコンポーネントを修正する必要があります。 Microsoft は、ゲートウェイまたはゲートウェイ関連のコンポーネントが過負荷になった場合のパフォーマンスの低下に関する調査は行いません。