Immichのデータパスとは何か、そしてそれが重要になるのはいつか？

エヴァ・ウォン

IceWhale author

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

What Is the Immich Data Path, and When Does It Matter? - Zima Store Online

Immichのデータパスは、クライアント、処理サービス、データベースレコード、メディアストレージを接続するものであり、単に写真が入っているフォルダを指すわけではありません。

ホームサーバーでは、同じアプリを使っていても、スマートフォンからのアップロードはすぐに受け付けられる一方、アップロードされた写真を開くのに時間がかかることがあります。これは、2つの操作が異なる依存関係を経由し、異なるファイルを読み取る場合があるためです。まず操作の経路を把握すると、より高速なネットワークリンク、別のMLマシン、またはディレクトリの移動によって、ある体験だけが改善され、別の体験は改善されない理由を説明できます。

アップロード経路の完了は、すべての機能の準備完了を意味しない

アップロード経路は、選択したオリジナルにアクセスできるクライアントから始まり、サーバーがアセットと関連する状態を受け入れた時点で終わります。認証、転送条件、書き込み可能なメディアストレージ、アプリケーションへの記録がすべて関与します。その後、バックグラウンド処理によって他の機能に必要な出力が作成されるため、転送の完了が処理の完了を意味するわけではありません。

スマートフォンのプライベートバックアップでは、完了カウンターの確認だけでは不十分です。代表的なオリジナル画像をサーバーから開き、期待どおりの日付と内容が表示されることを確認する必要があります。この確認により、リモートライブラリへのコピーと、モバイルデバイスが単にローカルで表示している写真とを区別できます。また、ローカルにキャッシュされた画像によって、サーバー側の処理が未完了であることが隠れるのも防げます。

この経路の時間を測定するときは、どのエンドポイントまでを測るのかを明確にしてください。アップロードが受け付けられるまでの秒数、プレビューが開くまでの秒数、意味検索が成功するまでの秒数は、それぞれ異なる結果を測定します。アップロード速度だけを示しても、家庭内のコレクション全体が閲覧可能、検索可能、または独立して保護されるまでの時間は判断できません。

バックグラウンド処理はMLエンドポイントだけを使うわけではない

受け入れ後、メディアワーカーが派生データを準備し、その他のサービスが分析結果を提供します。これらの処理はアセットとアプリケーションの状態を共有しますが、すべてが機械学習サービス内で実行されるわけではありません。サーバー所有者が、パフォーマンスを改善するために1つのコンテナだけを別のマシンへ移そうとする場合、これは重要な点です。

リモートサムネイル処理には、リモートMLエンドポイントとは異なる依存関係の構成が必要です。メンテナーによる議論では、追加のサーバーワーカーがメディアファイルシステムと関連サービスにアクセスする必要があると説明されています。この実験的な構成は、パブリックネットワークで安全に利用するための手順ではありません。ここでのアーキテクチャ上の要点は、サムネイル処理には、分離された推論リクエストよりも多くの共有状態への依存関係があるということです。

したがって、ML処理を別の場所へ移すことでローカルの推論処理は減らせても、オリジナルの読み取り、派生データの書き込み、データベースクエリまで移るとは限りません。残った段階が新たな上限になる可能性があります。完全なマップでは、オフロードを万能な高速化スイッチとして扱うのではなく、各操作をどのマシンが実行し、どの永続状態にアクセスする必要があるのかを明確にします。

検索リクエストは異なる読み取り経路をたどる

検索は、新しいオリジナル画像ではなく、ユーザーのリクエストから始まります。検索モードによっては、サーバーがメタデータ、視覚的表現、現在のアクセス範囲を評価します。一致したアセット識別子からメディアレスポンスが返されますが、その際にも到達可能なファイルが必要です。データベース検索が成功することと、写真が正常に表示されることは別の段階です。

リレーショナルクエリとベクトルクエリは、視覚的類似性だけを検索全体として扱うのではなく、互いに組み合わせて利用できます。Immichを中心としたエンジニアリング事例では、アセットレコード、メタデータ、埋め込みベクトルを組み合わせています。そこで使われている過去のデータベース拡張は、現在のインストール手順ではありませんが、類似性検索の後に無制限のファイル検索を行うのではなく、所有者などのフィルターを類似性検索と併用すべき理由を示しています。

この違いから、次のような有用な判断ができます。テキスト検索の結果は速いのに画像の表示が遅い場合、問題は後段の配信またはデコード処理にある可能性があります。反対に、結果の選択が遅く、既知のアセットはすぐに読み込める場合は、より前段に問題がある可能性があります。どちらの観察だけでも原因を証明することはできませんが、次に測定すべきデータパスの範囲を絞り込むことはできます。

Featured

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

ZimaCube2

マウント名によって、別のネットワーク経路が隠れることがある

コンテナ内のディレクトリはローカルに見えても、実際の保存先が別のホストやユーザー空間ファイルシステム経由でアクセスされている場合があります。表示されるパス名が示すのは、アプリケーションがデータにアクセスする場所であって、その背後にある物理的な遅延、整合性の挙動、障害ドメインではありません。そのため、マウントの対応関係は実際のストレージサービスと併せて解釈する必要があります。

S3QLを使用したImmichの構成では、ユーザー空間とネットワーク接続をまたぐファイルシステム操作の影響を受けやすいことが報告されています。その運用者は、この影響を抑えるためにコンピュートとオブジェクトストレージを近接させました。これは明示的にリモートストレージを使用する設計についての事例であり、Immichのすべてのインストールが標準でS3に直接保存するという意味ではありません。

通常の読み取りにホスト外の依存関係が関与すると、ローカルパスだけで説明することはできなくなります。その場合、アプリケーションコンテナが正常に動作していても、ネットワーク障害、リモートサービスの遅延、マウント障害によって処理が中断される可能性があります。プロセスのステータスが正常であっても、すべての下流のファイル操作が目的地に到達し続けるとは限りません。

ボトルネックを解釈する前に経路を描く

家庭内で行う各操作について、開始するクライアント、必要なサービス、永続状態、完了シグナルを書き出します。アップロードには受け入れられたオリジナルが必要です。タイムラインの閲覧には期待される表示用アセットが必要です。意味検索には利用可能な表現と認証済みの検索が必要です。復旧には保護されたオリジナルと対応するアプリケーション状態が必要です。これらは重なり合う経路であり、互換性のある単一の成功確認ではありません。

何を観測するかを選ぶ際には、リモートMLエンドポイントと追加のメディアワーカーの違いが特に役立ちます。提案された変更が推論だけを移動させるものであれば、推論の完了をデータベースの応答やサムネイル配信とは分けて測定してください。そうしなければ、ユーザー向けの経路では実際に改善されていない処理の高速化を、全体の改善として評価してしまう可能性があります。

マップを使って、既知のアップロード、既知のオリジナルのダウンロード、固定したクエリ、または独立した復旧確認のいずれか1つをテストとして選びます。どの接続部分で失敗または遅延が発生したかを記録し、証拠によって責任のある依存関係が特定できたら、調査を広げるのをやめます。データパスモデルの価値は、図を大きくすることではなく、範囲を正確に絞ることにあります。