Jellyfinに専用の演算処理能力、ストレージ、ネットワークが必要になるのはどんなとき？

共有リソースの競合が繰り返し発生したり、許容できない障害の連鎖を招いたり、明確に特定できる拡張要件が生じたりする場合、Jellyfinには専用の演算処理、ストレージ、またはネットワークが必要です。

専用にすれば必ず速くなるわけではありません。まず共有環境を基準に、再生、スキャン、トランスコード、バックアップ、その他のサービスを同時に実行したときの実際の負荷を確認しましょう。境界を満たせない役割だけを分離し、クライアントからメディア、さらに復旧用コピーまでの新しい経路を検証してください。

トランスコードの待ち行列が繰り返し発生するなら、演算処理を専用化する

同時に実行される変換の数を数え、使用中のコーデック、トーンマッピング、字幕処理でハードウェアアクセラレーションを利用できるか確認しましょう。近隣のサービスがCPUやGPUの処理時間を消費するたびにJellyfinでトランスコードが頻繁に待ち行列に入るなら、演算処理専用のノードを用意すると、遅延を予測しやすくなります。

ほとんどのクライアントがDirect Playを利用し、共有ホストにも余裕があるなら、演算処理は共有のままにしましょう。複数ストリームの負荷に関する説明では、ストリーム数の見出しよりも、実際のトランスコードの種類が重要な理由を解説しています。

状態データと大容量メディアで異なる保証が必要なら、ストレージを専用化する

ディスクの遅延、ドライブのスピンアップ、または保守作業が再生に影響する場合は、Jellyfinのデータベースとキャッシュを大容量メディアから分離しましょう。容量の拡張やディスク交換が主な課題なら専用NASが役立ちます。一方、アプリケーションの状態データや一時作業には、ローカルSSDが引き続き適しています。

機器を増やすだけのためにストレージを分割してはいけません。新しい構成では、安定したマウント、独立したバックアップ先、そして永続データを担う各役割の復元手順を確保する必要があります。

共有経路がボトルネックなら、ネットワークを専用化する

Jellyfin、クライアント、ストレージ、リモートユーザー間の経路を測定しましょう。バックアップやファイル転送、他のサービスによって同じリンクが飽和し、再生が途切れる場合は、専用インターフェースやVLANを導入する価値があります。ボトルネックがWANのアップロード速度やクライアントのコーデックにあるなら、LANポートを増やしても状況は変わりません。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

最後の判断基準として障害の連鎖を確認する

共有ホスト、ストレージプール、またはスイッチを再起動したらどうなるか考えてみましょう。1回の復元作業で簡単に復旧でき、障害の影響範囲も許容できるなら、役割をまとめたままにします。1つの障害でサービスと唯一の復旧用コピーの両方が失われるなら、分離しましょう。

測定したピーク時の負荷を処理でき、復旧テストも済み、次のアップグレードがまだ1つのコンポーネントで済むなら、共有リソースを選びましょう。同じ競合や障害が繰り返し発生するなら、専用リソースを選びます。分離しても再生、復旧、拡張のいずれも改善しなくなったら、そこで分割を止めましょう。