小型ホームサーバーでJellyfinを利用できるユーザー数は？

小規模なJellyfinサーバーの正確な固定ユーザー数は、同時再生の経路とビットレートのほうが登録アカウント数よりはるかに重要であるため、正直なところ存在しません。

ほとんど利用時間が重ならない家族プロフィール10個のほうが、クライアントによって4Kトーンマッピング、字幕の焼き込み、リモートビットレート変換を強制される同時利用ユーザー2人よりも扱いやすい場合があります。したがって、容量は同時実行されるワークロード単位から予測すべきです。具体的には、ダイレクトプレイセッション、リマックス、音声変換、動画トランスコード、バックグラウンドジョブ、リモート帯域幅の需要を確認します。その中で最も余裕の少ないリソースが、実用上のユーザー上限を決めます。

登録ユーザー数は同時実行ワークロード数とは異なる

Jellyfinのアカウントは、アイドル状態では再生容量をほとんど消費しません。サーバー負荷が発生するのは、ユーザーが閲覧、ストリーミング、トランスコード、スキャン、メタデータ更新などを行い、それらの処理が時間的に重なったときです。したがって、家庭内アカウントの総数を基準に計画すると、ID管理と同時実行数を混同することになります。重要なのは、通常の最繁忙時間帯に同時発生する高負荷処理の数です。

ZimaSpaceの帯域幅ガイドでは、リモート需要をアカウント数ではなく、同時に配信されるストリームのビットレートでモデル化しています。この同時ストリームモデルはサーバー全体にも当てはまります。CPUベンチマークを推測した人数で割るのではなく、アクティブなワークロードとそのリソース経路を数え、バーストに備えた余裕を加えます。

境界を決めるのは、利用行動のばらつきです。家庭内では夕方の利用時間が予測しやすい一方、多数のリモートユーザーに共有すると、同時実行数が急増しやすくなります。可能であれば観測したピークセッション数を使い、そうでなければ保守的に計画したピーク値を使ってください。実際にサービス要件でない限り、登録アカウントすべてを同時利用として数えるべきではありません。

ダイレクトプレイユーザーは通常、まずストレージとネットワークによって制限される

クライアントデバイスが元のメディアに対応している場合、各ダイレクトプレイセッションは主に読み出しとネットワークの負荷になります。CPU使用率は比較的低く抑えられるため、メディアの総ビットレート、ディスクの同時処理能力、ネットワーク容量の余裕が失われるまでは、小規模なサーバーでも複数セッションに対応できる場合があります。正確な数は、1080pか高ビットレートの4Kファイルか、またローカル配信かリモート配信かによって変わります。

Jellyfinのハードウェアガイドでは、通常の再生においてメディアストレージに必要なのは、要求されるビットレートを上回るシーケンシャル速度であり、ネットワークは配信されるストリームを運べればよいと説明されています。このダイレクトプレイのリソース経路があるため、ストレージとネットワークが十分に飽和しない範囲であれば、低消費電力のマシンでもCPUクラスから想像される以上の互換ユーザーに配信できます。

境界を決めるのは平均ファイルサイズではなく、ピークビットレートです。可変ビットレートのメディアは平均値を上回るバーストが発生することがあり、複数の独立したストリームが同時にシークする場合もあります。リンクやディスクを理論上の最大値まで使い切るのではなく、余裕を確保してください。そのうえで、家庭内で同時再生する予定の最高ビットレートのファイルを使って検証します。

トランスコードユーザーは別の容量プールを消費する

動画トランスコードでは、デコード、フィルタリング、トーンマッピングまたは字幕合成、エンコード、一時セグメントのI/Oが発生します。ハードウェアアクセラレーションによって効率化できますが、対応コーデック、エンジン世代、ドライバーへのアクセス、出力設定、エンジンの同時利用数によって、リアルタイムを維持できるストリーム数が決まります。ソフトウェアフォールバックが1つ発生するだけで、複数のダイレクトプレイユーザーを合わせた以上のCPUを消費することがあります。

ハードウェアトランスコードのガイドでは、この違いが明確に示されています。CPUのみの動画変換は非常に負荷が高い一方、適切なメディアエンジンを使えば、対応する処理経路をはるかに効率よく処理できます。したがって、小規模サーバーの「ユーザー数」は、安価なダイレクトプレイセッションと高負荷な変換セッションに分けて考える必要があり、1つの数値に平均化すべきではありません。

失敗の境界は、継続的なトランスコード速度とキューの増加です。代表的な各ストリームが、数分経過し通常の温度状態になった後もリアルタイムを上回っている場合に限り、トランスコードユーザーを1人追加します。1つの処理経路がソフトウェア処理に切り替わったり、リアルタイムを下回ったりした場合は、その容量への寄与を別途再計算し、平均値の中に隠してはいけません。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

バックグラウンドサービスとキャッシュ状態によって同じユーザー数でも変わる

ライブラリスキャン、バックアップ、ダウンローダー、写真のインデックス作成、その他のコンテナは、同じ視聴者数に対して利用できる余裕を減らす可能性があります。コールドキャッシュの状態では、初回の閲覧やメタデータ処理も、キャッシュが温まった状態での繰り返しリクエストより重くなります。そのため、アイドル状態でキャッシュが温まったサーバーで行った容量テストでは、実際の夕方のピーク時に家庭で得られる性能を過大評価する可能性があります。

ZimaSpaceのサービススタック分析では、コンテナは個別のライフサイクル境界を維持しながらも、ホストのCPU、RAM、ストレージ、アクセラレーターを共有すると説明しています。この共有リソースモデルが、現実的な容量テストに周辺サービスを含めるべき理由です。別のJellyfinユーザーを追加していなくても、ネットワークやトランスコードではなく、ストレージキューやメモリ圧迫が最初のボトルネックになる可能性があります。

境界を決めるのは、必要な同時稼働です。バックアップを視聴時間外に安全にスケジュールできるなら、それによってJellyfinホストを大きくする必要はありません。一方、写真のインデックス作成などのサービスを継続的に同時実行する必要があり、同じリソースを繰り返し飽和させるなら、その負荷は容量範囲に含めるべきです。それを除外すると、実際のホームサーバー要件が変わってしまうためです。

家庭内の利用をワークロード単位に変換し、余裕がなくなるまでユーザーを追加する

実際のピーク時の組み合わせから、1つのワークロード単位を作成します。たとえば、ローカルのダイレクトプレイ2つ、リモートトランスコード1つ、通常同時に動作するバックグラウンドサービス1つです。初回フレームの表示遅延、バッファリング、トランスコード速度、CPUまたはGPUの飽和、メモリ圧迫、ストレージ遅延、ネットワークスループットを測定します。メディアとクライアントを一定に保ちながら、代表的なセッションを一度に1つずつ追加し、最初に失敗するリソースを特定できるようにします。

リソース飽和の分析手法が示す判断基準は、単一の目立つ指標を選ぶのではなく、すべてのリソースについて使用率、飽和、エラーを確認することです。再生が期限に間に合わなくなる前に、あるキューが繰り返し現れるなら、そのキューが現在の構成における同時実行数の上限を決めます。観測されたボトルネックを、別のCPUスコアで覆すことはできません。

容量は普遍的なユーザー数ではなく、ワークロードの説明として公開します。「このサーバーは、このクライアントとメディアの組み合わせを、この余裕を保って処理できる」と表現するのです。最初に再現性のある失敗が起きる一段手前を本番運用の上限とし、コーデック、クライアント、ストレージ、ネットワーク、バックグラウンドサービスを変更したら再テストします。この答えは、実際の同時需要に基づいているため、登録ユーザー数が変わっても有用です。