Jellyfinの障害ドメイン：依存関係が停止に与える影響

Jellyfinの障害は依存関係グラフに沿って発生するため、同じコンポーネントの障害でも、どのユーザーリクエストがそれを必要とするかによって、無害な場合もあれば、一部停止や全面停止につながる場合もあります。

Jellyfinが1つのプロセスで動作している場合でも、ホームメディアスタックにはストレージマウント、データベース、DNS、リバースプロキシ、認証、コンテナ、アクセラレーション、連携サービスなどが含まれることがあります。重要なのはリクエストの経路です。バッファリング済みのストリームは、メタデータソースの障害を無視できる場合があります。一方、新規のリモートログインは、プロキシや認証情報の経路が失われると直ちに失敗する可能性があります。障害ドメインはプロセス数ではなく、依存関係の結合によって決まります。

Jellyfinのプロセスが稼働していても、サービス経路が正常だとは限らない

プロセスの健全性から分かるのは、Jellyfinが実行中かどうかだけです。ユーザーリクエストを処理するには、経路上にあるすべての同期依存先が正しく応答する必要があります。そのため、サーバーが「稼働中」でも、ライブラリが空になったり、リモートアクセスに到達できなかったり、認証に失敗したり、メディアデータを読み取れなかったりすることがあります。可用性は1つのPIDの状態ではなく、必要な処理段階全体の組み合わせです。

ホームラボのインシデントは、DNS、ストレージ、ルーティング、共有インフラなど、明らかなアプリケーションプロセスの外部にある隠れた依存関係から始まることがよくあります。そのためJellyfinでは、マウント、データベースアクセス、プロキシルーティング、名前解決を追跡せずにコンテナの状態だけを確認すると、依存先の障害をアプリケーションのバグと誤認する可能性があります。

最初に作成すべき診断資料は、1つのユーザー操作に対する依存関係マップです。「ライブラリを開く」「ローカルでDirect Playを開始する」「リモートでトランスコードを開始する」はそれぞれ異なる経路であり、依存するコンポーネントも異なる場合があります。これらの経路を明確にすれば、リクエストを満たせなくなった最初の必須段階に障害を割り当てられます。

クリティカルパスの依存関係が即時のユーザー影響を決める

Jellyfinがそのリクエストを完了するために不可欠な依存先は、そのリクエストにとってクリティカルです。今後のソースデータを読み取る必要がある時点では、メディアストレージがクリティカルになります。ユーザー情報やライブラリの状態には、データベースが不可欠になる場合があります。唯一の経路がリバースプロキシを通るクライアントにとっては、リバースプロキシがクリティカルです。オプションのメタデータサービスが停止しても、すでにインデックス化されたコンテンツは利用できる場合があります。

障害分析は、すべてのコンポーネントを同列に扱うのではなく、サービスの依存関係チェーンに沿って行うと明確になります。キャッシュ、プロキシ、データベース、キューの障害がもたらす影響が異なるのは、それぞれがリクエスト経路の異なる位置を占め、他の依存先にはない代替経路を持つ場合があるためです。

これにより、部分的な停止が自然に発生します。ライブラリの閲覧に失敗しても、サーバーとクライアントのバッファにより、既存のストリームは継続する場合があります。ローカルユーザーは利用できても、リモートユーザーはプロキシ経路を失うことがあります。Direct Playは動作していても、特定のトランスコードに必要なアクセラレーター経路だけが失敗することがあります。障害ドメインとは、失われたクリティカルな依存先を共有するリクエストの集合です。

共有依存関係がローカル障害を広範囲の影響へ変える

2つのコンテナが同じストレージプール、ネットワークブリッジ、DNSリゾルバー、リバースプロキシ、データベース、またはホストに依存しているなら、それらは独立していません。その共有レイヤーの障害により、一見別々に見える複数のサービスが同時に失われる可能性があります。コンテナ境界によってライフサイクルの分離は改善できますが、インフラストラクチャ層での運用上の影響範囲は変わらない場合があります。

データベースの事後分析では、複数のサービスが1つのデータベースに依存している場合に、共有データ層が共通の障害点になるパターンが示されています。Jellyfinスタックにも同じトポロジー上のリスクがあります。メタデータ補助サービス、監視、または自動化を別々のコンテナに移しても、それらすべてが1台のホスト、1つのマウント、または1つの入口経路を必要とするなら、独立性は生まれません。

したがって、アーキテクチャ上の問いは「コンテナはいくつあるか」ではなく、「何が一緒に停止するか」です。共有コンポーネントを、それを利用するサービスの下に配置して図示し、各ユーザー操作がどのコンポーネントを通過するかを示します。多数の依存関係エッジが入るコンポーネントは、障害ドメインが構造的に大きいため、より強固な監視、簡単な復旧手順、場合によっては冗長化が必要です。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

依存先の競合は、コンポーネントが停止する前からサービスを劣化させる

障害ドメインは、単純な稼働・停止の事象に限られません。依存先が到達可能なままでも、レイテンシー、接続数の上限、ストレージキュー、ロックの増加によって、下流のリクエストがタイムアウトすることがあります。この場合、供給側が単純なヘルスチェックには応答していても、目に見える障害はJellyfinに現れます。容量と障害の波及は、密接に関係しています。

移行インシデントの分析では、共有状態が完全に利用不能になるのではなく遅くなった場合に、データベースの競合がサービス全体に波及する仕組みが示されました。Jellyfinでも、ネットワークマウントが停止したり、データベースロックが長時間継続したり、プロキシが不健全な上流を待機したりすると、同様のパターンが発生します。キューに積まれた処理が時間を消費し、最終的に劣化がリクエストの失敗へ変わります。

見分けるポイントは、依存関係の境界におけるレイテンシーです。Jellyfinの応答時間が上昇するのと同時に、ストレージのレイテンシー、プロキシの上流応答時間、またはデータベースの待機時間も上昇しているなら、その依存先はプロセスが停止していなくても障害経路の一部です。障害モデルには、クラッシュ検知だけでなく、飽和状態やタイムアウトの挙動も含めるべきです。

障害境界：キャッシュされた状態はクリティカルな依存先の影響を遅らせられても、なくすことはできない

適切なローカル状態から現在のリクエストを処理できる間だけ、グレースフルデグラデーションは存在します。クライアントのバッファは短時間のネットワーク中断を隠せます。キャッシュされたメタデータは閲覧状態を維持できます。すでに認証済みのセッションは、オプションのプロバイダーの障害を乗り越えられる場合もあります。しかし、これらは影響が表面化するまでの時間を延ばすだけで、将来のすべての操作で欠落した依存先が不要になるわけではありません。

大規模なインシデントでは、個々のアプリケーションコンポーネントが無傷でも、共有ネットワーク障害によって複数の依存サービスが停止することがあります。Jellyfinでは、シーク、トークンの更新、新規ログイン、ライブラリの更新、次のメディアデータの読み取りなどの操作でキャッシュが尽き、失敗した依存先が避けられなくなることがあります。

依存先がなくても継続すべき操作をテストした後にのみ、その依存先をオプション扱いにしてください。プレーヤーがデータをバッファリングしているために30秒間だけサービスが継続するなら、その依存先は持続的な再生にとって依然としてクリティカルです。障害境界は、キャッシュされた状態が障害を隠している短い期間から推測するのではなく、ユーザー操作の時間軸で定義すべきです。

レジリエンスを主張する前に依存関係・障害マトリクスを作成する

既存のDirect Play、新規のローカル再生、リモートログイン、シーク、ライブラリ閲覧、トランスコード、視聴状態の更新、再起動といった固定したユーザー操作に対して、依存先を1つずつテストします。各操作について、成功するか、劣化するか、タイムアウトするか、状態が破損するかを記録し、依存先が復旧した後の回復挙動も記録します。結果がテスト対象の依存先に帰属するよう、メディアとクライアントの条件は一定に保ちます。

既存のサービススタックの依存関係グラフも同じ運用上の要点を示しています。分離されたライフサイクルによって、明示的なマウント、経路、デバイス、起動順序の関係が追加され、それらを管理する責任が生じます。障害マトリクスは、そのグラフを証拠へと変え、どの依存先が実際に各Jellyfinサービスの境界を定義しているかを示します。

必要なユーザー操作が正しく継続し、レイテンシーが一定範囲に収まり、無関係な経路が健全なままで、復旧に状態修復を必要としない場合にのみ、レジリエンスの主張を合格とします。1つのコンポーネントを取り除くと操作が一貫して停止するなら、そのコンポーネントは障害ドメイン内にあります。複数のサービスが同時に停止する場合は、各アプリケーションを個別に再起動するのではなく、それらが共有する依存先へ調査を下流から進めてください。