Jellyfinでデータベースまたはストレージホストを分離すべきタイミングは？

エヴァ・ウォン

IceWhale author

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

When Should Jellyfin Use a Separate Database or Storage Host? - Zima Store Online

ほとんどのJellyfin環境では、メディアストレージホストとデータベースホストを分離する前に、メディアストレージを分けることを検討しましょう。運用中のアプリケーション状態は低遅延のローカルSSDに保持し、容量、復旧、設置場所の要件がある場合にのみ、大容量メディアを分離します。

この判断で重要なのは、マシンの台数ではなくデータの役割です。Jellyfinには、遅延の影響を受けやすい設定やデータベースの状態、再構築可能なキャッシュ、一時的なトランスコードデータ、そして大容量でほぼシーケンシャルに読み取られるメディアファイルがあります。これらのデータ種別には、それぞれ異なるストレージ、バックアップ、障害境界が適しています。2台目のホストが有用なのは、以前はローカルだった依存関係を不安定なネットワーク経路に変えることなく、いずれかの役割に明確な容量上または復旧上のメリットをもたらす場合だけです。

マシンを分ける前にデータの役割を分ける

まず、4つの役割に分けます。信頼できるアプリケーション状態、再構築可能な派生データ、一時作業領域、メディアです。データベース、ユーザー情報、視聴状態、プレイリスト、設定、選択したメタデータは復旧単位に含めます。キャッシュやトランスコードの断片は通常、再作成できます。映画や音楽のファイルは大容量の元データであり、保護戦略がアプリケーションデータベースとは大きく異なる場合があります。

現在のJellyfinデータベースメンテナンスガイドでは、統合された10.11データベースを、使い捨てのキャッシュではなく、稼働中の運用状態として説明しています。そのため、ホストの配置は、名前に「Jellyfin」と付いたすべてのディレクトリを同じ共有領域に置くことではなく、所有権と復旧要件から考え始めるべきです。

ホスト構成を考える前に、これらの役割を図にしてください。現在のサーバーにアプリケーション状態を保持する十分なSSD容量とバックアップ体制があるなら、移動してもアーキテクチャ上のメリットはありません。メディアライブラリがローカルのドライブベイ、電力、冷却、または障害分離の限界を超えた場合は、アプリケーションをローカルに残したまま、その役割をNASやストレージサーバーへ移す明確な理由があります。

外部データベース経路が本当にサポートされていない限り、本番データベースはローカルに保つ

Jellyfin 10.11ではEF Coreへの大規模な移行が完了しましたが、それによって別のPostgreSQLサーバーが標準的な本番構成になるわけではありません。実験的なPostgreSQLアダプターは存在しますが、別のサービス、認証情報、バージョン互換性、バックアップ順序、ネットワーク依存関係が追加されます。一般的な家庭環境では、専用データベースホストによる理論上の整然さよりも、これらのコストのほうが大きくなります。

実験的なPostgreSQLリリース自体も、そのアダプターは本番用ではなく評価用だと警告しています。この実験的なデータベース境界が制止すべき理由です。構成をよりエンタープライズらしく見せるためだけに、サポートされていないバックエンドを中心に家庭用の復旧計画を設計してはいけません。

本番環境では、ローカルに置くことは保護しないことを意味しません。アプリケーション状態を信頼性の高いSSDストレージに置き、別の障害領域へバックアップし、使用中のJellyfinと一致するバージョンでバックアップを復元できることを確認してください。選択したバックエンドが使用中のリリースでサポートされ、独立して運用でき、復旧上のメリットが新たなネットワーク依存やバージョン依存を上回る場合にのみ、データベースサービスを分離します。

容量やドライブ構成が必要とする場合にメディアを別のストレージホストへ移す

大容量メディアはアクセスパターンが異なります。ダイレクト再生では主に、再生ビットレートで大きなファイルをシーケンシャルに読み取るため、ネットワーク、マウント、ディスクが同時再生の合計負荷を維持できれば、NASでも快適にメディアを提供できます。メディアを分離すれば、より大きなストレージプール、多数のドライブベイ、異なるバックアップ設計によってストレージホストを拡張しながら、計算ノードをコンパクトに保つこともできます。

Jellyfinを使う最近のホーム構成では、DockerデータをSSDに置き、メディアをHDDに保存しています。これは実用的なSSDアプリケーション・HDDメディア分離の例です。再生開始時には、SSD上のアプリケーションデータによってブラウジングが高速でも、スリープ中のHDDの起動による遅延が発生する可能性があります。

ドライブの拡張性、設置場所の静音性、冗長性、複数サービスでのストレージ共有が追加経路を導入する価値を持つ場合は、別のストレージホストを選びます。1台の筐体で容量とバックアップの要件を満たせるなら、メディアはローカルに保ちます。理由なく分離すると、実際のユーザー体験を変えないまま、DNS、マウント、権限、ネットワーク障害、起動順序への対応が増えるだけです。

Featured

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

ZimaCube2

ストレージネットワークを見えないケーブルではなく必須の依存関係として扱う

メディアを別のホストへ移すと、Jellyfinはスキャンや通常動作の前にマウントが存在していることを必要とします。NASが利用できない場合でも、空のマウントポイントが有効なディレクトリに見えることがあります。また、ネットワークが遅い、または不安定だと、ストレージの問題が再生遅延に変わる可能性があります。そのため、この構成にはフェイルクローズ型の起動ルールと、測定可能な帯域幅の目標が必要です。

コミュニティの経験から、ネットワークを適切に設計すれば、一般的な家庭内ネットワーク経由で別のNASからメディアを提供しても問題なく動作します。最近のある議論では、多くのユーザーがまさにこの構成を採用しており、再生上の問題はありませんでした。別NASへのメディアストレージ分離から得られる有用な教訓は、ネットワーク上の配置は実用的ですが、無料で利用できるものと考えず、メディア経路の一部として扱う必要があるということです。

最も遅い区間を検証してください。ストレージプール、NASのNIC、スイッチ、サーバーのNIC、マウントプロトコル、同時再生数を確認します。想定したメディアマウントが存在しない場合は、Jellyfinを停止するか、破壊的なライブラリメンテナンスを一時停止します。2台目のホストが信頼性の向上になるのは、障害が明確で影響範囲が限定される場合であり、障害が空のライブラリへと静かに変換される場合ではありません。

分離の判断には復旧テストと拡張テストを使う

別のホストを追加する前に、2つの事象を訓練してください。Jellyfinの計算ノードを失った場合と、メディアストレージノードを失った場合です。検証済みの復元優先の復旧ワークフローによって、設定、永続データ、バージョン管理されたサービス定義、復元順序は、バックアップファイルが存在するだけでなく、一体として検証しなければならないことが分かります。同様に、ストレージホストの障害テストでは、信頼できるメディアの状態を書き換えたり削除したりせず、Jellyfinが予測可能な形で機能低下することを確認します。

ZimaSpaceのJellyfinストレージ復旧監査も同じ所有権テストを採用しています。すべての永続パスについて、障害が発生する前に、明確な役割、バックアップ範囲、復元方法を定義しておくべきです。

アプリケーション状態、メディア容量、バックアップ、通常のピークI/Oをすべて余裕を持って収められるなら、1台のホストを維持します。容量やストレージのライフサイクルが制約になった場合は、メディアストレージを分離します。データベースプロバイダーが本番環境でサポートされ、独立して復旧可能になるまでは、別のデータベースホストを高度な例外として扱ってください。停止条件は、追加できる箱の数ではなく、役割を明確に説明し、復元できる構成です。