컨테이너를 다시 시작한 후 Immich가 다르게 작동하는 이유는 무엇인가요?

Immich는 재시작 후 일시적인 캐시가 사라지고 서비스 종속성이 다시 연결되기 때문에 변경된 것처럼 보일 수 있으며, 영속성 설정이 잘못되면 더 심각한 상태 손실이 발생할 수 있습니다.

첫 검색이 느린 것은 콜드 상태에서 흔히 나타나는 정상적인 동작일 수 있지만, 처음 설정하는 온보딩 화면이 다시 나타나는 것은 정상적이지 않습니다. 데이터를 변경하기 전에 지속 시간과 범위로 증상을 분류하세요. 캐시 워밍, 종속성 오류, 영구 스토리지 누락은 각각 완전히 다른 대응이 필요합니다.

재시작하면 일시적인 프로세스 상태가 사라집니다

재시작된 프로세스는 메모리에 저장된 모델, 연결 풀, 컴파일된 경로, 애플리케이션 캐시를 잃습니다. 호스트의 페이지 캐시는 컨테이너 재시작 후에도 남아 있을 수 있지만, 호스트를 재부팅하면 캐시된 상태가 더 많이 사라집니다. 따라서 첫 검색이나 타임라인 요청에서는 초기화 작업이 수행될 수 있으며, 바로 이어지는 반복 요청에서는 이를 건너뛸 수 있습니다.

커뮤니티 측정 자료에 따르면 첫 스마트 검색은 느리지만, 머신러닝 모델이 GPU 메모리에 로드된 뒤 반복 검색은 훨씬 빨라집니다. 정확한 시간은 해당 서버 환경에 따라 다르지만, 이 상태 전환은 재시작 직후의 요청 하나만으로 정상적인 운영 상태를 판단할 수 없는 이유를 설명합니다.

동일한 요청을 세 번 실행하고 지연 시간이 수렴하는지 기록하세요. 첫 요청만 느리고 결과가 정확하다면 콜드 로딩이나 보존 정책을 조사하세요. 모든 요청이 실패하거나 상태가 사라진 것처럼 보인다면 이를 단순한 캐시 워밍 문제로 보지 말고 종속성과 영구 저장소를 확인하세요.

종속성 순서 때문에 시작 순서 경쟁이 발생할 수 있습니다

Immich는 웹에 노출되는 프로세스 외에도 여러 구성 요소에 의존합니다. 데이터베이스, 작업 조정 서비스, 머신러닝 서비스, 마운트된 미디어가 호환되는 설정으로 접근 가능해져야 합니다. 컨테이너가 실행 중으로 표시되어도 아직 초기화 중일 수 있으므로, 스택이 잠시 후 정상 상태가 되더라도 초기 요청은 실패할 수 있습니다.

재시작 실패 보고에는 관련 없어 보이는 compose 변경 후 Immich가 PostgreSQL 또는 Redis에 대한 접근 권한을 잃은 사례가 설명되어 있습니다. 이 사례만으로 제품 전반의 결함을 입증할 수는 없지만, 애플리케이션 연결 오류를 종속성의 준비 상태 및 재시작 시점과 대조하는 것이 진단에 유용하다는 점을 보여 줍니다.

동일한 재시작 과정에서 애플리케이션과 해당 종속성의 로그를 타임스탬프와 함께 수집하세요. 컨테이너 내부에서 DNS 확인, 포트 연결 가능 여부, 상태 확인, 마운트 사용 가능 여부를 검증하세요. 자동 재시도로 서비스가 복구된다면 준비 상태 처리를 개선하고, 복구되지 않는다면 설정과 인증 정보를 직접 테스트하세요.

영구 상태는 컨테이너 교체 후에도 유지되어야 합니다

컨테이너의 쓰기 가능 계층에만 저장된 이미지와 데이터베이스 파일은 컨테이너가 교체될 때 사라집니다. 명명된 볼륨과 바인드 마운트는 배포 설정이 동일한 실제 위치를 참조할 때만 유지됩니다. 단순한 재시작은 일반적으로 이를 보존하지만, compose 편집이나 경로 변경으로 인해 새롭고 비어 있는 스토리지가 선택될 수 있습니다.

ZimaSpace의 데이터 경로 문서에서는 컨테이너 내부에 표시되는 경로만으로는 그 뒤에 있는 실제 스토리지나 장애 도메인을 알 수 없다고 설명합니다. 이는 컨테이너를 다시 만들 때 특히 중요합니다. 동일한 내부 경로가 다른 호스트 디렉터리, 비어 있는 볼륨 또는 사용할 수 없는 네트워크 마운트를 가리킬 수 있기 때문입니다.

Immich에 처음 설정하는 온보딩 화면이 나타나더라도 즉시 새 라이브러리를 만들지 마세요. 실제 마운트, 볼륨 식별자, 소유권, 데이터베이스 로그를 확인한 다음 마지막으로 정상 작동했던 배포와 비교하세요. 새 데이터를 쓰면 원래 상태가 사라진 옆에 두 번째 상태 집합이 만들어져 복구가 더 복잡해질 수 있습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

5분 동안 재시작 상태를 분류하세요

0분에는 어떤 컨테이너가 재시작되었고 이미지나 설정이 변경되었는지 기록하세요. 1분에는 종속성 상태와 마운트를 확인하세요. 3분에는 알고 있는 검색 하나와 기존 다운로드를 다시 실행하세요. 5분에는 동작이 개선되는지, 계속 사용할 수 없는지, 아니면 비어 있는 상태가 표시되는지 판단하세요.

데이터베이스 영속성 보고에는 compose 재시작 후 반복해서 온보딩 화면이 나타났지만, 예상한 호스트 데이터베이스 디렉터리는 비어 있었던 사례가 설명되어 있습니다. 단일 환경의 사례이지만, 명확한 장애 징후를 보여 줍니다. 재시작할 때마다 영구적인 애플리케이션 식별 정보가 사라진다면 데이터베이스가 의도한 영구 경로가 아닌 다른 위치에 기록되고 있다는 의미입니다.

개선되는 지연 시간은 콜드 상태로, 연결 오류는 종속성 시작 문제로, 누락된 미디어는 마운트 문제로, 사라진 사용자나 앨범은 데이터베이스 영속성 문제로 분류하세요. 변경하기 전에 로그와 현재 볼륨 매핑을 보존하세요. 원래 상태에 연결할 수 없는 것인지 실제로 사용할 수 없는 것인지 확인한 후에만 복원을 진행하세요.