1つの依存関係が利用できない場合でも、Jellyfinはクライアントでの一貫した再生を維持できますか？

場合によっては、失敗した依存関係がアクティブなストリームに必要でなければ、Jellyfinは再生を維持できます。ただし、クリティカルパス上の障害はサービスを中断します。

メタデータプロバイダーがオフラインになっても、すでにインデックス化された映画は再生できる場合があります。一方、メディアマウント、データベース、リバースプロキシのルート、認証経路、または必要なトランスコードデバイスを失うと、新しいセッションは直ちに停止する可能性があります。判断のポイントは、現在のクライアント要求がローカルですでに利用可能な状態だけで完了できるか、それとも次の再生セグメントや認証判断の前に、失われた依存関係を同期的に呼び出す必要があるかです。

依存関係がアクティブな再生経路上にあるかを分類する

依存関係にはそれぞれ異なる役割があります。メタデータサービスはカタログを拡充し、リバースプロキシは要求を運び、ストレージはソースデータを提供し、データベースはユーザー情報とライブラリ状態を提供し、GPUは特定の変換に必要になる場合があります。障害が再生に影響するのは、障害発生時または次の状態遷移時に、アクティブなセッションがその依存関係を必要とする場合だけです。

ZimaSpaceのリモートアクセスモデルでは、「Jellyfinが稼働している」ことを単一の二値条件として扱うのではなく、クライアントの信頼性を経路の段階ごとに分けています。アクセス経路の段階は、依存関係を考えるうえで役立ちます。正常なサーバープロセスでも、セッションを運ぶために必要なプロキシ、DNSルート、VPN経路、またはアップロード回線が利用できなければ、リモートストリームを維持できません。

境界となるのはセッションのフェーズです。すでにバッファリングされているクライアントは、経路に障害が発生してからもしばらく再生を続けられる場合がありますが、シーク、新しいセグメント要求、トークン更新、新しいログインによって、失われた依存関係が明らかになります。障害直後の数秒間、キャッシュされた再生が続いたかではなく、次に必要となる操作まで含めて回復性を判断してください。

キャッシュ済みおよび永続的なローカル状態で段階的な縮退を支えられる

必要な情報をすでにローカルに持っており、失われた依存関係が任意の付加情報や将来の更新だけを提供する場合、サービスは有用な処理を継続できます。そのため、既存のメタデータ、アートワーク、データベース状態、クライアントバッファーによって、一部の障害が目に見える影響を軽減できる場合があります。ただし、返される状態が要求された操作に対して十分に有効な場合に限り、これは段階的な縮退といえます。

一般的なサーキットブレーカーパターンは、応答しない供給元を何度も待ち続けることを避け、代わりにエラーを返したり、処理をキューに入れたり、許容できる古いデータを使用したりする理由を説明します。このパターンは、Jellyfinがすべての依存関係に特定のブレーカーを実装していることを示すものではありません。しかし、明確な設計上の判定基準を与えてくれます。つまり、コア経路が利用可能な間は、任意の障害によってすべての要求リソースを消費させるべきではありません。

境界となるのは正確性です。古いアートワークは通常許容できますが、古い認証情報や更新されていないメディアパスは許容できない場合があります。失敗した依存関係がなければ有効性を確認できないデータを提供して、可用性があるように見せるべきではありません。安全に再利用できる状態と、復旧まで失敗させるか待機させる必要がある判断を分類してください。

ストレージとデータベースの重大な障害は通常、新しい処理を停止させる

Jellyfinがソースメディアを読み取れなければ、クライアントとサーバーのバッファーが空になった時点で、そのストリーム向けに今後のデータを生成し続けることはできません。同様に、データベースや永続状態の障害によって、新しいセッションの確立、視聴状態の更新、ライブラリ検索、認証判断が妨げられる場合があります。これらは中核的な依存関係であるため、任意のメタデータ検索と比べると、段階的な縮退の範囲は狭くなります。

サービススタックの観点から見ると、この結び付きは明確です。コンテナを分離するとライフサイクルの境界は改善しますが、マウント、ルート、データベース、デバイス、起動順序から成る依存関係グラフが追加されます。依存関係グラフは、コンポーネントを分離しても機能上の関係はなくならないことを示しています。正常なJellyfinプロセスでも、必要な状態が別の場所にある要求を完了できない場合があります。

障害の境界となるのはデータの安全性です。アクティブなデータベース書き込み中にJellyfinを繰り返し再起動したり、ストレージを再マウントしたりすると、一時的な停止を受け入れるより大きなリスクが生じる可能性があります。重要な永続依存関係が消失した場合は、ログと状態を保持し、依存関係を安全に復元して、一貫性を検証してから、自動リトライを問題のないものとして扱ってください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

タイムアウトとリトライの動作が、1つの障害が連鎖するかどうかを決める

利用できない依存関係に対して呼び出し側が長時間待機し、積極的にリトライすると、スレッド、ソケット、メモリ、要求時間を消費する可能性があります。ブロックされた処理が増えすぎると、無関係な操作まで遅くなり、局所的な障害がより広範な停止に変わることがあります。したがって回復性は、依存関係が任意であるかどうかだけでなく、システムがどれほど速く障害を認識し、どれだけの処理を蓄積させるかにも左右されます。

障害封じ込めモデルは、この連鎖リスクを説明します。ブレーカーや上限付きキューによって、異常な供給元への繰り返し呼び出しが重要なリソースを使い果たすのを防ぎます。Jellyfinのデプロイでは、すべてのリトライが可用性を高めると考えるのではなく、プロキシ、マウント、メタデータサービス、その他の外部呼び出しにおけるタイムアウト時間、リトライ頻度、キューの増加を監視することが重要です。

境界となるのは復旧時の負荷です。短いタイムアウト1回の後に戻る依存関係なら介入は不要かもしれませんが、断続的に停止するサービスでは、再接続、スキャン、マウント処理が繰り返され、明確に停止を宣言する場合よりも再生に大きな悪影響を与える可能性があります。障害が封じ込められていると判断する前に、キュー飽和の確認を行い、待機中の処理が蓄積していないことを確認してください。

高可用性をうたう前に依存関係障害マトリクスを実行する

代表的なダイレクトプレイセッション中に依存関係を1つずつ停止し、別途、代表的なトランスコード中にも同じテストを行ってください。既存の再生、新しいセッションの開始、シークの動作、認証、ライブラリの閲覧、依存関係復旧後の回復を観察します。メディア、クライアント、ネットワークを一定に保ち、結果が別の再生経路ではなく、テスト対象の依存関係に起因するようにしてください。

クライアントとサーバーのタイミングモデルは、目に見える影響の特定に役立ちます。最初のフレームまでの遅延、バッファリング、サーバー応答時間によって、サーバー側の依存関係待ちとクライアントのデコード問題を区別できます。ログとキューのメトリクスも含め、サーバーがブロックされた処理をひそかに蓄積している間にセッションが「再生を続けている」だけで、正常と数えないようにしてください。

必要なユーザー操作が正しく完了し、遅延が抑えられ、無関係なセッションが劣化せず、復旧に状態の修復を必要としない場合に限り、再生は回復性があると判断してください。依存関係を取り除くとソースデータ、認証、データベースアクセス、または必要な変換が停止するなら、正直な結論は、その経路ではフェイルオーバーがサポートされていないということです。代わりに、その依存関係自体に冗長性を設計する必要があります。