Microsoft Fabric 容量のスロットリングをニアリアルタイム監視する Part 1

はじめに

Fabric 容量イベント のプレビューがアナウンスされたので、これを利用して、容量スロットリングに即応するための構成を考えます。

Part 1 では基本的な設定方法を紹介します。Part 2 では、複数の容量をまとめて監視していきたいと思います。

Fabric 容量のスロットリングについて参考

方針

スロットリングが発生したら、Teams チャットに投稿するように構成してみます。

1. Fabric 容量イベントは容量の使用率などの情報を供給します
2. アクティベーターは容量イベントに対して、スロットリング到達率に対する閾値条件で Teams 通知アクションを実行します
3. Teams 側でアクティベーターの通知アクションの内容として、使用率やメッセージを確認します

実装

1. アクティベーターを作成し、Fabric 容量イベントと接続します。
   
   
   

2. Summary イベントがスロットリング到達率の情報をもっています。
   
   
   

3. 接続できました。
   

4. 追跡対象のオブジェクトを作成し、スロットリング到達率の以下3点を監視対象としてプロパティ定義します。追跡単位は容量となるので、識別子はcapacity_name とします。

   1. interactiveDelayThresholdPercentage (対話型操作の遅延スロットリング到達率・・・現在の SKU において 10 分量の CU 超過で発生)
   2. interactiveRejectionThresholdPercentage　(対話型操作の拒否スロットリング到達率・・・現在の SKU において 1 時間量の CU 超過 で発生)
   3. backgroundRejectionThresholdPercentage　(バックグラウンド操作の拒否スロットリング到達率・・・現在の SKU において 24 時間量の CU 超過 で発生))
      
      

5. interactiveDelayThresholdPercentageの推移を確認できます。
   

6. 負荷をあげてみて、interactiveDelayThresholdPercentage の動きを観察します

   

   F2 で SQL DB を作成し、セッションを維持し続けることで、超過を起こすことができます。SQL DB の処理は対話型操作にあたり、スムージング幅が狭い特徴を利用しています。

7. interactiveDelayThresholdPercentage に対して、ルールを作成します。まずはルールの動作を確認するため、スロットリング到達 20 % 以上の値に増加する（Increase to or above）形で変化したらトリガーという条件にします。
   
   モニターの欄で、閾値との比較が表示されます。
   

   ルールはReal-time Hub から数クリックで直接作成することもできるのですが、イベント全体の監視が作成される形となり、値の変化などの細かい条件設定ができないので、最初にアクティベーターを作成しています。

8. condition と action では、ルールの条件に従うと、過去のデータがどのように評価されるのかを確認できます。

   

9. 容量負荷が上がるさいに一瞬の低下も記録されているため、複数回トリガーしてしまうようです。
   

10. ルール側で概要（イベントの集計）を調整して、トリガー回数を確認していきます。
    

11. 5分程度のウィンドウで判定してやることで、1回トリガーにできました。ルール条件=True のイベント発生時間も 5分に区切られていることがわかります。

    

12. 最後にTeams チャネル通知アクションを選択し、文章や、表記したいプロパティなど設定します。
    

    

13. テストアクションを確認します。

    

14. 内容の確認ができたので、閾値を本来の値に設定したら保存してルールを開始します。

    

確認

1. 100 % を超えるように負荷をあげました。
   

2. ルールイベントが発生していることがわかります。
   

3. 定義からも閾値を越えたことを検知していたことが確認できます
   

4. Teams でメッセージを確認できました。(ミスがあったので、あらためてアラートさせています。画像の数値は上記のアラート時のものと異なります。)
   

課題

1. ハイパーリンクをメッセージに埋め込めない

容量メトリックアプリなどに遷移するリンクを入れたかったのですが、現時点では Power Automate を使用しないとこうした細やかなメッセージ内容の指定はできなさそうです。

2. 複数の容量を同じルールで監視できない

容量イベントは容量ごとに別のデータソースとなるためアクティベーター単独では、対応ができません。
これを Part 2 で対策してみようと思います。

3. この監視の仕組みを構成している容量がバックグラウンドのスロットリングを起こすと監視が止まる

監視や運用管理専用の容量を構成しましょう。単位時間あたりの使用率は容量通知の機能で通知可能です。

以上です。参考になれば幸いです。