Power BI 埋め込み分析の容量計画

  • [アーティクル]

Power BI 埋め込み分析の展開に必要な容量の種類の計算は、複雑になることがあります。 必要な容量はいくつかのパラメーターに依存し、その一部は予測が困難です。

容量を計画する際には、次の点を考慮する必要があります。

  • 使用しているデータ モデル。
  • 必要なクエリの数と複雑さ。
  • アプリケーション使用量の時間単位の分布。
  • データの更新間隔。
  • その他、予測が困難な使用パターン。

注意

この記事では、必要な容量を計画する方法と、Power BI 埋め込み分析 A-SKU のロード テスト評価を行う方法について説明します。

容量を計画するときは、次の手順を行います。

  1. パフォーマンスとリソースの消費量を最適化する。
  2. 最小 SKU を決定する。
  3. 容量の負荷を評価する。
  4. 容量の自動スケーリングを設定する。

パフォーマンスとリソースの消費量を最適化する

キャパシティ プランニングまたはロード テスト評価を開始する前に、レポートとデータセットのパフォーマンスとリソース消費量 (特にメモリ占有領域) を最適化します。

パフォーマンスを最適化するには、次のリソースのガイドラインに従います。

パフォーマンスの最適化に関する詳細なチュートリアルについては、トレーニング モジュール「Power BI でのパフォーマンスに対するモデルの最適化」を参照してください。

最小 SKU を決定する

次の表は、容量のサイズに依存するすべての制限をまとめたものです。 容量の最小 SKU を決定するには、[データセット] ヘッダーの下の [最大メモリ (GB)] 列を確認してください。 また、現在の制限事項にも留意してください。

容量 データセット データフロー API のエクスポート
容量 SKU 仮想コア 最大メモリ (GB)1、2、3 DirectQuery/ライブ接続 (秒あたり)1、2 クエリあたりの最大メモリ (GB)1、2 モデル更新並列処理2 データフロー並列タスク5 最大同時ページ数6
EM1/A1 1 3 3.75 1 5 4 20
EM2/A2 2 5 7.5 2 10 8 25
EM3/A3 4 10 15 2 20 16 35
P1/A4 8 25 30 6 40 32 55
P2/A5 16 50 60 6 80 64 95
P3/A6 32 100 120 10 160 64 175
P4/A74 64 200 240 10 320 64 200
P5/A84 128 400 480 10 640 64 200

1 現在、Power BI Premium 使用率とメトリック アプリでは、これらのメトリックを公開していません。

2 これらの制限は、容量ごとのデータセットのワークロードにのみ適用されます。

3 "データセット" ヘッダーの "最大メモリ (GB)" 列は、データセットのサイズの上限を表します。 しかし、データセットに対する更新やクエリなどの操作のために、大量のメモリを予約する必要があります。 容量で許可されるデータセットの最大サイズは、この列の数値よりも小さい場合があります。 詳細については、メモリの割り当てに関する記事を参照してください。

4 これらの SKU は、すべてのリージョンで使用できるわけではありません。 このような SKU を使用できないリージョンでの使用を要求するには、Microsoft アカウント マネージャーにお問い合わせください。

5データフローでの並列タスクに関する詳細をご覧ください。

6 Power BI 対話型 (ページ分割されていない) レポートの詳細については、「Power BI レポートをファイルにエクスポートする」を参照してください。

容量の負荷を評価する

容量の負荷をテストまたは評価するには、次のようにします。

  1. テスト用に Azure に Premium Power BI Embedded 容量を作成します。 ご利用の Power BI テナントと同じ Azure Active Directory (Azure AD) テナントに関連付けられているサブスクリプションと、その同じテナントにサインインしているユーザー アカウントを使用します。

  2. 作成した Premium 容量のテストに使用するワークスペースを 1 つまたは複数割り当てます。 ワークスペースは、次のいずれかの方法で割り当てることができます。

  3. 容量管理者として、Power BI Premium 使用率とメトリック アプリを使用します。 監視する容量 ID と時間 (日数) を指定し、データを更新します。 詳細については、「Premium メトリック アプリを使用する」を参照してください。

  4. Power BI 容量負荷評価ツールを使用して、容量のニーズを評価します。 この GitHub リポジトリには、ビデオ チュートリアルも含まれています。 このツールは慎重に使用します。最大数十人の同時シミュレートしたユーザーでテストし、より高い同時負荷 (ニーズに応じて数百または数千) について推定します。詳細については、「容量の負荷を評価する」を参照してください。 または、他のロード テスト ツールを使用しますが、iFrame をブラック ボックスとして扱い、JavaScript コードを使用してユーザー アクティビティをシミュレートします。

  5. 手順 3 でインストールしたメトリック アプリを使って、ロード テスト ツールによる容量の使用率を監視します。 あるいは、Azure Monitor のアラートを使用して Premium メトリックをチェックして、容量を監視することもできます。

ロード テストによって容量に発生した実際の CPU が容量制限に近づいている場合は、容量により大きな SKU を使用することを検討してください。

自動スケーリングを設定する

次の自動スケーリング手法を使用すると、現在のメモリと CPU のニーズに対応するように、A-SKU 容量のサイズを柔軟に変更できます。

  • Capacitys Update API を使用して、容量 SKU をスケール アップまたはスケール ダウンします。 API を使用してスケール アップおよびスケール ダウンのための独自のスクリプトを作成する方法については、Runbook PowerShell スクリプトの容量スケールアップのサンプルに関するページを参照してください。

  • Monitor アラートを使用して、次の Power BI Embedded 容量メトリックを追跡します。

    • オーバーロード (ご利用の容量の CPU が 100% を超え、オーバーロード状態の場合は 1、それ以外の場合は 0)
    • CPU (CPU 使用率)
    • 特定のワークロード (ページ分割されたレポートなど) が使用されている場合のワークロードあたりの CPU 数

  • これらのメトリックが指定された値に達した場合に、容量をスケール アップまたはスケール ダウンするスクリプトの実行がトリガーされるように、Monitor アラートを構成します。

たとえば、オーバーロード = 1 の場合または CPU 値が 95% の場合にスケールアップ容量 Runbook を呼び出して容量をより高い SKU に更新するルールを作成できます。 また、CPU 値が 45% または 50% を下回った場合にスケールダウン容量 Runbook スクリプトを呼び出して容量をより低い SKU に更新するルールを作成することもできます。

また、データセットの更新が実行される前後に、必要に応じてプログラムによりスケールアップおよびスケールダウン Runbook を呼び出すこともできます。 このアプローチにより、その容量を使用する大規模なデータセット用に十分な RAM (GB) を確保できます。

次の手順