メディアのリアルタイム監視と観測可能なシステムの構築

Azure Data Explorer
Azure Functions
Azure AI Metrics Advisor
Azure Blob Storage
Azure Event Hubs

このアーキテクチャは、システムとエンド ユーザー デバイスのテレメトリ データのリアルタイム監視と可観測性を提供するソリューションを表しています。 メディア業界のユース ケースに焦点を合わせたものになっています。

Grafana は、各社の商標です。 このマークを使用することは、保証を意味するものではありません。

アーキテクチャ

システムとエンド ユーザー デバイスのテレメトリ データのリアルタイム監視と可観測性を提供するアーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

図に示されている観測可能なシステムでは、生のテレメトリが HTTP とコネクタを介して Azure Blob Storage にストリーミングされます。 生のテレメトリは、分析のために Azure Data Explorer で処理、変換、正規化、保存されます。 Grafana や Azure Metrics Advisor は、Data Explorer からデータを読み取り、エンド ユーザーに分析情報を提供するシステムです。

より具体的には、図にあるシステムの要素は次のとおりです。

  1. インストルメンテーション。 インストルメンテーションは、データを監視するためにシステムにインストールされているプローブまたはエージェントを介して行われます。 これらのエージェントは、さまざまな形式で提供されます。 たとえば、ビデオ オンデマンド ストリーミング プラットフォームで、企業はオープン標準の dash.js を使用して、顧客からエクスペリエンスの質のメトリックを収集する場合があります。
  2. 取り込み 。 この生のテレメトリは、HTTP 呼び出しを介してエンド クライアントから直接取得できます。 または、サードパーティのシステムを介して、Blob Storage などの永続ストレージとデータ レイクにアップロードすることもできます。 Blog Storage では、新しいファイルがアップロードされたときに Azure 関数を呼び出す機能がサポートされています。 このトリガー メカニズムを使用して、生のテレメトリを構造化データ ウェアハウスに移動できます。
  3. 変換と永続化。 データを正規化するために変換システムが必要な場合があります。 Azure Functions アプリで必要に応じてデータを変換し、それを Data Explorer に書き込みます。 Data Explorer は、大規模なデータ セットを対象にハイ パフォーマンスとスループットを実現するように設計されているため、ビッグ データ分析に最適です。
  4. 監視。 Azure Managed Grafana では、Data Explorer との統合がサポートされています。 Grafana のドラッグ アンド ドロップ機能を使用すると、ダッシュボードとグラフをすばやく作成できます。 Grafana は、ダッシュボード タイルを 1 分未満で更新でき、アラートにも使用できるため、メディア監視に適しています。
  5. 異常の検出。 Grafana ダッシュボードでは、NOC での手動監視がサポートされています。 ただし、大規模なデータ セットとユーザー ベースが地理的に分散し、さまざまなデバイスが使用されている場合は、しきい値がハードコーディングされたグラフやアラート ルールを使用して問題を手動で識別することは、非効率になります。 AI を使用してこの問題に対処できます。 Metrics Advisor などのサービスは、機械学習アルゴリズムを使用して、時系列データに基づいて異常を自動的に理解して検出します。 さらに、Kusto データ プラットフォームには、データの季節性とベースラインの傾向を考慮した異常検出機能が組み込まれています。

Components

  • Data Explorer は、大量のデータのリアルタイム分析を実現するマネージド データ分析サービスです。 Data Explorer は、高速で高スループットのデータ取得を必要とする大規模なデータセットを処理するための優れたツールです。 このアーキテクチャでは、Data Explorer を使用してデータセットを格納し、分析のためのクエリを実行します。
  • Blob Storage は、生のテレメトリを保持するために使用されます。 このテレメトリは、お使いのアプリケーションとサービス、またはサードパーティ ベンダーから取得できます。 後でさらに分析を実行する必要がない場合は、データを一時的なものとして扱うことができます。 Blob Storage からデータが Data Explorer クラスターに取り込まれます。
  • Azure Event Grid はイベント配信システムです。 それは、Blob Storage によって発行されたイベントをリッスンするために使用されます。 Azure Storage イベントを使用して、BLOB の作成、削除などのイベントにアプリケーションで対応できます。 Event Grid によって発行されたイベントに Azure 関数でサブスクライブします。
  • Azure Event Hubs は、任意のソースから 1 秒あたり何百万ものイベントを取り込むために使用できるリアルタイム データ インジェスト サービスです。 イベント ハブは、イベント パイプラインのフロント ドア (多くの場合、イベント "インジェクター" と呼ばれます) を表します。 イベント インジェスターは、イベント パブリッシャーとイベント コンシューマーの間にあるコンポーネントまたはサービスです。 これにより、イベント ストリームの生成とイベントの消費が切り離されます。
  • Azure Functions は、HTTP エンドポイントと BLOB エンドポイントを介して取り込まれたデータを解析して変換し、Data Explorer クラスターに書き込むために使用されるサーバーレス ソリューションです。
  • Azure Managed Grafana は、Data Explorer に簡単に接続できます。 このアーキテクチャでは、それによって、テレメトリ データを視覚化するグラフとダッシュボードが生成されます。 Azure Managed Grafana によって Microsoft Entra ID との緊密な統合が提供されるため、ダッシュボードとビューへのロールベースのアクセスを実装できます。
  • Metrics Advisor は、Azure Applied AI Services の一部です。 AI を使用して、データ監視と時系列データの異常検出を行います。 Metrics Advisor は、データにモデルを適用するプロセスを自動化すると共に、データ インジェスト、異常検出、診断を行うことができる一連の API と Web ベースのワークスペースを備えています。 機械学習に関する知識がなくても使用できます。

代替

Azure Data FactoryAzure Synapse Analytics には、ETL ワークフローを構築するためのツールおよびワークスペースと、グラフィカル インターフェイスからジョブを追跡および再試行する機能が用意されています。 Data Factory と Azure Synapse の両方で、インジェストから永続化まで少なくとも約 5 分のラグがあることに注意してください。 お使いの監視システムでこのラグを許容できる場合があります。 その場合に、これらの代替手段を検討することをお勧めします。

シナリオの詳細

多くの場合、組織はビジネス上の問題を解決するために、多様で大規模なテクノロジをデプロイします。 これらのシステムとエンド ユーザー デバイスでは、大量のテレメトリ データセットが生成されます。

このアーキテクチャは、メディア業界向けのユース ケースに基づいています。 ライブおよびビデオ オンデマンド再生用のメディア ストリーミングでは、アプリケーションの問題を準リアルタイムで識別し、対応する必要があります。 このリアルタイム シナリオをサポートするには、組織は膨大な量のテレメトリ セットを収集する必要があります。これにはスケーラブルなアーキテクチャが必要です。 データが収集された後、非常に大規模なデータ セット全体の問題を効率的に特定するために、AI や異常検出などの他の種類の分析が必要です。

大規模なテクノロジがデプロイされると、それらを操作するシステムおよびエンド ユーザー デバイスで大量のテレメトリ データセットが生成されます。 従来のシナリオでは、このデータをデータ ウェアハウス システムを介して分析し、管理上の決定をサポートするために使用できる分析情報を生成します。 この方法は、一部のシナリオでは機能する可能性がありますが、ストリーミング メディアのユース ケースには十分に対応できません。 この問題を解決するには、監視サーバー、ネットワーク、それらを操作するエンド ユーザー デバイスから生成されるテレメトリ データに関するリアルタイムの分析情報が必要です。 障害やエラーをキャッチする監視システムは一般的ですが、準リアルタイムでキャッチすることは困難です。 それが、このアーキテクチャの焦点です。

ライブ ストリーミングまたはビデオ オンデマンドの環境では、テレメトリ データはシステムと異種クライアント (モバイル、デスクトップ、テレビ) から生成されます。 このソリューションでは、生データを取得し、データ ポイントにコンテキストを関連付けます。たとえば、地理的な場所、エンドユーザーのオペレーティング システム、コンテンツ ID、CDN プロバイダーなどのディメンションです。 生のテレメトリは Data Explorer で収集、変換され、分析のために保存されます。 その後、AI を使用してデータを理解し、観察とアラートの手動プロセスを自動化できます。 Grafana や Metrics Advisor などのシステムを使用して Data Explorer からデータを読み取り、対話型のダッシュボードを表示し、アラートをトリガーできます。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

ビジネスクリティカルなアプリケーションは、Azure リージョンや CDN の停止などの破壊的なイベント中でも実行を続ける必要があります。 システムに冗長性を組み込むための 2 つの主要な戦略と 1 つのハイブリッド戦略があります。

  • アクティブ/アクティブ。 重複するコードと関数が実行されます。 どちらのシステムも障害発生時に引き継ぐことができます。
  • アクティブ/スタンバイ。 アクティブ/プライマリであるノードは 1 つだけです。 もう 1 つは、プライマリ ノードがダウンした場合に備えて引き継ぐ準備ができています。
  • 混合。 一部のコンポーネントまたはサービスはアクティブ/アクティブ構成であり、一部はアクティブ/スタンバイです。

すべての Azure サービスに冗長性が組み込まれているわけではないことに注意してください。 たとえば Azure Functions で関数アプリは特定のリージョンでのみ実行されます。 「Azure Functions geo ディザスター リカバリー」では、関数のトリガー方法 (HTTP と pub/sub) に応じて実装できるさまざまな戦略について説明しています。

インジェストおよび変換関数アプリは、アクティブ/アクティブ モードで実行できます。 Data Explorer は、アクティブ/アクティブ構成とアクティブ/スタンバイ構成の両方で実行できます。

Azure Managed Grafana では、可用性ゾーン冗長がサポートされています。 リージョン間冗長を作成するための 1 つの戦略は、Data Explorer クラスターがデプロイされている各リージョンに Grafana を設定することです。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させることです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

このアーキテクチャのコストは、イングレス テレメトリ イベントの数、Blob Storage と Data Explorer での生テレメトリのストレージ、Azure Managed Grafana の時間単位のコスト、Metrics Advisor の時系列グラフの数に応じた静的コストによって異なります。

時間単位または月単位のコストを見積もるには、Azure 料金計算ツールを使用できます。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

受信要求のスケールと頻度によっては、主に次の 2 つの理由で関数アプリがボトルネックになる可能性があります。

  • コールド スタート。 コールド スタートは、サーバーレス実行の結果です。 これは、関数の初回実行の開始前に環境を起動するために必要な、スケジュールとセットアップの時間を指します。 必要な時間は多くても数秒です。
  • 要求の頻度。 たとえば、1,000 個の HTTP 要求があり、それらを処理するのにシングルスレッド サーバーしかないとします。 1,000 個の HTTP 要求をすべて同時に処理することはできません。 これらの要求をタイムリーに処理するには、より多くのサーバーをデプロイする必要があります。 つまり、水平方向にスケーリングする必要があります。

Premium SKU または Dedicated SKU を使用して、次のようにすることをお勧めします。

  • コールド スタートを排除します。
  • サービス仮想マシンの数をスケールアップまたはスケールダウンして、同時実行要求の要件を処理します。

詳細については、「Azure Data Explorer クラスターの SKU を選択する」を参照してください。

このシナリオのデプロイ

このシナリオのデプロイの詳細については、GitHub の「real-time-monitoring-and-observability-for-media」を参照してください。 このコード サンプルには、開発のブートストラップに必要なコードとしてのインフラストラクチャ (IaC) と、HTTP および BLOB エンドポイントからデータを取り込んで変換するための Azure 関数が含まれています。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • John Hauppa | シニア テクニカル プログラム マネージャー
  • Uffaz Nathaniel | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順