Plexのリソーススケジューリング：クライアントの混在による同時実行でスムーズなダイレクト再生が変わる理由

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Plex Resource Scheduling: Why Mixed-Client Concurrency Changes Smooth Direct Play - Zima Store Online

異なるセッションがストレージ、ネットワーク、バッファー、そして追加されるトランスコードリソース上で重なると、複数クライアントの同時実行によってPlexのダイレクト再生の滑らかさが変わります。

テレビでは高ビットレートのファイルをダイレクト再生しながら、ブラウザーではリマックスし、リモートのスマートフォンでは低ビットレートへトランスコードする場合があります。これらの経路は同じサーバーに異なる負荷をかけ、平均使用率が低く見えていても、再生開始、シーク、バックグラウンド処理が重なることがあります。実用的なスケジューリングモデルでは、各セッションの経路を追跡し、最初に余裕を失う共有リソースを特定します。

同時実行中でもダイレクト再生の判断はクライアントごとに行われる

複数クライアントの同時実行によって、サーバー全体で1つの再生モードが決まるわけではありません。テレビ、ブラウザー、スマートフォン、ストリーミングボックスはそれぞれ、対応コーデック、選択したトラック、画質設定、ネットワーク状態に基づいて再生経路を選択します。同じライブラリから再生していても、あるセッションはダイレクト再生を続け、別のセッションはトランスコードを開始できます。

そのため、集計されたサーバーメトリクスよりも先にクライアントのダイレクト再生設定を確認することが重要です。リモート画質の低い設定や、あるデバイスでのコーデックの組み合わせの弱さによって、別のクライアントでは発生しない変換処理が生じることがあります。

混在環境のテストを始める際は、アクティブなセッションごとのモードを記録し、視聴者数の合計だけを確認しないでください。3台のクライアントがダイレクト再生し、1台がトランスコードしている場合、最初からリソースのスケジューリングは非対称です。その後の速度低下は、4つ目の経路が現れたときに変化した共有リソースと結び付けて考える必要があります。

ダイレクト再生でもストレージとネットワークの処理は発生する

ダイレクト再生では映像の再エンコードを回避できますが、サーバーはソースファイルを開き、異なるビットレートを読み込み、メタデータを提供し、同時に複数のネットワークフローを送信します。そのため、CPUやGPUのグラフが静かなままでも、複数クライアントがストレージキューや上り回線を奪い合うことがあります。計算処理がほとんど発生していなくても、滑らかな再生は配信スケジューリングの問題です。

実際の管理者は、多数のセッションが同時に動作する期間について説明しており、同時実行されるPlexセッションは、再生モードとビットレートがなければ単純なストリーム数だけでは判断できないことを示しています。応用可能な教訓は、すべてのセッションが実際に利用する共有経路を測定することです。

代表的なピークビットレートの合計を計算し、同時にストレージのレイテンシーを確認します。ディスクが応答性を保ったままネットワークが飽和に近づくなら、スケジューリングの負荷はネットワークエッジにあります。リンク使用率が控えめなのにシークや読み取りがキューに入るなら、メディアプールがより有力な候補です。

1つのトランスコードでリソース構成が変わることがある

互換性のないクライアントが加わると、ソースの読み取りとネットワーク配信だけで構成されていた可能性のあるワークロードに、デコーダー、変換、エンコーダー、トランスコードバッファーの処理が追加されます。その1つの経路によってCPU、メモリ、一時ストレージ、GPUの負荷も高まり、残りのダイレクト再生セッションはモードが変わっていないにもかかわらず、より悪い状態になることがあります。

ダイレクト再生とトランスコードの違いを理解すると、複数クライアントの同時実行によってシステムの挙動が突然変化する理由が分かります。負荷の大きいセッションが、軽いセッションでは使われていなかったリソースを消費するためです。したがって、スケジューリングは視聴者数だけでなく、リソースの種類ごとに観測する必要があります。

同じ組み合わせを2回繰り返します。1回目はトランスコードするクライアントなしで、2回目はそのクライアントを含めて実行します。2回目だけで劣化が現れるなら、明確な実行前後の比較ができます。次に、最初に変化した指標が映像エンジンの負荷、CPU、トランスコード用スクラッチ領域、ネットワークビットレートのどれかを特定します。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

再生開始とシークは短時間のリソースバーストを生む

安定した再生中の状態だけでは、最も難しいスケジューリングの瞬間を見落とすことがあります。複数のクライアントが短い間隔で再生を開始したり、シークしたり、画質を変更したりすると、バースト読み取り、新しいバッファーの充填、新しいトランスコードパイプライン、メタデータ要求が重なります。定常状態の使用率に余裕があるサーバーでも、こうした同期した切り替えの際には目に見える遅延が発生することがあります。

高負荷の混在環境では、一度に複数のボトルネックが明らかになります。高同時実行環境についての議論では、ストレージ、ネットワーク、トランスコードの制限が取り上げられています。平均グラフが滑らかでも、同時開始に十分なバースト余力があるとは限りません。

最初のフレームが表示されるまでの時間と、シークからの復帰を、定常再生とは分けて記録します。弱点がバースト時だけに現れるなら、持続的な計算能力を高めても改善しない可能性があります。サーバー全体を交換するよりも、バックグラウンドジョブの時間をずらす、アプリケーション状態の保存先を高速化する、ネットワークの余裕を増やすといった対策の方が的確な場合があります。

安定した限界は、最初に余裕を失う共有リソースで決まる

滑らかなダイレクト再生が悪化する瞬間に、測定したリソースの1つが繰り返し限界へ達するなら、リソーススケジューリングは具体的な対策につなげられます。その限界は、ネットワークの合計スループット、ストレージのレイテンシー、音声や字幕によるCPU処理、または1つの変換セッションによるアクセラレーターの負荷かもしれません。これらすべてを表す単一のPlexメトリクスはありません。

リモート経由やストレージに依存する経路でのダイレクト再生は、バッファリングとレイテンシーの影響を受けやすいことがあります。ダイレクト再生のレイテンシーへの敏感さが示すように、エンコーダーのボトルネックがなくてもストリームが停止することがあります。クライアントのバッファーとサーバー側のカウンターを同時に観測してください。

家庭内で実際に使われる組み合わせを受け入れテストの負荷とし、一度に変更するクライアントまたは共有リソースを1つに限定します。ネットワークが限界になるなら、次の手順はネットワーク同時実行テストです。そうでなければ、実際に余裕を失ったリソースを中心に診断を続けてください。