Fabric のスロットリング ポリシー

スロットリングは、テナントの容量消費量が購入されている容量リソースを超えると発生します。 スロットリングが大きすぎると、エンド ユーザー エクスペリエンスが低下する可能性があります。 Microsoft Fabric テナントでは、複数の容量を作成し、課金とサイズ設定に関してワークスペースを特定の容量に割り当てることができます。

スロットリングは容量レベルで適用されます。これは、1 つの容量つまりワークスペースのセットのパフォーマンスが過負荷のために低下した場合も、他の容量は正常な実行を継続できる可能性があることを意味します。 OneLake 成果物などの機能がある容量で生成され、別の容量によって消費される場合は、消費している容量のスロットリング状態によって、成果物の呼び出しがスロットルされるかどうかが決まります。

パフォーマンスと信頼性のバランス

Fabric は、容量に割り当てられているよりも多くの容量ユニット (UC) リソースを操作がアクセスできるようにすることで、お客様に超高速のパフォーマンスを提供するように設計されています。 他のプラットフォームでは完了するまでに数分かかる場合があるタスクが、Fabric では数秒で完了できます。 運用負荷が急増したときにユーザーに悪影響がないようにするため、Fabric は、少なくとも 5 分間にわたって操作の CU 使用率を平滑化または平均化し、CU の使用率が高い時間は長くなるものの、実行時の要求は短くなります。 この動作により、スロットリングを発生させずに常に高速なパフォーマンスを実現できます。

実行時間が長く、CU の消費負荷が高いバックグラウンド操作の場合、Fabric は 24 時間にわたって CU の使用を平滑化します。 平滑化により、データ科学者やデータベース管理者は、アカウントの凍結を防ぐために、CU の負荷を 1 日全体に分散させるためのジョブ スケジュールの作成に時間を費やす必要がなくなります。 24 時間の CU の平滑化により、スケジュールされたジョブはすべて、1 日の間のいつでもスパイクを発生させることなく同時に実行でき、ジョブ スケジュールの管理に時間を無駄にすることなく、一貫して高速なパフォーマンスを実現できます。

インフライト操作はスロットルされない

スロットルされた状態になった容量は、その容量がスロットリングを開始した後で要求された操作にのみ影響します。 スロットリングが始まる前に送信された実行時間の長い操作を含め、すべての操作は完了まで実行できます。 この動作により、CU 使用量のサージ中であっても操作が完了することが保証されます。

スロットル トリガーとスロットル ステージ

平滑化の後でも、一部のアカウントでは、レポートのピーク時に CU の使用量が急増する可能性があります。 このような急増を管理するため、管理者は、容量がプロビジョニングされた CU リソースの 100% を消費したときにメール アラートを受け取れるように設定できます。 このパターンは、負荷分散が容量にメリットをもたらす可能性があることを示しており、管理者は SKU サイズを増やすことを検討する必要があります。 F SKU の場合は、管理設定でいつでもそれを手動で増減できることに注意してください。 ただし、容量が最大 CU 能力で動作している場合でも、Fabric はスロットリングを適用しません。 こうした動作により、ユーザーには中断の発生しない一貫した高いパフォーマンスが保証されます。

スロットリングの最初のフェーズは、容量が次の 10 分間に使用できるすべての CU リソースを消費すると開始します。 たとえば、10 単位の容量ユニットを購入し、1 分あたり 50 ユニットを消費した場合、1 分あたり 40 ユニットの繰り越しが発生します。 2 分半後には、将来の期間から借りた繰り越しの蓄積が 100 ユニットに達することになります。 次の 10 分間の容量のすべてを使い果たしたこの時点で、Fabric は最初のレベルのスロットリングを開始し、すべての新しい対話型操作は送信時に 20 秒だけ遅延されます。 繰り越しが 1 時間に達すると、対話型の要求は拒否されますが、バックグラウンドでスケジュールされている操作は引き続き実行されます。 容量の繰り越しが 24 時間分蓄積された場合、繰り越しが解消されるまで、容量全体が凍結されます。

将来的に円滑化される消費

繰り越し容量使用量の削減

容量にアイドル容量がある場合は常に、繰り越しレベルが先に解消されます。

100 CU 分ぶんの容量と、200 CU 分ぶんの繰り越しがあり、操作が実行されていない場合、繰り越しの解消には 2 分かかります。 この例では、繰り越しは 2 分間であるため、システムはスロットルされません。 スロットリングの遅延は、繰り越しが 10 分になるまで開始されません。

繰り越しをもっと速く解消する必要がある場合は、SKU サイズを一時的に増やして、繰り越しに適用されるアイドル容量を増やすことができます。

スロットリングの動作は Fabric に固有である

ほとんどの Fabric 製品は前に説明したスロットリング規則に従いますが、例外がいくつかあります。

たとえば、Fabric イベント ストリームには、開始したら何年間も実行できる多くの操作があります。 新しいイベント ストリーム操作をスロットルしても意味がないため、代わりに、容量が再び適正な状態になるまで、ストリームを開いたままにするために割り当てられる CU リソースの量が減らされます。

もう 1 つの例外は Real-Time Intelligence であり、操作が 20 秒遅れた場合はリアルタイムになりません。 そのため、Real-Time Intelligence は、10 分の繰り越しで 20 秒の遅延が発生する最初のスロットリング ステージを無視し、60 分の繰り越しで拒否フェーズのスロットリングが開始されるまで待機します。 この動作により、ユーザーは需要が多い期間でもリアルタイムのパフォーマンスを引き続き保証されます。

同様に、ウェアハウス カテゴリのほとんどすべての操作は、最も柔軟な使用パターンに対応できるよう、アクティビティの 24 時間の円滑化を利用するため、"バックグラウンド" として報告されます。 すべてのデータ ウェアハウスを "バックグラウンド" として分類すると、CU 使用率のピーク時にスロットリングのトリガーが早くなりすぎるのを防ぐことができます。 一部の要求では、スロットリングが異なる一連の操作がトリガーされる場合があります。 これにより、バックグラウンド操作が対話型操作としてスロットリングの対象になる可能性があります。

スロットリングと円滑化のための対話型とバックグラウンドの分類

Microsoft Fabric では、操作は "対話型" と "バックグラウンド" の 2 種類に分類されます。 これらの説明とこれらの説明の違いは、Fabric 操作にあります。

管理者は、対話型として分類された操作がバックグラウンドとして円滑化されたり、その逆のことが行われたりすることに、気付く場合があります。 この違いは、Fabric のスロットリング システムは、要求の実行が開始する前にスロットリング規則を適用する必要があるために発生します。 円滑化は、ジョブの実行が開始され、CU の消費量を測定できるようになった後で発生します。

スロットリング システムは、送信の時点で操作を正確に分類しようとしますが、スロットリングが適用された後で操作の分類が変更される場合があります。 操作の実行が開始すると、要求に関するいっそう詳細な情報がわかるようになります。 あいまいなシナリオでは、スロットリング システムは、誤るとしても、操作をバックグラウンドと誤って分類する方を試みます。これは、ユーザーにとって最善の方法です。

超過分と拒否された操作を追跡する

Microsoft Fabric 容量メトリック アプリで使用率グラフを確認すると、容量が過負荷になっているかどうかを確認できます。 線を越えるスパイクは過負荷を示しています。 過負荷をさらに調査するには、タイムポイント ページにドリルスルーします。 その後、"対話型" 操作と "バックグラウンド" 操作の両方を確認し、容量の過負荷の原因となっていた操作を確認できます。 また、過負荷イベントが発生したタイミングを確認することもできます。

使用率が 100% を超えても自動的に調整が行われるわけではないため、超過分を評価する際には調整グラフを使用する必要があります。 そこから、バーンダウンする時間 (分) を示すテーブルや、追加やバーンダウン、累積パーセントなどを含むグラフを開くことができます。

使用データの繰り越しや累積、バーンダウンなど、容量の過剰使用の履歴を視覚的に表示するには、[超過分] タブに移動します。超過分のビジュアル スケールを変更すると、10 分、60 分、24 時間のデータを表示できます。 繰り越しでは、課金対象の操作のみが考慮されます。

Microsoft Fabric 容量Metrics アプリのドリルダウンを使うと、管理者はスロットリング イベントの間に拒否された操作を確認できます。 これらの操作は開始することすら許可されなかったため、それに関する情報は限られています。 管理者は、製品、ユーザー、操作 ID、および要求が送信された日時を確認できます。 要求が拒否されると、エンド ユーザーは、後でもう一度やり直すように求めるエラー メッセージを受け取ります。

過負荷状況から回復するために実行できるアクション

容量が凍結された時点まで調整されると、ユーザーのアクションに Fabric コンピューティング リソースが必要な場合にエラーが発生します。 たとえば、エラーは 容量制限に達したためモデルを読み込めないとします。 このような場合は、これらの戦略を使用して、容量を凍結状態から回復できます。

• 過負荷状態が終わるまで待ってから、新しい要求を発行します。
• F 容量の SKU をアップグレードします。
• F 容量を一時停止/再開します。
• P 容量のオートスケール。
• より低い優先度、または過剰なワークスペースを容量から移動します。

関連するコンテンツ

• Microsoft Fabric 容量メトリック アプリをインストールして、Fabric の容量を監視します。