ストレージのレイテンシーがImmichの家族写真バックアップをどう変えるか

エヴァ・ウォン

IceWhale author

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

How Storage Latency Changes Immich Family Photo Backup - Zima Store Online

ストレージのレイテンシーは、必要な読み取りや書き込みが待たされることでImmichを遅くします。特に、共有デバイス上でインポートがデータベース処理やブラウジングと競合している場合に顕著です。

2台のスマートフォンが週末旅行の写真をバックアップしている一方で、別の家族が同じNAS上にある古いアルバムをスクロールしているとします。大容量ファイルは十分な速度でコピーされていても、サムネイルの表示が不均一になり、一部のリクエストが一時停止することがあります。重要なのは、ドライブが高いシーケンシャル転送速度を達成できるかではなく、該当する処理でストレージ待ちが発生しているかどうかです。

高速な転送と低速な小規模読み取りは両立する

スループットは一定時間内に移動できるバイト数を表し、レイテンシーは処理が完了するまでにどれだけ待つかを表します。ディスクは大きなシーケンシャルデータを効率よく処理できても、分散した小規模な読み取りには時間がかかる場合があります。Immichのブラウジングやアプリケーションの状態は、常に1つの連続したファイルコピーのような動作をするわけではないため、この2つの状況は両立します。

ホストのパフォーマンス分析では、単一の使用率だけでなく、スループットと併せてデバイスの待ち時間やキューの挙動を調べます。リクエストレイテンシー、キューの深さ、CPUの待機時間、アプリケーションの処理時間などの測定値は、組み合わせて見ると有用です。ただし、その解釈はストレージスタックに依存します。特に、報告されるボリュームの下に仮想化、キャッシュ、複数のデバイスが存在する場合は注意が必要です。

単純化した例として、互いに依存する20個の処理にそれぞれ5ミリ秒かかると、ほかの作業を考慮する前に合計100ミリ秒を消費します。1処理あたり0.5ミリ秒なら、合計は10ミリ秒です。実際のリクエストは並行して処理されたり、キャッシュを利用したりするため、これは待ち時間の蓄積を説明する例であり、Immichの応答時間を測定して予測するものではありません。

データの役割によってストレージへの到達方法は異なる

元のアップロードではメディアのバイトデータが追加され、バックグラウンド処理では入力が読み取られて派生データが書き込まれます。ブラウジングでは表示用アセットが取得され、データベースではアプリケーションのレコードやクエリが処理されます。同じ物理プールですべてを処理できますが、リクエストサイズやアクセスパターンはそれぞれ異なります。そのため、ストレージを変更しても、ある段階には大きな効果があり、別の段階にはほとんど効果がないことがあります。

実際のImmich構築例では、メディアとサムネイルをハードディスクに残しつつ、PostgreSQLをSSDに配置していました。この記録された混在構成は、ストレージの役割を分離できることを示していますが、その配置が最適であることや、SSDによる高速化の規模を証明するものではありません。このような例は、ハードウェア構成から一般化する前に、観察している現象がどの役割に関係するのかを特定するために利用してください。

家族でのバックアップでは、受け付けられた元データと、完全に準備されたプレビューや検索可能なレコードを区別してください。元データの書き込みが速くなっても、推論処理のボトルネックは解消されません。また、データベースが高速でも、キャッシュされていない画像の読み取りが速いとは限りません。重要なのは、必要なすべての段階を含めて測定した、家庭内で実際に行う操作の完了時間です。

インポートによって共有ストレージは待ち行列になる

インポート中は、バックグラウンドの書き込みと対話的な読み取りが同じデバイスキューに入ることがあります。同時実行するジョブを増やすと、全体のスループットが向上していても、待機する処理量が増える場合があります。目に見える影響は、長時間かかるリクエストが時折発生する形で現れることが多く、ほとんどのタイムラインのタイルが通常どおり読み込まれていると、平均値ではその影響が隠れてしまいます。

サムネイルストレージの分離を求める声は、生成されたブラウジング用アセットには高速ストレージを使い、元データには大容量ストレージを使いたいという意図から明確に出ています。これはアクセス優先度が異なることを示す証拠であり、すべての環境で別々のドライブが必要だという普遍的な主張ではありません。実際の効果は、現在どこでリクエストが待機しているか、そして提案したストレージ階層によってその待ち時間が変わるかどうかに左右されます。

デバイスのレイテンシーが安定しているのにクライアントがデコード中に停止したり、ネットワークが転送を再試行したり、推論処理が飽和したりしている場合、この仕組みでは速度低下を説明できません。その場合、CPU使用率が低いという理由だけでデータを移動しても、原因を見誤る可能性があります。共有ストレージは考えられる依存要因の1つであり、インポート中に発生するすべての停止の自動的な判定材料ではありません。

Featured

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

ZimaCube2

ディスク待ち時間を家族の操作と相関させる

同じアルバムを開く、決められたサンプルをアップロードするなど、再現可能な家族の操作を1つ選びます。ホストがアイドル状態のときと、代表的なインポート中に、その所要時間を記録し、デバイスのレイテンシー、キューの挙動、データベースの処理時間、エラーも併せて測定します。比較結果を明確にするため、アカウント、ネットワーク経路、メディア設定、クライアントは変更しないでください。

同じクリティカルパスの区別は、共有ホームサーバーのストレージ分析にも見られます。バックグラウンドの永続化処理があるからといって、目に見えるすべての操作がディスクへの書き込みを待つとは限りません。このアプリケーション横断の原則は観察結果を整理するのに役立ちますが、Home Assistantの測定結果はImmichのベンチマークではありません。写真のワークフローで、ストレージ待ちとユーザーが感じる遅延とのつながりを独自に示す必要があります。

ストレージの待ち時間が遅延した段階と一貫して一致し、管理された別の条件を変更したときに両方が変化するなら、ストレージを有力な説明として扱えます。最初のキャッシュされていない読み取りだけが遅い場合は、継続的な競合とは分けて記録してください。特定できた依存関係のところで止めましょう。この仕組みの分析に、本番環境の写真ライブラリへ破壊的な負荷テストを行う必要はありません。