共有世帯向けJellyfinサーバーの設計書

エヴァ・ウォン

IceWhale author

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

A Jellyfin Server Blueprint for a Shared Household - Zima Store Online

共同住宅向けのJellyfinサーバーでは、ベンチマークを最優先したハードウェア選びよりも、安定した再生、ユーザーごとの独立したID、静かに常時稼働するストレージ、そして復旧性を重視すべきです。

一般的な家庭では、常時利用可能な状態と、変動する負荷が混在します。夕方のテレビ再生、時折のスマートフォンやブラウザー利用、新しいメディアのスキャン、バックアップ、場合によってはリモートストリーミングなどです。こうした繰り返し発生する場面を中心にシステムを構築してください。サーバーに高い性能が必要なのは、実際のクライアントやバックグラウンド処理が限界を超える場合だけです。それ以外では、使われない余裕よりも、シンプルさと復旧性のほうが価値があります。

購入や移行の前に、家庭内のワークロードマップを作成する

誰がサーバーを使うのか、どの部屋とデバイスが重要なのか、同時視聴が最も起こりやすい時間帯、どの処理を無人で実行するのかを洗い出します。ライブラリのスキャン、サムネイル生成、バックアップ、ダウンロード、同じホスト上で共有するその他のコンテナも含めてください。

「4人いる」ことをそのまま「4本のトランスコードが必要」と考えないでください。ある家庭では、4台の最新クライアントがほぼすべてをダイレクト再生できます。一方で、別の家庭では、1台のブラウザーと1台のリモートテレビが繰り返し変換を強制することがあります。重要なのは人数ではなく、クライアントとファイルの組み合わせごとに生じる再生経路です。

実装の基準として、Jellyfinハードウェア要件ページでは、固定のストリーム数を約束することなく、クライアント、ストレージ、ネットワーク、アクセラレーションに関する確認事項を公式ガイダンスに基づいて整理しています。

状態や権限を分ける必要がある場合は、全員にプロフィールを用意する

家族それぞれで視聴履歴、お気に入り、ライブラリの表示範囲、再生制限、リモートアクセス権限を分ける必要がある場合は、個別のユーザーアカウントを作成します。共有アカウントが簡単なのは、全員が本当に同じ状態と権限を望む場合だけです。

管理者の認証情報は、日常の再生用アカウントと分けてください。ライブラリ、プラグイン、ネットワーク、ユーザーを変更するアカウントを、特に共有されたテレビや更新頻度の低いデバイスすべてにログインさせる必要はありません。

権限はサーバーのダッシュボードだけでなく、クライアントからも確認してください。子ども用プロフィール、一般の成人用プロフィール、管理者が、実際に使用するデバイス上で意図したライブラリと機能だけを利用できて初めて、家庭向けの設計図は完成です。

リビングルームの経路をダイレクト再生向けに最適化する

リビングルームのクライアントは利用頻度が最も高い経路になりやすいため、予測しやすい構成にします。安定した有線ネットワークまたは強力なローカルネットワーク、可能な範囲で互換性の高いメディア形式、そしてライブラリでよく使うコーデックや字幕形式に対応した再生デバイスを優先してください。

Jellyfinのトランスコード動作はクライアント主導です。サーバーは、プレーヤーから送られた対応能力の情報と制約に応じて処理します。そのため、一般用途のCPU性能を追加するよりも、普段使うクライアント経路を改善したほうが、サーバー負荷を大きく減らせる場合があります。

サーバー自体はEthernetに接続してください。テレビが無線接続でも、経路上の無線区間は1か所だけになり、両端が変化するWi-Fi状況の影響を受ける構成を避けられます。

-15% OFF

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

Single board computer zimaboard2

騒音の大きい容量と、遅延に敏感なデータを別の役割に分ける

家庭用サーバーは一日の大半をアイドル状態または軽負荷で過ごすため、静音性とバックグラウンドでのディスク動作が重要です。大容量HDDはメディア保存に費用対効果が高い一方、メタデータの閲覧やデータベースはSSDの低遅延の恩恵を受けます。小さなランダム読み取りのために、すべての大容量ディスクを起動させる必要がないようにしてください。

Jellyfinは、ランダムアクセスが発生する自身のファイルにはSSDを推奨しています。一方、大容量のメディアファイルは主にシーケンシャルアクセスです。ZimaSpaceのメタデータ配置ガイドでは、アプリのデータベース、移行可能なサイドカー、アートワーク、再構築可能なプレビューを、復旧時の価値に応じてさらに分けています。

サーバーが居住空間の近くにある場合は、ハードウェアを追加する前に、負荷の大きいインポートやバックアップを主な視聴時間帯以外にスケジュールしてください。処理を実行する時間帯を変更するだけで、トポロジーを変えずに競合や騒音を解消できる場合があります。

家庭で実際に維持できるリモートアクセスの境界を選ぶ

リモートストリーミングが不要なら、Jellyfinをローカルに限定し、外部公開と帯域幅計画に関する問題をまとめて減らしてください。リモート利用が必要なら、VPN、またはHTTPSを正しく設定したリバースプロキシなど、意図的に選んだ1つの経路を使用します。

Jellyfinのネットワークガイドでは、インターネットへの直接ポート転送は推奨されていないと説明し、リバースプロキシとVPNの方法を紹介しています。また、ユーザーごとにリモートアクセスを有効または無効にできるため、一部の家族だけが必要とする場合にも便利です。

リモートURL、証明書またはVPNの管理者、復旧手順を文書化してください。誰か1人が記録されていないルーター設定を覚えているからという理由だけで動作するリモート経路は、家庭向けの永続的なサービスとはいえません。

シンプルな拡張ルールを使う：家庭内の処理に支障が出たときだけ役割を追加する

計算性能、ストレージ、バックアップの要件を満たすなら、まずは把握しやすい1台のサーバーから始めてください。ドライブの拡張限界、再生に影響するバックアップ時間帯、GPUの配置、ピーク時間帯にJellyfinと競合する別のアプリなど、具体的な問題が発生したときに役割を分離します。

ZimaBoard 2のような小型コンピュートノードは、分離構成におけるアプリケーションサーバーの役割を担えます。一方、より大型のマルチベイシステムはストレージの役割を担えます。判断はワークロードマップに基づいて行い、Jellyfinを使う家庭には必ず2台必要だというルールに従うべきではありません。

最後に、1つの障害を想定して訓練してください。Jellyfinの状態を復元し、メディアへの経路を再接続し、一般ユーザーが再生を再開できることを確認します。その復旧が成功し、家庭内のピーク利用時もスムーズに動作するなら、この設計図は拡張を止める条件に達しています。