Azure Data Explorer
Azure Functions
Microsoft Fabric
Azure Blob Storage
Azure Event Hubs
このアーキテクチャでは、システムとユーザーデバイステレメトリデータのほぼリアルタイムの監視と監視を提供するソリューションについて説明します。 メディア業界のユース ケースに焦点を合わせたものになっています。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
データ フロー
クライアント デバイスとアプリケーションは、HTTP とコネクタを介して生テレメトリを Microsoft Fabric にストリーミングします。 Eventstreams はデータを取り込む。 Fabric Real-Time Intelligence 機能は、スケーラブルな時系列データベースであるイベントハウスにテレメトリ データを変換、正規化、および永続化します。 Real-Time インテリジェンス ダッシュボードは分析情報を提供し、データ アクティベーターは検出されたパターンに基づいて自動化されたアクションをトリガーします。
次のデータ フローは、前の図に対応しています。
計装： インストルメンテーションは、データを監視するためにシステムにインストールされているプローブまたはエージェントを介して行われます。 これらのエージェントにはさまざまな形式があります。 たとえば、ビデオ オンデマンド ストリーミング プラットフォームでは、企業はオープン標準 のdash.js を使用して、顧客から Quality of Experience (QoE) メトリックを収集する場合があります。
摂取： クライアントは、サービス固有のエンドポイントへの HTTP 呼び出しを介して直接生テレメトリを取り込みます。 Azure Functions は受信データを処理します。 または、Azure Blob Storage やデータ レイクなどの永続的なストレージ ソリューションに、外部システムを介してテレメトリをアップロードすることもできます。 Fabric イベントストリームでは、イベントハウスやデータ アクティベーターなどのファブリックネイティブ エンティティにこのデータをルーティングするためのコードなしのエクスペリエンスが提供されます。
変換と永続化: Fabric は、テーブル更新ポリシーと具体化されたビューを使用してデータ変換を管理します。 Eventhouse は、変換されたデータを格納し、大規模な時系列データセットで高スループットの分析をサポートします。 このアプローチは、既存のインジェスト メカニズムを補完します。 また、変換と分析のために Azure Functions とデータ エクスプローラーに依存する従来のパイプラインに代わる、より統合されたスケーラブルな代替手段も提供されます。
モニタリング： Fabric 内の Real-Time Intelligence ハブは、ストリーミング イベントと監視データへのアクセスを一元化します。 これを使用して、メトリックの視覚化、アラートの設定、Fabric テナント全体のパフォーマンスの監視を行うことができます。 このアーキテクチャでは、主に、図の左側に示すように、プレイヤーが存在するアプリケーション、サービス、クライアント デバイスを監視することに重点を置いています。 これらのコンポーネントは、他のコンポーネントが取り込んで分析するテレメトリと運用シグナルを生成します。 これらは、可観測性の中核となるターゲットとして機能します。
異常検出: Real-Time インテリジェンスには、データ アクティベーターによる AI を利用した異常検出が組み込まれています。 この機能を使用すると、ストリーミング データの異常なパターンやしきい値違反を自動的に特定し、応答性の高いアクションをトリガーできます。 これらの機能では、機械学習モデルを使用して、手動構成なしでリアルタイムで異常を検出します。 Eventhouses では、季節性、傾向、履歴ベースラインを考慮した高度な異常検出機能もサポートされています。 この機能により、大規模な時系列データセット全体で、より正確でコンテキストに対応した分析情報を得ることができます。
コンポーネント
Blob Storage は、非構造化データ用のスケーラブルなオブジェクト ストレージ サービスです。 このアーキテクチャでは、Blob Storage は、アプリケーション、サービス、または外部ベンダーから送信された生のテレメトリを格納します。 これ以上分析する必要がない場合は、このデータを一時的なものとして扱います。 テレメトリは、Fabric イベントストリームを介してイベントハウスにルーティングされます。 ファブリックネイティブ機能を使用して、高スループット分析のためにデータを変換および永続化できます。
Azure Event Grid は、イベント ドリブン アーキテクチャを有効にするマネージド イベント ルーティング サービスです。 このアーキテクチャでは、Event Grid は、BLOB の作成や削除など、Blob Storage が発行するイベントをリッスンする信頼性の高いイベント配信システムとして機能します。 これらのイベントは、Event Grid 通知をサブスクライブする Azure 関数を介してダウンストリーム処理をトリガーします。 この統合により、より広範な Fabric ベースのアーキテクチャ内でテレメトリの取り込みとルーティングをサポートする応答性の高いイベント ドリブン ワークフローが可能になります。
Azure Event Hubs は、1 秒あたり何百万ものイベントを受信して処理できるビッグ データ ストリーミング プラットフォームおよびイベント インジェスト サービスです。 このアーキテクチャでは、Event Hubs は、イベント パイプラインのフロント ドア (多くの場合、イベント インジェクタと呼ばれます) として機能します。 イベント インジェクタは、イベント パブリッシャーとイベント コンシューマーの間にあるコンポーネントまたはサービスです。 イベント ストリームの生成とイベントの使用を切り離します。
Azure Functions は、インフラストラクチャを明示的にプロビジョニングまたは管理することなく、イベントによってトリガーされるコードを実行するために使用できるサーバーレス コンピューティング サービスです。 このアーキテクチャでは、Azure Functions は HTTP エンドポイントと BLOB エンドポイントを介して取り込まれたデータを解析して変換します。 テレメトリ データは、スケーラブルな変換と分析のために eventstreams と eventhouses にルーティングされます。
Fabric イベントストリームは、リアルタイムのイベント インジェスト、変換、ルーティングを可能にする Fabric の機能です。 このアーキテクチャでは、Fabric イベントストリームは、さまざまなソースからイベント データをフェッチするためのさまざまなソース コネクタを提供します。 この方法を使用すると、コードを記述することなく、イベント データの処理、変換、ルーティングロジックを作成できます。
Fabric イベントハウスは、時系列データとリアルタイム分析ワークロード用に最適化された分析データベースです。 このアーキテクチャでは、イベントハウスは、構造化データ、半構造化データ、非構造化データを含む時間ベースのストリーミング イベントに合わせて調整されます。 複数のパイプラインと複数のデータ形式で、複数のソースからデータを取得できます。 このデータは、インジェスト時間に基づいてインデックスが作成され、パーティション分割されます。
データ アクティベーター は、データの変更パターンを検出したときに自動的にアクションを実行する、Fabric のコードなしの機能です。 このアーキテクチャでは、データ アクティベーターは、データ ソース内の特定のパターンまたは条件を検出したときにアクションをトリガーする待機時間の短いイベント検出エンジンとして機能します。 これらのデータ ソースを 1 秒未満の待機時間で監視し、データがしきい値を満たしたとき、または特定のパターンを検出したときにアクションを開始します。 これらのアクションには、電子メールや Teams 通知の送信、Power Automate フローの起動、外部システムとの統合などがあります。
代替
Azure Data Factory には、抽出、変換、読み込み (ETL) ワークフローを構築し、グラフィカル ユーザー インターフェイス (GUI) からジョブを追跡および再試行するためのツールが用意されています。 Data Factory には、インジェストから永続化までの最小ラグは約 5 分です。 監視システムがこのラグを許容できる場合は、この代替手段を検討してください。
シナリオの詳細
多くの場合、組織はビジネス上の問題を解決するために、多様で大規模なテクノロジをデプロイします。 これらのシステムとユーザー デバイスは、大量のテレメトリ データセットを生成します。
このアーキテクチャは、メディア業界向けのユース ケースに基づいています。 ライブおよびビデオ オンデマンド再生用のメディア ストリーミングでは、アプリケーションの問題を準リアルタイムで識別し、対応する必要があります。 このリアルタイム シナリオをサポートするには、組織は膨大な量のテレメトリ セットを収集する必要があります。これにはスケーラブルなアーキテクチャが必要です。 データを収集したら、AI や異常検出などの他の種類の分析を実行して、このような大規模なデータセット全体の問題を効率的に特定する必要があります。
大規模なテクノロジがデプロイされると、それらを操作するシステム デバイスとユーザー デバイスは、大量のテレメトリ データセットを生成します。 従来のシナリオでは、組織はデータ ウェアハウス システムを介してこのデータを分析し、管理上の意思決定をサポートする分析情報を生成します。 この方法は、一部のシナリオでは機能する可能性がありますが、ストリーミング メディアのユース ケースには十分に対応できません。 この問題を解決するには、サーバー、ネットワーク、およびユーザー デバイスを監視するテレメトリ データに関するリアルタイムの分析情報が必要です。 多くの場合、監視システムは障害やエラーを検出しますが、ほぼリアルタイムで検出することは困難です。 このアーキテクチャでは、その問題の解決に重点を置いています。
ライブ ストリーミングまたはビデオ オンデマンドの設定では、システムとモバイル デバイス、デスクトップ、テレビなどの多様なクライアントがテレメトリ データを生成します。 ソリューションは生データを受け取り、コンテキストを各データ ポイントに関連付けます。 コンテキストの例には、geography、ユーザー オペレーティング システム、コンテンツ ID、コンテンツ配信ネットワーク プロバイダーなどのディメンションが含まれます。 システムは、分析のために生のテレメトリを収集、変換、および Fabric イベントハウスに保存します。 AI ツールを使用すると、データを解釈し、観察とアラートの手動プロセスを自動化できます。 Data Activator は、Real-Time インテリジェンス ハブからデータを読み取り、対話型のダッシュボードを表示し、アラートをトリガーします。
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。
[信頼性]
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性
ビジネスクリティカルなアプリケーションは、Azure リージョンやコンテンツ配信ネットワークの停止などの破壊的なイベント中でもアクティブなままである必要があります。 次の戦略は、2 つの主要な戦略と 1 つのハイブリッド戦略で、システムへの冗長性の構築をサポートします。
アクティブ/アクティブ: 重複するコードと関数が実行されます。 どちらのシステムも障害発生時に引き継ぐことができます。
アクティブ/スタンバイ: アクティブ ノードまたはプライマリ ノードとして機能するノードは 1 つだけです。 プライマリ ノードが失敗した場合、もう一方のノードは引き継ぐ準備が整います。
ミックス： 一部のコンポーネントまたはサービスはアクティブ/アクティブ構成を使用し、他のコンポーネントはアクティブ/スタンバイ構成を使用します。
すべての Azure サービスに冗長性が組み込まれているわけではありません。 たとえば Azure Functions で関数アプリは特定のリージョンでのみ実行されます。 関数のトリガー方法 (HTTP と発行/サブスクライブ) に応じて実装する方法の詳細については、「 Azure Functions の信頼性」を参照してください。
Fabric では、ゾーン冗長可用性ゾーンがサポートされています。リソースはゾーン間で自動的にレプリケートされ、構成する必要はありません。 OneLake に格納されているデータのリージョン間レプリケーションの詳細については、「 Fabric の信頼性」を参照してください。 要件に基づいて、この機能をオプトインまたはオプトアウトできます。
コストの最適化
コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コストの最適化
このアーキテクチャのコストは、受信テレメトリ イベントの数、Blob Storage および Fabric イベントハウスでの生テレメトリのストレージ、および Fabric 容量の専用の価格モデルまたは従量課金制の価格モデルによって異なります。
合計コストを見積もる場合は、 Azure 料金計算ツールを使用します。
パフォーマンス効率
パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率
受信テレメトリのスケールと頻度によっては、Fabric でのストリーミングでパフォーマンスの制約が発生する場合があります。 これらの制約は、通常、次の要因によって発生します。
コールド スタート: サーバーレス呼び出しでは、関数を実行する前に環境をスケジュールして設定する時間が必要です。 このセットアップには、最大で数秒かかります。
要求の頻度: たとえば、1,000 個の HTTP 要求が到着したが、シングル スレッド サーバーしか使用できない場合、システムはすべての要求を同時に処理することはできません。 それらを効率的に処理するには、より多くのサーバーをデプロイして水平方向にスケーリングする必要があります。
Eventstream 初期化の遅延: 新しいデータ ソースがアクティブ化されると、Fabric イベントストリーム パイプラインによって待機時間が発生する可能性があります。 この遅延はコールド スタートに似ています。 簡単に説明しますが、待機時間に依存するシナリオに影響を与える可能性があります。
高周波データ バースト: 何千ものテレメトリ イベントが一度に到着した場合、1 つのイベントストリーム構成で同時に処理されない可能性があります。 リアルタイムの応答性を維持するには、イベントストリーム パイプラインをスケールアウトし、複数の宛先にわたってルーティング規則を最適化する必要があります。
これらの問題を軽減するには、Fabric SKU で専用の容量ワークスペースを使用します。 この方法には次のような利点があります。
初期化の遅延を取り除くことで、一貫したパフォーマンスを確保します
同時インジェストと変換のワークロードを処理するためのイベントストリーム パイプラインの水平方向のスケーリングをサポートします
詳細については、「 ファブリック Real-Time インテリジェンス」を参照してください。
共同作成者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
プリンシパルの作成者:
- John Hauppa | シニア テクニカル プログラム マネージャー
- Uffaz Nathaniel | プリンシパル ソフトウェア エンジニア
その他の共同作成者:
- Dilmurod Makhamadaliev | ソフトウェア エンジニア
- Omeed Musavi | プリンシパル ソフトウェア エンジニアのリーダー
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次の手順
- リアルタイムインテリジェンスのドキュメント
- Real-Time インテリジェンスチュートリアル: 概要
- Azure Functions の概要
- 補足コード サンプル
- Azure Media Services の監視