前回 は Fabric 容量、スケール Out/Up 等に関する基礎的な概念について紹介をしましたが、今回は以下の通りの内容について解説をしていきます。
- コンピュート (Compute) と 課金 (Billing) を分けて考える
- Bursting / Smoothing / Throttling を正しくイメージする
Power BI Desktop や Power BI Pro / PPU をメインで活用するPower BI ペルソナは Fabric 容量を意識する必要はないですが、Fabric 機能を含む高度な機能を使用する必要がある場合、あるいは OneLake を中心にデータ活用をする必要がある場合、Fabric 容量に関してある程度しっかり把握しておくことが推奨されます。
コンピュートと課金
Fabric は容量別にスループット（使用できる容量の幅）が決まっており、以下が概要となっています。
容量は 1秒あたりの Capacity Unit (CU) で定義されますが、実際の負荷評価は 30秒単位 で行われます。
PAYG（Pay As You Go）は従量課金、RI（Reserved Instance）は年間コミットメントとして購入できます。Fabric 容量は F2 から利用可能で、F2 は 2 CU/秒、F64 は 64 CU/秒というように、SKU が大きくなるほど、より多くの負荷を処理できるようになります。
SKU は Stock Keeping Unit の略で、もともとは物流・在庫管理の分野で使われる用語です。在庫管理において最小の品目単位を表し、単品別に分析することを「SKU 分析」と呼ぶこともあります。Microsoft Fabric では、Fabric を 1 つのデータ製品と捉えると、その 1 つの Fabric サービス（データ製品）を表す単位が SKU に相当します。
一方、課金については：
- PAYG の場合：
- 容量を起動している時間に対して課金
- 最初の 1 分は最低料金として必ず課金され、その後は秒単位で課金
- RI の場合：
- 1年 / 3年のコミットと引き換えに定価ベースで 41% のディスカウントを受けられる
- Fabric の 3年予約が2025年12月～からできるようになりましたが、2025年12月中ばにおいて、3年予約だからといって定価 41% よりさらに深い割引は「原則として」存在しない（それ以上は商談ベース）
ここで例えば、ざっくり概算でいくと、F64 SKU で処理可能な CUは以下のようになります。
- 64 CU × 60 秒 × 60 分 × 24 時間 × 30 日 ＝ 165,888,000 CU / 月
- F64 の場合、64 CU × 30 秒 = 1,920 CU / 30 秒
- 165,888,000 ÷ 1,920 = 86,400 バケット
1ヵ月を30日とした場合、合計86,400 バケットをベースに、30秒ごとの課金が行われ、一か月で利用できる CU の上限が上記の計算式になります。ここで、例えば、容量 Metrics App より、以下のような14日間の消費CUがあるとします。
Microsoft は SKU をサイジング（どのSKUを選択するかを測定）する際に、実績値を参考にしたほうが良いと提案していますが、下記は上記14日間の実績をベースに計算された推奨SKU (SKU 換算) となっており、この結果を見ると、F64 SKU で問題なく運用できることが判明しました。
CU_Cost_Calculation.xlsx
こちらはざっくり値ですが、ワークロード別により詳細なパラメータを入力してサイジングを行いたい場合、下記の SKU Estimator をご参考ください。
Fabric SKU Estimator (プレビュー) とは - Microsoft Fabric | Microsoft Learn
Fabric SKU Estimator: http://aka.ms/FabricSKUestimator
Bursting / Smoothing / Throttling の仕組み
容量と評価ウィンドウ (30秒間隔) について、以下が基本的な考え方となります。以下、Bursting はバースティング、Smoothing はスムージング、Throttling はスロットリングとして表現をしていきます。
- SKU により「1秒あたりの CU」が決まる
- Fabric は 30秒ごと に使用量を評価
例：F2 は 2 CU/sec → 30秒で 60 CU
一般的に「常に 2 CU/sec ある」と理解しがちですが、実際は 30秒ごとの合計を見て、スロットリング判定が行われることに留意が必要です。
なお、下記説明するバースティングやスムージングは、2023年に発表された Fabric ブログ（英語）でも網羅されており、今回の説明と一緒に参考にして頂くと良いと思います。
バースティング
バースティングの特徴は以下の通りです。
- 本来の容量上限（例えば F64 の 100% ライン）を一時的にオーバーしてクエリやジョブを実行できるようにする
- 例えば、本来であれば 64 CU で 60 秒かけて実行するジョブをバースティングによって 256 CU を使用し、15 秒で完了させることが可能
- ワークロードごとに仕組みが異なる：
-
分かりやすい表現：「今使って、後で払う」
※ Fabric 容量を一時停止した場合、将来支払う予定のCU消費は PAYG のレートで一気に回収されることに留意
スムージング
バースティングによって「使いすぎた分」を、一定時間にわたって 分割して返済していくのがスムージングです。ここで言う「返済」は、実行済みのクエリをもう一度実行するという意味ではなく、計算リソースの“負債”を時間に分散して扱う、という意味です。
- インタラクティブ処理
- バックグラウンド処理
- Spark ノートブック
- Data Warehouse / Lakehouse のバッチクエリ
- Dataflow Gen2 / Pipelines
- Power BI インポートモードのセマンティックモデルの更新、等
- Fabric の世界では ほとんどのバッチ処理がここに入る
- ロジック
- クエリ・ジョブ完了後、その使用量を 24時間 に渡って 30秒単位で分割して計上（平準化）
- これにより、「夜に更新をまとめれば安全」という考え方はあまり意味を持たない
- 消費量を 144 分割（60分＝10分 × 6分割、24時間にすると24 × 6 = 144分割）し、その値を次の 144 個の「10 分ウィンドウ」に適用（=24時間でスムージング）
スムージングとスロットリング
スムージングはスロットリングより先に適用されます。その後、現在のウィンドウにおけるすべての消費量そのウィンドウ内で発生したもの、および過去のウィンドウから繰り越されたものを含む）を集計し、それがベース容量内に収まるか、あるいは carry forward（繰り越しバケット） に加算する必要があるかを判定します。
この carry forward バケット（正確には、繰り越し分と当該ウィンドウにスムージングされた消費量の合計）が 10 分／60 分／24 時間 のいずれかのしきい値に達すると、容量のステータスが「スロットリング中（throttled）」に更新され、該当レベルに応じたスロットリング制御が適用されます。
なお、注意点として、carry forward を追加する処理そのものはスロットリングされません。スロットリングは、容量がすでにスロットリング状態にある場合に、処理の開始時点でのみ適用されます。すなわち、
- carry forwardは、「その時間枠で使い切れなかった CU 消費」を次の時間枠に持ち越すための“帳簿上の計算（加算処理）”
- この carry forward を計算して足す処理そのものは、スロットリングの対象にならない
- つまり「繰り越し計算をするから遅くなる／止められる」ということはない、という意味になる
- スロットリングが効くのは“実際のジョブ（クエリ・更新・Spark など）が開始される瞬間”
となります。その時点で容量がスロットル状態になっていれば、そのジョブに対して遅延や制限（Interactive delay / Rejection など）が適用されます。以下、簡単な例です。
- ある時点で負荷が高くなり、結果として carry forward が増える（＝未払い分が溜まる）
- その“未払い分を帳簿に記録する”のは普通に行われる（ここはスロットリングされない）
- その後、新しくユーザーがレポートを開く／更新が走る
→ 開始時点でスロットル状態なら、その操作が遅くなる／拒否される
スロットリング
バースティングとスムージングによって「先に使った分を後で返している」状態を、Fabric は内部的に “future usage”（将来返済すべき CU） として管理しています。この future usage が一定以上に膨らんだときに発動するのがスロットリングです。
スロットリングの発生に際してのしきい値は3段階あり、以下のように区分されます。
- インタラクティブ遅延（約10分）
- インタラクティブ拒否（約60分）
- 返済分が 60分（1時間） に達すると：
- インタラクティブ操作（レポートのフィルター変更など）が エラーで失敗
- メッセージ例：「容量のリソースが不足しています。管理者に連絡してください」 といった内容
- 返済分が 60分（1時間） に達すると：
- バックグラウンド拒否（約24時間）
- 将来返済分が 24時間 に達すると：
- Spark ノートブック、Data Warehouse のクエリ、Dataflow などの バックグラウンド処理は新規に実行できない
- 将来返済分が 24時間 に達すると：
スロットリングに関するブログ（参考）
Fabric Operations: https://aka.ms/FabricOperation
よくある要望として、「まずバックグラウンドジョブを止めて、ビジネスユーザーを守れないか？」というものですが、こちらはサージ保護（Surge Protection）という機能が容量全体 (V1) 及び、ワークスペース別 (V2) に対応できるようになります。
容量の停止
容量を一時停止したときの課金と、一時停止をすべきかどうかの判断について教えて欲しい
Q: ある顧客は「分析用」の容量を使っていて常時稼働ではない。集中的に分析して容量をかなり使った後、その容量を一時停止している。この場合、スムージング中の分を含めてすべて課金されるのは理解しているが、24時間走らせたままにしてスムージングを待つのと、一時停止してしまうのとでは、どちらがお得か？
- 容量を一時停止するとき：
- Fabric は Billing Reconciliation Event（精算イベント） を発生させる
- その時点までに溜まっている将来返済分（future usage） を一括で Azure に請求することになる
- したがって、支払うものは：
- 容量稼働中の稼働時間分の料金 + 一時停止した時点でのスムージング未返済分
- 一時停止が有利かどうかは 条件次第：
- F64 での内部検証例では、使用率・割引率などを踏まえて、10時間以上、一時停止 し続ける場合なら得になる、というような計算結果も出ている
- 逆に、数時間だけ一時停止してすぐ再開するような運用では、スムージング分は即清算されるのに、容量自体の稼働時間はあまり減らないため、結果として割高になることが多い
- 特に RI の場合、どうせ RI で支払いは発生しているので、一時停止すべきではない
一時停止に関しての選択については下記ブログ（Microsoft 従業員である Matthew Farrow 氏）の解説が分かりやすい。
Fabric Billing Part 4- Implications of pause and restart
容量を停止する理由はいくつか挙げられますが、主に以下2つになるであろうと予想されます。
- 使用していない間のコスト削減
- 容量負債（CU の借り）を即時に解消するため
1の一時停止は「将来の負債を清算するコスト」を上回る長さが必要であり、極端なケースでは、一時停止によってコストが下がるのは、再開が一時停止から24時間以上後になる場合のみとなります。なぜなら、容量負債は最大で将来24時間分まで蓄積される可能性があり、一時停止時点でその分を PAYG 価格で一括精算する必要があるためです。
ちなみに、RI を持っていた場合でも再開時に PAYG 価格が課金される理由として、一時停止 → 再開を行うと・・
結果として、「RI を持っていても再開時は PAYG 課金が発生する」ように見えてしまいます。
一方、2の「容量負債を解消する手段としての一時停止」は短期的なスロットリングへの非常に有効な対処手段となります。上記 Matthew のブログに記載の通りですが、以下のようなケースが有効となります。
想定シナリオ
- 小さなキャパシティでフィルターをかけずにセマンティックモデルを更新
- 本来 100 万行のはずが 10 億行をインポート
- CU が 24 時間に平滑化され、ユーザーが Power BI レポートを操作できない
→ 月末で業務影響が深刻
この場合、24時間待つのは現実的ではありません。一時停止 → 再開を行えば、
- PAYG 価格で負債を即時清算
- 容量を正常状態に戻せる
これは、旧 P SKU の自動スケールよりも、コスト面で効率的な解決策になり得ます。ただし、一時停止と再開を頻繁に繰り返している場合、
- PAYG の高い単価での課金が発生
- ジョブ（更新）のキャンセルによる運用影響
が問題としてあげられます。これらを考慮すると、処理内容の見直しや RI 前提でのより大きな容量購入を検討すべきサインと言えます。
まとめ
今回はバースティング、スムージング、スロットリングについて理解を深めてきました。次回はFabric Capacity Metrics App の実際の操作について見ていきたいと思います。
