Power BI 埋め込み分析の容量計画
Power BI 埋め込み分析の展開に必要な容量の種類の計算は、複雑になることがあります。 必要な容量はいくつかのパラメーターに依存し、その一部は予測が困難です。
容量を計画する際には、次の点を考慮する必要があります。
- 使用しているデータ モデル。
- 必要なクエリの数と複雑さ。
- アプリケーション使用量の時間単位の分布。
- データの更新間隔。
- その他、予測が困難な使用パターン。
注意
この記事では、必要な容量を計画する方法と、Power BI 埋め込み分析 A-SKU のロード テスト評価を行う方法について説明します。
容量を計画するときは、次の手順を行います。
パフォーマンスとリソースの消費量を最適化する
キャパシティ プランニングまたはロード テストの評価を始める前に、レポートとセマンティック モデルのパフォーマンスとリソース消費量 (特にメモリ占有領域) を最適化します。
パフォーマンスを最適化するには、次のリソースのガイドラインに従います。
パフォーマンスの最適化に関する詳細なチュートリアルについては、トレーニング モジュール「Power BI でのパフォーマンスに対するモデルの最適化」を参照してください。
最小 SKU を決定する
次の表は、容量のサイズに依存するすべての制限をまとめたものです。 容量の最小 SKU を決定するには、[Semantic model] (セマンティック モデル) ヘッダーの下の [最大メモリ (GB)] 列を確認します。 また、現在の制限事項にも留意してください。
SKU | 容量ユニット (CU) | Power BI SKU | Power BI v コア |
---|---|---|---|
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 |
F5121 | 512 | P4/A7 | 64 |
F10241 | 1,024 | P5/A8 | 128 |
F20481 | 2,048 | 該当なし | 該当なし |
1 これらの SKU は、すべてのリージョンで使用できるわけではありません。 このような SKU を使用できないリージョンでの使用を要求するには、Microsoft アカウント マネージャーにお問い合わせください。
容量の負荷を評価する
容量の負荷をテストまたは評価するには、次のようにします。
テスト用に Azure に Premium Power BI Embedded 容量を作成します。 お使いの Power BI テナントと同じ Microsoft Entra テナントに関連付けられているサブスクリプションと、その同じテナントにサインインしているユーザー アカウントを使用します。
作成した Premium 容量のテストに使用するワークスペースを 1 つまたは複数割り当てます。 ワークスペースは、次のいずれかの方法で割り当てることができます。
- "プログラムで" Groups AssignToCapacity API を使用します。 Groups CapacityAssignmentStatus API を使用するか、PowerShell スクリプトを介して、割り当ての状態を確認します。 サンプル コードについては、GitHub 上の Zero-Downtime-Capacity-Scale サンプルの
AssignWorkspacesToCapacity
関数を参照してください。 - ワークスペース管理者として "手動" で行うか、容量管理者として管理ポータルを使用します。詳細については、「マスター ユーザーを使って容量にワークスペースを割り当てる」を参照してください。
- "プログラムで" Groups AssignToCapacity API を使用します。 Groups CapacityAssignmentStatus API を使用するか、PowerShell スクリプトを介して、割り当ての状態を確認します。 サンプル コードについては、GitHub 上の Zero-Downtime-Capacity-Scale サンプルの
容量管理者として、Microsoft Fabric Capacity Metrics アプリをインストールします。 監視する容量 ID と時間 (日数) を指定し、データを更新します。
Power BI 容量負荷評価ツールを使用して、容量のニーズを評価します。 この GitHub リポジトリには、ビデオ チュートリアルも含まれています。 このツールは慎重に使用します。最大数十人の同時シミュレートしたユーザーでテストし、より高い同時負荷 (ニーズに応じて数百または数千) について推定します。詳細については、「容量の負荷を評価する」を参照してください。 または、他のロード テスト ツールを使用しますが、iFrame をブラック ボックスとして扱い、JavaScript コードを使用してユーザー アクティビティをシミュレートします。
Microsoft Fabric Capacity Metrics アプリ(手順 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) を確保できます。