ファブリック アクティベーターとは データ ストリームを自動化されたアクションに変換する

Fabric Activator は、データ ソースで特定のパターンまたは条件が検出されたときにアクションを自動的にトリガーする、コード不要で待機時間の短いイベント検出エンジンです。 主な機能は次のとおりです。

これらのデータ ソースは、待機時間が 1 秒未満で継続的に監視され、しきい値が満たされるか、特定のパターンが検出されたときにアクションが開始されます。 これらのアクションには、電子メールや Teams 通知の送信、Power Automate フローの起動、サードパーティシステムとの統合などがあります。

コア アーキテクチャ

アクティベーターは、Fabric Real-Time インテリジェンス スタックの中心にあるイベント検出およびルール エンジンです。 アーキテクチャ上、高度なオブザーバーとして機能します。高速データ ストリームを使用し、ほぼリアルタイムでルールの条件を評価し、イベント状態の変化に基づいて自動化されたダウンストリーム アクションを開始します。

これは、データが継続的に流れるリアクティブかつイベントドリブンのアーキテクチャに適合し、イベントデータのステートフルな評価に基づいてほぼリアルタイムで意思決定が行われます。

• イベント ソース の

  アクティベーターは、さまざまなプロデューサー (Azure Event Hubs、IoT デバイス、カスタム エンドポイントなど) からデータを取り込む eventstreams に直接接続します。 これらのストリームはイベントのソースとして機能し、Activator は 1 つ以上のイベントストリームをサブスクライブしてデータの変更を監視できます。 その他のイベント ソースには、Fabric または Azure のイベント、Power BI レポートまたは Real-Time ダッシュボードをリッスンするアクティベーターなどがあります。

• イベントとオブジェクト

  イベントは、eventstream を介して受信された個々のレコード (テレメトリシグナルやファイルドロップなど) です。 これらのイベントは、共有識別子 ( bikepoint_id、 device_id など) に基づいてオブジェクトにグループ化されます。 その後、オブジェクトごとにルールが評価され、きめ細かい検出が可能になります (たとえば、センサーごと、資産ごと)。

• ルールと条件

  各アクティベーターには、継続的に評価される 1 つ以上のルールが含まれています。 これらのルールには、単純な比較 (value < threshold) や、 BECOMES、 DECREASES、 INCREASES、 EXIT RANGE、データの有無 (ハートビート) などのステートフルな式を指定できます。 アクティベーターはオブジェクトごとの状態追跡を保証します。これにより、時間の経過に伴う複雑なパターン検出が可能になります。

• アクション

  ルール条件が満たされると、アクティベーターは次をトリガーできます。

  • Fabric のデータ パイプラインまたはノートブック。
  • Power Automate を使用した外部アクション。
  • Teams メッセージを送信する
  • 電子メールの送信

• アラートの管理とルールのテスト

  アクティベータは、ルールがアクティブ化される前にプレビューと影響を推定し、過去のデータに基づいてルールがどのくらいの頻度で発生したかを示します。 これらの機能は、アラートのスパムや過剰な発生を防ぐのに役立ちます。 内部的には、状態遷移はノイズを抑制するために管理されます（たとえば、値は単にしきい値を下回るのではなく、しきい値を超える必要があります）。

• 監視とコスト管理

  アクティベーターがアクティブに実行されている場合にのみコストが発生します。 アクティベーター インスタンスは Fabric 容量にスコープされており、ワークスペースを介して監視できます。 ランタイム ログとテレメトリは、イベントストリームとパイプライン出力を介して使用できます。

デプロイメント モデル

アクティベーター インスタンスはワークスペースごとにデプロイされ、特定のデータ ソースにバインドされます。 複数のアクティベーターが同じストリームを監視できるため、個別のビジネス機能の並列ルール評価が可能になります。 アクティベーターは容量に制約があるため、従量課金制の価格は、ルールがアクティブに実行されている場合にのみ適用され、断続的な検出シナリオのコスト効率を実現します。

Real-Time インテリジェンス内の統合ポイント

オーケストレーターとしてのアクティベーター

エンタープライズ レベルのリアルタイム アーキテクチャでアクティベーターを効果的に使用するには、Microsoft Fabric コンポーネント全体の意図的なオーケストレーションと、イベント ボリューム、オブジェクトカーディナリティ、ルールの複雑さのパフォーマンス チューニングが必要です。 このセクションでは、アクティベーターを他のサービスと調整する方法と、検出ロジックとランタイム動作を最適化して、低待機時間でコスト効率の高い大規模な自動化をサポートする方法について説明します。

アクティベーターは、到着時点でデータを評価し、ダウンストリームでアクションをトリガーすることで、イベント ドリブン パイプラインで中心的な役割を果たします。 一般的な オーケストレーション パターンは 次のとおりです。

主要な概念

Microsoft Fabric Activator は、ストリーミング イベントの低遅延評価用に設計された、高パフォーマンスの状態対応ルール エンジンとして動作します。 アクティベーターは、イベントストリームを介して生成されたリアルタイムイベントを処理し、論理オブジェクトごとのルール条件を評価し、状態遷移に応答してダウンストリームアクションを開始します。 Fabric Activator の概要については、「Fabric Activator の概要」を参照してください。

次の概念は、Fabric Activator で自動アクションと応答を構築およびトリガーするために使用されます。

イベント ソースとイベント

Fabric Activator は、すべてのデータ ソースをイベントのストリームとして扱います。 イベントはオブジェクトの状態に関する観察を表し、通常は、監視対象のフィールドのオブジェクトの識別子、タイムスタンプ、および値が含まれます。

Activator に取り込まれるイベントの発生元は次のとおりです。

• Eventstream。複数のアップストリーム ソース (Azure Event Hubs、IoT Hub、Blob Storage トリガーなど) をサポートします。 Eventstream は Microsoft Fabric の特定の項目の種類であり、コードを記述することなく、リアルタイム イベントの取り込み、変換、ルーティングを行うことができます。 Fabric Activator はイベントストリームを監視し、定義されたパターンまたはしきい値が検出されると自動的にアクションを実行します。 アクティベーターは、2 つ以上のイベントストリームをサブスクライブして、データの変更を監視することもできます。 Eventstream は頻度によって異なります。 たとえば、IoT センサーは 1 秒に複数回イベントを出力し、物流システムは、配送先でパッケージをスキャンするときなど、散発的にイベントを生成します。
• ファブリック イベント たとえば、Fabric ワークスペース項目イベントは、Fabric ワークスペースに変更が加えられたときに発生する個別の Fabric イベントです。 これらの変更には、Fabric アイテムの作成、更新、または削除が含まれます。
• Azure イベント。 たとえば、Azure Blob Storage イベントは、クライアントが BLOB を作成、置換、削除するときにトリガーされます。
• Power BI レポート。 この場合、イベントは Power BI セマンティック モデル (旧称データセット) の更新スケジュールに基づく定期的な観察です。 これらの観測値は毎日または毎週発生し、動きが遅いイベントストリームを形成する可能性があります。
• Fabric Real-Time ダッシュボード。

各イベントには次のものが含まれます。

• タイムスタンプ
• ペイロード (構造化データまたは半構造化データ)
• オブジェクト識別に使用される 1 つ以上の属性 (device_id、bikepoint_idなど)

オブジェクト

Fabric Activator では、監視するエンティティはビジネス オブジェクトと呼ばれ、物理オブジェクトまたは概念オブジェクトのいずれかになります。 たとえば、フリーザー、車両、パッケージ、ユーザーなどの物理的なオブジェクトや、広告キャンペーン、顧客アカウント、ユーザー セッションなどの概念オブジェクトなどがあります。

Activator でビジネス オブジェクトをモデル化するには、1 つ以上のイベントストリームを接続し、オブジェクト ID として機能する列を選択し、オブジェクトのプロパティとして扱うフィールドを指定します。

オブジェクト インスタンスという用語は、特定の冷凍機、車両、またはユーザー セッションなどのビジネス オブジェクトの特定の例を指します。 これに対し、オブジェクトは通常、一般的な定義またはクラス (たとえば、型としてフリーザー) を参照します。 用語「母集団」は、監視されているオブジェクト インスタンスの完全なセットを指します。

オブジェクトの作成は暗黙的です。アクティベーターは、指定されたオブジェクト キーを使用してイベントをグループ化します。 ルールのスコープはオブジェクトです。つまり、すべての評価ロジックはオブジェクトに対応し、インスタンス間で独立しています。 たとえば、ルール監視 bikepoint_id では、一意の自転車ステーションごとに個別の論理評価が作成されます。

ルール

ルールは、オブジェクトで検出する条件と、それらの条件が満たされたときに実行するアクションを定義します。 たとえば、フリーザー オブジェクトのルールでは、温度が安全なしきい値を超えたときに検出され、割り当てられた技術者に電子メール アラートが自動的に送信される場合があります。

Activator のルールは、ステートレスまたはステートフルにすることができます。

• ステートレス ルール は、各イベントを分離して評価します (たとえば、値 < 50)。
• ステートフル ルール は、オブジェクトごとのイベント間でメモリを維持します (値の減少、BECOMES、EXIT RANGE など)

ステートフル評価は次の事項に依存します。

• 差分検出: 以前のイベント値と現在のイベント値の間の変更を追跡します。
• 一時的なシーケンス処理: イベントがないなどの時間ベースの条件を評価します (ハートビート検出)
• 状態遷移: ルールは新しい状態に入ったときにのみ発生し、変更されていない条件で繰り返し発生することを防ぎます

各ルールの条件は、継続的、メモリ内、ほぼ瞬時に評価される実行グラフにコンパイルされます。 システムは、イベント到着後の 1 秒未満の意思決定待ち時間に最適化されています。

アクション

ルールの条件が満たされ、アクションが開始されると、ルールはアクティブ化されると言われます。 アクションでサポートされるターゲットは次のとおりです。

• ファブリック データ パイプライン (データ移動、エンリッチメント用)
• ファブリック ノートブック (機械学習スコアリング、診断用)
• Power Automate フロー (ビジネスプロセスの統合用)
• Teams の通知 (テンプレート ベースのメッセージングを使用)

アクティベーターは、現在のオブジェクトの状態とルールのメタデータを含むトリガー メッセージを出力します。アクションは非ブロッキングです。つまり、アクティベーターは、スケーラブルな非同期フローを有効にするためにアクションの完了を待機しません。

プロパティ

プロパティは、監視するビジネス オブジェクトの特定のフィールドまたは属性です。 これらは物理的または概念的な特性であり、例として次に示します。

• パッケージの温度
• 出荷の状態
• 顧客アカウントの残高
• ユーザー セッションのエンゲージメント スコア

これらは、IoT センサー、Power BI レポート、その他のシステムなどのソースからの継続的なデータ フローであるイベントストリームから派生しています。

Activator でビジネス オブジェクトを定義するときは、1 つ以上のイベントストリームを接続し、オブジェクト ID として機能する列を選択し、そのオブジェクトのプロパティとして扱う他の列を選択します。 これらのプロパティに対してルールを作成して、時間の経過に伴う変更の追跡、プロパティがしきい値を超えた場合や範囲外の場合の検出、アラート、ワークフロー、通知などのアクションのトリガーを行うことができます。

プロパティは、複数のルール間でロジックを再利用する場合にも便利です。 たとえば、フリーザー オブジェクトでは、1 時間の温度平均を計算するプロパティを定義できます。 定義すると、このプロパティは、過熱、温度変動、メンテナンスしきい値を検出するルールなど、複数のルールで参照できます。ロジックは重複しません。 プロパティのロジックを一元化することで、ルールの管理が容易になり、一貫性が高く、時間の経過とともに更新が容易になります。

振り返り期間

ルックバック期間とは、アクティベーターがルールを評価するために分析する履歴データの期間を指します。 これにより、データが遅延または不規則に到着した場合でも、パターンを正確に検出したり、平均などの集計を計算したりするのに十分な過去のデータを使用できるようになります。

ルックバック期間は、次の方法で決定されます。

• ルールの定義方法 。たとえば、傾向の分析、異常の検出、時間の経過に伴う値の比較が必要かどうか。
• イベント ストリーム内の 1 秒あたりのイベント数など、受信データの量。

コールド チェーン内の医薬品パッケージを輸送する医薬品物流操作について考えてみましょう。 目標は、パッケージが暖かくなりすぎるときにアラートを受信することです。

ルールが次のように定義されるとします。

• 各パッケージの平均温度を 3 時間で評価する
• 平均気温が 8°C を超えた場合にアラートをトリガーする

このルールを正確に計算するには、Fabric Activator は履歴データのより広い期間 (具体的には 6 時間のルックバック期間) を分析する必要があります。 これにより、ある程度の遅延や不規則性でデータが到着した場合でも、任意の時点で 3 時間の平均を計算するのに十分なデータが確保されます。

ルックバック期間は、特にデータ パターンが時間の経過と同時に進化するシナリオで、状況をタイムリーかつ正確に検出するために不可欠です。

個別のアクティブなオブジェクト ID

属性に基づいて構築されたルールは、オブジェクトの特定の属性が時間の経過とともにどのように変化するかを監視するために使用されます。 医薬品物流の例では、各医薬品パッケージは一意のオブジェクト ID で表され、システムは各パッケージの定期的な温度測定値を受け取ります。

これらのルールを効果的に評価するために、Fabric Activator はアクティブなオブジェクト ID、つまり定義されたルックバック期間内にイベントが到着するオブジェクトを追跡します。 この動作により、ルールを適用するときに、関連する現在アクティブなオブジェクトのみが考慮されます。

たとえば、有料ステーションでは、通過する車両 (オブジェクト ID) を追跡できます。 各車両はイベント (入退出スキャンなど) を生成し、最近のアクティビティを持つオブジェクトのみがアクティブと見なされ、システムによって評価されます。

また、ルックバック ウィンドウ内で追跡される個別のオブジェクト ID の数 (パッケージの数) に基づく制限もあります。

一般的なユース ケース

ファブリック アクティベーターを使用できる実際のシナリオをいくつか次に示します。

• 同じ店舗の売上が減少したときに広告キャンペーンを自動的に開始し、パフォーマンスの低い場所でのパフォーマンスを向上させます。
• 腐敗が発生する前に、食品を誤動作するフリーザーから再配置するように食料品店のマネージャーに通知します。
• 顧客がアプリ、ウェブサイト、または他のタッチポイントを通じてネガティブな体験を示した場合、その対応としてパーソナライズされたアウトリーチ ワークフローを開始します。
• 定義された期間内に出荷の状態が更新されなかった場合に調査ワークフローを事前に開始し、紛失したパッケージをより迅速に見つけることができます。
• 顧客が延滞に陥ったときに、顧客ごとの時間または未払いの残高に対してカスタマイズされたしきい値を使用して、アカウント チームにアラートを送信します。
• データ パイプラインの正常性を監視し、異常または障害が検出されたときに失敗したジョブまたはアラート チームを自動的に再実行します。

次のステップ

「 チュートリアル: ファブリック アクティベーター ルールを作成してアクティブ化する」を参照してください。