Subscribe
Share
Share
Embed
Fabricは処理の実行時に課金するのではなく、2880個の30秒タイムポイントにコストを前方分散します。このひと言が、容量にまつわるあらゆる不可解な挙動を説明します。サージ保護が、守るべきSQLを拒否する理由も含めて。
Episode 37 • 2026-10-16 Duration: 11:14
Fabricは処理の実行時に課金するのではなく、2880個の30秒タイムポイントにコストを前方分散します。このひと言が、容量にまつわるあらゆる不可解な挙動を説明します。サージ保護が、守るべきSQLを拒否する理由も含めて。
The Fabric Friday video on this topic: https://youtu.be/iE-jdcseCaY
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
このポッドキャストは AI によって生成されています。どちらの音声も合成です。Matthias はクローン音声、Fabia は設計された AI 共同ホストです。
Brand design based on fabricperiodictable.com.
Microsoft Fabric のア���キテクチャ意思決定。匿名化された実際の顧客シナリオ、コストのリアリズム、反論を含む。Fabric Friday の録画に合わせた週刊エピソード。AIにより生成。
昨夜の更新が絞る午後3時
Episode 37 | 2026-10-16
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: 午後3時。ユーザーからFabricが遅いと連絡が入ります。4時には、もう落ちてると。管理者がメトリック アプリを確認しても、何も動いていません。
[00:12] Matthias: パイプラインも更新処理もなし？
[00:13] Fabia: 原因の処理は12時間前に終わっています。
[00:15] Matthias: 処理の課金がそう動くとは、普通は思わない。
[00:17] Fabia: Fabricの仕組みは違います。コストを先の時間帯に分散させるんです。対話型の処理は5分から64分、バックグラウンド処理は24時間かけて。このひと言で、容量にまつわる不可解な挙動がすべて説明できます。
[00:23] Matthias: では今日は、その時間分散が実際に何を引き起こすのか、掘り下げていきましょう。
[00:26] Fabia: 誰も話題にしない単位があります。タイムポイントです。30秒ごとに1つ。1日に2880個。実行したすべての操作が、そのコストの一部を一連のタイムポイントに振り分けます。
[00:31] Matthias: つまり各タイムポイントにはSKUに応じた予算がある、と。
[00:33] Fabia: F2なら1タイムポイントあたり60 CU秒です。平滑化によって、操作のコストがいくつのタイムポイントに配分されるかが決まります。
[00:37] Matthias: つまり大きなバックグラウンド処理でも、1つのタイムポイントに集中しない。2880個すべてに……分散される。
[00:41] Fabia: ドキュメントに具体例があります。F2で1 CU時間を消費するバックグラウンド処理。つまり3600 CU秒です。各タイムポイントへの配分は1.25 CU秒。そのタイムポイントの予算の約2%です。
[00:47] Matthias: 2%。次の10分間の容量の6倍を使った処理が、たった2%。
[00:49] Fabia: しかもスロットリングは一切発生しません。平滑化の効果です。平均値で容量を決められます。
[00:52] Matthias: 平滑化のせいで、処理自体が遅くなることはないんですか？
[00:54] Fabia: ありません。ドキュメントにも明記されています。平滑化は実行時間に影響しません。処理はフルスピードで走ります。変わるのは、コストがいつ計上されるか、だけです。
[00:59] Matthias: つまり会計処理ですね。優れた会計処理だけど、あくまで会計。
[01:01] Fabia: 何よりもまず、コスト管理の仕組みです。
[01:02] Fabia: 動画でもこの動きを確認できます。何時間も前に終わった重いノートブック処理が、まだ夜のタイムポイントにコストを振り分けている。合計2万2000 CU秒超のうち、1つのタイムポイントに7.75 CU秒が計上されています。
[01:10] Matthias: それを2880で割ると？
[01:10] Fabia: ぴったりその数字になります。平滑化とは割り算です。
[01:12] Matthias: では、5分の窓になるか24時間の窓になるか、誰が決めるんですか？自分で選べます？
[01:15] Fabia: 選べません。操作が実行される前に分類が行われます。すべての操作がまずゲートを通り、対話型かバックグラウンドかのスタンプを押されてから、初めて実行が始まります。
[01:20] Matthias: あいまいな場合は？
[01:21] Fabia: バックグラウンドにフォールバックします。ドキュメントによれば、それがユーザーにとって有利だからです。24時間の平滑化なら、タイムポイントあたりの負担が小さくなりますから。
[01:26] Matthias: 既定がやさしい方だというのは……安心します。
[01:28] Fabia: スロットリングに関しては、そうです。この話、覚えておいてください。
[01:30] Fabia: スロットリング自体は階段状に進みます。3段階あって、将来の容量をどれだけ先食いしたかで決まります。10分未満なら何も起きません。これが超過保護です。10分を超えると、新しい対話型操作に20秒の待機が入ります。
[01:37] Matthias: バックグラウンドは？
[01:38] Fabia: 第1段階では影響を受けません。60分を超えると、対話型操作は完全に拒否されます。バックグラウンド処理はまだ開始も実行もできます。24時間を超えると、すべての新規操作が拒否されます。
[01:44] Matthias: え、第2段階ではダッシュボードが使えなくなるのに、裏のパイプラインは走り続ける？しかも負債を積み上げながら？
[01:47] Fabia: 設計どおりです。
[01:48] Matthias: レポートが真っ暗になるのをチームが見ている間、その原因が——
[01:50] Fabia: ——走り続けている、そうです。そして2つのワークロードは段階を飛ばします。リアルタイム インテリジェンスは20秒の遅延をスキップします。遅延を入れたら意味がなくなりますから。60分で拒否されるまでフルスピードです。
[01:57] Matthias: Eventstreamは？
[01:58] Fabia: Eventstreamの操作は何年も動き続けることがあるので、新規操作のスロットリングは意味をなしません。代わりにFabricは、ストリーム維持に割り当てるCUを減らします。エラーは出ません。ただ遅れるだけです。
[02:05] Matthias: 最も気づきにくいワークロードの、最も静かな障害モード。
[02:07] Fabia: まさにこのパターンについて投稿した方がいます。その方の言葉です。「午後3時にスロットリングされました。午後3時には何も動いていませんでした。何が起きたのですか？」
[02:13] Matthias: 仕組みを理解した今なら、答えはもう見えていますね。
[02:14] Fabia: 昨夜終わった更新処理が、その後の2880個すべてのタイムポイントにコストを配分しています。午後3時でもまだ支払いが続いている。メトリック アプリで調べるべき容疑者リストは、丸1日分です。
[02:21] Matthias: 午後3時の犯人を探すのではなく、台帳を読む。
[02:22] Fabia: タイムポイントの画面には、過去24時間以内に完了したすべてのバックグラウンド操作が一覧されます。それが容疑者リストです。
[02:26] Matthias: さっきの分類スタンプの話に戻らせてください。覚えておいてと言っていましたよね。
[02:29] Fabia: ここからが本題です。FabricはWarehouseの操作をほぼすべてバックグラウンドに分類します。意図的にです。クエリのピークが24時間に分散されるので、スロットリングが発生しにくくなります。
[02:35] Matthias: それが恩恵ですね。
[02:36] Fabia: ではサージ保護を有効にしてみてください。サージ保護は、対話型処理を守るためにバックグラウンド処理を拒否します。そしてドキュメントにはこう書いてあります。SQLクエリのような対話型操作の多くもバックグラウンドとみなされ、拒否される可能性がある、と。
[02:44] Matthias: つまり、SQLをスロットリングから守っているスタンプが、サージ保護ではそのSQLを拒否する理由になる。
[02:47] Fabia: ひとつの事実。正反対のふたつの結果。
[02:49] Matthias: では、サージ保護は実際には誰のためのものなんですか？
[02:50] Fabia: Power BIのレポートとSparkのパイプラインが同じ容量にいる場合です。レポートは対話型、パイプラインはバックグラウンド。この組み合わせならサージ保護は理にかなっています。
[02:56] Matthias: でもクリティカルパスがSQLなら、サージ保護はむしろ敵です。そういう分析ワークロードは実際多い。ドキュメントは専用の容量を推奨しています。正しいんですが、予算担当者との交渉がひと回り大変になります。
[03:03] Fabia: ドキュメントはサイジングの代替とは言っていません。適切な容量サイジングの代わりにはならない、と明記しています。
[03:07] Matthias: 夜間にスケールダウンしたいチームのことを考えてみましょう。提案はいつも同じです。小さいSKUに落として、請求を半分にしよう、と。
[03:11] Fabia: 計算は単純ですが、数字は甘くありません。SKUを半分にすれば使用率は2倍です。ドキュメントの例では、F128の平滑化後の使用率が40%以下でなければ、F64で80%に収まりません。
[03:17] Matthias: 50%だったら？
[03:17] Fabia: F64で100%です。余裕はゼロ。次のスパイクが10分間の超過保護を使い切れば、もう第1段階に入ります。
[03:21] Matthias: 快適な50%が——
[03:22] Fabia: ——緊急事態に変わります。そしてその罠の中にもう一つの罠があります。スケールダウンしたい夜は、昼間の処理をまだ背負っている。バックグラウンドの平滑化は24時間です。カレンダーには静かな時間帯があっても、会計上は静かな時間帯などありません。
[03:29] Matthias: その一文をスライドに出して、会議の最後まで表示しておきたいですね。
[03:32] Matthias: ただ逆の視点も考えてみましょう。Sparkの自動スケーリング課金は、まったく別のモデルですよね。
[03:35] Fabia: Sparkに関しては平滑化もバーストも完全に無効になります。従量課金です。対話型のSpark処理はCUを使い切るとスロットリングされます。バックグラウンドのSpark処理はキューに入ります。CUの上限が2048なら、そこまでキューイングされます。
[03:43] Matthias: つまり、請求の予測可能性を手放す。
[03:45] Fabia: その代わり、自ら招くスロットリングが確実になくなります。
[03:46] Matthias: Sparkの処理が重くて平滑化の窓に苦しんでいるチームなら、真剣に検討すべきだと思います。固定の請求額が助けになるのは、容量のサイジングが正しい場合だけです。実際に使っている量に対して容量が足りていないチーム、何度も見てきました。
[03:54] Fabia: ドキュメントもまさにその点を指摘しています。ある種の予測可能性を、別の種類と交換する仕組みだと。問題は、どちらの想定外を避けたいか、です。
[03:59] Matthias: 本当に夜眠れなくなるのは、サージ保護の誤解です。チームがサージ保護を有効にして、SQLは守られていると信じている。そこにバックグラウンドのスパイクが来たら、そのクエリが拒否されます。
[04:05] Fabia: しかも拒否メッセージには「バックグラウンドとして分類されました」とは書いてありません。ただ失敗する。チームはクエリに問題がないか調べ始めます。
[04:10] Matthias: 受け入れられるリスクですか？計算の答えより1段階大きいSKUを選ぶこと。コストはかかります。でも障害のコストの方が高い。
[04:14] Fabia: クエリパターンを見せてください。ただし容量の話なら、平滑化された線を見てください。予測できるのは、あの線だけです。
[04:18] Matthias: 今日のまとめはひと言です。容量とは、24時間の遅延が組み込まれた会計システムである。この遅延を理解すれば、メトリック アプリは謎ではなく台帳として読めるようになります。
[04:24] Fabia: 今このとき、どこかの容量のグラフに、穏やかに見える夜があります。でもそこから明朝までのタイムポイントは、今日の処理でまだ埋まり続けています。
[04:29] Matthias: そして誰かが、グラフが静かだからとSKUを半分にしようとしている。
[04:31] Fabia: グラフに見えるスパイクは領収書です。平滑化された線は、まだ届いていない請求書です。
[04:34] Matthias: 今日の話で容量のサイジングの考え方が変わったという方、ぜひLinkedInでDMをください。Matthias Fallandで見つかります。
[04:39] Fabia: また来週の金曜日に。
---
End of episode. ~04:39 estimated.