Premium の容量負荷の評価

[アーティクル]
03/23/2023

ヒント

この記事では、お使いの Premium の最大能力負荷を評価する方法について説明します。 "過負荷" や "自動スケール" などの概念について説明します。この記事で説明されている Premium の一部の機能を紹介する、以下の内訳のビデオもご覧ください。

CPU スループットの制限を適用するために、Power BI では、Premium 容量のスループットを継続的に評価します。

Power BI では、スループットを 30 秒ごとに評価します。ここでは、操作の完了を許可し、共有プールの物理ノードの CPU 上での実行時間を収集した後、その容量でのすべての操作について、それらを 30 秒の CPU 間隔で集計し、その結果をユーザーが購入した容量でサポートできる数値と比較します。

次の図は、Premium によってどのようにクエリが評価され、完了するかを示しています。

1 つの例を見てみましょう。8 つの仮想コアを備えた P1 では、$8\times{30}=240$ 秒の仮想コアの実行時間 ("CPU 時間" とも呼ばれます) をサポートできます。

この集計は複雑です。ここでは、次の要点で説明されているように、さまざまなワークロードや、さまざまな操作の種類に対して特殊なアルゴリズムを使用します。

実行速度の遅い操作 (セマンティックモデルやデータフローの更新など) は、通常はバックグラウンドで実行され、ユーザーが積極的に監視したり視覚的に確認したりしないため、バックグラウンド操作と見なされます。バックグラウンド操作は長く、長いプロセスの完了にはかなりの CPU パワーを必要とします。 Power BI では、バックグラウンド操作の CPU コストを 24 時間にわたって分散させ、同時に実行される更新の数が多すぎるために容量が最大のリソース使用率に達してしまうことがないようにします。これにより、Power BI Premium サブスクライバーは、購入した容量の SKU によって許可される数のバックグラウンド操作を実行できます。
高速な操作 (クエリやレポートの読み込みなど) は、"対話型の操作" と見なされます。これらの操作を完了するために必要な CPU 時間は、その操作の完了の後に影響を受ける 30 秒ウィンドウの数を最小限に抑えるために集計されます。

Premium のバックグラウンド操作のスケジュール設定

更新は、同じ時間にスケジュールされている他のバックグラウンド操作の数には関係なく、スケジュールされた時間か、またはそれに近い時間に Premium 容量で実行されます。更新されるセマンティックモデルやデータフローは、それらを読み込むために使用できる十分なメモリを備えた物理処理ノードに配置された後、更新プロセスを開始します。

更新の処理中に、セマンティックモデルでは、その更新プロセスを完了するためにより多くのメモリが消費される可能性があります。更新エンジンによって、どの項目も、その基本 SKU で消費することが許可されているメモリの量 (たとえば、P1 サブスクリプションでは 25 GB、P2 サブスクリプションでは 50 GB など) を超えることはできなくなります。

レポートを表示するときに容量サイズの制限を適用する方法

Power BI Premium では、使用率レコードを 30 秒ごとに集計することによって使用率を評価します。各評価は、次の 2 種類の集計で構成されます。

対話的な使用率
バックグラウンド使用率

対話的な使用率は、現在の 30 秒の評価サイクルか、またはほぼその評価サイクルで完了したすべての対話型の操作を考慮することによって評価されます。

バックグラウンド使用率は、過去 24 時間以内に完了したすべてのバックグラウンド操作を考慮することによって評価されます。各バックグラウンド操作は、その合計 CPU コストの 1/2880 にのみ寄与します (2880 は 24 時間の期間内の評価サイクルの数です)。

各容量は、定義された数の仮想コアで構成されます。使用率レコードで測定された CPU 時間には仮想コアの使用率が反映されており、その使用率によって自動スケーリングが必要かが駆動されます。

8 つの仮想コアを含む P1 サブスクリプションがある場合、各評価サイクルクォータは $8\times{30}=240$ の CPU 使用率に相当します。対話型とバックグラウンドの両方の使用率の合計が、容量内の仮想コアクォータの合計を "超え"、かつオプションで自動スケーリングを有効に "しなかった" 場合、Premium 容量のワークロードは、利用可能なリソース ("容量しきい値" とも呼ばれます) を超えます。次の図は、自動スケーリングが有効 "ではない" 場合に発生する "オーバーロード" と呼ばれる状態を示しています。

これに対し、自動スケーリングがオプションで有効になっている場合に、CPU 使用率が容量内の仮想コアクォータの合計を超えると、次の 24 時間にわたり、1 つの仮想コアによって容量の自動スケーリングが自動的に行われます (発生します)。

次の図は、自動スケーリングのしくみを示しています。

自動スケーリングでは、使用している量を評価するために、常に現在の容量サイズを考慮します。自動スケーリングすると、容量に 1 つの仮想コアが追加されます。つまり、8 つの仮想コアを備えた P1 SKU を使用している場合、最大容量は評価サイクルで 270 秒 ($8\times{30}+1\times{30}$) の CPU 時間になります。

自動スケーリングでは常に、1 つの対話型の操作ですべての容量を使用できないように保証するため、自動スケーリングを開始するには、1 つの評価サイクルで 2 つ以上の操作が実行されるようにする必要があります。

自動スケーリングを行わない Premium の使用

容量の使用率がそのリソースの 100% を超えたが、自動スケーリングが無効になっているか、または既にその最大の仮想コアの値に達しているために自動スケーリングを開始できない場合、その容量は一時的な "対話型の要求遅延" モードになります。 "対話型の要求遅延" モードの間、対話型の各要求 (レポートの読み込みや、ビジュアルの相互作用など) は、実行のためにエンジンに送信される前に遅延されます。

以前の評価が 100% を超えるリソース使用率に評価されている場合、その容量は "対話型の要求遅延" モードのままになります。