大規模なモバイルライブラリのインポート時、ネットワーク遅延はImmichにどのような影響を与えるか？

エヴァ・ウォン

IceWhale author

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

How Does Network Latency Affect Immich During Large Mobile-Library Imports? - Zima Store Online

ネットワーク遅延は、大量のImmichモバイルインポートにおいて、途切れのない一括転送よりも、多数のラウンドトリップ、再試行、リモートサービスの経由を必要とするワークフローで大きく影響します。

各リクエストが長いラウンドトリップを待つ場合、高帯域幅のリンクでも遅く感じることがあります。一方、低遅延のLANでは、理論上の帯域幅が低くても制御処理をすばやく完了できます。ただし、アセットが受け付けられた後は、サムネイル生成、メタデータ処理、ローカルインデックス作成をスマートフォンがクリティカルパス上にない状態で継続できるため、アップロード遅延と処理遅延は分けて測定する必要があります。

遅延とスループットはインポートの異なる部分を制限する

スループットは、転送が継続的にビジーな状態で、大容量の写真や動画のペイロードがリンクを通過する速度を決めます。遅延は、リクエストとレスポンスのやり取り、認証、接続確立、再試行が完了するまでの速さを決めます。インポートの体感は、どちらか一方の指標だけでなく、これらの処理がどのように組み合わさるかによって決まります。

Tailscaleの経路選択とリレーに関する解説は、Immichサーバー自体を変更しなくてもネットワーク経路によって遅延が加わる理由を示しています。直接経路とリレー経路は同じエンドポイントに到達できますが、ラウンドトリップとスループットの特性は異なる場合があります。

つまり、多数の小さなファイルで構成されたアップロードは、合計サイズが同じ1本の大容量動画よりも、ラウンドトリップのオーバーヘッドの影響を受けやすいということです。テストが実際のモバイルインポートのリクエストパターンと方向に似ていない限り、単一の速度テスト結果で完了時間を予測しないでください。

再試行は長いラウンドトリップのコストを増幅する

無線通信の損失、モバイルネットワークの切り替え、VPN経路の変更、過負荷状態の上りリンクによって、リクエストやセグメントの再試行が必要になることがあります。低遅延の経路では復旧がほとんど気にならない場合でも、高遅延の経路では再試行のたびに待機時間が加わり、進行が断続的に見えることがあります。

遅いリモートImmichアクセスに関する実例は、コメント欄でリレー経路の疑いとエンドポイント設定の問題が切り分けられているため、診断例として役立ちます。教訓は、単純に帯域幅を原因と決めつける前に、転送経路とアプリケーションのリクエスト動作の両方を確認することです。

サーバーが安定した速度でアセットを受信している一方、転送停止後もバックグラウンドキューの処理が遅い場合、ネットワークによる説明力は弱くなります。その時点では、スマートフォンとサーバー間の遅延ではなく、CPU、ストレージ、データベース、機械学習処理が準備完了までの時間を左右しています。

リモート機械学習は別のネットワークエッジを追加する

機械学習の推論を別のホストで実行すると、インデックス作成にサーバーから機械学習ホストへのネットワークホップが加わります。この経路はモバイルアップロード経路と共有されない場合があります。そのため、推論サービスがリモートにある、または断続的にしか到達できない家庭環境では、スマートフォンからのアップロードは速いのに、セマンティック検索の完了が遅いという状況が起こり得ます。

リモート機械学習の例では、プライベートネットワーク経由で別のマシンにImmich MLを配置できることが示されています。この構成では、ローカルCPUの負荷を減らせる一方、サービス間のネットワーク到達性とラウンドトリップ時間への依存が生じます。

このケースは、通常のリモート閲覧とは分けて考えてください。機械学習ホストがImmichサーバーと同じLAN上にある場合、スマートフォンからインターネットまでの遅延は、その推論処理には関係ありません。トンネルやWANの先にある場合は、そのサービス経路を個別に測定してください。

Featured

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

ZimaCube2

インポートのトラフィックは対話的なリモート利用と競合する

大容量のアップロードが消費するのは、スマートフォンがホームサーバーに対してどこにあるかによって、上り容量の場合も下り容量の場合もあります。同じ制約のあるWANリンクで、タイムライン画像、APIレスポンス、バックアップ、その他の家庭内トラフィックも処理していると、ルーターやISP側のキューイングによって、小さな対話的リクエストの遅延が増加することがあります。

ZimaSpaceによるImmichにおけるストレージ遅延の分析は、同じ因果関係を検証するための参考になります。共有リソースの競合が影響するのは、そのリソースの待ち時間の増加が、遅延しているユーザー操作と重なる場合だけです。すべてのインポートがネットワークを飽和させると決めつけず、ネットワークにも同じ考え方を適用してください。

WANの利用率が控えめで、ラウンドトリップ時間も安定している一方、サーバー側でリクエストやストレージの遅延が増加している場合、この仕組みでは遅延を説明できません。ネットワークとサーバーの競合は同時に起こる可能性があるため、制御したワークロードで最初に変化する遅延を特定してください。

インポートを4つのタイムラインに分けてテストする

多数の小さな写真と、複数の大容量動画を含む固定バッチを用意します。4つのタイムライン、つまりクライアントからサーバーへの転送、サーバーによる受け付け、バックグラウンド処理、最終的な検索準備完了を記録してください。同時に、ラウンドトリップ遅延、実効転送速度、再送や再試行の兆候、関連するサーバーリソースの指標も記録します。

サーバー設定を変更せず、同じバッチをローカルのWi-Fiまたは有線LANと、想定しているリモート経路で比較します。トンネルを解釈する際の転送経路の参考として、Tailscaleの直接経路とリレー経路を利用してください。転送時間が延びてもサーバー側の処理が同程度なら、ネットワークが支配的な変数です。

制御した経路の変更によって、予測した段階だけが改善し、他の段階は同程度に保たれた場合にのみ、ネットワークが原因だと判断してください。その証拠は、速度テストの結果や一度だけ高かったPing値、あるいはリモートアップロードは常に遅いという一般論よりも強いものです。