Microsoft Fabric の容量超過 (プレビュー)

容量超過 (プレビュー) は、容量管理者が設定した上限まで、超過した容量の使用料金を自動的に支払うオプトイン機能です。 これによりスロットリングを防ぎ、一時的に容量の上限を超えてもワークロードが途切れずに継続されることを保証します。

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

Important

容量超過は現在プレビュー段階です。 この情報は、リリース前に大幅に変更される可能性があるプレリリース製品に関連しています。 Microsoft は、ここに記載されている情報に関して、明示または黙示を問わず、一切の保証を行いません。

主な利点

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

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

容量超過のしくみ

容量オーバーは、管理者が設定した上限まで余剰容量の使用量を自動的に支払うことで、スロットリングを防ぎます。 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 時間の制限を設定します。 上限に達すると、容量超過は停止し、使用量が時間枠の対象外になるか、上限を引き上げるまで、スロットリングが再開されます。 超過容量は5分ごとにこの制限をチェックするため、制限を超えることもあります。合理的な限度額を設定する際には、このチェックを考慮してください。
サージ保護の相互作用 容量超過はサージ保護をオーバーライドしません。両方の機能が連携して負荷を管理します。
自己管理の動作 完全自動化;使用量が閾値に達した時点で始まり、使用量が閾値以下に落ちると終了します。

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

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

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

  • 使用制限: コストを制御するために、ローリング 24 時間 CU の制限を設定します。 上限に達すると、容量超過が停止し、使用量がウィンドウからロールアウトされるか、制限が引き上げられるまで調整が再開されます。

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

  • 制限の調整: 制限はいつでも更新できます。 制限を引き上げると、オーバーロードが続くと課金が再開されます。 制限を下げると、処理処理容量の超過が新しい制限を超えるとスロットリングが発生する可能性があります。

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

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

    • ワークロードを確認し、可能な場合は最適化または再配布します。
    • 頻繁な容量超過や深刻なスロットリング状態(例えばバックグラウンドリジェクション)がある場合は、より大きなSKUにスケールアップしましょう。
    • 予算とパフォーマンスのニーズに基づいて制限を調整します。
  • 料金の表示: Azure Cost Managementを使用し、超過メーター (容量超過容量使用量 CU) でフィルター処理して使用状況とコストを監視します。

容量超過の制限

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

次の表は、適切な超過分の制限を選択するのに役立つ、各容量 SKU で使用可能な毎日の 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. 超過分が発生した場合にのみ支払います。