小型Plexサーバーで何人のユーザーをサポートできますか？
小規模なPlexサーバーでも、アクティブなユーザーが少なければ多数の登録ユーザーをサポートできます。一方、同時に複数のトランスコードが発生すると、すぐにリソースを使い切る可能性があります。
アカウント数は、同時再生と同じリソースを消費するわけではありません。ダイレクト再生、リモート変換、アップロード帯域幅、字幕処理、バックグラウンドスキャンによって、1セッションあたりの負荷は変わります。実際の家庭内の利用状況からピーク時の同時利用シナリオを作成し、測定したリソースのいずれかが飽和に近づくまでユーザーを追加してください。
総アカウント数より同時セッションが重要
同時に2つのダイレクト再生セッションを行う10アカウントのほうが、3アカウントすべてで負荷の高い4K変換が発生する場合よりも処理しやすいことがあります。重要なのはユーザー記録の数ではなく、アクティブな処理量です。
マルチユーザー動画システムでは、同時需要が利用可能なエッジ容量に近づくと、共有帯域幅の競合が発生します。そのため、セッションの重なりを容量モデルに含める必要があります。
1週間にわたって最も混雑する時間帯を記録し、ローカルのダイレクト再生、リモートのダイレクト再生、トランスコードのセッションに分けてください。「ユーザーあたりのストリーム数」を推測して掛け合わせるのではなく、その分布を負荷テストに使用します。
トランスコードによってユーザーあたりの計算負荷が変わる
互換性のないクライアントが1台あるだけで、互換性のあるクライアントなら不要な処理をサーバー側で行うことになります。ハードウェアアクセラレーションによって、小型プロセッサーが同時に処理できる変換数は変わります。
低消費電力のIntel N100は、メディアエンジンが処理内容に対応していれば、複数のハードウェアトランスコードセッションを維持できます。そのため、ユーザー容量はダイレクト再生の場合と変換中心のシナリオの場合で大きく異なります。
家庭内で実際に使われるコーデック、字幕、HDR条件、画質制限を正確にテストしてください。一般的なクライアントの経路がソフトウェア処理にフォールバックする場合、そのハードウェアトランスコードの結果をカウントしてはいけません。
リモートユーザーはアップロード容量を共有する
リモートのダイレクト再生はCPU負荷が低い場合でも、同じ上り回線を奪い合う可能性があります。すでにWAN回線が飽和に近い状態なら、CPUを増強しても解決しません。
リソース飽和の分析手法は、CPUやストレージと同じようにネットワーク経路にも適用できます。単一の高い使用率サンプルよりも、継続的なキューイングやエラーのほうが重要です。
外部ネットワークから複数のリモートセッションを同時に実行し、アップロード帯域の余裕を確認してください。リモートストリーミング経路は、ユーザーが実際に選択する画質設定と同じ条件でテストする必要があります。
バックグラウンド処理によって安全なユーザー数の範囲が狭まる
ライブラリのスキャン、プレビュー生成、バックアップ、関連コンテナは、視聴と同時に実行され、同じCPU、メモリ、ストレージを消費する可能性があります。これらを無視した容量テストでは、安定して利用できるユーザー数を過大評価してしまいます。
大規模なライブラリでは、バックグラウンドのデータベース処理やメタデータ処理が大量のCPUとメモリを消費し、同時再生に利用できる余裕を減らすことがあります。
スケジュールされた処理を有効にした状態でも、ピーク時のユーザーテストを繰り返してください。サポート対象の範囲は、アイドル状態のサーバーで得られた最高記録ではなく、通常想定される最悪の状況でも健全性を保てる最大負荷として定義します。
おすすめ商品
テック＆AIハブ
もっと読む
バックアップ頻度はPlexの復旧時点の品質にどのような影響を与えますか？
任意のコピー数ではなく、復旧ポイントの要件、障害の発見が遅れるリスク、取得時の整合性、復元テストを基準にPlexのバックアップ頻度を選びましょう。
安全なPlexアップグレードの境界とは何か、そしてなぜ重要なのか？
ランタイム、状態、アクセラレーション、ロールバックデータ、エンドツーエンド検証を明確な変更境界に分離し、Plexのアップグレードをいつでも元に戻せるようにします。
Plexはデバイス間の変更をどのように検出し、同期するのか？
Plexデバイスの整合性を理解するには、信頼できるサーバー状態、クライアントキャッシュ、アカウントのアイデンティティ、そして各デバイスが使用するネットワーク経路を分けて考えます。
