はじめに
こんにちは。プラットフォーム技術戦略室の青木です。
普段はLaravelやクラウドネイティブインフラストラクチャ、IoTなどの記事を執筆しています。 業務ではPoCやR&Dを行うことが多く、今回はPoCとして正式導入を検討する上でのパフォーマンステストを行うこととなり実証実験結果を記したいと思います。
結果サマリー
特定のEdgeで検証した結果、 ソフトウェアエンコードからNVIDIA GPUによるハードウェアエンコードに切り替えたことで安定して同時配信できる映像が5〜8本から10〜13本程度に増加しました。
システム概要
性能検証をすることとなったシステムの大まかな概要を説明します。
構成図
背景
弊社既存のサービスで、映像を解析し様々な分析が行えるサービスがあります。その解析は基本的*1に OPTiM Edge にて行われ、そのデータをWebブラウザで閲覧出来る仕組みとなっています。
OPTiM Edge（以下Edgeとする）のMiddlewareでAI解析をした映像を WebRTC Native Client Momo と WebRTC SFU Sora を利用し配信を行っていましたが、ソフトウェアエンコードでは性能が頭打ちすることが判明したため、Momoを開発している時雨堂様に依頼してハードウェアエンコードの機能を実装していただきました。そしてその性能評価を行うこととなりました。
目的
Edgeには複数のIPカメラが接続され、 WebRTC Native Client Momo はその台数分、及び映像数分のプロセスとなり WebRTC SFU Sora へ送信します。
IPカメラの台数や映像数は環境によって変動するため、どの程度の映像を捌けるかを検証する必要が出てきました。
調査内容
WebRTC Native Client Momo ではLinuxにおいてCPUによるエンコード*2とGPUによるエンコード*3があり、それぞれの性能差やマシンリソースの状況を調査いたしました。
今回の検証では、普段のOPTiM Edgeの状態を再現するためミドルウェアなどのアプリケーションを起動した状態で検証しています。
また、ミドルウェアからWebRTC Native Client Momoへの映像入力の為、Momo本体に一部改良を加えております。
したがって、本質的な WebRTC Native Client Momo の性能比較となっておりませんので、注意してください。*4
また、Momoの使っているlibwebrtcのビルドでライセンス問題回避のためにH.264のソフトウェアエンコーダを取り除いている為、ソフトウェアエンコードは VP8, ハードウェアエンコードは H264 で検証を行います。
性能検証
前提条件
- 検証マシン
- CPU : Intel Xeon E3-1225v5 @3.30GHz 4core
- Mem : DDR4 8GB @2133MHz
- GPU : NVIDIA Quadro P4000 8GB
- NVIDIA 情報
- ドライバーバージョン : 440.64.00
- CUDA バージョン : 10.2
- Momo 情報
- バージョン : momo-2020.3.1
- ビットレート : 3000kbps 指定
- フレームレート : 30fps 指定
- その他OPTiM Edge にて稼働させるAIエンジンをバックグラウンドにて常時起動
⚠️注意：ミドルウェアやその他OPTIM Edgeで稼働しているアプリケーションがあるためアイドル時のGPU使用率やCPU使用率などが高くなっています。
そのためミドルウェアやアプリケーションの状況なるべく同じになるように配慮しています。
検証方法
Prometheus を利用し、各メトリクスを取得します。 使用するExporterは以下のとおりです
- nvidia/dcgm-exporter:1.4.3
- quay.io/prometheus/node-exporter
上記の方法で以下のメトリクスを取得しております。
- CPU使用率
node_cpu_seconds_total - メインメモリ
node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes - GPU使用率
dcgm_gpu_utilization - GPUメモリ
dcgm_fb_used
上記については 5分間計測後、平均値を計測しています。
以下サンプル (H.264,10動画)
下記については、chrome://webrtc-internals/ にて特定の箇所の瞬間値を記録したものになっております。
- フレームレート
framesReceives/s - ビットレート
bytesReceived/s - 解像度
frameWidth,frameHeight
検証パターン
VP8(ソフトウェアエンコード) と H264(ハードウェアエンコード) を図の分検証します。
15動画目の VP8 はプロセス立ち上げ時点でメトリクスが取得できない程の切迫したリソース状況でしたので検証出来ませんでした。
20動画目の H264 も同様の理由で検証出来ず、今回は15動画迄とします。
検証結果では VP8の場合とH264の場合でどの程度差が生まれるのか、それぞれのコーデックと消費リソースの関係をざっくり見て頂けると幸いです。
検証結果
CPU使用率
CPU使用率では、 4core 4thread で400%を上限として表示しています。
検証の結果は、VP8の方がCPUの使用率が高く、H264の方が上昇率が低くなっています。
VP8の5動画 ~ 10動画の上昇率が低下しているのはMomoが自動的に動画の解像度を下げている為このような挙動になっています。
詳しいデータは後記いたします。
メインメモリ
メインメモリはVP8よりもH264の方が高くなっています。CPUの利用率を下げる代わりにメインメモリの利用率が高くなってしまうということがわかりました。
H264の15動画での上昇率が下がっていますが、これはMomoが自動的にフレームレートとビットレートを下げている為このような挙動になっています。
詳しいデータは後記いたします。
GPU使用率
ここは変化ありません。ばらつきがありますが誤差範囲内かと思われます。
H264でGPU使用率が上昇しないのは、NVENCを利用したエンコードで物理的にチップが異なっている事が考えられます。
GPUメモリ
VP8ではGPUを利用しませんので、メモリに変化はありません。H264では1動画あたり 127MB 程度のメモリを利用します。動画の本数を増やしたり動画自体の解像度などを上げる場合はGPUメモリに目を配る必要がありそうです。
また、ミドルウェアでGPUメモリを大量に利用するケースも存在しますのでこのあたりは解像度などのパラメータ毎に検証する必要がありそうです。*5
全体とその他の項目
これまでのデータと、その他計測したデータを一覧化しました。
VP8では、10動画目でCPU使用率の上昇率が低下し、代わりに解像度が下がっています。
H264では、フレームレートとビットレートが低下し、メモリの上昇率が低下しています。
まとめ
今回の検証では、実際に利用する際にどの程度の動画数を捌くことが出来るかを検証いたしました。 特徴的なのはVP8(ソフトウェアエンコード)とH264(ハードウェアエンコード)でボトルネックの箇所がCPU使用率からメモリ等に変わったということです。
多少大雑把な検証となりましたが、実際に客先へ導入する場合はストレステストや安定した動画提供が出来るよう検証する必要があるかと思います。 検証結果を踏まえて、どのようにアプローチしていくかを検討していくことができればと思っています。
どちらのほうが優れているかは、環境によって変わるかと思いますのでこの検証方法やメトリクス取得方法を活かし、次回以降の精密な検証に利用できれば良いかなと思っております。
最後に一言。 ~ 数字に現れるって楽しい ~
以上、最後まで読んでいただきありがとうございました。
謝辞
株式会社時雨堂 (Shiguredo Inc.) 様のご協力で、ご提供されているOSSの WebRTC Native Client Momo にNVIDIA GPUによるハードウェアエンコーディング機能を実装して頂き、その性能評価結果を記しております。
この場をお借りしてお礼を申し上げます。ご協力頂きありがとうございました。
OPTiMでは様々な分野で活躍できるエンジニアを募集しております。
興味がある方は是非弊社採用ページにてご覧ください！ www.optim.co.jp
