Jellyfinは同時変更中の整合性をどのように保護しますか？

Jellyfinは、関連するデータベース変更をトランザクションとしてコミットし、同時アクセスを調整することで共有状態を保護します。これにより、読み取り側が処理途中の更新を観測することを防ぎます。

メディアサーバーは、視聴状態の更新、メタデータのスキャン、ライブラリの編集、ユーザー認証、クエリの処理を同時に行えます。しかし、同時実行できるからといって、すべての処理が自由に並列で書き込めるわけではありません。一貫性は、トランザクション境界、データベースのロックまたはスナップショットの規則、ファイルシステムの永続性、アプリケーション内の処理順序に左右されます。実用上の限界は、調整の遅延がインタラクティブなリクエストに影響するほど長くなったときに現れます。

トランザクションによって、どの変更を同時に可視化するかが決まる

トランザクションは関連するデータベース操作をまとめ、すべてが同時にコミット済みの状態になるか、処理に失敗した場合に破棄できるようにします。これは、1回のユーザー操作が複数のレコードに影響する場合に重要です。変更の一部だけが公開されると、関連性が壊れた状態になる可能性があるためです。そのためアプリケーションは、書き込みの同時実行性を一部犠牲にして、古い状態と新たにコミットされた状態の明確な境界を作ります。

SQLiteのジャーナリングを基盤とする基本的な永続性モデルを見ると、アトミック性にバイト列を順番に書き込む以上の仕組みが必要な理由が分かります。トランザクションジャーナルの仕組みは、書き込みが完了しなかった場合に以前の一貫した状態へ復旧できるだけの情報を保持します。これが、途中で中断された更新が有効な部分トランザクションとして現れるのを防ぐ基盤です。

境界となるのは、トランザクションの範囲です。データベースのコミットによって、関連のないメディアファイル、リモートマウント、外部メタデータサービスまでトランザクション化することはできません。アプリケーションがそれらのリソースも明示的に調整する場合を除きます。複数のシステムにまたがるワークフローでは、一貫性は各システムが実際に保証できる範囲で決まります。

読み取りスナップショットによって、進行中の書き込みとの干渉を抑える

インタラクティブなブラウジングでは、すべてのバックグラウンド更新が完了するまで待たなければ、安定したデータを読み取れないという状況は避けたいものです。スナップショット方式の動作では、書き込み側が新しいページを準備している間も、読み取り側は一貫したビューを読み続けられます。これにより、1つの読み取りトランザクション内で古い値と書き込み途中の値が混在することなく、読み取りと書き込みを同時に実行できます。

SQLiteのWALモードでは、既存の読み取り側がトランザクション開始時点で有効だったスナップショットを再構成できる一方、新しいページバージョンは先行書き込みログに追加されます。読み取りスナップショットモデルにより、書き込み中でも読み取りトランザクションを進められる仕組みが分かります。ただし、書き込みの調整には独自の限界があり、最終的にはチェックポイント処理によって状態を統合する必要があります。

境界は「無制限の並列実行」ではありません。長時間続く読み取りはチェックポイントの進行を遅らせる可能性があり、書き込み競合は単一の永続データベース状態の周辺に蓄積することがあります。大規模なスキャン中にユーザー向けのレイテンシーが上昇した場合は、スナップショット読み取りによって調整コストがすべてなくなると考えず、トランザクションの継続時間と待ち行列を測定してください。

ロックは重要な状態を保護するが、パフォーマンスの境界にもなり得る

2つの書き込み処理が同じ論理構造を同時に変更すると、前提条件が崩れたり、互いの変更を上書きしたりする可能性があります。そのため、一部の処理ではより強い排他制御が必要です。ロックはこうした重要な領域を直列化し、順序を明確にします。これは正確性を保護しますが、ロックを長時間保持する処理があると、インタラクティブな操作が同じ保護対象の状態を必要とする際に、バックグラウンド処理が目に見える待ち時間へ変わる可能性があります。

Jellyfinの10.11バックエンドでは、EF Coreへの移行とともに新しいデータベースロックオプションが導入されました。これは、ロックの動作が偶発的なエラーではなく、一貫性設計の一部であることを示しています。ロック動作の変更は、調整方法を調整できる一方で、重複する書き込みを安全な順序で処理する必要がサーバーにあることも明確にしています。

失敗の境界は、想定される処理時間内に解除されないロック、または通常のリクエストがレイテンシー目標を達成できなくなるほど繰り返し発生する競合です。スキャン中の一時的な待機は問題にならない場合がありますが、長時間の待機が繰り返される場合、コミットの失敗、データベースロックエラーが発生する場合は、設定を変更する前にログと負荷のタイミングから証拠を集める必要があります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

ファイルシステムのライトバックが、さらに別の永続性レイヤーを加える

データベースは、ジャーナルモードに必要な永続性の保証を満たした後にのみ、トランザクションを論理的にコミット済みと判断できます。その下では、オペレーティングシステムとストレージデバイスがキャッシュされたページとライトバックを管理しています。この違いが重要なのは、アプリケーションレベルで高速に書き込めたからといって、呼び出し元のスレッドが処理を続ける瞬間に、すべてのバイトが不揮発性メディアへ到達しているとは限らないためです。

Linuxのページキャッシュの動作では、ダーティなメモリページと、永続化を待つ同期操作が区別されます。ライトバックと同期の経路は、データベースがバックグラウンドフラッシュのタイミングに依存せず、明示的な永続化メカニズムを使う理由を示しています。特に、クラッシュや停電が発生した際、安定したストレージに到達していない状態がコミット済みとして公開されないようにする必要があります。

境界は、ハードウェアとファイルシステムの完全性です。フラッシュ完了を偽って報告するストレージデバイス、容量不足のファイルシステム、破損した永続メディアを、トランザクション処理で補うことはできません。一貫性メカニズムが保護するのは状態間の遷移であり、基盤となるストレージを完全に障害とは無縁にするものではないため、バックアップと復旧テストは引き続き必要です。

同時変更はスループットだけでなく、不変条件でテストする

ライブラリスキャン、メタデータ編集、2回の視聴状態更新、対象アイテムの繰り返し読み取りなど、制御された重複処理を選びます。実行前に不変条件を定義してください。たとえば、アイテムが欠落しないこと、論理的に重複するレコードがないこと、フィールドの一部だけが設定された状態にならないこと、最終状態が最後に受け付けた更新と一致することです。そのうえで、重複処理中のリクエストレイテンシー、データベースエラー、完了順序を測定します。

Jellyfinをプロキシ、ストレージサービス、自動化コンテナとともに実行する場合、サービス境界モデルが有用なクロスチェックになります。上流のマウントや依存サービスが利用できなくても、データベースの不変条件は満たされる可能性があります。一方の障害種別を他方と誤認しないよう、永続データの一貫性とサービス到達性は分けてテストしてください。

すべての読み取りが有効なスナップショットを観測し、最終的なコミット済み状態が受け付けた操作と一致し、一時的な待機が繰り返しエラーを伴わずに解消されれば合格です。データベースが完全性エラーを報告した場合、同じ書き込みが繰り返しデッドロックまたはタイムアウトする場合、再起動によってコミット済みのはずの結果が変わった場合は停止してください。こうした兆候がある場合は、手動修復を行う前に状態とログを保存する必要があります。