他のセルフホストアプリと併用してJellyfinを安全に運用する方法

エヴァ・ウォン

IceWhale author

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

How to Run Jellyfin Alongside Other Self-Hosted Apps Safely - Zima Store Online

データの役割を分離し、再生リソースを保護し、最も負荷が高く重なるワークロードでホストをテストすることで、他のセルフホストアプリと並行してJellyfinを運用できます。

共有ホームサーバーでは、単一のワークロードがすべてのリソースを独占しなければ、メディア、バックアップ、写真のインデックス作成、ホームオートメーション、ダウンローダー、ダッシュボード、データベースを安定して実行できます。Jellyfinには安定したアプリデータ用パスを割り当て、大容量メディアと一時的なトランスコードファイルを分離し、再生に必要なCPU、メモリ、ストレージI/O、ハードウェアビデオアクセスを十分に確保します。また、ピーク時に家庭内の利用へ影響を与える可能性がある周辺サービスには制限を設けます。

Jellyfinをホスト全体の所有者ではなく、再生担当にする

まず、常に応答性を保つ必要がある役割を明確にします。Jellyfinはメディアのインデックス作成、クライアントセッション、必要なトランスコードを担当します。バックアップツールは復旧用コピー、写真アプリはインポートと画像解析、ダウンローダーは取り込み、ホームオートメーションは常時稼働する制御を担当します。ホストは共有できますが、各サービスには明確な役割と、予想される繁忙時間帯を設定する必要があります。

アプリの一覧を、コンテナ数ではなく重複するワークロードとして捉えます。一日中アイドル状態の小さなダッシュボードは、写真の再インデックス、圧縮バックアップ、4Kビデオのトランスコードとは比較できません。夕方の視聴時間帯にどの重い処理が発生し得るか、またどれをその時間帯の外へ移動できるかを記録します。

この役割優先のモデルは、統合が依存関係の肥大化に変わることも防ぎます。ZimaSpaceの家庭内の複数サービスを1台のサーバーに統合するガイドでも同じ原則が用いられています。1台のボックスが成功するのは、他のワークフローが動作中でも各ワークフローを利用でき、復旧可能な状態に保てる場合に限られます。

永続状態、大容量メディア、一時的な作業データを分離する

Jellyfinの永続的な設定、データベース、メタデータ、プラグインの状態には、コンテナを置き換えても維持される明示的な保存場所を割り当てます。大容量のメディアライブラリは容量重視の独立したパスに置き、トランスコード出力、キャッシュ、一時ファイルは、サーバーの識別情報を壊さずに削除できる別の作業データとして扱います。

同じルールを、すべての状態を保持する周辺サービスにも適用します。コンテナの永続ストレージに関する実用ガイドでは、コンテナの置き換え後も保持する必要があるデータは、使い捨てのコンテナレイヤーの外部に置くべき理由を説明しています。複数のサービスがシステムディスク内に隠れた状態を蓄積する前に、各アプリの正式なデータパスを文書化しておきます。

高速だからという理由だけで、無関係なデータベース、キャッシュ、ダウンロード、トランスコード用の一時領域を1台の小容量SSDに集めないでください。共有低遅延ストレージは、同時書き込みによって遅延や容量不足の圧力が生じるまでは便利です。問題が発生したら、最も書き込みの多いワークロードを分離するか、一時領域を重要なアプリ状態から移動します。

再生用の余裕を確保し、急増する周辺サービスに制限を設ける

ホストが高負荷でも利用可能な状態を維持すべき再生リソースの最低ラインを決めます。これは、リビングルームでのDirect Playセッション1つと必要なハードウェアトランスコード、または家庭で実際に使う最も負荷の高い通常の組み合わせです。その最低ラインが稼働している状態で、CPU、メモリ、GPU／ビデオエンジンの使用状況、ストレージ遅延を測定します。

コンテナは、名前で分離されているだけで無害になるわけではありません。コンテナのリソースクォータに関するガイダンスでは、CPUとメモリのクォータを使って、1つのコンテナがホストのリソースを無制限に消費するのを防げると説明しています。まずは、遅くなっても許容できる急増しやすいサービスや実験的なサービスに制限を適用します。ピーク時の再生要件を把握する前に、Jellyfinへ無条件に制限をかけてはいけません。

OSとストレージサービスも、リソース競争の対象外にしておきます。アプリのワークロードによってホストがスワップ、メモリ不足によるプロセス終了、システムボリュームの容量不足に陥る構成は、Jellyfin自体に名目上のCPU予約があっても安全に統合されているとはいえません。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

共有GPU、ネットワーク、ストレージの経路を明確にする

ハードウェアアクセラレーションは、抽象的な設定ではなく共有デバイスの経路です。別のコンテナがローカルAI、画像処理、ビデオ処理でGPUを使用する場合、キュー待ちやドライバーの競合なしに両方のワークロードを共存させられるかテストします。共存できない場合は、CPUコアを増やせばメディアエンジンのボトルネックが解消すると考えず、二次的なワークロードをスケジュール実行するか、別のホストへ移します。

ネットワークとストレージも同じように扱います。Jellyfinが高ビットレートのソースを読み取る一方で、バックアップが大容量のシーケンシャルデータを書き込み、写真アプリが多数の小さなメタデータ処理を実行する場合があります。メディアがネットワークストレージにあるなら、コンピュートとストレージの間の経路も再生トポロジーの一部となるため、競合する転送中にテストする必要があります。

書き込みアクセスの不要な共有は避けます。ダウンローダーは、完了したファイルをJellyfinが後で読み取る取り込み先へ配置できますが、Jellyfinの設定へ書き込みアクセスする必要はありません。監視コンテナはアプリケーションデータを所有せずにメトリクスを読み取れます。権限を絞ることで、別のサービスの状態を破損または削除できるサービスの数を減らせます。

家庭での利用時間帯に合わせて重いバックグラウンド処理をスケジュールする

柔軟に実行できる処理は、再生が最も集中する時間帯から外します。ライブラリ全体のスキャン、写真の再インデックス、バックアップの圧縮、整合性チェック、AIインデックス作成、大容量ダウンロードは、多くの場合、夜間や主な視聴時間帯の後に実行しても最終結果は変わりません。

スケジュール設定は容量の代わりにはなりませんが、トポロジーを調整する手段です。2つの正当な重いジョブを同時に実行する必要がないなら、時間を分けることで、小型で効率的な単一ホスト構成を維持できます。毎日重なる必要があるなら、その重複を前提にシステムの容量を確保するか分割し、脆弱なスケジュールに依存しないでください。

再起動時の動作と依存関係も記録します。リモートメディアのマウントが見つからない状態でJellyfinを起動させてはいけません。また、実験的なアプリの障害によって、家庭内でメディアサーバーへ接続するために必要なDNS、ストレージ、認証経路が停止してはいけません。

繁忙時間帯の再現テストで共有ホストを検証する

構成を安全だと判断する前に、通常発生する最悪の重複状態を再現します。代表的で最も負荷の高いメディアを再生し、通常同時に実行されるバックアップまたは写真処理を動かし、他の常時稼働サービスも起動したままにします。再生の安定性、メモリの圧迫、ストレージ遅延、空き容量、温度、ハードウェアビデオ経路を監視します。

十分な余裕を保ってテストに合格したら、複雑さを増やすのをやめます。1台目のホストで複数のアプリを運用しているからといって、2台目のサーバーが必要になるわけではありません。大幅なアプリ変更、ストレージ移行、新しいGPUワークロードの追加後は、リソースグラフが変化しているため、引き続き測定します。

スケジュール設定と妥当な制限を適用しても同じ測定上の競合が再発する場合にのみ、役割を分割します。ストレージ遅延が繰り返し再生を妨げる、GPUが必要な2つのワークロードに対応できない、メモリ圧迫が中核サービスを脅かす、または実験的なスタックに別のメンテナンス時間帯が必要になる場合です。その時点で、追加のホストには明確な役割があり、目的なく拡張するためのものではありません。