次の方法で共有

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

Power BI 埋め込み分析のデプロイに必要な容量の種類の計算は複雑になる場合があります。 必要な容量は、いくつかのパラメーターによって異なりますが、その一部は予測が困難です。

容量を計画する際に考慮すべき点は次のとおりです。

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

注

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

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

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

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

容量計画またはロード テストの評価を開始する前に、レポートとセマンティック モデルのパフォーマンスとリソース消費量 (特にメモリ占有領域) を最適化します。

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

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

最小 SKU を決定する

次の表は、容量サイズに依存するすべての制限事項をまとめたものです。 また、 現在の制限事項にも留意してください。

SKU1 容量ユニット (CU) Power BI SKU Power BI 仮想コア
F2 2 なし なし
F4 4 なし なし
F8 8 EM1/A1 1
F16 16 EM2/A2 2
F32 32 EM3/A3 4
F64 64 P1/A4 8
F128 128 P2/A5 16
F256 256 P3/A6 32
F5122 512 P4/A7 64
F10242 1,024 P5/A8 128
F20482 2,048 なし なし

1 Microsoft 365 または Embed for your organization (ユーザー所有データ) シナリオでは、F64 より小さい SKU では、Pro または Premium Per User (PPU) ライセンス、または Power BI コンテンツを使用するための Power BI 個別試用版が必要です。

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

容量の負荷を評価する

容量の負荷をテストまたは評価するには:

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

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

  3. 容量管理者として、 Microsoft Fabric Capacity Metrics アプリをインストールします。 監視する容量 ID と時間 (日数) を指定し、データを更新します。

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

  5. ロード テスト ツールを使用して発生した容量使用率を監視するには、手順 3 でインストールした Microsoft Fabric 容量メトリック アプリを使用します。 または、Azure Monitor でアラートを使用して Premium メトリック を確認することで 、容量を監視することもできます。

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

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

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

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

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

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

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

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

また、セマンティック モデルが更新される前後に、必要に応じてプログラムでスケールアップおよびスケールダウン Runbook を呼び出すこともできます。 この方法により、その容量を利用する大規模なセマンティックモデルのために十分なRAM（GB）が確保されます。

関連コンテンツ