家族の写真バックアップに Immich が必要とするサムネイルおよび機械学習用ストレージ容量はどのくらいですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Much Thumbnail and ML Storage Does Immich Need for Family Photo Backup? - Zima Store Online

Immichにはサムネイルのみの信頼できるストレージ比率がないため、ファミリーライブラリではアセットあたりの生成バイト数を測定し、MLモデル用に別の容量を確保する必要があります。

2 TBの家族写真アーカイブだけでは、Immichのサムネイルディレクトリがどれほど大きくなるかは分かりません。アセット数、元データの解像度、サムネイル設定、動画の割合、有効にしているモデルによって、生成される容量が変わるためです。より安全な容量見積もり方法は、代表的なサンプルを処理し、サムネイルとモデルキャッシュを別々に測定し、ライブラリの増加を予測したうえで、1つの割合を普遍的な要件とみなすのではなく、運用上の余裕を追加することです。

オリジナルとImmichが生成するストレージを分ける

まず、容量の境界を明確にしましょう。元の写真や動画は、Immichライブラリを支えるディスク容量の一部にすぎません。サーバーには、閲覧や互換性のために使用する生成アセットも保存され、機械学習サービスはダウンロードしたモデルファイルを独自のキャッシュに保存します。これらの容量は異なる要因で増加するため、すべてを曖昧な1つの割合にまとめると、どの設定やワークロードが実際に容量を消費しているのか分かりにくくなります。

長期運用されているImmichコミュニティの容量目安では、サムネイルとトランスコード済み動画を合わせると、平均でおよそ10～20%が追加される可能性があるとされています。ただし、この数値はあくまで大まかな参考にすぎません。2つの生成カテゴリを合算したものなので、サムネイルのみの比率として示してはいけません。動画が少ない写真中心の家族ライブラリは、動画中心のアーカイブとは大きく異なる場合があります。

追加容量をどこに配置するかを決める際には、アーキテクチャも重要です。ZimaSpaceのAIによる写真整理に関する記事では、インデックスや生成データを元のライブラリを置き換えるものではなく、その周辺で動作するサービスとして扱っています。容量計画では、同じ物理ディスクを共有する場合でも、オリジナル、サムネイル／プレビュー領域、動画派生データ、データベース、MLキャッシュを別々の項目として管理しましょう。

拡張する前にアセットあたりのサムネイル容量を測定する

最も扱いやすい1,000ファイルではなく、家族ライブラリを代表するサンプルを選びます。普段の利用状況を反映するため、スマートフォンの世代ごとのデータ、カメラの解像度、ポートレート、スクリーンショット、パノラマなど、さまざまな画像タイプを含めてください。サムネイル関連のジョブが完了するまで待ち、処理済みアセット数を記録して、サムネイルディレクトリの容量を測定します。測定したバイト数を処理済みアセット数で割れば、選択したサムネイルやプレビュー設定をすでに反映した、環境固有の計画比率を得られます。

実際の導入例を見ると、この環境固有の比率が重要である理由が分かります。あるImmichのディスカッションでは、特定のシステムでサムネイルが21 GB、エンコード済み動画が58 GBあると報告されています。この数値は個別事例であり、目標値ではありません。しかし、生成フォルダーごとに容量が大きく異なる可能性があること、そして元のライブラリが何TBあるかだけから推測せず、個別に測定すべきことを示しています。

たとえば、代表的な画像10,000枚からサムネイルとプレビューが12 GB生成された場合、観測された速度はアセット1件あたり約1.2 MBです。同じ設定で6万枚の画像ライブラリを想定すると、増加分を含める前の見積もりは約72 GBになります。サムネイルの解像度や品質を変更した場合は、元のファイルが変わっていなくても、以前のアセットあたりの比率は無効になるため、サンプルを再度実行してください。

MLモデルキャッシュは写真数よりモデルに左右される

機械学習用ストレージは、サムネイルとは異なる動きをします。モデルキャッシュには主に、MLサービスがダウンロードして再利用するモデルファイルが保存されるため、その容量はライブラリに写真が2万枚あるか20万枚あるかよりも、スマート検索や顔認識でどのモデルを選択するかに大きく左右されます。ライブラリのサイズによって処理量は変わりますが、アセットごとにモデルのバイナリが新たにコピーされるわけではありません。

最近のセルフホスト型Immichの導入例では、機械学習サービス用に永続化されたモデルキャッシュをマウントしており、そこで使用されたモデルの合計容量は1 GB未満だったと報告されています。これは1つの構成における結果であり、保証ではありません。重要なのは、選択したファイルが一度保存されれば、その後は永続化されて再利用されるという仕組みです。通常、写真数が増えてもモデルのバイナリが同じ割合で増えることはありません。

将来的にモデルを変更する可能性があるファミリーサーバーでは、現在観測されている最小のキャッシュ容量よりも大きめに見積もるのが適切です。Immichのメンテナーは、モデルの選択によって異なるものの、一般的には10 GB程度のストレージで十分だと述べています。これを必須容量ではなく、保守的な初期目安として扱い、最初のMLジョブが完了した後に、実際に稼働している構成のキャッシュサイズへ置き換えてください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

動画の割合とクライアントキャッシュは写真だけの見積もりを崩す可能性がある

ライブラリに大量の動画が含まれている場合や、端末上のアプリストレージを確認している場合、サムネイルとMLの見積もりだけでは総容量を適切に表せなくなります。動画の互換性処理によってサーバー側に大容量の派生データが生成されることがある一方、スマートフォンやブラウザーのキャッシュは、サーバーのサムネイルディレクトリやMLモデルキャッシュには含まれないクライアント側の容量を占有します。これらの数値を混同すると、通常のサムネイル見積もりが大きく外れているように見えてしまいます。

大規模ライブラリのユーザー報告が、この境界を示しています。約2.4 TBのライブラリに写真17万9,000枚、動画1万9,000本があるケースでは、サムネイルとトランスコード済み動画を合わせたサーバー側の派生データが822 GBに達し、Androidアプリも端末上で数十GBを使用していたと報告されています。これは個別事例であり、容量計画のルールではありません。しかし、動画とクライアントキャッシュによって、単純な写真のみのモデルが大きく変わる可能性を示しています。

測定時には、サーバーのサムネイル／プレビューデータ、エンコード済み動画、MLモデルキャッシュ、データベース、クライアント側のローカルキャッシュを分けて管理してください。サムネイル容量が予想外に大きい場合は、Immichのデータツリー全体ではなく、サムネイルディレクトリ自体を調べます。エンコード済み動画が最大のフォルダーであれば、計画すべき問題は写真のインデックス処理によるオーバーヘッドではなく、動画の互換性とトランスコードポリシーに変わっています。

サンプルと増加量の計算式で家族向けストレージを見積もる

使用する入力値は3つです。代表的なアセットあたりの測定済みサムネイル容量、今後1～2年間の予想画像数、測定済みのMLモデルキャッシュ容量です。最初の2つを掛け合わせ、モデルキャッシュを加算し、再生成、設定変更、通常のファイルシステム増加に備えた運用上の余裕を追加します。ここでの20～25%という余裕は計画上の目安であり、Immichの必須要件ではありません。容量に余裕がないユーザーは、余裕が常に十分だと考えるのではなく、より頻繁に測定してください。

保守的なモデルキャッシュの上限は、モデルの選択によって異なるものの、一般的には約10 GBあれば十分というメンテナーの案内を基準にできます。この値は、10～20%というサムネイルとトランスコードの合計比率ではなく、自分で測定したサムネイル容量と組み合わせてください。予測されるサムネイル容量が72 GB、モデル用の割り当てが10 GB、余裕が25%の場合、計画上確保すべき容量は約103 GBです。

見積もりを左右する変数が変わったら、再計算してください。たとえば、サムネイルの解像度や品質、カメラ解像度の大幅な変化、異なるMLモデルへの変更、動画の大幅な増加、家族がアセットをアップロードする人数の大幅な増加などです。判断基準は単純です。予測される生成ストレージと余裕の合計が、想定している高速ボリュームの空き容量に近づいたら、そこに達する前に派生データの保存先を移動するか、容量を追加するか、関連する生成設定を下げてください。