今回は、Microsoft Fabric を本気で使おうとすると必ずぶつかるテーマ、「Fabric 容量の仕組み」 について、少し腰を据えて整理してみます。まずは Fabric 容量とは何か？からスタートし、Fabric の PoC や本番導入をする際の下記の会話に深堀していきます。
- 「容量が足りないって言われるけど、そもそも容量って何？」
- 「Metrics アプリを見ると 100% って出てるのに、体感はそんなに詰まってない…？」
- 「Bursting？ Smoothing？ Throttling？ 結局どういうロジックで動いてるの？」
- 「Capacity Metrics App が難しすぎて、結局何を見ればいいのかわからない」
これらの概念は混乱しやすいため、分かりやすく嚙み砕いて紹介していきたいと思います。
Fabric 容量とは
Microsoft Fabric を触り始めると、最初に出会うキーワードが 「容量（Capacity）」 です。しかし、この概念が掴みづらく、多くの人がこう感じます。
「容量ってストレージ？それとも Azure の VM みたいなコンピュートのこと？」
実は Fabric の容量は、パソコンに例えると “CPU + メモリをまとめた処理能力セット” と考えると分かりやすいと思います。
Fabric 容量 = あなたの PC の「CPU & メモリ」
パソコンでは、CPU が計算を行い、メモリがその作業内容を一時的に保持します。
これらを同時に行うと CPU とメモリを大量に使い、負荷が高くなり PC が重くなります。同じように、Fabric における「容量」もいろいろな処理を実行するための計算資源で構成されています。Fabric では次のような作業が並行して走ります。
- Power BI のレポート表示（DAX 計算）
- Semantic Model の更新（データ刷新）
- Spark ノートブックの実行
- Warehouse / Lakehouse のクエリ処理
- Dataflow の実行、等
つまり、Fabric 容量とは 「これらの処理をどれだけ同時に・快適に動かせるか」を決める CPU & メモリ枠になります。
PC と同じで、重い処理をすると容量は一気に使われる
パソコンでも、動画編集ソフトやゲームを立ち上げると CPU 使用率が 100% 近くになります。Fabric でも同様で、
- 複雑な DAX を含むレポートを多人数で閲覧
- 大規模な Spark ジョブを並列実行
- Warehouse で重いクエリを連発
などが発生すると、容量（CPU & メモリ）が急激に消費されます。
PC の「固まる」を防ぐ仕組みが、Fabric の Bursting / Smoothing / Throttling
パソコンは負荷が高くなるとフリーズしますが、Fabric はクラウドならではの仕組みでそれを防いでいます。
- Bursting：一瞬だけ CPU を“借金して”増やす
- Smoothing：借りた CPU 分を少しずつ返していく（返済スケジュール）
- Throttling：返済が無理になったら処理を遅延／拒否して守る
これらによって、急激なアクセスや重い計算となった場合でも、Fabric 全体が倒れないようコントロールされています。これらをまとめ、更に特徴を追加したものが以下のスライドとなります。
ここで更にポイントとなるのは
容量は「箱」ではなく「共有プール」
ということです。つまり、Fabric 容量は 1人や1ワークスペース専用の箱ではないということです。容量は、次の 3 つの観点で共有されます。
- ワークロード（Fabric アイテム）間の共有
- Power BI（Semantic model & レポート）
- Spark（ノートブック）
- Warehouse / Lakehouse / Eventhouse
- Real-Time Intelligence (RTI) など
これらが 同じ容量の上で動く ことが可能
- ワークスペース / プロジェクト間の共有
- ユーザー間の共有
- レポート閲覧ユーザー、開発者、データエンジニアなど、多くのユーザーが同じ容量を使用
- その結果、1人の“重い”ユーザー（例えば複雑な DAXクエリを連射する人）"が、他のユーザー全員に影響を与え得るという構造に
容量を細かく分割して固定で割り当てるよりも、ある程度まとめてプールし、複数チームでうまく共有した方が、コスト効率も、リソース利用効率も上がります。しかし同時に、「ノイジーネイバー (Noisy Neighbor) 問題*1」が起きやすい構造でもありますので、Fabric 容量の可視化・制御が重要になります。
スケールの考え方 — Up / Out / Region
Fabric 容量は、2 の累乗でスケールします。
F2 / F4 / F8 / F16 / F32 / F64 / … / F2048
負荷が足りない場合の選択肢は大きく 2 つです。
- Scale up (垂直スケール)：SKU を上げる（例：F64 → F128）
→ 1つの大きな容量をみんなで共有するパターン - Scale out (水平スケール)：容量を複数用意し、ワークスペースや組織単位で割り当てる
→ 事業部 A 用容量、事業部 B 用容量…のように「論理的な箱」を分けるパターン
どちらがベストか？それは常に ‘It depends (状況次第)’ で、顧客のやりたいこと・求めるもの次第ということになります。
ただ、ヒントとして、以下が該当するでしょう。
1つの大きな容量：運用はシンプルだが、ノイジーネイバーの影響が出やすい
複数容量：分離はしやすいが、配置設計やコスト配賦が難しくなる
PoC の段階では 1つの 容量に集約し、容量 Metrics App を見ながらボトルネックを探すのが現実的でしょう。長期運用を見据えると、組織構造・データドメインに合わせて容量を分割することも検討する価値があります。
一方、地域（Region）に関しては 2 つの概念があります。
ポイントは、
データレジデンシー*2を満たしたいとき、実際にどのリージョンにデータが保存されるかを決めるのは容量のリージョンである
ということです。
また、パフォーマンス面ではユーザーと容量の物理的な距離も重要です。
例) 容量がアメリカ、ユーザーが日本にいる場合
→ Azure バックボーン上とはいえ、物理距離によるレイテンシは避けられない
そのため、初期設計ではまず：
- 既存の Azure サービス（SQL Database / Synapse / Databricks 等）がどのリージョンにあるか
- どの地域のユーザーが主に使うのか
を踏まえた上で、容量のリージョンを決めていく必要があります。
まとめ
Fabric 容量に関しては量が膨大になるため、初回はこの程度で終わらせたいと思います。次回はコンピュート (Compute) と 課金 (Billing)、Bursting / Smoothing / Throttling等について解説をしていきます。
