コンテナを再起動すると、Immichの動作が異なるのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Immich Behave Differently After a Container Restart?

Immichは、再起動後に一時キャッシュが消失してサービスの依存関係が再接続されるため、動作が変わります。一方、永続化の設定ミスがあると、より深刻な状態消失が発生する可能性があります。

最初の検索が遅いのはコールド状態では通常のことかもしれませんが、初回セットアップ画面が表示されるのは通常ではありません。データを変更する前に、症状を継続時間と範囲で分類してください。キャッシュのウォームアップ、依存サービスの障害、永続ストレージの欠落では、必要な対応がまったく異なります。

再起動すると一時的なプロセス状態が失われる

プロセスを再起動すると、メモリ上のモデル、接続プール、コンパイル済みパス、アプリケーションキャッシュが失われます。コンテナを再起動してもホストのページキャッシュは残る場合がありますが、ホストを再起動すると、より多くのウォーム状態が失われます。そのため、再起動直後の最初の検索やタイムライン要求では初期化処理が実行され、直後の繰り返しではそれを回避できることがあります。

コミュニティによる測定では、最初のスマート検索は遅いものの、機械学習モデルがGPUメモリに読み込まれると、その後の検索は大幅に速くなると報告されています。正確な時間はサーバーごとに異なりますが、この状態遷移から、再起動直後の1回の要求だけでは通常時の動作を判断できないことが分かります。

同じ既知の要求を3回実行し、レイテンシーが収束するか記録してください。最初の要求だけが遅く、結果が正しい場合は、コールドロードまたは保持ポリシーを調査します。すべての要求が失敗する、または状態が欠落しているように見える場合は、キャッシュのウォームアップとして扱うのをやめ、依存サービスと永続化を確認してください。

依存サービスの起動順序がスタートアップ競合を引き起こすことがある

Immichは、Webに公開されるプロセスだけに依存しているわけではありません。データベース、ジョブ調整、機械学習サービス、マウントされたメディアが、互換性のある設定で利用可能になる必要があります。コンテナが「実行中」と表示されていても初期化中の場合があるため、スタックが少し後に正常化するまで、初期の要求が失敗することがあります。

再起動後の障害報告では、無関係に見えるComposeの変更後、ImmichからPostgreSQLまたはRedisへアクセスできなくなったと説明されています。この事例だけで製品全体の不具合とは断定できませんが、アプリケーションの接続エラーを依存サービスの準備状況や再起動のタイミングと照合することの診断上の有用性を示しています。

同じ再起動について、アプリケーションと該当する依存サービスからタイムスタンプ付きのログを収集してください。コンテナ内でDNS名前解決、ポート到達性、ヘルスチェック、マウントの利用可能性を確認します。自動リトライでサービスが復旧する場合は、準備完了の処理を改善してください。復旧しない場合は、設定と認証情報を直接テストします。

永続状態はコンテナの置き換え後も維持する必要がある

コンテナの書き込み可能レイヤーにのみ保存されたイメージやデータベースファイルは、そのコンテナが置き換えられると消失します。名前付きボリュームとバインドマウントは、デプロイメントが同じ基盤上の場所を参照している場合にのみ永続します。通常の単純な再起動では保持されますが、Composeの編集やパスの変更によって、新しい空のストレージが黙って選択されることがあります。

ZimaSpaceのデータパスに関する記事では、表示されるコンテナ内パスだけでは、その背後にある物理ストレージや障害ドメインは分からないと説明しています。これは再作成後に重要です。同じコンテナ内パスでも、別のホストディレクトリ、空のボリューム、または利用できないネットワークマウントを指している可能性があります。

Immichに初回セットアップ画面が表示された場合は、すぐに代替ライブラリを作成しないでください。有効なマウント、ボリューム識別子、所有者情報、データベースログを確認し、最後に正常だったデプロイメントと比較します。新しい書き込みを行うと、見つからない元の状態の隣に2つ目の状態セットが作成され、復旧が複雑になる可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

5分間で再起動の状況を分類する

0分時点で、どのコンテナが再起動したか、またイメージや設定が変更されたかを記録します。1分時点で、依存サービスの状態とマウントを確認します。3分時点で、既知の検索と元のダウンロードを1回ずつ再試行します。5分時点で、動作が改善しているのか、継続的に利用できないのか、それとも空の状態が表示されているのかを判断します。

データベース永続化に関する報告では、Composeの再起動後に初回セットアップ画面が繰り返し表示され、想定していたホストのデータベースディレクトリは空のままだったと説明されています。これは単一環境での事例ですが、明確な障害の兆候を示しています。再起動をまたいで永続的なアプリケーションの識別情報が消える場合、データベースは意図した永続パス以外の場所に書き込まれています。

改善するレイテンシーはコールド状態、接続エラーは依存サービスの起動、欠落したメディアはマウント、失われたユーザーやアルバムはデータベースの永続化に関連付けてください。変更を行う前に、ログと現在のボリュームマッピングを保存します。元の状態が利用できないのではなく、単に接続されていないだけではないことを確認してから、復元に進んでください。