Share via

ページ分割されたレポートの容量計画

  • [アーティクル]

適用対象: Power BI のページ分割されたレポート Power BI サービス Power BI Desktop

ページ分割されたレポートから最小限のコストで最適なパフォーマンスを得るために Premium 容量を計画する方法について説明します。 別のビジネス インテリジェンス ツールから Power BI に移行する場合、使用する容量を決定する前に、以下の記事をお読みください。

容量計画

必要な容量の種類の計算は、レポート内の視覚エフェクトの数、レポートに対するクエリの複雑さ、データ ソースまたはデータ モデルの品質などのいくつかの要因によって異なります。 また、ページ分割されたレポートを容量に追加する前に、現在ピーク時に使用されている容量も考慮する必要があります。

必要な容量の計画を開始する前に、「容量と SKU」の表を参照して、各容量によって提供されるリソースを確認します。

容量を計画する場合、次の点を考慮してください。

  • レポート デザインの複雑さ。 入れ子になった tablix、複数のサブレポート、複数の行と列のグループは、デザインの複雑さが増し、より多くの容量リソースを必要とします。

  • レポートによって取得されるデータの量。 レポートで必要とされるデータ量が多いほど、より多くの容量リソースが必要です。

  • レポートでデータを取得する方法。 コネクタ、ドライバー、またはゲートウェイを使用すると、データ取得に時間がかかり、より多くのリソースが必要になり、その結果、コストが高くなるおそれがあります。

  • 大きなレポートを Excel や PDF などの形式にエクスポートする場合、すべてのページを読み、トグルを使用し、レポート内を検索するよりも多くのリソースが必要です。

SKU で処理できるユーザー数

ページ分割されたレポートを異なる容量でテストするために、Microsoft では、異なる SKU サイズに対して 3 つの異なる種類のワークロードを実行しました。 各ワークロードは、サイズの異なる単一のレポートを同時にレンダリングすることで構成されました。

  • 小 - Azure SQL データ ソースの 100 を超える行で構築されたデータ集計テーブル。

  • 中 - Azure SQL データ ソースの 100,000 を超える行で構築されたデータ集計テーブル。

  • 大 - Azure SQL データ ソースの 250,000 を超える行で構築されたデータ集計テーブル。

Microsoft による Power BI Premium の分析を見ると、毎日のピーク時を含め、特定の時点の同時ユーザー数は、総ユーザー ベースの 5% を超えないことがわかります。

次の表では、5% というコンカレンシーの割合に基づいて、SKU が過負荷になる前に処理できるおおよその最大ユーザー数を示します。 容量が過負荷になると、容量に対してスロットリングが発生します。 詳細については、「自動スケーリングしていない場合、オーバーロード中にトラフィックはどうなりますか?」を参照してください。

ワークロード F64 または P1 SKU F128 または P2 SKU
Small 2,500 ユーザー 5,000 ユーザー
Medium 1,900 ユーザー 3,800 ユーザー
Large 1,300 ユーザー 2,600 ユーザー

表中の数値は、他の操作を実行しない指定された容量を参照することを考慮してください。 お使いの容量では既に、CPU リソースを次のような操作に使用している可能性があります。

  • データの取得と処理

  • 他のワークロードとバックグラウンド操作

  • 複雑なデータのグループ化と再作成

  • データのフィルタリング

同時要求数

改ページ対応レポート ワークロードを含む容量の各ワークロードでは、同時に最大 500 個のレポートをレンダリングできます。 容量で 100 個のレポートをレンダリングしていて、改ページ対応レポートのエクスポートの要求が 200 件ある場合、残っている同時レポート レンダリング要求は 200 件です。

混雑を避けるには、事前に同時要求の負荷を計画します。 同時要求の制限を超えると、"要求が多すぎます (429)" エラーが発生します。

メトリック アプリの使用

Microsoft Fabric Capacity Metrics アプリを使うと、改ページ対応レポートが容量に与える影響を推定できます。 このアプリでは時間の経過に伴う CPU 使用率が測定されます。これにより、容量のパフォーマンスを把握することができます。

ページ分割されたレポートをテストするには、専用のクリーンな容量を使用することをお勧めします。 クリーンな容量は、他のユーザーやワークロードの影響から結果を分離するのに役立ちます。

対象となるテスト シナリオ (たとえば、平均または最大の使用量の検証など) に応じて、予想されるリソース消費量を表すレポートを選択または作成し、テスト用に作成した容量内の Premium/Fabric ワークスペースにアップロードします。

レポートを数回実行し、メトリック アプリを使用して、レポートに実行に費やされた平均 CPU 秒数を取得します。 レポートの実行に要した時間を計算する場合、次の点を考慮します。

  • アプリでは集計値が示されるため、結果をレポートの実行回数で除算することが必要な場合があります。

  • レポートのレンダリングには複数の Power BI 項目および操作が関係する可能性があります。 それらの CPU 消費量を合計する必要があります。

  • レンダリングに時間がかかる場合があるため、レポートのレンダリングに関連する可能性のある複数の Power BI 項目と操作があります。 [タイムポイント] ページでは、実行時間の長い操作を操作の一覧として表示できます (期間が 30 秒を超えるものは含まれません)。 レンダリング操作の CPU 消費量を合計することが必要な場合があります。 開始時刻で並べ替えると、レンダリングの完全な履歴を表示するのに役立ちます。

レポートの最大レンダリング数を計算する

容量が過負荷になる前に処理できるレポートの最大同時レンダリング数を計算するには、次の数式を使用します。

$ \text {レポートの最大同時レンダリング数} = {\text {容量 SKU のコア数} \times {30} \over \text {レポートの CPU 処理時間 (秒数)}} $

最大ユーザー数を計算する

合計ユーザー数と最大同時レンダリング数との相関関係に、推定 5% のコンカレンシーの割合を使用すると、SKU で処理できる合計ユーザー数を取得できます。

$ \text {最大 SKU ユーザー数} = {\text {レポートの最大同時レンダリング数} \over 0.05} $

複数のレポートの容量リソースを計算する

拡張式を使用して、さまざまなレポートの使用に必要な容量を見積もることができます。

1 日のレンダリング数が異なる複数の改ページ対応レポートをアップロードし、メトリック アプリを使ってそれぞれの平均 CPU 処理時間を取得します。 すべてのレポート レンダリングの 1 日あたりの合計は、100% になる必要があります。 すべての情報がそろったら、次の数式を使用します。

$ \text {レポートの最大同時レンダリング数} = {\text {容量 SKU のコア数} \times {30} \over {\text {A レンダリング数} \times \text {A 処理時間}} + \text {B レンダリング数} \times \text {B 処理時間} + \text {...} + \text{N レンダリング数} \times \text{N 処理時間}}$

例

このセクションには、2 つの例が含まれています。1 つは通常の計算の例で、もう 1 つは高度な計算の例です。

通常の計算

8 コアを備えた F64 または P1 SKU で改ページ対応レポートを実行しているとします。 10 回の実行の合計 CPU 使用量は 40 秒であるため、レポートあたりの平均 CPU 時間は 4 秒です。

$ 60 = {8 \times {30} \over 4} $

2 番目の数式を使用すると、最大ユーザー数は 1,200 になります。

$ 1,200 = {60 \over 0.05} $

F128 または P2 SKU の場合、容量は CPU コアの数の 2 倍になるため、これらの数値を 2 倍にすることができます。

高度な計算

次の表に示す 1 日あたりの割合でレンダリングされる 3 つのページ分割されたレポートがあるとしましょう。

レポート 1 日あたりにレンダリングされるレポートの数 CPU 処理時間 (秒数)
A 60% 4
B 30% 10
C 10% 20

F64 または P1 SKU の式は次のようになります。

Value 計算式
レポートの最大同時レンダリング数 $ ~32.4 = {8 \times {30} \over 0.6 \times{4} + 0.3 \times{10} + 0.1 \times{20}} $
SKU ユーザーの合計数 $ ~650 = {32.4 \over 0.05} $

関連するコンテンツ