このブログでは、ステップ4：監視について見ていきます。 


何をする必要がありますか？

監視は非常に単純に思えますが、多くの側面があります。オーケストレーション・プラットフォームは、どのリソースが利用可能か、また予約済みのリソースを把握するだけでなく、インフラストラクチャ、番組、制作も監視する必要があります。前述の制御の側面と同様に、監視機能もインフラストラクチャが対応するプロトコルやAPIに大きく依存します。 

まずは、いくつかの監視の基本について考えてみましょう。 

リアクティブ・モニタリング(反応的監視)かプロアクティブ・モニタリング(積極的監視)か 
長年にわたり、監視はかなりリアクティブ・モニタリング（反応的監視）な方法で行われてきました。つまり、静的な閾値が設定され、ある指標がその事前設定値を超えた場合にアラームが作動するというものです。しかし、今日の監視ソリューションは、はるかにプロアクティブなアプローチを必要としています。異常検知や予測といったAI駆動の機能は、そのために欠かせません。運用に影響が出る前に行動するための十分な時間を確保するには、将来的に問題が発生する可能性が高いことを知らせてくれるシステムが必要です。たとえば、メモリリークのために数時間後にサーバーのメモリが不足することが予測される場合などです。 

リアルタイム監視 
監視は、どんな状況下でもリアルタイムで行うべきだという議論に出くわしたことがあるかもしれません。任意のパラメータやメトリクスの変更は、監視プラットフォームに遅延なく反映されるべきだという考えです。ネットワークインターフェースのステータスが「UP」から「DOWN」に変わったことを即座に通知することは非常に理にかなっていますが、実際の帯域幅のように常に変化するメトリクスについては、それほど有用ではありません。スイッチの実際の帯域幅を数ミリ秒ごとにポーリングしていると、デバイスに過負荷をかけてしまうことになります。また、デバイスがすべての変更後に監視システムに積極的に通知するサブスクリプションベースのプロトコル（例：OpenConfig）をサポートしていたとしても、常に変化するメトリクスについてはデバイスのCPU利用率に大きな影響を与える可能性があります。こうした常に変化するパラメータを数秒ごとにポーリングする方が良い選択かもしれません。また、デバイスのファームウェアのように、日常の運用中にはほとんど変化しないパラメータについて考えてみてください。この値をポーリングしたいのは、おそらくデバイスの再起動後だけでしょう。 

何を監視するか 
完全な可視性を確保するためには、インフラストラクチャとコンテンツの両方を監視する必要があります。後者については、オーディオおよびビデオコンテンツをデコードできるデバイスを統合する必要があります。具体的には、トランスポート・ストリーム・プローブ、ビデオアナライザー、マルチビューワー、またはファイル分析用のQCエンジンなどが考えられます。また、ソフトウェアアプリケーションについては、すべてのインフラストラクチャレイヤーを監視することを確実に行う必要があります。これをノース・サウス監視とも呼びます。 
・設備（空調、温度プローブ、水漏れセンサー、風センサーなど） 
・コア・インフラストラクチャ（サーバー、ネットワーク、ストレージなど） 
・オペレーティングシステム、仮想マシン、マイクロサービスなど 
・メディアアプリケーション（ハードウェア、ソフトウェア、オンプレミス、オフプレミス）

24時間365日の監視とサービス意識のある監視 
次に、監視とオーケストレーションを独立して扱うことができなくなった理由を見てみましょう。過去には、監視は主に24時間365日の静的監視でした。この静的監視は、番組や制作に依存しないデバイスやリソースにはまだ適しています。たとえば、PTP（Precision Time Protocol）やマスタークロックのリファレンスジェネレーターなどが該当します。 

サービス意識のある監視では、リソースの監視が番組のライフサイクルに動的に追従します。どのパラメータを監視し、どの閾値が重要かを決定する条件は、サービスに応じて適応する必要があります。番組制作の一部として使用されていないビデオサーバーはクリップを再生しないため、サーバーにクリップがロードされていなく、ネットワークインターフェースが0 Mbpsの出力を報告してもアラームは作成されるべきではありません。しかし、ビデオサーバーが使用されると、トラフィックシステムでスケジュールされた内容に従ってクリップが再生されているかどうかを監視する必要があります。このサーバーが実際に再生しているかどうかだけでなく、正しいフォーマットが使用されているかどうかも監視する必要があります。ビデオサーバーが誤って、1.5GbpsのHDストリームではなく、10GbpsのUHD出力を作成すると、大問題に発展します。 

また、何か問題が発生した場合には、監視システムがその影響を正確に伝えてくれることを望みます。そのため、監視システムには正確なトポロジーとサービス情報が必要です。どの基盤となるハードウェアやプロセスがどのトップレベルのサービスをサポートしているのか？ もしこのサーバーがダウンした場合、どのサービスが影響を受けるのか？ 予備のサーバーでどのプロセスが優先的に再起動されるべきか？ 事態が緊迫しているときには、すべての情報を即座に把握できる必要があります。そうしないと、対策を講じる前にすべてを手動で診断する必要が出てきてしまいます。これが、エレメントレベルだけでなくサービスレベルでも監視が必要な理由です。 

なぜこれが必要なの？ 
・24時間365日のリアルタイム監視は、インフラストラクチャとコンテンツ全体を360°の視点で把握するために不可欠です 
・リソースは、次回の制作に使用したいリソースが健康な状態であると確信できるときにのみ、動的に管理することができます 
・サービス意識のある監視は、番組のライフサイクルや関連する設定に応じて監視およびアラームテンプレートを適応させ、誤報を回避します 


SDNおよびBCコントローラとのスムーズな統合を実現するには

他のデバイスと同様に、SDNコントローラーやブロードキャストコントローラーも監視する必要があります。コントローラーのハードウェアからアプリケーションレイヤーまで、すべてを監視する必要があります。 

360°監視には、メディアフローも含まれます。オーケストレーション・プラットフォームは、SDNコントローラーによって設定された“クロスポイント”（つまりフロー）をネットワーク内の実際の状況と比較することができます。例えば、BCコントローラーのルーティングパネルを介してソースとデスティネーションを接続したとしましょう。SDNコントローラーがコマンドを実行した場合でも、TAKEボタンを押した後にモニターが黒いままであれば、何かがチェーン内でうまくいかなかったということになります。メディアフローの追跡により、問題の根本原因を特定することが可能になります。例えば、スイッチの一つでマルチキャストルートが欠落していることなどです。また、ネットワーク内に存在するがSDNコントローラーによって設定されていない“ゴーストフロー”を検出することも同様に重要です。 

ブロードキャストコントローラーとの統合に関しては、運用に影響を与える重要なデバイスやイベントのアラームをブロードキャストコントローラーに転送することができるため、オペレーターはBCコントローラーのユーザーインターフェースを通じて通知を受け取ることができます。 



Skyline Communications 『DataMiner』製品ページは[こちら]
デモや見積もりのご依頼、製品に関するお問い合わせは [こちら]

次回のブログの最後パートでは、DataMinerに注目し、DataMinerがオーケストレーター、ブロードキャストコントローラー、SDNコントローラーの役割を単一のプラットフォームで果たすことができる放送業界の運用分野の概要を紹介します。また、サードパーティのコントローラーとインターフェースする方が効率的な場合についても触れていきます。 

Skyline Communications 『DataMiner』製品ページは[こちら]
デモや見積もりのご依頼、製品に関するお問い合わせは [こちら]