パート2では、スイッチやメディアエッジデバイスなどのインフラのオンボーディングに関する説明をしました。オーケストレーション・プラットフォームが使用可能なリソースリストを構築し維持する方法についてお話ししました。このリストは、ブロードキャストコントローラーやSDNコントローラーと共有することができます。 

このブログでは、ステップ2：プランについて見ていきます。 

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

リソースや機器が使用準備完了になったら、イベントや制作の準備やリソースの確保を事前に始めることができるため、リソースを予約する必要があります。 

専用の機器を指定する代わりに、リソースプールを利用することができます。これにより、必ずしも完全に同一である必要のない類似のリソースタイプをまとめることができます。例えば、CCU（カメラコントロールユニット）などです。各CCUは異なる機能を持つことがあり、10台のCCUのプールの中には、UHD対応のものが3台しかない場合もあります。また、異なるベンダーのものであったり、そのうちの1台は特定のスタジオでしか使用できない制限があるかもしれません。 

イベントに必要なすべてのリソースは、サービス定義としても知られるテンプレートに保存されます。これらのテンプレートは、特定のリソースを指し示すことなく、リソースタイプごとに必要なリソースの数量や特性を定義します。 

オーケストレーターは使用可能なリソースリストを維持しています。次のステップでは、テンプレートの一つを選び、イベント/番組の開始時刻と終了時刻を定義します。その情報に基づいて、オーケストレーション・プラットフォームは、要求された時間に利用可能で、要件を満たす性能とキャパシティを持つ特定のリソースの予約を行います。 

ソフトウェアおよびクラウドベースのシステムへの移行に伴い、リソースの予約や管理に関して新たに考慮すべき点が出てきました。また、永久に存在しないリソースも予約できるようにする必要があります。そのため、オーケストレーション・プラットフォームは、必要に応じてリソースをデプロイし、起動する性能を持つ必要があります。たとえば、イベントが開始する直前に、クラウドベースのトランスコーダーやビデオサーバーをホストするためのバーチャルマシンを立ち上げることが求められます。 

物理的なオンプレミスリソースの予約も、必ずしも簡単ではありません。例えば、6チャンネルのビデオサーバーで2つのデコーダーチャンネルを予約したいとします。このような場合、物理リソースを基本的な（仮想）機能にバーチャル化できることは、オーケストレーション・プラットフォームがそれらの基本的なバーチャル機能を効率的に管理するためのもう一つの重要な要件となります。 

以下は、さまざまなリソースとその特性の例の一部です： 
◯リソースの種類
・オンプレミスの物理リソース（例：モニター、マルチビューワー、CCU、コントロールパネルなど） ・バーチャルリソース（例：マルチキャストアドレスのプール、スタジオ、スタッフなど） ・クラウドベースのリソース（例：マイクロサービス、トランスコーダー、パッケージャーなど）  

◯性能
・技術的な性能（例：HDやUHDなど） ・ロケーション（例：リモートスタジオ、スタジアムなど） ・管理能力（例：デバイスに関連付けられた権限） 

◯キャパシティ
・ネットワークキャパシティ（例：10Gigリンクや100Gigリンク） ・デバイスキャパシティ（（例：SDで4つの並行エンコーディングをサポートするエンコーダーだが、HDでは2つのエンコーディングしかサポートしない） 

◯可能性
・リソースが他のイベントのために予約されていないこと
・また、ブログのパート２で述べた要因（例：計画メンテナンス中、アラーム中など）によって影響を受けていないこと

機器の予約が完了すると、オーケストレーション・プラットフォームは、予約状況と各リソースの可用性を常に追跡することで、プロダクションに必要なすべてのリソースが利用可能であることを保証します。 

イベント/番組が始まる前やイベント中にリソースがアラーム状態になった場合、オーケストレーターは制作を遂行するためにリソースプールから代替リソースを適用しなければなりません。リソース管理は、常に変化する状況に適応しなければならない動的なプロセスです。 

リソースの管理は、オーケストレーション・プラットフォームにとって必須です。使用ケースに応じて、オーケストレーターはネットワークトポロジーを把握し、すべてのリソースやメディアエンドポイントがネットワーク内でどこに接続されているかを理解している必要があります。その情報をもとに、オーケストレーターは予約されたリソースが互いに接続可能であることを保証できます。また、ネットワークインフラストラクチャがオーバーサブスクライブされる可能性がある場合には、ネットワークキャパシティを予約できることが必須となります。 


なぜこれが必要なの？ 

1. リソースのオーバーブッキングはなくなり、要求された時間にリソースが利用可能になります 
2. リソースの利用率とネットワークの利用率が最適化されます 
3. リソースごと、インベント/番組ごとのコストを簡単に追跡できます 

要するに、このような運用スタイルにより、リソースが常に自動的に最も効率的な方法で割り当てられるため、少ないリソースでより多くのことを行うことが可能になります。 


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

オーケストレーターがSDNコントローラーおよびブロードキャストコントローラーの役割も満たさない場合、これらの分離されたシステムは連携して機能する必要があります。 

オーケストレーション・プラットフォームは、リソースが予約されたイベントを含む各リソースの予約状態をブロードキャストコントローラーとSDNコントローラーと共有します。 

これにより、ブロードキャストコントローラーは、オーケストレーターによって事前に予約されたリソースを、そのユーザーインターフェース上で正確に利用可能にすることができます。 

SDN コントローラーは、オペレーターが利用できるソースとデスティネーションを制作に必要なものだけに制限することができます。これにより、オペレーターが制作に不要な信号を切り替えたり、帯域幅を消費したりすることを避けることができます。 

ブロックネットワークにおいては、オーケストレーション・プラットフォームがSDNコントローラーに対して、将来計画されているイベント/番組のために十分なネットワークキャパシティが利用可能かどうかを確認する必要があることを言及することが重要です。 

どのようなコントローラーとオーケストレーターの組み合わせを選んでも、それらが相互にインターフェースできることを確認しましょう。 

次回、パート４では、ステップ3：制御についてお話しします。 

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