Immichの機械学習インデックス作成で家族写真のバックアップワークフローはどう変わるか

エヴァ・ウォン

IceWhale author

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

How Immich Machine-Learning Indexing Changes a Family Photo Backup Workflow - Zima Store Online

機械学習によるインデックス作成により、Immichの家族向け写真バックアップは、単一の転送タスクから、アップロード、処理、検索、検証という個別のマイルストーンを持つ段階的なワークフローへと変わります。

ホームサーバーがまだサムネイルを生成し、メタデータを抽出し、画像の視覚表現を生成して検索状態を更新している間に、スマートフォンは週末のアルバムの送信を完了できます。家族にとって、この違いは「完了」の意味を変えます。写真はすでに安全に保存されていても、自然言語検索や人物ビューで完全に見つけられる状態になっているとは限りません。

アップロード完了は最初の準備完了状態にすぎない

最初の状態は、永続的な到着です。サーバーが元のアセットを受け入れ、それを認識するのに十分なアプリケーション状態を記録した状態を指します。これはバックアップにとって重要ですが、後続機能の準備が整ったことを証明するものではありません。すべての派生データや機械学習の結果が生成される前でも、アセットはタイムラインに表示されることがあります。

ローカル視覚インデックスについての実用的な解説は、意味検索に別個のインデックス作成処理が必要な理由を示しています。画像は、後から入力されるテキストクエリと比較できる再利用可能な表現に変換されるため、検索のマイルストーンは自然に転送のマイルストーンより後になります。

ワークフローを計画する際は、アップロード完了と検索準備完了を別々に記録してください。数分後に新しい意味検索でアセットが見つからないというだけで、バックアップジョブを失敗扱いにするべきではありません。また、検索に成功したからといって、元のデータに独立した復旧用コピーがある証拠とみなすべきでもありません。

機械学習によって再利用可能な分析段階が加わる

Immichでは、写真が追加されるたびに家族のアーカイブ全体で汎用モデルを再トレーニングする必要はありません。その代わり、対象となる画像を設定済みのモデルで処理し、生成された表現を対応するアセットに関連付けます。これにより、負荷の大きい初回処理が再利用可能な検索状態へと変わります。

このImmichのアーキテクチャ解説で説明されている分離は有用です。アプリケーションサーバー、機械学習サービス、データベース、キューに入った処理を区別しているためです。したがって検索は、1つの一体化した写真スキャン処理ではなく、複数のコンポーネント間の連携に依存します。

これにより、家庭での通常の利用ペースも変わります。過去の写真を大量に移行すると、初回の分析待ちが大きく発生します。一方、普段のスマートフォンからのアップロードでは、通常、追加される処理対象ははるかに少量です。そのため、容量計画では一度きりの追いつき処理の期間と、家族が継続的に利用する状態を分けて考える必要があります。

インデックス作成は他のバックグラウンド処理と競合する

新しいアセットが追加されると、プレビューの作成、メタデータ処理、動画処理、検索インデックス作成、顔関連の処理など、複数種類の後続処理が発生することがあります。これらのジョブはリソースコストが同じではありません。並列度を上げると全体の処理速度が向上する一方で、CPU、メモリ、ストレージ、データベースをめぐる競合が増える可能性もあります。

ジョブの並列度についての長い議論は、この運用上の問題を示しています。独立したジョブ種別が重なって実行され、小規模なホストに全体として負荷をかけることがあるのです。重要なのは、どの環境にも当てはまる1つの並列度ではありません。バックグラウンド処理の完了とインタラクティブな応答性が、限られたリソースを共有しているという点です。

家族の写真を初めて取り込む際は、キューを最大速度で消化することよりも、観測可能なサービス目標を優先してください。過去のアルバムを問題なく検索でき、新しいアセットの処理も進んでいるなら、大きなキューが残っていても許容できます。タイムラインの閲覧や既知の検索が大幅に遅くなるなら、バックグラウンド処理がインタラクティブ処理の余力を使いすぎています。

Featured

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

ZimaCube2

検索できることは完全に保護されていることを意味しない

機械学習機能が向上させるのは、データの耐久性ではなく発見性です。埋め込み、人物グループ、サムネイル、データベースの記録によってライブラリははるかに使いやすくなりますが、元のメディアや、アカウント、アルバムなどのアプリケーション状態を再構築するために必要な復旧情報の代わりにはなりません。

ZimaSpaceによるAIによる写真整理の解説でも、同じ区別が示されています。認識と検索は、ストレージおよびバックアップのワークフローの上に成り立つ機能です。これらの層は相互補完的なものとして扱い、印象的な検索結果を家庭におけるバックアップの健全性の定義にしてしまわないようにしてください。

元のデータ自体が失われている、読み取れない、または想定したバックアップ経路から復旧できない場合、仕組みを説明しても問題の本質には届きません。その場合、インデックスの状態は二次的な問題です。同様に、正常なインデックスがあるにもかかわらず意味検索で見つからない場合、それはファイルが存在しない証拠ではなく、関連性の限界である可能性があります。

5つのマイルストーンによる受け入れテストを行う

一般的な写真、短い動画、既知の人物数名、簡単に検索できる視覚的な概念をいくつか含む、小規模な基準グループを用意してください。各項目について、サーバーに受け入れられた時点、プレビューが開く時点、メタデータが表示される時点、期待した検索結果または人物結果が表示される時点、独立したバックアップまたは復元セットにアセットが存在する時点という、5つのタイムスタンプまたは状態を記録します。

数テラバイト規模のライブラリを含む家庭の移行事例は、ストレージの配置、データベースの配置、インデックス作成にかかる時間、リモートアクセスが、それぞれ別の運用上の判断であることを思い出させてくれます。ワークフロー全体を1本の進捗バーにまとめるのではなく、測定においてもその分離を維持してください。

元のデータが安定して到着し、到着が落ち着いた後に処理キューが消化され、代表的な検索で期待したアセットが返され、復旧用コピーを独立して検証できるなら、そのワークフローを受け入れてよいでしょう。1つのマイルストーンだけが繰り返し遅れる場合は、スタック全体を変更する前に、その段階を担当するコンポーネントだけを調査してください。