Jellyfinのスケーラビリティを決める構成要因は何ですか？

Jellyfinのスケーラビリティは、家庭内で実際に行われる再生とバックグラウンド処理の組み合わせにおいて、最初に飽和するリソースまたは依存関係によって決まります。

同じCPUを搭載した2台のサーバーでも、一方が互換性のあるファイルを主にダイレクト再生し、もう一方が字幕の焼き付け、HDRのトーンマッピング、リモートユーザーへの配信、ライブラリのスキャンを同時に行う場合、対応できるワークロードは大きく異なります。設定が重要なのは、各セッションが生み出す処理経路、ストレージパターン、ネットワーク需要を決めるためであり、生のハードウェア性能が関係する前段階に影響するからです。

再生モードによって負荷の高いリソースが決まる

ダイレクト再生のセッションでは、サーバーは主にメディアファイルを読み込み、そのビットレートで配信するため、計算負荷を小さく抑えられます。リマックスではコンテナ処理が加わり、音声変換ではコーデック処理が加わり、動画のトランスコードでは主な負荷がGPUのメディアエンジンまたはCPUに移ります。したがって、スケーラビリティは、セッションのうちどれだけが低コストな経路にとどまるかから始まります。

Jellyfinのハードウェアに関するガイドでは、これらの経路を区別し、CPUのみの動画トランスコードは、特にHDRからSDRへの処理を伴う場合、非常に大きな負荷になり得ると警告しています。ハードウェアアクセラレーションのガイドから導ける条件付きの原則は次のとおりです。「小規模なサーバー」でも互換性のあるクライアントには十分対応できますが、同じクライアントが高コストなソフトウェア変換を強制すると、対応上限は非常に低くなる可能性があります。

境界を決めるのはクライアントの多様性です。扱いやすいH.264ファイル1本で行ったベンチマークでは、4K HEVC、画像字幕、非対応音声、デコード対応が異なるブラウザが混在する家庭の状況は予測できません。実際のメディアとクライアントの組み合わせからスケーラビリティテストを作成し、同時セッション数を増やす間はその組み合わせを固定してください。

トランスコード設定は品質、帯域幅、計算負荷のバランスを変える

ビットレート制限、エンコーダーのプリセット、トーンマッピング、字幕処理、出力コーデックは、変換ストリームごとに必要な処理量を変えます。低い出力ビットレートはリモート接続の上り帯域を節約できますが、元の映像ならダイレクト再生できた場合でも、変換処理を増やします。高品質のエンコーダープリセットは、ユーザー数が変わらなくてもアクセラレーターの処理時間をより多く消費することがあります。

ZimaSpaceの帯域幅モデルは、リモートの容量をファイルサイズだけでなく、同時に配信されるビットレートから計算する必要がある理由を示しています。その同時ビットレートモデルは、相互作用も明らかにします。リモート帯域幅の上限が、ネットワークの問題をトランスコードの負荷に変える可能性があるため、スケーラビリティはCPUやアップロード速度だけから推定できません。

境界を決めるのはリアルタイムでの処理完了です。トランスコードが開始したからといって、処理速度が再生速度を下回ったり、セグメントキューが増加したりする場合に持続可能とは限りません。代表的な変換ストリームごとに、テスト期間全体を通じてリアルタイムを上回る余裕を維持し、必要な他のセッションも安定している場合にのみ、その設定をスケーラブルと判断してください。

メモリとキャッシュがクエリおよびメタデータの余裕を左右する

ユーザーは動画をストリーミングするだけではありません。ライブラリを閲覧し、検索し、アートワークを読み込み、視聴状態を更新し、メタデータクエリを発生させます。十分なメモリがあれば、頻繁に使われるデータベースページやファイルシステムページをメモリ上に保持でき、ストレージへの反復アクセスを減らせます。メモリが少なすぎると、メモリの回収やスワップが増え、メディアエンジンが限界に達する前にインターフェースの応答が低下することがあります。

ハードウェアを変更していないのに、ウォームアップ後にサーバーが高速化する場合、その実際の効果を確認できます。ウォームキャッシュの挙動は、再利用可能なメタデータと新たに発生した変換処理を切り分けます。これはスケーラビリティテストの解釈で重要です。ライブラリを同じ条件で10回開くテストは、大規模なカタログの異なる部分に10台のコールドクライアントがアクセスするテストとは同等ではありません。

境界となるのは、キャッシュがキャッシュされていない処理や計算負荷の高い処理のスループットを生み出すわけではないことです。UIが快適に動作していてもエンコーダーが過負荷になることはあり、豊富なRAMが飽和したネットワークを修復することもありません。すべての遅延を単一の「サーバーが限界に達した」という結論にまとめず、メモリ圧力と反復リクエストのレイテンシーをそれぞれ別の軸として追跡してください。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ストレージとネットワークは独立した同時実行上限を作る

メディアの読み取りは通常、大容量のシーケンシャル処理です。一方、Jellyfinのデータベース、メタデータ、サムネイル、ログ、トランスコードセグメントは、より小さく、書き込みの影響を受けやすい処理を発生させることがあります。同時に、リモートセッションは上り帯域幅を共有します。そのため、同じユーザー数でも、あるシステムはローカルのストレージキューイングに、別のシステムはリモートのアップロード帯域に制限される可能性があります。

使用率、飽和、エラーのフレームワークが有用なのは、CPU、メモリ、ストレージ、ネットワークを、それぞれ異なる証拠を持つ別個のリソースとして扱うためです。同時実行数の増加に伴って最初に繰り返し現れるキューやエラーを探すほうが、飽和したディスク、NIC、ハードウェアエンコーダーを隠してしまう可能性がある平均CPU使用率を見るより有益です。

境界となるのは処理の重なりです。映画を3本簡単に配信できるディスクでも、ライブラリスキャン、バックアップ、ダウンロード、トランスコードキャッシュへの書き込みが同時に発生すると苦戦することがあります。単独のストリームではなく、通常のピーク時に重なる組み合わせをテストしてください。競合するワークロードを移動またはスケジュール変更するのは、同じリソースが使用率の段階からキューイングの段階へ繰り返し移行した場合に限ります。

単一のユーザー上限ではなくスケーラビリティ曲線を測定する

まず、リビングルームでのダイレクト再生1本、ブラウザでのトランスコード1本、リモートストリーム1本など、固定したワークロード単位を定めます。1単位ずつ追加しながら、初回フレームまでのレイテンシー、トランスコード速度、バッファリング、CPUまたはGPU使用率、メモリ圧力、ストレージキューイング、ネットワークスループットを記録します。重要なのは、性能劣化の形状と、最初に余裕を失う指標です。

ZimaSpaceのサービススタック分析も、論理的な分離によってホストリソースが専有化されるわけではないと警告しています。共有ホストリソースモデルは、通常Jellyfinと同時に動作する周辺サービスをテストに含めるべきだという有用な注意点です。そうしなければ、そのベンチマークは家庭で実際には使われない実験室状態を表すことになります。

スケーラブルな上限は、一度だけ開始できた最大セッション数ではなく、最初に再現性のある障害が発生する一つ手前に設定してください。設定変更後は同じ組み合わせで再テストし、ボトルネックが移動するか、別の経路を壊さずに余裕が増えた場合にのみ改善を認めます。これにより、マーケティング的な「1サーバーあたり何ユーザー」という数字ではなく、根拠のある容量範囲を示せます。