インデックスを作成するビデオの大規模なアーカイブが拡大し続けています。あなたは、Microsoft Video Indexer の評価を行ってきたので、スケールアップすることでその関係を次のレベルに引き上げることにしました。

一般に、スケーリングは難しいことではありませんが、そのようなプロセスに最初に直面したときは、最良の方法がわからない場合があります。"考慮する必要がある技術的な制約はあるのか?"、"スマートで効率的な方法はあるのかか?"、"プロセスで余分な費用がかからないようにすることはできるのか?" といった質問がわいてくる可能性があります。ここでは、Video Indexer を大規模に使用する方法の 6 つのベスト プラクティスを紹介します。

 

1.ビデオをアップロードするときに、ファイルをバイト配列として送信するより URL を選ぶ

Video Indexer では、URL からビデオをアップロードするか、ファイルをバイト配列として送信して直接アップロードするかを選択できますが、後者には制約がいくつかあることに注意してください。

まず、ファイル サイズの制限があります。URL の使用時のアップロード サイズの制限は 30 GB であるのに対し、バイト配列フ​​ァイルのサイズは 2 GB に制限されています。

第 2 に、スケーリングにおいてさらに重要なことですが、マルチパートを使用してファイルを送信する場合、ネットワーク、サービスの信頼性、接続、アップロード速度、World Wide Web のどこかで失われるパケットへの依存度が高くなります。これらは、パフォーマンスに影響する可能性があり、その結果としてスケーリングの能力に影響を及ぼす可能性がある問題の一部にすぎません。

URL を使用してビデオをアップロードする場合は、メディア ファイルの場所へのパスを指定するだけで済みます。残りの処理は Microsoft が行います (upload-video API の下記のフィールドを参照してください)。

API 経由で URL を使用してビデオをアップロードするときは、こちらの短いコード サンプルを確認できます。また、AzCopy を使用して、高速かつ信頼性の高い方法でコンテンツをストレージ アカウントに取得し、そこから SAS URL を使用して Video Indexer に送信することもできます。

2.必要に応じてメディア占有ユニットを増やす

通常、Video Indexer を使い始めたばかりの概念実証段階では、多くの処理能力は必要ではありません。Video Indexer の使用をスケールアップするときには、インデックスを作成するビデオのアーカイブがさらに大規模になっており、プロセスをユース ケースに合ったペースにする必要があります。そのため、現在の処理能力では不十分な場合、使用するコンピューティング リソースの数を増やすことを検討します。

Azure Media Services では、処理能力と並列化について話すときに、メディア予約ユニット (RU) について話します。これは、メディア処理タスクのパラメーターを決定するコンピューティング ユニットです。RU の数は各アカウントで同時に処理できるメディア タスクの数に影響し、RU の種類によって処理速度が決まります。インデックスの作成が複雑な場合、1 つのビデオで複数の RU が必要になる場合があります。RU がビジー状態の場合、別のリソースが利用可能になるまで新しいタスクはキューに保持されます。

お客様は効率的に運用することを望んでおり、最終的にリソースのアイドル時間が続くことは望ましくないことがわかっています。そのため、必要な処理が少ないときは RU をスピンダウンし、ラッシュ アワーになったら RU をスピンアップする (すべての RU を最大限に使用する) 自動スケール システムが用意されています。この機能は、アカウント設定で自動スケールをオンにするか、Update-Paid-Account-Azure-Media-Services API を使用することで簡単に有効にすることができます。

インデックス作成時間と低スループットを最小限に抑えるために、種類が S3 の10 個の RU から開始することをお勧めします。後でより多くのコンテンツやより高いコンカレンシーをサポートするためにスケールアップし、そのためにさらに多くのリソースが必要な場合は、サポート システム (有料アカウントのみ) を使用して Microsoft に連絡し、RU の割り当てを増やすことを要求できます。

4.調整に従う

Video Indexer は大規模なインデックス作成を処理するように構築されているので、最大限に活用するときは、システムの機能を認識し、それに応じて統合を設計する必要があります。一部の動画がアップロードされなかったことを検出するためだけにビデオのバッチのアップロード要求を送信し、結果的に HTTP 429 応答コード (要求が多すぎる) を受け取ることは望ましくありません。これは、サポートされている 1 分あたりの動画数の上限よりも多くの要求を送信したことが原因で発生する可能性があります。心配はありません。HTTP 応答で retry-after ヘッダーが追加されます。このヘッダーでは、次の再試行を試みるタイミングが示されます。次の要求を試みる前に、必ずこれに従ってください。

5.コールバック URL を使用する

カスタマー サービスに電話をしたときに、「お客様の要求を現在処理しています。これには数分かかります。お電話番号を頂戴できれば、処理が完了した時点でご連絡させていただきます」と言われたことはありませんか?電話番号を伝えておくと、要求が処理されたときに連絡が入ります。コールバック URL の使用はこれとまったく同じ概念です。

アップロード要求を送信した後、要求の状態を常にポーリングするのでなく、コールバック URL を追加し、更新されるまで待ちます。アップロード要求の状態が変更されるとすぐに、送信した URL に POST 通知が送信されます。

コールバック URL は、upload-video API のパラメーターの 1 つとして追加できます (この API の下記の説明を参照してください)。方法がわからない場合は、GitHub リポジトリのコード サンプルを確認してください。コールバック URL については、Azure Functions を使用することもできます。これは、HTTP によってトリガーされ、次のフローを実装できるサーバーレスのイベント ドリブン プラットフォームです。

6.適切なインデックス作成パラメーターを使用する

Video Indexer を使用するとき、特にスケーリングしようとしているときに、おそらく最初に行う必要があるのは、ニーズに適したパラメーターを使用して Video Indexer を最大限に活用する方法を検討することです。費用を節約し、ビデオのインデックス作成プロセスを高速化できるさまざまなパラメーターを定義して、実際のユース ケースについて考えます。

インデックス作成パラメーターを選択して Video Indexer での使用をカスタマイズするオプションが提供されています。視聴する予定がない場合は、プリセットのストリーミングを設定しないでください。また、オーディオの分析情報だけが必要な場合は、ビデオの分析情報のインデックスを作成しないでください。これは簡単です。

ビデオをアップロードし、インデックスを作成する前に、こちらの短いドキュメントをご覧ください。オプションの内容について理解を深めるために、indexingPreset と streamingPreset の部分を確認してください。

7.最高解像度ではなく、最適な解像度でインデックスを作成する

それほど昔ではありませんが、HD ビデオが存在しない時代がありました。現在は、HD から 8K までさまざまな品質のビデオがあります。ビデオのインデックスを作成する場合、どのビデオ品質が必要なのでしょうか?アップロードする動画の品質が高いほど、ファイル サイズが大きくなるので、動画のアップロードに必要な処理能力と時間が増加します。

経験から、多くの場合、インデックス作成のパフォーマンスは HD (720P) ビデオと 4K ビデオでほとんど変わらないことがわかっています。最終的には、同じ信頼度でほぼ同じ分析情報が得られます。

たとえば、顔検出機能の場合、小さくてもコンテキスト上重要な顔が多数あるシナリオでは、解像度が高い方が役立ちます。ただし、この場合、実行時間が二次的に増加し、誤検知のリスクが高まります。

そのため、ユース ケースに適した結果が得られることを確認し、最初にローカルでテストすることをお勧めします。同じビデオを 720P と 4K でアップロードし、得られた分析情報を比較します。ハエを仕留めるために大砲を使う必要はありません。

ご質問やフィードバックなど、皆様のご意見をお待ちしております。Microsoft では、UserVoice ページから寄せられたフィードバックに基づいて機能の優先順位を付けています。ご不明な点があれば、下にコメントを残していただくか、VISupport@Microsoft.com までお問い合わせください。

皆様のユース ケースについてお聞かせください。スケーリングをお手伝いいたします。