Fabric の容量運用についての方策
Fabric の容量管理において、使いすぎによるスロットリングの影響をどのように減らすかを整理してみました。
スロットリングとは
スロットリングとは、システムに過大な負荷がかかり、一定以上の超過が発生した場合に行われる利用制限のことです。
この「超過」を理解するには、まず CU の消費と清算の仕組みを押さえる必要があります。
Fabric の操作によって発生したシステム負荷は、すべて CU という単位に変換されます。
ただし、それらが発生した瞬間にそのまま請求されるわけではなく、10 分または 24 時間に分散されて、平準化（スムージング）された形で観測・請求されます。
これにより、夜間バッチ中心の場合など一日の間で負荷が大きく異なる状況でもスペックの上げ下げは不要というのがFabricの容量の考え方です。
ジョブの種類は大きく次の 2 つです。
- 対話型ジョブ：主にレポートの参照。SQL DB も実はこちらに含まれる
- バックグラウンドジョブ：Copilot を含め、データ処理の多くはこちらに含まれる
請求の清算は、Fabric 容量が毎秒提供する CU によって行われます。（一定の時間ごとに集計を繰り返す）
このとき、請求に対して CU が不足すると、「超過」という状態が発生します。
なお、清算に使われず余った CU は蓄積されません。
そのため、なるべく 100% に近い形で継続的に CU を使えている状態が、コスト効率の高い状態だと言えます。
この、超過が一定以上累積された場合に発生するのがスロットリングと名付けられた、使用制限です。
スロットリング回避の手段
スロットリングはシステム利用の制限であり、ユーザーへの影響範囲も大きいため、容量運用においてはスロットリング回避が最重要と言ってよいでしょう。
監視
容量がどのように使われているのか、事態の把握を素早く行い、対応します。
予兆の検知: 容量アラート
容量通知を使って、使用率がしきい値を超えたことをメールで把握します。
ただし、これは「そろそろ危ない」ことを知るための仕組みであり、スロットリングそのものを直接検知するものではありません。
可視化：容量メトリックアプリ、FUAM
可視化ソリューションを使用して、スロットリングへの到達率や、各ワークスペース、アイテムの使用量を可視化します。
- Qiita - Fabric Unified Admin Monitoring (FUAM) の設定
- Qiita - Microsoft Fabric Capacity Metrics アプリの設定方法
- MSLearn - Microsoft Fabric Capacity Metrics アプリとは?
追跡と検知とアクション：容量イベント
Fabric Capacity Overview Events と Activator を組み合わせることで、スロットリング到達率のような指標をリアルタイムに監視し、しきい値超過時にアラートやアクションを設定できます。
- MSLearn - Fabric Real-Time ハブでの Fabric の容量に関する概要イベントを探索する
- MSLearn - Eventstream に Fabric 容量の概要イベントを追加する (プレビュー)
- Qiita - Microsoft Fabric 容量のスロットリングをニアリアルタイム監視する Part 1
抑止・低減
スロットリングを実際に回避するための機能の利用です。
重要ワークロードの保護：サージ保護
CU 使用量に閾値を設け、これを超えた場合に追加のバックグラウンドジョブを送信できなくする仕組みです。
いわば疑似的なスロットリングであり、レポート参照を本来のスロットリングから保護するための機能と言えます。
ただし、1 ジョブで一気に大量の CU を消費し、そのまま即スロットリングに至るようなケースは防止できません。
- Workspace-level surge protection：容量内の各ワークスペースが使用できる CU 量を設定する
- Capacity-level surge protection：容量全体で使用できる CU 量を設定する
イメージ：
- MSLearn - 過電圧保護
- Speaker Deck - Microsoft Fabric のワークスペースと容量の設計原則
- Speaker Deck - Microsoft Fabric 開発ガイド
- Qiita - Power BI Premium/Fabric 容量のサージ保護 (Surge Protection)
追加清算による回避：超過清算（Capacity overage）
有効化すると、超過が発生した時点で課金処理を行い、スロットリングへの到達を避けることができます。
ただし、従量課金の 3 倍単価で課金されるため、常用ではなくスパイクを吸収する用途として考えるのが基本です。
目安としては、1 日あたりの CU 時間の 1/3 未満を上限として考えると、スケールアップとの費用比較がしやすくなります。
どうしてもスロットリングを回避したい場合には1/3より大きい値で清算限度を設定することもできます。
月に数度のスパイク程度であれば、スペックアップによる月間費用>現状スペックの月間価格＋3倍で清算された金額という場合もあり得ます。
Azure では従量課金制の 3 倍の料金で超過分の使用量が請求されるため、超過分の上限は 1 日の CU 時間の 3 分の 1 を下回るようにすることをお勧めします。コストが SKU のスケールアップに似ているポイント。 ただし、上限を高く設定することで、スケールアップ後でもスロットルが発生する可能性がある短くて重大なインタラクティブスパイクを処理する場合に役立ちます。
引用：https://learn.microsoft.com/ja-jp/fabric/enterprise/capacity-overage-overview
イメージとしては、左側の赤枠部分を即時清算する形です。
なお、この機能をオフにしている場合、超過分は次の時間枠で余っている CU から返済されます。
返済が間に合わないと、超過が累積し、最終的にスロットリングに至るイメージです。
まとめ
- 早く気づく = 通知 / イベント監視
- レポートだけは保護 = surge protection
- 止めたくない = capacity overage
このように役割分担して考えると整理しやすいです。