複数の同時ストリーミングに対応するPlexホームサーバーの選び方

エヴァ・ウォン

IceWhale author

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

How to Size a Plex Home Server for Multiple Simultaneous Streams - Zima Store Online

複数ストリームに対応するPlexサーバーは、まず家庭内の再生構成を基準に規模を決めます。Direct Play、ソフトウェアトランスコード、ハードウェアトランスコード、リモート帯域幅、字幕の動作によって、ホストにかかる負荷は大きく異なります。

システムは家族の総人数ではなく、実際に発生するピーク時の組み合わせを中心に構築すべきです。4人家族でも、有線LAN経由ですべてをDirect Playできる家庭がある一方、別の家庭では複数のリモート変換を同時に必要とする場合があります。ユーザー数が同じでも、必要なコンピューティングとネットワークの役割は異なります。

「4人のユーザー」を実際のワークロードに置き換える

同時に発生するピーク時のセッションを一覧にし、それぞれについて、想定される再生モード、ソース解像度、リモートアクセスかローカルアクセスか、字幕の必要性を分類します。これにより、曖昧なユーザー数を、サーバーの設計とテストに利用できる再現可能なワークロードへ置き換えられます。

サーバーは、クライアントの互換性とストリーム要件に応じて、Direct Play、Direct Stream、トランスコードを選択します。そのため、各セッションが消費するリソースも変わります。これを複数ストリーム対応のPlexサーバーの規模設計における基準として確立します。

コンピューティング、ストレージ、ネットワークの役割を割り当てる

クライアントがソースをそのまま再生できない場合、コンピューティングが変換を処理します。アプリデータ用ストレージはライブラリの応答性を維持し、メディアストレージはシーケンシャル読み出しを担い、ネットワークは生成されたストリームを転送します。これらの役割を、単一のCPUベンチマークだけで規模決定すべきではありません。

重要な経路はシンプルに保ちます。安定したローカルのアプリデータ、十分な持続スループットを備えたメディアストレージ、そして有線接続のサーバーネットワークを用意します。変換ワークロードに必要な場合はハードウェアアクセラレーションを追加しますが、アップロード帯域幅や互換性のあるクライアントの代わりになるものと考えてはいけません。

最も弱い部分を規模設計の基準にする

リモートユーザーがいる場合、コンピューティングより先にアップロード帯域幅が上限を決めることがあります。複数のソフトウェアトランスコードでは、CPUが主な制約になる可能性があります。大規模な共有ホストでは、個々のコンポーネントが理論上は高速でも、バックグラウンドジョブによってストレージのレイテンシやCPUスケジューリングがボトルネックになることがあります。

複数ストリーム対応のPlexサーバーの規模を測定したテストでは、Intel N100システムが控えめなCPU負荷で複数のハードウェアトランスコードを処理しました。これは、広範なCPUの分類名よりも、コーデックのサポートとアクセラレーションが重要になる場合があることを示しています。

-15% OFF

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

Single board computer zimaboard2

1本のストリームではなく、ピーク時の組み合わせで検証する

予定しているセッションを同時に実行し、どのストリームがDirect Playになり、どれがトランスコードされるかを記録します。そのうえで、CPU/GPU負荷、ネットワークスループット、メモリ使用圧力、ディスクレイテンシを測定します。必要な組み合わせを、熱やスケジューリングの限界が明らかになる十分な時間にわたって安定して処理できた場合にのみ、構成は合格と判断します。

複数ストリーム対応のPlexサーバーの規模設計で限界点を見極めるには、リソースごとのボトルネックチェックで、単一の平均値に頼らず、CPU、メモリ、ネットワーク、ストレージ全体の使用率、飽和状態、エラーを確認します。

新しい役割を明確にできる場合だけ拡張する

最初の制約が変換能力であれば、コンピューティングまたはアクセラレーターの役割を追加・アップグレードします。ストレージ管理やドライブ拡張が問題になった場合は、ストレージの役割を追加します。共有サービスによる干渉が発生する場合は、1台ですべてのコンポーネントを交換するよりも、2台目のアプリケーションホストを用意するほうが合理的な場合があります。

最初のDockerメディアサーバー構成は、コンピューティング、アプリデータ、メディアストレージ、ネットワークの役割を個別に書き出しておくと、より簡単に評価できます。