업그레이드 후 Immich가 기존 데이터를 다시 처리하는 이유는 무엇인가요?

Immich는 업그레이드로 현재 출력물을 정의하는 코드, 모델, 메타데이터 또는 파생 규칙이 변경되면 기존 자산을 다시 처리할 수 있습니다.

원본 사진은 변경되지 않았지만 썸네일, 임베딩, 얼굴 정보, 미리 보기 또는 데이터베이스 레코드는 새 릴리스의 요구 사항을 더 이상 충족하지 못할 수 있습니다. 다음에서는 어떤 출력이 무효화되었는지, 어떤 큐가 이를 재생성하는지, 그리고 작업이 한 번 완료되는지 아니면 비정상적으로 반복되는지를 구분해 설명합니다.

업그레이드로 현재 출력물의 기준이 달라질 수 있습니다

생성된 데이터는 이를 만든 코드, 모델, 설정 및 스키마를 기준으로 유효합니다. 이러한 기준이 변경되면 기존 썸네일, 임베딩, 얼굴 분석 결과 또는 메타데이터 레코드가 더 이상 최신 상태로 간주되지 않을 수 있습니다. 자산은 입력으로 남아 있으며, 작업이 필요한 것은 파생 표현뿐입니다.

ZimaSpace의 Immich 백업 문서는 필수 원본과 데이터베이스 상태를 재생성할 수 있는 파생 데이터와 구분합니다. 이 구분은 원본 파일이 복제되었다는 의미 없이도 업그레이드 작업이 대규모로 발생할 수 있는 이유를 설명합니다. 애플리케이션이 변경되지 않은 미디어를 기반으로 파생 상태를 다시 구축할 수 있기 때문입니다.

업그레이드 직후 어떤 큐가 증가하는지, 어떤 디렉터리나 데이터베이스 크기가 변하는지 기록하세요. 썸네일 큐, 머신러닝 큐, 데이터베이스 마이그레이션은 서로 다른 메커니즘입니다. 이들을 모두 “재인덱싱”이라고 부르면 소요 시간과 리소스 부담을 추정하는 데 필요한 근거가 사라집니다.

종속성과 모델 변경으로 이전 작업이 무효화될 수 있습니다

Immich는 애플리케이션 코드, 데이터베이스 동작, 큐 조정, 머신러닝 모델 및 미디어 파생 데이터를 아우릅니다. 업그레이드로 이러한 구성 요소 사이의 인터페이스나 저장 표현에 대한 요구 사항이 변경될 수 있습니다. 마이그레이션은 레코드를 빠르게 업데이트할 수 있지만, 이후 백그라운드 워커가 영향을 받은 각 자산에 대해 비용이 큰 출력을 다시 생성할 수 있습니다.

Immich v3 준비에 관한 커뮤니티 논의에서는 PostgreSQL, Redis, 벡터 확장 기능 및 애플리케이션 버전의 호환성에 대한 불확실성을 다룹니다. 이 논의가 특정 업그레이드 작업을 입증하는 것은 아니지만, 종속성 호환성이 무관한 유지 관리 세부 사항이 아니라 상태 전환의 일부임을 보여줍니다.

업그레이드 전 구성 요소 버전과 업그레이드 후 큐 스냅샷을 보존하세요. 하나의 출력 유형만 예약되고 한 번 완료된다면 이는 제한적인 재생성에 해당합니다. 구성 요소가 스키마나 확장 기능에 대해 서로 다른 상태를 가지면 유용한 재처리가 시작되기도 전에 반복적인 오류가 발생할 수 있습니다.

재처리는 호환성 작업을 리소스 부담으로 바꿉니다

규모가 큰 라이브러리에서는 규칙 하나가 변경되어도 수천 개의 작업이 생성될 수 있습니다. 썸네일 생성과 미디어 분석은 CPU 또는 가속기를 사용하며, 원본 읽기와 파생 데이터 쓰기는 스토리지 대역폭을 사용합니다. 데이터베이스 업데이트와 큐 작업도 동시에 계속되므로 재처리가 정상적으로 진행 중이어도 전면 탐색이 느려질 수 있습니다.

한 Immich 지원 스레드에서는 두 서버에서 업데이트 후 야간 CPU 사용량 증가와 썸네일 생성 재개가 보고되었습니다. 이는 의도된 동작을 입증하는 자료는 아니지만, 큐 진행 상황, 로그 및 완료 작업의 반복 여부와 대조해 확인해야 할 관찰 패턴을 제공합니다.

분당 완료 항목 수, 남은 스토리지, 장치 지연 시간, 메모리 압박 및 고정된 대화형 요청을 추적하세요. 정상적인 재처리라면 유한한 백로그가 줄어들어야 합니다. 동시 실행 수를 낮추면 처리 시간은 늘어나지만 가정 내 사용을 보호할 수 있습니다. 반대로 해당 단계가 이미 한계에 도달한 상태에서 워커를 추가하면 스토리지나 데이터베이스 경합이 악화될 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

일회성 재생성과 반복되는 오류를 구분하세요

업그레이드 전에 작업 수, 버전, 여유 공간 및 여러 자산 식별자를 저장하세요. 업그레이드 후 동일한 식별자를 샘플링하여 어떤 출력이 다시 생성되는지, 큐 수가 감소하는지, 재시작 또는 다음 예약 유지 관리 시간 이후에 작업이 다시 나타나는지를 기록하세요.

썸네일 복구 논의에서는 처리가 결국 완료된 후 누락된 이미지가 해결되었으며, 일부 개별 자산에는 수동 새로 고침이 도움이 되었다고 보고합니다. 이러한 상반된 보고는 중요한 구분을 보여줍니다. 경과 시간만으로는 동작을 분류할 수 없습니다. 유한한 큐가 진행되는 것과 동일한 자산이 반복해서 실패하거나 다시 큐에 등록되는 것은 다릅니다.

출력 결과가 안정적이고 큐가 꾸준히 감소한다면 일회성 재생성으로 판단하세요. 완료 수가 초기화되거나, 동일한 자산이 반복되거나, 오류가 되풀이되거나, 여유 공간이 급감하거나, 유용한 처리량이 전혀 나타나지 않으면 문제를 확대해 조사하세요. 작업 상태를 변경하기 전에 백업과 로그를 보존하세요. 증거를 삭제하면 업그레이드가 루프를 유발했는지 아니면 환경이 원인이었는지 파악하기 어려워질 수 있습니다.