Microsoft Fabricの容量超過

容量超過は、適格な余剰容量使用量に対して、管理者が設定する24時間のローリング閾値まで支払いを行うオプトイン機能です。 これにより、プロビジョニングされたSKUを超える一時的な需要時のスロットリングを防ぐのに役立ちます。 設定された閾値はハード支出上限ではありません。 Fabricは定期的に過剰料金を評価し、すでに進行中の作業が継続しているため、料金が閾値を超えることがあります。

この機能は、さらなる制限を防ぐために対応を行っている間、容量を維持する安全策として機能します。 有効にすると、容量超過料金は従量課金料金の3倍で請求されますが、対象となるのは、現在の容量を超え、そうでなければスロットリングが発生する使用分のみです。 容量超過を有効にすることで、予期しない需要の急増や小さな定期的な過負荷の間もワークロードが中断されることなく継続されることを保証します。 この方法は、適切な容量管理プラクティスを補完しますが、それらに取って代わるものではありません。

Note

Fabric容量を作成すると、容量超過はデフォルトで有効になります。 容量作成時やプロビジョニング後、OneLakeカタログや管理者ポータルを通じて設定できます。

主な利点

容量超過には、次の主な利点があります。

  • 予期しない過負荷の間はセーフティネットとして機能し、管理者が対応するための時間を提供しながら容量を維持します。
  • 管理者の操作を必要とせずに、小規模で日常的な対話型オーバーロードを自動的に処理します。

容量超過のしくみ

容量の超過は、管理者が設定した閾値までの余剰容量使用量を自動的に支払うことでスロットリングを防ぎます。 Fabricでのスロットリングが容量超過とどのように関わるかは以下の通りです:

  • 各容量には、容量ユニット (CU) で測定された固定コンピューティング リソースがあります。

  • 設定されたしきい値を超えて需要が使用可能な容量を超過した場合（平滑化後）、Fabricはスロットルを適用します。 スロットリングについてもっと知りたい方は、 スロットリングの仕組みをご覧ください。

  • 容量超過は、スロットリングが起こるはずの時点での余剰使用量を補償します。

容量超過は、調整の時点で介入します。 容量の平準化された使用量が組み込みのしきい値を超えた場合、遅延や拒否を行う代わりに、容量超過分は Azure サブスクリプションに課金することで、超過使用量を自動的に精算します。 この方法により、容量はスロットルなしで維持されます。 実行中のジョブは中断されることなく継続され、キャパシティもユーザーに見えるスロットリングが発生することなく稼働し続けます。

コストと性能のバランスを取るために、容量管理者は24時間の回転超過閾値を定義します。 Fabricはこの閾値を過去24時間の処理超過と比較し、5分ごとに評価します。 例えば、Fabricが09:00にチェックを行った場合、昨日の09:00から今日の09:00までの処理済み超過分と閾値を比較します。 09:05 にウィンドウが 5 分進み、昨日の 09:05 から今日の 09:05 までの使用状況が評価されます。

超過しきい値は Fabric クォータを使用するため、しきい値が利用可能なクォータの範囲内である場合にのみ設定できます。 必要なクォータは設定した閾値の1/24に相当します。なぜならFabricはCU時間の閾値を24時間に分散させるからです。 例えば、48 CU時間の閾値でノルマに2 CUが加算されます。 利用可能なクォータが設定済みの閾値をサポートできない場合、クオータを増やすか閾値を下げるまで容量の超過を有効化できません。 クォータの詳細については、「Fabric クォータ」を参照してください。

超過分の使用状況を追跡する

Microsoft Fabricは、容量超過がいつ有効になり、どれだけ余裕が使われているかを追跡するいくつかの方法を提供しています。

メソッド 表示される内容
容量メトリック アプリ 処理された超過分のログ、課金された CU 時間、容量の状態 (アクティブとスロットル) が表示されます。
Azure Cost Management 請求された超過分を別のメーター(容量超過容量使用量)で追跡します。時間経過による経済的影響を示しています。
Real-Time Hub の容量イベント サマリーテーブルを用いて容量超過イベントのリアルタイムアラート。

主要な動作の概念

概念 説明
トリガー ポイント インタラクティブ遅延の閾値が100% を超えると(つまり、今後10分間の平滑化された使用が100% 容量を超えたときに有効になります)。
課金対象 対話型遅延しきい値の割合が 100%を超える時点での累積繰り越し。
パフォーマンスの向上なし SKUのサイズや利用可能なリソースは増えません。スロットリングを防ぐだけです。 継続的な読み込みのために SKU のサイズを設定します。
支出閾値 24時間のCU時間の閾値を設定しましょう。 閾値に達した後は容量超過は停止し、使用量が時間枠の対象外になるか、閾値を引き上げるまでスロットリングが再び適用されます。 閾値は厳密な上限ではありません。 詳細は 「超過閾値の理解」をご覧ください。
サージ保護の相互作用 容量超過はサージ保護をオーバーライドしません。両方の機能が連携して負荷を管理します。
自己管理の動作 完全自動化;使用量が閾値に達した時点で始まり、使用量が閾値以下に落ちると終了します。

超過しきい値を理解する

設定する超過閾値は支出の閾値であり 、ハード支出上限ではありません。 Fabric は定期的に処理済みの超過分を評価します。 容量が閾値に達すると、スロットリングが始まるまでの短い遅延があり、すでに実行中の操作は継続されます。 その結果、実際の過剰料金が設定した閾値を超えることがあります。

以下の利用は、スロットリングを回避し、超過料金率で課金されます：

  • 容量超過に達する前に発生した超過使用量。

  • 容量が超過している間に実行される処理。

  • 収容能力に達した後、最大5分間続く作業。

この閾値は、直近24時間のローリングウィンドウ内で処理された超過分に適用されます。 古い超過使用量が集計期間の対象外になると、超過利用枠が再び利用可能になります。

Phase 容量の挙動 課金の動作
Normal 使用はSKUの割り当て内に収まります。 過剰料金はかかりません。
オーバーエイジ・アクティブ Fabricは処理超過が閾値以下に保たれている間、適格な過剰使用を受け入れます。 Fabricは超過使用量を過剰料金で請求します。
閾値に達した Fabricはサービス評価間隔を過ぎるとスロットリングに移行します。 飛行中の消費は充電を閾値以上に押し上げることがあります。
Recovery 古い処理済みの超過分はローリングウィンドウから外れます。 超過分の利用可能枠が再び利用可能になります。

容量超過のコストに関する考慮事項

容量超過を有効にすると、あなたの容量を超える追加料金が発生する可能性があります。 次のコスト管理と動作を検討してください。

  • 請求メーター:Azureは超過使用量を別のメーターで請求し、使用量分の3倍の従量分料金で請求します。 この料金は、SKU 許容量を超える CU 時間にのみ適用されます。

  • 支出閾値: コスト管理のために24時間のローリングクレジット閾値を設定します。 閾値に達すると容量超過は停止し、使用量がそのウィンドウの集計対象から外れるか、閾値を引き上げるまで、スロットリングが再開されます。

  • 使用量に基づく料金: 有効化容量の超過には常設料金がかかりません。 スロットリングを防ぐCU時間だけに支払います。

  • 閾値の調整: 閾値はいつでも更新可能です。 閾値を増やすと、過負荷が続く場合は請求が再開されます。 閾値を下げると、処理容量の超過が新しい閾値を超えるとスロットリングが発生する可能性があります。

  • スロットリング中の超過保護の有効化: 深刻なスロットリングイベント中に容量超過を有効にすると、その時点で全ての累積繰越に対してFabricから課金されます。

  • 容量超過がアクティブになった場合:

    • ワークロードを確認し、可能な場合は最適化または再配布します。
    • 頻繁な容量超過や深刻なスロットリング状態(例えばバックグラウンドリジェクション)がある場合は、より大きなSKUにスケールアップしましょう。
    • 予算やパフォーマンスのニーズに応じて閾値を調整してください。

  • 料金の表示: Azure Cost Managementを使用し、超過メーター (容量超過容量使用量 CU) でフィルター処理して使用状況とコストを監視します。

容量超過の閾値

容量超過の閾値はCU時間で定義されます。 たとえば、F2 では 1 時間あたり 2 CU 時間、または 1 日あたり 48 CU 時間が提供され、F256 では 1 時間あたり 256 CU 時間、または 1 日あたり 6,144 CU 時間が提供されます。

以下の表は、各容量SKUごとに利用可能な1日のCU時間を示しており、適切な超過閾値の選択に役立ちます。 Azureは超過使用量を3倍の従量随量制で請求するため、1日のCU時間の3分の1以下に超過閾値を抑えてください。これはSKUのスケールアップに似たコストのポイントです。 高い閾値は、スケールアップ後でもスロットリングが発生する可能性のある短時間で激しいインタラクティブスパイクの処理に役立ちます。

容量 SKU 基本容量ユニット 1 日あたりの CU 時間数
F2 2 48
F4 4 96
F8 8 192
F16 16 384
F32 32 768
F64 64 1,536
F128 128 3,072
F256 256 6,144
F512 512 12,288
F1024 1,024 24,576
F2048 2,048 49,152
F4096 4,096 98,304
F8192 8,192 196,608

考慮事項と制限事項

容量超過を利用する際には、以下のポイントを考慮してください。

  • 容量超過は、F SKU でのみ使用できます。

  • 容量超過は、現在の時間枠に対して過剰な容量負債を支払いますが、将来の負債はクリアされません。 この動作により、容量の稼働を維持するために必要な最小限の CU を、容量超過分で賄えるようになります。 また、過負荷が大きい場合、容量の超過が長期間続き、最終的にはCU時間の閾値に達することもあります。 容量超過がアクティブになったら、容量を確認し、適切なアクションを実行します。

  • 容量超過によってスロットリングが防止され、新しいジョブが実行できるようになります。 この挙動はユーザーへの下流の影響を防ぎつつ、新たな大きなジョブを許容することもあります。 バックグラウンド拒否中にFabricが新しいバックグラウンド ジョブを受け入れないようにするには、容量サージ保護の制限を 100%に設定します。

  • 容量超過を有効にして容量をスケールダウンするときは注意が必要です。 容量を減らすと、容量の超過分が自動的に課金される大幅な超過が発生する可能性があります。

FAQ とベスト プラクティス

容量超過を使用する必要がある場合

稼働時間が重要で、時々容量制限に達するときに使うのが良いでしょう。 これは、まれに予期せぬ急増や、スケールアップの必要のない小さな通常の急増に理想的です。 これらのシナリオ以外で定期的に制限されている場合は、代わりに規模を拡大します。

容量超過はパフォーマンスを向上させるのでしょうか?

No. スロットリングは防止されますが、メモリや速度は追加されません。 ジョブは通常どおりに実行されますが、遅延や拒否は発生しません。

スロットリング中に有効にするとどうなりますか?

それは蓄積された超過分をすぐに支払います。

超過の原因となったワークロードまたはユーザーを特定できますか?

オーバーロードは、容量に対するすべての操作の蓄積に起因します。 容量メトリック アプリのデータを分析して、指定された時間枠内に容量に対して実行された操作に関する分析情報を見つけます。

No. CU枯渇によるスロットリングのみを防ぎます。 メモリ、コンカレンシー、およびその他の制限は引き続き適用されます (セ マンティック モデル SKU の制限 を参照してください)。

容量が100%の対話型遅延を超えない場合、容量超過をそのままにしておくコストは発生しますか？

No. 超過分が発生した場合にのみ支払います。

関連するコンテンツ

  • 最終更新: