スロットリングは、操作が容量 SKU で許可されているよりも多くのコンピューティングユニット秒 (CU) を消費する場合に発生します。 スロットリングが大きすぎると、エンド ユーザー エクスペリエンスが低下する可能性があります。 Microsoft Fabric テナントでは、複数の容量を作成し、課金とサイズ設定に関してワークスペースを特定の容量に割り当てることができます。
スロットリングは容量レベルで適用されます。これは、1 つの容量つまりワークスペースのセットのパフォーマンスが過負荷のために低下した場合も、他の容量は正常な実行を継続できる可能性があることを意味します。 OneLake 成果物などの機能がある容量で生成され、別の容量によって消費される場合は、消費している容量のスロットリング状態によって、成果物の呼び出しがスロットルされるかどうかが決まります。
パフォーマンスと信頼性のバランス
Fabric は、お客様に高速なパフォーマンスを提供するように設計されています。 他のプラットフォームで完了するまでに数分かかる場合があるタスクは、Fabric でわずか数秒で完了できます。 大規模な操作は、操作の速度を低下させることなく、より長い期間にわたって分散されるため、慎重なスケジュール設定を必要とせずにいつでも実行できます。 ファブリックは、組み込みの バースト と スムージングを使用してこれを可能にします。 一時的な使用量の急増によって他のシステムの障害や速度低下が発生する場合に、容量を自己管理および自己復旧できます。
バースト
高速なパフォーマンスを確保するために、Fabric では バーストを 使用して、操作をできる限り高速に実行できます。 バーストすると、操作時に、容量 SKU のプロビジョニング済みコンピューティングよりも大量のコンピューティングを一時的に使用できます。 バーストのため、ユーザーは待たずにすばやく結果を得ることができます。 バーストを使用すると、通常より高価な容量を必要とする大規模な操作を、より低容量で実行できるようになります。
スムージング
バーストすると操作時に都合が良い場合にユーザーがペナルティを課されないように、Fabric では、操作時の CU 使用量を、長期間にわたって "平滑化" または平均化します。 この動作により、調整を発生させずに常に高速なパフォーマンスを実現できます。
平滑化すると、消費された CU 使用量が、将来の各 "タイムポイント" に分散されます。 Fabric のタイムポイントは 30 秒です。 次の 24 時間には 2,880 個のタイムポイントがあります。 Fabric は、各タイムポイントの消費 CU の量を自動的に管理します。
操作の使用率の種類によって、スムージングに使用されるタイムポイントの数が決まります。 Fabric の操作について説明します。
- 対話型操作は、少なくとも 5 分間、消費する CU 使用量に応じて最大 64 分にわたって平滑化されます。
- バックグラウンド操作は、通常、長いランタイムと大規模な CU 消費量があるため、24 時間にわたって平滑化されます。
スムージングにより、操作の CU 使用量の一部のみが個々のタイムポイントに適用され、調整全体が減少します。 スムーズな CU の利用は、操作が進むにつれて蓄積します。 平滑化された使用量は、"将来の容量" によって支払われます。容量は実行され続けているため、これは将来のタイムポイントで使用できる CU ということになります。
バーストと平滑化は、容量ユーザーが作業しやすくなるように、共に機能します。 たとえば、ユーザーは通常、ジョブのスケジュール設定に時間を費やし、それらを1日を通じて分散させます。 スムージングを使用すると、バックグラウンド ジョブのコンピューティング コストが 24 時間にわたって平滑化されます。 つまり、スケジュールされたジョブはすべて同時実行が可能であり、スパイクが発生してジョブが開始できなくなることはありません。 同時に、ユーザーは、低速のジョブが完了するのを待たずに、またはジョブ スケジュールの管理に時間を無駄にすることなく、常に高速なパフォーマンスを実現できます。
注
容量管理者が Spark の自動スケール課金を有効にしている場合、バーストとスムージングはサポートされません。 このシナリオでは、Spark の使用は従量課金制You-Go モードで動作し、バーストとスムージングの概念は適用されません。
スロットル トリガーとスロットル ステージ
容量には、使用量の急増の影響を軽減するスムージングが組み込まれていますが、多すぎる操作を実行することで容量を 過負荷 にすることは引き続き可能です。
容量が過負荷になると、新しい操作の頻度が自動的に制限されます。 調整は、データ更新などの重要なタスクへの影響を最小限に抑えるために、段階的な手順で行われます。
容量が100%を超える使用率で動作している場合でも、ファブリックはすぐにスロットリングを適用しません。 代わりに、容量には、将来の容量を調整なしで 10 分間消費できる "超過分の保護" が用意されています。 この動作により、サージからの組み込み保護が制限され、中断することなく一貫して高速なパフォーマンスがユーザーに提供されます。
調整は、容量で次の 10 分間に CU リソースがすべて使い果たされると開始します。 スロットリングの最初の段階では、新しい対話型操作に 20 秒の遅延が適用されます。 調整の 2 番目のフェーズでは、容量で次の 1 時間に CU リソースがすべて使い果たされると、新しい対話型操作が拒否されます。 このフェーズでは、バックグラウンド操作の開始と実行が許可されます。 調整の 3 番目のフェーズでは、容量で次の 24 時間に CU リソースがすべて使い果たされると、すべての新しい要求 (対話型とバックグラウンド) が拒否されます。 容量では、消費された CU が精算されるまで、要求が調整され続けます。
注
Microsoft は、お客様の容量使用量を管理する必要性のバランスを取りつつ、お客様がサービスを利用するうえでの柔軟性を向上させるように努めています。 このため、Microsoft はファブリックの調整ポリシーを変更または更新する場合があります。
表は、制御トリガーとその段階をまとめたものです。
| 使用方法 | ポリシーの制限 | プラットフォーム ポリシーのエクスペリエンスへの影響 |
|---|---|---|
| 使用量 <= 10 分 | 超過分の保護 | ジョブは、スロットリングなしで将来 10 分間の容量使用量を消費できます。 |
| 10 分 < 使用量 <= 60 分 | 対話型の遅延 | ユーザーが要求した対話型ジョブは、送信時に 20 秒だけ遅延されます。 |
| 60 分 < 使用量 <= 24 時間 | 対話型の拒否 | ユーザーが要求した対話型ジョブは拒否されます。 |
| 使用量 > 24 時間 | バックグラウンドの拒否 | すべての要求が拒否されます。 |
平滑化と調整の制限の例
次に示すのは、1 CUHr を消費した 1 つのバックグラウンド操作でスムージングがどのように機能するかの例です (その使用は 1 時間の 1 CU に相当します)。 バックグラウンド操作は 24 時間にわたって平滑化されます。 あるタイムポイントでのバックグラウンド操作の寄与度は、その操作の CUHr 数 / SKU レベルでの CUHr 数です。 F2 の場合、このジョブは、各タイムポイントに 1 CUHr / 48 CUhr = ~2.1% 寄与します。 10 分間と 60 分間の調整の制限への影響は、~2.1% です。
この例をサポートする詳細を次に示します。
1 CUHr = 3,600 CU (1 CU * 60 分/時 * 60 秒/分)
各タイム ポイントの長さは 30 秒です。 24 時間には、2,880 個のタイムポイント (24 時間 * 60 分 * 1 分あたり 2 つのタイムポイント) があります。
3,600 CU は 24 時間に対して平滑化されるため、ジョブは 30 秒間の各タイムポイントに 3,600 CU/2,880 タイムポイント寄与します。 そのため、タイムポイントあたり 1.25 CU が提供されます。
10 分間の調整率は、次の 10 分間の容量アップタイムで使用可能な合計 CU に基づいています。
F2 容量では、1 秒ごとに 2 CU です。 各タイムポイントでは、F2 には 2 CU * 30 秒 = 60 CU のコンピューティングがあります。
個々のタイムポイントに対するバックグラウンド ジョブの寄与度は、個々のタイムポイントあたり 1.25 CU/60 CU = ~2.1% です。
10 分間で、F2 には 2 CU * 60 秒 * 10 分 = 1,200 CU の処理能力があります。
バックグラウンド ジョブのうち次の 10 分間の容量に平滑化された部分は、1.25 CU * 1 分あたり 2 タイムポイント * 10 分間 = 25 CU です。
したがって、10分間のスロットリング率は、25 CU / 1,200 CU = 約2.1%となります。
同様に、バックグラウンド ジョブの 60 分間の調整率の影響も ~2.1% です。
バックグラウンド操作で、次の 10 分間に使用できる CU よりも多くが消費されました（消費量は6倍でした）。ただし、合計 CU は 24 時間にわたって平均化されるため、F2 容量は制限されません。 スムージングにより、消費される CU のごく一部のみが個々のタイムポイントに適用されます。
超過分、繰り越し、バーンダウン
操作で 1 つのタイムポイントで SKU がサポートする容量よりも多くの容量を使用すると、 超過分 が計算されます。 超過分は、スムージングが適用された後に計算されます。 許可された 10 分間の調整期間を超える超過分がある場合は、"繰り越し" CU になります。
"超過分の保護" により、10 分間の調整期間が終了するまで、容量では調整が行われません。 これは、使用率の一時的な急増による対話型遅延の頻度を減らすように設計されています。
繰り越し CU は、後続の各タイムポイントに適用されます。 タイムポイントがいっぱいでない場合、未使用のCUによって、繰り越しされるCUの量が減少します。 削減は バーンダウンと呼ばれます。
調整の実施は、未使用の容量によってすべての繰り越し CU が支払われるまで続きます。
調整を目的とした容量の監視
容量管理者は、容量がプロビジョニングされた CU リソースの 100% を消費したときに通知を受け取る電子メール アラートを設定できます。 管理者は、容量メトリック アプリを使用して、容量の調整レベルを確認することもできます。
容量の適切なサイズ設定と最適化
一貫して高い調整レベルは、複数の容量間で負荷分散を行うか、容量の SKU サイズを増やす必要があることを示します。 F SKU を使用する場合は、管理者設定でいつでも SKU サイズを手動で増減できます。これにより、必要に応じて調整を解決できます。
容量制限が発生していることを見分ける方法
容量が要求を拒否すると、ユーザーには特定のエラー コードとエラー テキストが表示されます。
- 状態コード
CapacityLimitExceeded - エラー メッセージ
Your organization's Fabric compute capacity has excceded its limits. Try again later。 - エラー メッセージ
Cannot load model due to reaching capacity limits
注
アイテムのデザインが原因でパフォーマンスが低下することがよくあります。 パフォーマンスの低下は、容量の調整によってのみ発生することがあります。
容量が過負荷になると、容量管理者は Fabric 容量メトリック アプリを使用して調整を確認できます。
- [コンピューティング] ページの [システム イベント] テーブルには、調整イベントの履歴が表示されます。
- [コンピューティング] ページの "調整" グラフは、平滑化された使用量がいずれかの調整制限を超えたときに表示されます。
調整を停止する方法
容量は自己復旧であるため、オーバーロード状態が終了するまでいつでも待機してから、新しい要求を送信できます。
ただし、調整をすばやく停止するには、次に示す方法を使用します。
F SKU 容量を使用している場合、調整を停止するには、次の手順を実行します。
- SKU を一時的に増やします。 SKU を増やすと、余剰容量が増えるため、各時点での繰り越し分の消化が速まります。
- 容量を一時停止して、再開します。 容量を一時停止すると、将来の容量使用量の累積に対する課金イベントが発生します。 容量が開始または再開されると、将来の容量使用量はゼロになるため、新しい操作をすぐに受け入れることができます。
P SKU 容量を使用する際にスロットリングを防ぐには、次の手順を実行します。
- P 容量の 自動スケーリング を有効にします。
インフライト操作はスロットルされない
調整の影響を受けるのは、容量で調整が開始した後に要求された操作のみです。 調整が開始される前に送信された実行時間の長い操作を含むすべての操作は、完了まで実行できます。 この動作により、CU 使用量のサージ中であっても操作が完了することが保証されます。
複合調整の保護
Fabric では、多くの場合、1 つの操作によって他の項目またはワークロードがトリガーされ、完了します。 多くの例がありますが、一般的なものはレポートを表示することです。 レポート内の各ビジュアルは、基になるセマンティック モデルに対してクエリを実行します。 セマンティック モデルでは、クエリ結果を提供するために、OneLake 形式のデータを読み取ることもできます。 これらの要求はそれぞれチェーンを形成します。
呼び出しのチェーンがある場合、 複合調整のリスクがあります。これは、調整が同じ要求に複数回適用される場合です。 ファブリックには、複合スロットリングが発生する可能性を減らす保護機能が組み込まれています。 ワークロードでは、この保護の使用をオプトインできます。
ワークロードが複合調整の保護をサポートしている場合、要求の調整は、チェーンに参加する容量ごとに 1 回のみ行われます。 調整の決定は、要求が開始すると行われ、そのチェーン内のすべての操作に適用されます。
チェーンが複数の機能に依存している場合、各機能はチェーンで最初に受け取った要求に対してスロットリングを 1 回適用します。
次のワークロード エクスペリエンスは、複合調整をサポートしています。
- ダイレクト クエリを使用して他のセマンティック モデルに接続するセマンティック モデル。
- ページ分割されたレポートからセマンティック モデルへの DAX クエリ。
調整動作は Fabric ワークロードに固有です
ほとんどの Fabric 製品は前に説明したスロットリング規則に従いますが、例外がいくつかあります。
たとえば、Fabric イベントストリームには、いったん開始されると何年も実行される可能性がある多くの操作があります。 新しいイベントストリーム操作を制限しても意味がないので、代わりに、容量が再び適正な状態になるまで、ストリームを開いたままにするために割り当てられる CU リソースの量が減らされます。
もう 1 つの例外は Real-Time Intelligence であり、操作が 20 秒遅れた場合はリアルタイムになりません。 その結果、リアルタイム インテリジェンスでは、将来の 10 分間の容量で 20 秒間の遅延を伴う調整の第 1 段階が適用されません。 リアルタイム インテリジェンスは、将来の 60 分間の容量の拒否フェーズで調整が開始するまで待機します。 この動作により、ユーザーは需要が多い期間でもリアルタイムのパフォーマンスを引き続き保証されます。
同様に、ウェアハウス カテゴリのほとんどすべての操作は、最も柔軟な使用パターンに対応できるよう、アクティビティの 24 時間の円滑化を利用するため、"バックグラウンド" として報告されます。 すべてのデータ ウェアハウスを "バックグラウンド" として分類すると、CU 使用率のピーク時にスロットリングのトリガーが早くなりすぎるのを防ぐことができます。 一部の要求では、調整が異なる一連の操作がトリガーされる場合があります。 対話型操作がバックグラウンド操作を含むチェーンを開始すると、バックグラウンド操作が対話型操作として調整の対象になる可能性があります。
スロットリングと円滑化のための対話型とバックグラウンドの分類
管理者は、対話型として分類された操作がバックグラウンドとして円滑化されたり、その逆のことが行われたりすることに、気付く場合があります。 この違いは、Fabric のスロットリング システムは、要求の実行が開始する前にスロットリング規則を適用する必要があるために発生します。
調整システムは、送信時に操作を正確に分類しようとします。 操作の実行が開始されると、分類を変更するより詳細な情報が使用できるようになる場合があります。 あいまいなシナリオでは、調整システムによって操作がバックグラウンドとして分類されてしまいますが、これはユーザーにとっては良いことです。
超過分と拒否された操作を追跡する
容量が過負荷になっているかどうかを確認するには、Microsoft Fabric Capacity Metrics アプリの使用率グラフを確認します。 しきい値を超えるピークは超過を示します。 超過分を詳細に調査するために、タイムポイントのページに移動してください。 その後、対話型操作とバックグラウンドプロセスの両方を確認することができ、どの操作が超過分を担当していたかを確認できます。
使用率が 100% を超えても自動的に調整が行われるわけではないため、超過分を評価する際には調整グラフを使用する必要があります。 そこから、バーンダウンする時間 (分) を示すテーブルや、追加やバーンダウン、累積パーセントなどを含むグラフを開くことができます。 バーンダウンまでの時間 (分) は、容量内でこれ以上操作が行われなかった場合にバーンダウンにかかる時間を見積もります。
使用データの繰り越しや累積、バーンダウンなど、容量の過剰使用の履歴を視覚的に表示するには、[超過分] タブに移動します。超過分のビジュアル スケールを変更すると、10 分、60 分、24 時間のデータを表示できます。
Microsoft Fabric 容量Metrics アプリのドリルダウンを使うと、管理者はスロットリング イベントの間に拒否された操作を確認できます。 これらの操作は開始することすら許可されなかったため、それに関する情報は限られています。 管理者は、製品、ユーザー、操作 ID、および要求が送信された日時を確認できます。 要求が拒否されると、エンド ユーザーは、後でもう一度やり直すように求めるエラー メッセージを受け取ります。
課金対象のコンピューティングと課金対象外のコンピューティング
容量メトリック アプリで容量の使用状況を確認すると、一部の操作は課金対象となり、その他の操作は課金対象外です。 調整の計算には、課金対象の操作のみが含まれます。 プレビュー機能では、課金対象ではない操作を生成できます。 課金対象外の操作を使用して、これらのプレビュー機能が課金対象になったときに容量のサイズが正しく調整されるように事前に計画します。
関連するコンテンツ
- Microsoft Fabric 容量メトリック アプリをインストールして、Fabric の容量を監視します。
- 容量のサイズを変更する方法。