データベースの配置はImmichの信頼性にどのような影響を与えるか？
Immichのデータベース配置は、レイテンシ、ファイルシステムの挙動、マウントの可用性によって、重要な書き込みを適時かつ確実に保持できるかどうかが決まるため、信頼性に影響します。
ホームサーバーでは、オリジナル画像をNASに安全に保存できても、稼働中のデータベースまで同じネットワークマウント上に置くと不安定になることがあります。重要なのは、単純にSSDかHDDかではありません。データベース操作が予測可能なローカルセマンティクスを受けられるか、そして稼働中の障害ドメインの外に復旧用コピーが存在するかどうかです。
データベースが保持するのはキャッシュだけではなく、正規の関連情報
Immichは、ユーザー、所有権、アルバム、アセット情報、メタデータ、処理結果を関連付けるためにデータベースを使用します。これらの関連情報は、ディスク上の画像ファイルを見つけるだけでは再構築できません。そのため、配置に問題が起きるとオリジナル写真が残っていても、コレクションを使いやすくしている構造をアプリケーションが失う可能性があります。
ZimaSpaceのImmichバックアップ記事では、オリジナルとデータベースが復旧に不可欠な組み合わせだと説明しています。この違いから、データベースの配置はサムネイル保存より厳格に扱う必要があります。データベースの消失や不整合は、メディアファイルが残っていても、識別情報、アクセス権、ライブラリ構成を変えてしまうためです。
配置を決める際は、まずデータの種類を分類します。オリジナルとデータベースには独立した保護が必要ですが、サムネイルやエンコード済みコピーは時間をかければ再生成できます。すべてのディレクトリを1つの大容量ボリュームに置くとパス管理は簡単になりますが、重要なデータと派生データが同じ障害にさらされることにもなります。
レイテンシのばらつきは、通常の書き込みをサービス不安定化につなげる
データベースは、多数の小さな同期処理やランダム処理を実行します。重要なのは、大きなファイルを一度転送した結果よりも、それらの処理が完了するまでの時間です。レイテンシが変動すると、トランザクションの待ち時間が長くなり、ワーカーキューが蓄積し、状態変更の処理待ちによって通常のリクエストがブロックされることがあります。マウントが技術的には接続されたままでも、運用上信頼できないタイミングになる場合があります。
TrueNASコミュニティで紹介された構成では、ImmichのPostgreSQLデータをSSDに置き、大容量のライブラリとエンコード済み動画のパスをHDDストレージに移しています。この例の価値は、アクセスパターンを分離している点にあります。容量を大量に消費するオリジナルと、レイテンシに敏感なアプリケーション状態を、1つの物理配置で共有する必要はありません。
インポート、検索、バックアップを同時に実行しながら、デバイスのレイテンシとデータベースの応答を測定してください。高いシーケンシャル帯域幅があっても、トランザクション処理が安定しているとは限りません。レイテンシの急上昇がジョブの停止やクライアントエラーと一致する場合は、共有キューを減らすか、稼働中のデータベースをより予測可能にローカルで処理できるパスへ移してください。
ネットワーク配置は、マウントとパスに関する障害ドメインを追加する
リモートストレージ上のデータベースでは、各I/Oが完了するまでに、ホストのファイルシステムクライアント、ネットワークインターフェース、スイッチング経路、ストレージサーバー、エクスポート状態に依存します。どの層もローカルファイルシステムとは異なる形で停止したり再接続したりする可能性があります。保存先のディスクが冗長化されていても、その間にある依存関係がなくなるわけではありません。
詳細なImmich Composeの分析記事では、データベースをネットワーク共有に置かないよう警告し、メディアライブラリの保存先とは分けて考えています。この記事は現在のデプロイ要件を踏まえたものですが、長期的に有効な設計上の要点は、稼働中のデータベースに求められるセマンティクスと、大容量の写真を保存する要件が異なるということです。
この境界は逆方向にも当てはまります。ローカル配置だからといって、自動的に信頼できるわけではありません。電源保護、ファイルシステム監視、バックアップのない単一のコンシューマー向けSSDは、突然故障する可能性があります。ローカル配置によって稼働経路からネットワークマウントの挙動は排除できますが、世代管理された復旧機能が得られるわけでも、ホスト全体の損失から保護されるわけでもありません。
障害ドメインのテストで配置を検証する
テスト用のユーザー、アルバム、アップロード、既知の検索条件を含む、使い捨てのライブラリを作成します。代表的なインポートを実行し、ストレージシステムが通常のバックアップ処理を行っている間に、データベースのレイテンシを測定してください。平均スループットだけに頼らず、アプリケーションエラー、キューの進行状況、デバイスの待ち時間、最も遅いインタラクティブリクエストを記録します。
HDDとSSDの配置に関するコミュニティの議論では、稼働中のデータベースや生成データと、大容量のライブラリファイルが繰り返し区別されています。コメントは経験に基づく報告であり、普遍的なベンチマークではありませんが、データベースが実際に生成するI/Oの種類をテストする必要性を示しています。
次に、実際の配置で起こり得る障害を使い捨ての環境で再現します。リモートマウントを切断するか、ローカルのデータベースボリュームを停止してください。独立したコピーから復元し、ユーザー、アルバムの所属、オリジナルへのアクセス、検索状態を確認します。通常運用と復旧の両方が設定した目標を満たした場合にのみ、その配置は合格です。
おすすめ商品
テック＆AIハブ
もっと読む
アップグレード後にImmichが既存のデータを再処理するのはなぜですか？
アップグレードによって以前の派生データ、メタデータ、モデル、またはジョブの状態が無効になると、Immich はアセットを再処理する場合があります。処理が繰り返し終わらない場合は、別の障害です。
Immichの実際のパフォーマンス上限を最も頻繁に決める依存要因とは？
Immichは、測定対象となる各経路上で最も遅い依存関係によって上限が決まるため、アップロード、検索、ブラウジング、再生ではそれぞれ異なる上限が生じる場合があります。
Immichのネットワーク：ディスカバリー、DNS、ルーティングによって到達性が実現される仕組み
Immichにアクセスできるのは、エンドポイントの選択、DNS、ルーティング、NATまたはプロキシ処理、TLS、アプリケーションの応答が一つの有効な経路を形成している場合だけです。
