同時負荷下における専用メディアサーバーと汎用ホームサーバーの比較

エヴァ・ウォン

IceWhale author

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

Dedicated Media Server vs General Home Server Under Concurrent Loads - Zima Store Online

一般的なホームサーバーは、同時に実行するワークロードがCPU、メモリ、ストレージI/O、ネットワーク、ビデオエンジンの余力を十分に残しているなら、Plex、Jellyfinなどのメディアアプリを最初に置く場所として通常は適しています。ピーク時のトランスコード、ライブラリのメンテナンス、ダウンロード、バックアップ、VM、AIタスクなどが繰り返し互いに干渉する場合、またはメディアのメンテナンスに、ホームサーバーの他のサービスとは異なる再起動や障害対応のスケジュールが必要な場合は、メディアを専用サーバーに移しましょう。

比較の焦点は、専用ボックスのほうが本質的に高速かどうかではありません。同じCPUやiGPUなら、どちらの役割でも同程度の性能を発揮できます。変わるのはリソースの競合と所有範囲です。統合では余っている容量を再利用する一方、分離ではメディア専用のハードウェアと保守領域を確保します。

分離のきっかけになるのは平均CPU使用率ではなく、ピーク時の負荷の重なり

一般的なサーバーは一日の大半をアイドル状態で過ごしていても、肝心な瞬間に処理に失敗することがあります。たとえば、バックアップでデータを圧縮している最中に4Kトランスコードが始まり、写真ライブラリが新しいアップロードをインデックスし、別のコンテナがデータベースの移行を実行する、といった状況です。平均使用率では、こうした衝突は見えません。

Plexのストリーミングモデルでは、Direct Play、Direct Stream、トランスコードを区別しています。再生経路の概要では、一見似ている2つのストリームでも、サーバーにかかる負荷が大きく異なる理由が説明されています。Direct PlayのセッションではCPUにほとんど負荷がかからない一方、互換性のないストリームでは変換が開始されることがあります。

メディア処理を、重要な他のサービスと並行して実行した状態で、繰り返し発生する最も負荷の高い時間帯を測定します。レイテンシーに敏感なアプリが応答し続け、再生も安定しているなら、統合は機能しています。干渉がまれな単発ジョブの実行時にしか発生しないなら、2台目のホストを購入する前に、そのジョブのスケジュールを調整するか、リソースを制限しましょう。

統合によってアイドル状態のハードウェアをより効率的に活用できる

一般的なホームサーバーなら、それ以外の時間には使われずに余っている容量をメディア処理に回せます。同じRAMでファイルをキャッシュし、同じネットワークインターフェースでアプリケーションと動画を配信できます。また、1台のUPS、筐体、ブートドライブ、監視スタック、バックアップ計画で複数のサービスを支えられます。

Dockerには、コンテナのリソース使用量を制限できるCPUおよびメモリ制御が記載されています。これらの制御により、バックグラウンドサービスがCPU時間やメモリを使い切るのを防げます。専用の2台目のマシンを用意しなくても、統合サーバーを予測可能な状態に保つには十分なことがよくあります。

ワークロードが衝突せず、互いに補完し合う場合、統合にはメリットがあります。夜間は主にダイレクト再生を行うメディアサーバーなら、日中のバックアップや開発タスクとうまく共存できます。使われていない分離環境のために、常時稼働する別ホストの電力と保守コストを負担しても、ユーザー体験は向上しません。

専用ホストは予測可能なメディア処理の余裕を確保する

専用メディアサーバーは、再生とライブラリ処理のためにCPU、メモリ、ビデオエンジン、ストレージ経路、ネットワークスケジューリングを確保します。これによってバッファリングが完全になくなるわけではありませんが、別のホームラボ実験が最悪のタイミングで同じコンピュートプールを消費することはなくなります。

Jellyfinのハードウェアアクセラレーションに関するドキュメントでは、固定機能のビデオエンジンがコーデック処理を担える一方、部分的なアクセラレーションではCPUに多くの処理が残る場合があると説明されています。ハードウェアアクセラレーションによるトランスコードに関する説明は、重要な境界線を明確にしています。メディア負荷は単純なユーザー数ではなく、正確なデコード、フィルター、エンコードの経路によって決まります。

メディア用リソースが定期的に飽和し、汎用ホスト内で適切に保護できない場合、分離の効果は最も高くなります。唯一の問題が、暴走したバックグラウンドコンテナ1つであるなら、リソース制御による小規模な修正で済みます。避けられない複数のメディア変換によってマシンの利用可能なビデオまたはCPU容量が消費されていることが問題なら、専用ホストによって実際の余裕を確保できます。

-15% OFF

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

Single board computer zimaboard2

リソース制限は分離を遅らせられても、新しいハードウェアは生み出せない

コンテナとサービスマネージャーでは、CPUシェア、厳格なCPUクォータ、メモリ制限、I/O優先度を設定できます。これらの制御により、ノイジーネイバーの影響を抑え、汎用サーバー上の1つのタスクが他のすべてをリソース不足に陥らせる可能性を減らせます。

Linuxのcgroup v2インターフェースは、階層構造を通じてリソースを分配するためのCPU、メモリ、I/Oコントローラーを公開しています。カーネルのリソース制御モデルは、重要な違いを説明しています。制限は既存のリソースを再分配または上限設定するものであり、別のエンコーダー、メモリーチャネル、ストレージデバイス、ネットワークリンクを追加するものではありません。

これが、統合に踏み切れない境界線を生みます。バックアップジョブのCPUやI/Oの割り当てを減らすことで安定した再生が戻るなら、汎用サーバーを使い続けましょう。メディア処理自体が利用可能なハードウェアを使い切っている状態で再生が目標を下回り続けるなら、どのスケジューリングポリシーでも不足している容量を生み出すことはできません。

共有ストレージとビデオエンジンが、見えない衝突要因になることがある

CPUグラフだけを見ると、統合されたサーバーは健全に見える一方で、ストレージやアクセラレーターの競合が実際の速度低下を引き起こしていることがあります。ダウンロードしたファイルの展開、パリティチェック、サムネイル生成、写真のインデックス作成、VMの書き込みは、メディアの読み取りやトランスコード用の一時領域と競合する可能性があります。同様に、複数のサービスが同じiGPUやディスクリートGPUを必要とすることもあります。

FFmpegの処理モデルでは、デコード、フィルタリング、エンコード、ストリームコピーが分離されています。トランスコードパイプラインは、1つの主要な指標が低く見える場合でも、メディア変換が複数のリソースに影響する可能性があることを思い出させてくれます。

サーバー全体を専用化する前に、まず実用上可能な範囲でホットパスを分離します。トランスコード用の一時領域は高速なローカルストレージに置き、視聴のピーク時には大規模な展開処理を実行しないようにし、ネットワークが実際の上限になっていないことを確認します。こうした対策をしても競合が繰り返し発生する場合や、アクセラレーターを共有する運用が不安定な場合は、専用ホストが正当化されます。

スループットよりもメンテナンスと障害の影響範囲が重要な場合がある

汎用サーバーではメンテナンス時間帯が連動します。ハイパーバイザーの更新、GPUドライバーの変更、カーネル変更のための再起動、壊れたストレージマウントからの復旧は、ホスト上の他のすべてのサービスとともにメディアを中断させる可能性があります。メディアを毎日使う家電のように扱う家庭では、パフォーマンスが十分でも、この連動が重要になる場合があります。

隣接するコンパクトなx86メディアサーバーとAndroid TVボックスの比較では、クライアント数とトランスコードの必要性によってメディアアーキテクチャが変わることがすでに示されています。ここで次に問うべきなのは、メディアの役割を他のホームサーバーサービスと無関係なコンピューティングおよびメンテナンスの領域で共有するのかどうか、という運用の分担です。

そのため、ラボ実験のための再起動で家族の再生を止めたくない場合や、メインサーバーには入れたくないドライバーやパッケージがメディアスタックに必要な場合は、専用化が合理的です。家庭がときどき共有メンテナンスを許容できるなら、統合したほうが復旧モデルをシンプルに保てます。

別のホストを購入する前に、負荷の高い時間帯を2回測定する

メディアのワークロード単独で1つの時間帯を測定し、実際に同時稼働しているサービスと合わせて別の時間帯を測定します。再生経路、トランスコードのFPSまたは速度、CPU負荷、メモリ負荷、ストレージのレイテンシ、GPU／ビデオエンジンの使用状況、ネットワーク使用率を記録します。2回の実行結果の差から、問題がメディア処理能力にあるのか、干渉にあるのかが分かります。

確認された状態	汎用サーバーを最優先	メディアサーバーを最優先
ほとんどがダイレクトプレイ	適合度が高い	パフォーマンス上、通常は不要
たまにトランスコードが1回発生	余裕のある高い適合性	メンテナンスの分離専用
避けられないトランスコードが複数発生	ハードウェアアクセラレーションに余裕があれば機能する	メディアが共有リソースを飽和させる場合に適合度が高い
バックアップやインデックス作成が再生を妨げる	制限とスケジュール設定を試す	競合が続くなら分離を選ぶ
独立した再起動時間帯が必要	適合度が低い	適合度が高い
消費電力とデバイス数を優先する	適合度が高い	ホストを追加するとアイドル時の消費電力とメンテナンスが増える

メディアのみを実行した場合にすでに遅いなら、専用マシンにより適したハードウェアがない限り、分離だけでは改善しません。メディアのみの実行は正常で、同時実行時に失敗するなら、競合の問題を特定できています。その場合は、リソース制御と物理的な分離を比較してください。

同時実行の時間帯を安定させるために必要な、最小限の変更で止めてください。CPUまたはI/Oの制限で競合が解決するなら、2つ目のメンテナンス領域を作る必要はありません。同じピーク負荷で共有ハードウェアが使い果たされる、または許容できない停止が発生する場合に限り、物理的な分離に測定可能な役割があります。

よくある質問

Dockerの制限で、汎用サーバーを専用メディアサーバーと同等にできますか？

いいえ。制限を設定すれば、CPU、メモリ、I/Oの動作を予約または上限設定できるため、リソースを過剰に消費するプロセスを止めるには十分なことがよくあります。ただし、同じホストカーネル、物理デバイス、電源、メンテナンス時間帯を共有するため、別のマシンのような障害分離やハードウェア分離は実現できません。

ハードウェアトランスコードがあれば、専用サーバーは不要ですか？

CPUへの負荷を大幅に軽減できますが、共有されるすべてのリソースがなくなるわけではありません。複数の変換処理で、同じ映像エンジン、メモリ帯域幅、ストレージ、トランスコード用の一時領域、ネットワーク経路を使用する可能性があります。これらが上限を下回っているなら、通常は統合したままで十分です。

ダウンロードとライブラリの自動化をメディアサーバーから移すべきですか？

展開、ハッシュ計算、移動、スキャンが繰り返し再生に干渉する場合に限ります。まずは、これらをスケジュールまたは制限し、大量の一時I/Oを適切に配置してください。それでも必要な分離を実現できない場合に、サービスを分割します。

高負荷の時間帯を変える場合にのみ分離する

メディアの大半がダイレクト再生で、ハードウェアアクセラレーションに余裕があり、バックグラウンドサービスを制限でき、共有のメンテナンス時間帯を1つにまとめても問題ない場合は、汎用ホームサーバーを使い続けます。これは最もリソース効率のよい構成で、バックアップ、監視、予備ハードウェアの管理も簡単です。

同時に実行するメディア処理によって、共有ホストで利用可能な計算能力、アクセラレーター、ストレージ、またはネットワーク容量が繰り返し消費される場合、または関係のないメンテナンスで家族の再生を中断させたくない場合は、専用メディアサーバーを選びます。この場合の価値は、理論上の速度向上ではなく、リソースの占有を予測しやすくすることです。

同時負荷の問題を再現できない場合、または分離が必要なメンテナンス境界を明確にできない場合は、役割を分けないでください。分離によって結果が変わることを、測定した高負荷の時間帯で確認してから、2台目のホストを追加してください。クライアント、ネットワーク、ストレージの修正が原因ではないことも確認します。