ImmichのメタデータをSSDに、大容量データをHDDに保存すべき？
はい。Immichのデプロイでは、データベースとレイテンシーの影響を受けやすい生成データをSSDに置き、大容量の元の写真や動画ファイルをHDDに保存すると、特にライブラリがアプリケーションの状態データよりはるかに大きい場合に有効です。ただし、この分離が役立つのは、パス、空き容量の余裕、バックアップ、復旧手順が明確に保たれている場合に限られます。
判断基準は「メタデータは高速、メディアは低速」ではありません。Immichは複数のストレージ役割に異なる形でアクセスします。PostgreSQLは多数の小さな状態操作を処理し、サムネイルやプレビューは閲覧中に頻繁に読み込まれ、エンコード済み動画は大容量になることがあります。一方、元ファイルでは容量と耐久性が重視されます。何かを移動する前に、それぞれの役割を個別に測定してください。
頻繁に使う小規模I/Oの状態データと、容量重視のメディアを分ける
PostgreSQLのデータ、サムネイル、プレビュー、エンコード済み動画、モデルキャッシュ、アップロードした元ファイル、外部ライブラリ、バックアップコピーを一覧にします。現在のサイズ、増加量、読み書きの頻度、再構築コスト、復元後も維持する必要があるかどうかを記録してください。こうすることで、「メタデータ」フォルダーという大まかな分類に、実際には大きく異なる複数のワークロードが隠れてしまうのを防げます。
メディアのメタデータとアクティブキャッシュを配置するためのZimaSpaceストレージフレームワークでは、重要な区別が示されています。データベースとインデックスは低レイテンシーのストレージから恩恵を受けますが、アクセスパターンが同じIOPSを必要としない場合、容量重視のストレージに大量のソースメディアを置いたままでも問題ありません。現在のHDDで検索、タイムラインの閲覧、バックグラウンドジョブ中のレイテンシーが低いなら、すべての派生データをSSDに移しても、ユーザーが体感できる改善はほとんどない可能性があります。アクティブなストレージパスが実際に待ち時間の原因になっていることを、管理された比較テストで確認するまでは、現在の構成を維持してください。
PostgreSQLと頻繁に読み込まれる派生データは、待ち時間の原因ならSSDに置く
PostgreSQLやサムネイルを多用する閲覧では、多数の小さな読み書きが発生します。同じデバイスでインポートやバックアップも実行している場合、負荷の高い機械式ディスクでは特に遅く感じられることがあります。
現在のImmichの構成では、データベースをローカルの低レイテンシーストレージに置き、任意の入れ子マウントを作るのではなく、対応している生成データのパスを計画的に移動してください。
ストレージの仕組みは、Immich以外でもよく知られています。PostgreSQLのストレージチューニングでは、回転ディスクよりもランダムアクセスのコストが大幅に低いストレージが有利です。これだけでImmichの目に見える改善が保証されるわけではありませんが、測定したデバイスレイテンシーが待ち時間の原因なら、データベースとインデックスの処理がSSDの有力な候補になる理由は説明できます。
同じアルバム、検索、インポートのサンプルを移動前後で使い、改善を測定してください。データベースのレイテンシーが低下しても、ユーザーが目にするリクエストがネットワーク転送、画像のデコード、機械学習処理を待っているなら、残りの遅延をHDDのせいにするのはやめましょう。
容量と保護がランダムI/Oより重要なら、元ファイルはHDDに置く
元の写真や動画は通常、最も大きなストレージ分類に入り、小さなデータベースページとしてではなく、ファイル全体として読み込まれることが多いものです。そのため、大容量のHDDプールは、必要な信頼性、スループット、バックアップ容量を提供できる場合、元ファイルの保存先として合理的です。ただし、インポートと閲覧を同時に行う場合でも、HDD層には十分な空き容量と安定したレイテンシーが必要です。
サムネイルをメディアから分離することについてのImmichの長期的なストレージ議論にも、同じ運用上の意図が表れています。閲覧用に生成されるアセットと大量の元ファイルでは、アクセスの優先度が異なります。ただし、すべての環境で物理デバイスを2台用意する必要があることを証明するものではありません。効果は、現在リクエストがどこで待たされているかによって決まります。
安価だからという理由だけで、かけがえのない元ファイルをHDDに置き、RAIDをバックアップとして扱わないでください。家庭で目標とする保護レベルに応じて、2つ目のコピーと、ホスト外またはオフラインのコピーを保持してください。ストレージの階層化によって性能とコストは変わりますが、家族のライブラリの唯一のコピーを失った場合の影響が小さくなるわけではありません。
ストレージの役割を一度に1つだけ移動し、マウントを再起動テストする
パスを移動する前に、データベース整合性のあるバックアップを取得し、現在のホストとコンテナ間のマウント対応を記録してください。1つの役割だけを移動し、スタックを起動して、既存と新規のアセットを確認します。検索を実行し、動画を再生し、使い捨てファイルをアップロードして、新しい書き込みが意図したデバイスに行われることを確認してください。データベース、サムネイル、元ファイル、バックアップ先を1回の変更でまとめて移動しないでください。
コンテナを再作成するだけでなく、ホストを再起動してください。正常な分離構成では、Immichが書き込みを行う前にSSDとHDDの両方のマウントが利用可能になり、ユーザーと関連付けが維持され、サンプルの元ファイルを読み込め、両方の階層で空き容量の監視が継続されます。想定されたマウントポイントに空の置き換えディレクトリが現れた場合は、作業を中止してください。測定したボトルネックが改善し、復旧方法も理解しやすいままなら、分離構成を維持します。古いパス、欠落したアセット、権限のずれ、片方の階層しか保護しないバックアップ処理が発生した場合は、ロールバックしてください。最良のストレージ設計とは、正しく復元できる範囲で最も高速な設計です。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
