Jellyfinサービスを複数のホストに分散すべきタイミングは？

エヴァ・ウォン

IceWhale author

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

When Should You Split Jellyfin Services Across Multiple Hosts? - Zima Store Online

1台のマシンでは明確なリソース、信頼性、または配置要件を満たせなくなった場合に限り、Jellyfin関連サービスを複数のホストに分散します。複数ホストの構成図がきれいに見えるという理由だけで分散しないでください。測定によってボトルネックや障害境界が明らかになり、別のマシンが必要になるまでは、Jellyfinアプリケーションと稼働中のデータベースをシンプルに保ちます。

多くの家庭では、最初に分離すると効果的なのは、ストレージとコンピュート、メディアホストとリバースプロキシまたはVPN、再生処理と負荷の高いダウンロード・インデックス処理、またはメインサーバーと専用トランスコード処理です。分離するたびに、ネットワーク依存関係、パスの一貫性、認証情報、監視、バックアップ作業が増えます。そのため、一度に1つだけ分離し、次のホストを追加する前に、同じ家庭内の負荷で元の問題が改善したことを確認してください。

1台のホストに実際の競合問題があることを証明する

重要な負荷がかかっている間に症状を測定します。たとえば、バックアップ処理中に再生が停止する、スキャンによってストレージが飽和する、GPUタスクによってトランスコード処理が圧迫される、またはメンテナンスによって許容できない停止時間が発生する、といった症状です。ホストにCPU、メモリ、I/O、ネットワークの余裕が十分にあるなら、マシンを追加しただけで信頼性が向上する可能性は低いでしょう。

CPUの飽和、GPUキューの滞留、ストレージの遅延、継続的なネットワークスループットなど、再現可能な観測結果を利用します。短時間の負荷上昇しか発生せず、再生が正常に完了するホームサーバーには、まだスケーリング上の問題はありません。

この境界を優先する考え方は、共有ホームサーバーのワークロードを評価する際にも役立ちます。実際の共有リソースの上限と、ダッシュボード上で単に忙しそうに見えるマシンを区別してください。

容量とドライブ構成に別の置き場所が必要になったらストレージを分離する

ドライブ台数、RAID構成、騒音、物理的な設置場所、またはバックアップ要件がJellyfinのコンピュートボックスに収まらなくなったら、メディアストレージをNASまたはストレージに特化したホストへ移します。テスト済みの理由がない限り、Jellyfinのデータベースとキャッシュは、アプリケーションに近い信頼性の高い低遅延ストレージに置いてください。

分離後は、高ビットレートのDirect Playを1つ、ライブラリスキャンを1つ、同時実行のファイル転送を1つ行い、メディアパスをテストします。新しいネットワークストレージによって、ローカル接続では発生しなかった停止が起きるなら、分離によってボトルネックを解決するどころか移動させただけです。

リモートのメディア共有が利用できない状態でJellyfinがクリーンアップやスキャンを開始しないよう、安定したマウントパスと起動順序を維持します。マウントの可用性は、ライブラリメンテナンスを実行する前に正常でなければならない依存関係として扱ってください。

実証済みのコンピュート上限を解消できる場合にのみ専用トランスコードを分離する

メインのJellyfinホストで必要なハードウェアアクセラレーションを利用できない場合、リモートトランスコードは専用分離の選択肢になります。ただし、単に2台目のサーバーを追加するよりも複雑です。共有パス、ネットワーク帯域幅、権限、障害処理のすべてが再生の一部になります。

Jellyfinでは、rffmpegを使用して別のLinuxマシンにトランスコードを委任するリモートハードウェアアクセラレーションの方法が説明されています。この方法にはSSHと共有ストレージが必要です。追加の依存関係に見合うだけのコンピュート上のメリットがある場合にのみ使用してください。

元の過負荷を引き起こした正確なコーデック、字幕、HDR、ビットレートのケースで分離構成を検証します。メインサーバーのCPU使用率が下がっても、ネットワークや共有ストレージの遅延によってバッファリングが発生するなら、リモートワーカーによる実質的な改善は得られていません。

-15% OFF

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

Single board computer zimaboard2

障害境界を分ける必要がある場合にネットワークエッジサービスを分離する

Jellyfinに影響を与えずに更新や再起動を行いたい場合、またはエッジ側に異なる公開ポリシーが必要な場合は、リバースプロキシ、VPNゲートウェイ、リモートアクセスノードを別のホストに配置できます。家庭内のローカル再生が不要なインターネット公開コンポーネントに依存しないよう、経路は十分にシンプルに保ってください。

サイト間VPNやルーティングVPNの構成には、明確なサブネットとルーティングの要件があります。たとえばTailscaleでは、マルチサブネットルーティングに関するサイト間ルーティングの要件と制限が説明されています。2台目のホストを透過的な依存先として使用する前に、これらの経路を計画してください。

ローカルアクセス、リモートアクセス、エッジホストの障害をそれぞれ個別にテストします。意図的に別の設計にしていない限り、リモートアクセス用マシンがオフラインでも、ローカルクライアントは想定したローカル経路を維持できる必要があります。

運用がボトルネックより難しくなったら分離を止める

ホストを追加するたびに、パッチ適用、ヘルスチェック、認証情報、ログ、バックアップ、新しいネットワークホップが増えます。どのサービスを先に起動する必要があるのか、ストレージ、トランスコード、DNS、プロキシホストが停止した場合に何が起きるのかを示す、シンプルな依存関係マップを維持してください。

分離するたびに、元の繁忙時間帯の負荷を実行し、単一ホスト構成を基準として、再生の安定性、CPU/GPU使用率、ストレージ遅延、復旧動作を比較します。測定した問題が改善し、復旧方法も分かりやすい場合にのみ、その分離を維持してください。

どのホストがデータベースを管理しているのか、どのパスが正となるのか、バックアップをどのように復元するのか、1つのノードがオフラインになったとき何が起きるのかを説明できないなら、これ以上の分散は一旦止めてください。余裕のあるシンプルな単一ホストのJellyfin構成のほうが、文書化が不十分なマルチホスト構成より安全なことがよくあります。