大規模なモバイルインポート中でも、Immichの写真検索は使いやすい状態を保てますか？

エヴァ・ウォン

IceWhale author

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

Can Immich Keep Photo Search Usable During Large Mobile Imports? - Zima Store Online

はい、共有リソースに余裕がある場合、Immichはインポート中も既存の写真検索を利用可能な状態に保てます。ただし、新しくアップロードした写真が検索可能になるまで時間がかかることがあります。

ある家庭で、誰かが古い誕生日アルバムを検索している間に、何年分ものスマートフォン写真をインポートするとします。既知のアルバムをすぐに返すことと、今この瞬間にアップロードされたすべての写真を見つけられることは、別の約束です。バックグラウンド処理が遅れても既存の検索をオフラインにせずに済む一方、リソース競合によって、すでにインデックス化された検索結果まで遅くなる可能性があるため、両者は分けて評価してください。

既存の検索と新しい写真への対応範囲は別の約束

すでにインデックス化されたアセットには、対応する検索経路に必要な情報がそろっています。一方、新しく受け付けたアップロードには、メタデータの抽出、表示用データの準備、関連するインデックス作成ジョブがまだ必要な場合があります。したがって、アップロードが成功したからといって、意味検索がすぐに利用可能になることや、そのアセットに対するすべての検索機能の処理が完了していることが保証されるわけではありません。

実際の大規模ライブラリに関する報告では、小型ボードと高性能なマシンでインポート体験が大きく異なり、処理中も利用可能な状態を保てた環境も報告されています。これらは最低RAM容量の基準を示すものではなく、環境によるばらつきを示しています。写真の枚数だけでなく、メディアの種類、有効化したジョブ、同時実行中のサービス、許容できる待ち時間も重要です。

既知の検索が家庭で許容できる範囲内の時間で期待どおりの結果を返し、新しいアセットの処理も進み続けているなら、条件付きで答えは「はい」です。古い検索が機能していてもインデックス作成が進まなくなれば、新しさの面では「いいえ」になります。逆に、キューが増えているだけでは、対話的なサービスが利用不能になった証拠にはなりません。

インポート作業の増加は対話的処理の余力を消費する

アップロード、派生データの生成、データベース操作、推論は、重複するリソースを消費します。バックグラウンドの同時実行数を増やすと、共有依存先が飽和するまでは1分あたりの完了ジョブ数が増えますが、その限界を超えると、待ち時間が増えて対話的なリクエストに悪影響を与えることがあります。そのため、同じホスト上で取り込み速度が上がる一方、検索体験が遅くなることもあります。

バージョン固有のインポーターに関する報告では、immich-go 0.28.0とImmich 2.3.1において、ジョブの一時停止機能が稼働中のすべてのキューを対象にしていなかったと説明されています。報告者は、これが観測された接続エラーの原因だとは立証していません。この報告から得られる教訓は限定的です。つまり、機能のラベルだけでは、すべてのバックグラウンド処理が実際に停止している証拠にはなりません。

家族が利用する時間帯にバックグラウンド処理を減らすと、完了までの時間と引き換えに、対話的処理の余力を確保できる可能性がありますが、容量そのものが増えるわけではありません。サポートされている変更を行った後、稼働中のキューとユーザーが目にする処理時間を確認してください。キューがアイドル状態なのに検索が遅い場合は、すべての遅延をインポートの同時実行数のせいにせず、残っている検索経路を調査してください。

MLアクセラレーションですべての依存関係を保護できるわけではない

推論をアクセラレーターや別のホストに移すと、1つのサービス境界が変わります。しかし、PostgreSQL、元メディアの読み込み、サムネイル生成、クライアント側の描画まで自動的に高速化されるわけではありません。高速な機械学習処理と、混雑したデータベースやストレージプールは共存し得ます。また、リモートサービスには独自のネットワークおよび可用性の依存関係が生じます。

Immich 2.2.0に関するOCRリソース報告では、特定のモデルと環境において、顔認識やスマート検索の処理は速い一方、OCRの動作ははるかに重かったと説明されています。これは過去の事例であり、現在も普遍的に存在する不具合ではありません。1つのMLジョブの速度やメモリ需要を、すべての有効なジョブの代表とみなせない理由を示す例です。

必要なサービスがメモリ不足で再起動する、クエリがタイムアウトする、ストレージの書き込み可能な空き容量がなくなる、必要なネットワーク経路に到達できなくなる、といった場合は、可用性に関する主張は成り立ちません。推論だけを高速化しても、これらの境界は解決できません。また、プライバシーについても分けて考えてください。ローカル処理であっても、広すぎるアカウント権限、外部に公開されたエンドポイント、不適切なバックアップ運用を補うことはできません。

Featured

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

ZimaCube2

家庭にとっての「利用可能」の意味を定義する

古い写真を対象に、結果が分かっている検索を少数選び、認識しやすい被写体を含む新しいインポート用サンプルを用意してください。検索完了までの時間、エラー、サンプルが意図した機能で検索可能になるまでの遅延を記録します。アカウント、クライアント、ネットワーク経路を変えずに、静かな時間帯と通常のインポート中の両方で繰り返し測定してください。

セルフホスティングでは、サービスの可用性、アクセス、バックアップの判断など、家庭内の運用責任がサーバー所有者に移ります。検索を利用可能と判断する際には、この違いが重要です。たまにインデックス作成が遅れることは許容できても、毎晩のインポート中にアクセスできなくなることは許容できない場合があります。クラウドとの比較は、その責任の違いを示すものであり、Immichの性能を保証するものではありません。

既存の検索の待ち時間と、新しい写真が利用可能になるまでの時間について、それぞれ別の許容範囲を設定してください。そのうえで、アップロードが止まった後にバックログが解消されるかを確認します。両方を満たしていても、それはテストした負荷のもとで継続利用できることを示すにすぎません。どちらか一方でも満たさない場合、次に判断すべきなのは、すべての大規模ライブラリに同じハードウェアが必要だと決めつけることではなく、どの依存関係またはスケジュールの重複が許容範囲を超えたのかという点です。