複数アプリ対応のホームサーバーでImmichを使う：共有リソースが結果をどう変えるか

エヴァ・ウォン

IceWhale author

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

Immich in a Multi-App Home Server: How Shared Resources Change Results

マルチアプリサーバー上でImmichの結果が変動するのは、コンテナが別々のプロセス境界を持っていても、CPU、メモリ、ストレージ、ネットワーク容量を共有しているためです。

写真検索は正午には高速でも、別のアプリケーションがバックアップ、スキャン、トランスコードを実行している間は遅くなることがあります。Immichの設定は変わっていなくても、利用可能なリソース予算とキャッシュの内容が変化しているため、適切な説明にはホスト全体のワークロードを含める必要があります。

コンテナが分離するのはプロセスであり、物理的な容量ではない

コンテナは名前空間と制御可能な上限を提供しますが、最終的には同じプロセッサ上で実行され、通常は同じメモリコントローラー、ディスク、ネットワークインターフェースにアクセスします。Immichのサービスが自身の制限内に収まっていても、共有する物理デバイスやカーネルスケジューラー上で、無関係な処理の後ろで待たされることがあります。

複数コンテナでのImmich運用レポートでは、通常のCPU使用率が控えめな状態で数十個のコンテナを実行する低消費電力ホストが紹介されています。これは別の環境でも同じ結果になることを保証するものではありません。サービス数だけでは判断材料として弱く、実際に重なっている処理をホストレベルで観測する必要がある理由を示しています。

バックアップ、メディアスキャン、ダウンロード、データベース、ビデオトランスコードなど、スケジュール実行とバースト的に実行されるすべての隣接処理を一覧化します。Immichのレイテンシーとともに、それらの開始時刻を記録してください。相関関係だけでは因果関係は証明できませんが、繰り返し一致するタイミングから、疑わしい干渉を検証するための一時停止または再スケジュール実験を特定できます。

メモリ競合はキャッシュの常駐状態を変える

頻繁に使用するデータベースページ、サムネイル、モデルデータがメモリ上に常駐していると、Immichは有利です。隣接するサービスがワーキングセットを拡大すると、メモリ不足による強制終了を引き起こさずに、それらのページを追い出すことがあります。その後のリクエストでは、データがキャッシュに保持されていたときには不要だったストレージアクセスやモデル読み込みのコストが発生します。

Kingstonのサーバーメモリに関する解説では、十分な容量があれば、メモリを大量に使用するアプリケーションが低速なストレージに依存する度合いを減らせると説明されています。ここで重要なのは、すべてのホームサーバーにエンタープライズ向けメモリが必要だということではありません。キャッシュの喪失によって、一見同じImmichリクエストでも異なる物理ワークロードに変わる可能性があるという点です。

隣接サービスの開始前後で、ページキャッシュの動作、スワップ、メジャーフォールト、ストレージ読み取りを比較します。Immichを変更せずにそのサービスを一時停止すると、キャッシュが温まった状態での挙動が戻るなら、メモリの常駐状態が関係していると考えられます。ただし、RAM使用率の合計が高いというだけでは不十分です。正常なファイルシステムキャッシュは、意図的に未使用のメモリを消費するためです。

ストレージキューは無関係なサービスを結び付ける

バックアップが大きなファイルをストリーミングする一方で、Immichが小さなデータベース処理やサムネイル処理を実行することがあります。総帯域幅がドライブの公称最大値を下回っていても、キューイングによってレイテンシーに敏感なリクエストの完了時間が増加する可能性があります。ネットワークマウントされたストレージでは、同じ競合の連鎖に別のスケジューラーとネットワーク経路も加わります。

ZimaSpaceのImmichのデータパスに関する記事では、検索結果の選択と表示メディアが異なる依存関係を持つ別々の段階であることが示されています。この違いは、ストレージの結合箇所を特定するのに役立ちます。結果IDがすぐに返る一方でサムネイルの表示が遅れるなら、データベースによる選択自体が遅い場合よりも、後段の処理に問題があることを示します。

同じリクエストを再現しながら、マウントポイントごとのデバイスレイテンシーとキュー深度を測定します。疑わしいI/O負荷の高い隣接サービスだけを一時停止し、キャッシュが落ち着いてから同じ手順を繰り返してください。複数回の交互実行でも改善が続くなら、スケジューリングの調整またはストレージの分離が妥当です。そうでなければ、CPU、メモリ、ネットワークの仮説に戻ります。

Featured

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

ZimaCube2

一時停止して再実行する分離テストを使う

同じタイムライン範囲を読み込む、既知のスマート検索を実行するなど、固定したエンドポイントを選び、コールド状態またはウォーム状態の条件を定義します。すべてのサービスを動かした状態で3回実行して記録します。次にImmichを再起動せず、候補となる隣接サービスを1つ一時停止し、同じクライアント操作と観測時間で繰り返します。

アップデート後の処理中にImmichが大きく競合したという報告では、ホストがビジーな状態で別の写真サービスのアップロードが失敗したと説明されています。これは1つの構成における事例であり、普遍的な上限ではありません。しかし、正常なバックグラウンドキューでも、別の対話型サービスに影響するほど共有容量を消費できることを示しています。

一時停止によって再現性のあるレイテンシーの変化が生じ、関連するリソース待ちも同時に減少した場合にのみ、干渉を受け入れるべきです。次に、同時実行数の削減、スケジュール時間帯の設定、CPUクォータ、メモリ予約、ストレージの分離など、限定的な緩和策を試します。1つの隣接サービスを分離すると2つ目の制限が表面化する可能性があるため、ロールバック設定を保持してください。