대규모 모바일 가져오기 중에도 Immich의 사진 검색을 계속 사용할 수 있나요?

예, 공유 리소스에 여유 용량이 남아 있다면 Immich는 가져오기 작업 중에도 기존 사진 검색을 계속 사용할 수 있습니다. 다만 새로 업로드한 사진은 검색 가능해지기까지 더 오래 걸릴 수 있습니다.

한 가정에서 수년 치 휴대폰 사진을 가져오는 동안 누군가 오래된 생일 앨범을 검색한다고 가정해 보겠습니다. 이미 알고 있는 앨범을 즉시 반환하는 것과 방금 업로드된 모든 사진을 찾는 것은 서로 다른 요구 사항입니다. 백그라운드 처리가 뒤처져도 기존 검색 기능이 중단되지 않을 수 있고, 반대로 리소스 경합으로 이미 색인된 결과조차 느려질 수 있으므로 두 가지를 별도로 평가해야 합니다.

기존 검색과 새로운 검색 범위는 서로 다른 요구 사항입니다

기존에 색인된 자산에는 지원되는 검색 경로에 필요한 정보가 이미 있습니다. 새로 수락된 업로드에는 메타데이터 추출, 표시 준비, 관련 색인 작업이 아직 필요할 수 있습니다. 따라서 업로드가 성공했다고 해서 즉시 시맨틱 검색이 가능해지거나 해당 자산의 모든 검색 기능 처리가 완료된다는 의미는 아닙니다.

직접 확인된 대규모 라이브러리 관련 보고를 보면 소형 보드와 대형 시스템에서 가져오기 경험이 크게 달랐으며, 처리가 계속되는 동안에도 사용 가능한 상태를 유지한 설치 사례도 있었습니다. 이러한 사례는 최소 RAM 기준을 제시하는 것이 아니라 환경에 따른 차이를 보여 줍니다. 사진 수뿐 아니라 미디어 구성, 활성화된 작업, 동시 실행 서비스, 허용 가능한 대기 시간도 중요합니다.

알려진 검색어가 가정에서 허용 가능한 시간 안에 예상한 결과를 계속 반환하고 새 자산의 처리도 계속 진행된다면 조건부로 답은 예입니다. 기존 검색이 작동하더라도 색인 진행이 멈췄다면 최신성 측면에서는 아니오가 됩니다. 반대로 대기열이 늘고 있다는 사실만으로 대화형 서비스가 사용할 수 없게 되었다고 단정할 수는 없습니다.

가져오기 작업이 늘어나면 대화형 처리 용량을 사용할 수 있습니다

업로드, 파생 파일 생성, 데이터베이스 작업, 추론은 서로 겹치는 리소스를 사용합니다. 백그라운드 동시 실행 수를 늘리면 공유 종속 요소가 포화되기 전까지는 분당 더 많은 작업을 완료할 수 있지만, 그 지점을 넘어서면 대기 시간이 늘어나 대화형 요청이 느려질 수 있습니다. 따라서 같은 호스트에서 가져오기 속도가 빨라지는 동시에 검색 경험은 느려질 수 있습니다.

버전에 따라 작성된 가져오기 도구 보고서에서는 immich-go 0.28.0과 Immich 2.3.1에서 작업 일시 중지 제어가 활성화된 모든 대기열을 다루지 못했다고 설명합니다. 보고자는 이것이 관찰된 연결 오류의 원인이라고 입증하지는 않았습니다. 이 사례에서 얻을 수 있는 유용한 교훈은 더 제한적입니다. 제어 항목의 이름만으로 모든 백그라운드 작업이 실제로 일시 중지되었다고 볼 수는 없습니다.

가족이 사용하는 시간대에 백그라운드 작업을 줄이면 대화형 처리에 더 많은 여유를 확보할 가능성이 생기는 대신 완료 시간이 늘어납니다. 하지만 처리 용량 자체가 늘어나는 것은 아닙니다. 지원되는 변경을 적용한 뒤 활성 대기열과 사용자에게 보이는 응답 시간을 관찰하세요. 대기열이 비어 있는데도 검색이 느리다면 모든 지연을 가져오기 동시 실행 탓으로 돌리지 말고 남아 있는 검색 경로를 조사해야 합니다.

ML 가속으로 모든 종속 요소를 보호할 수는 없습니다

추론을 가속기나 다른 호스트로 옮기면 하나의 서비스 경계가 바뀝니다. 그렇다고 PostgreSQL, 원본 미디어 읽기, 썸네일 생성, 클라이언트 렌더링까지 자동으로 빨라지는 것은 아닙니다. 빠른 머신러닝 단계가 데이터베이스나 스토리지 풀이 혼잡한 상태와 동시에 존재할 수 있으며, 원격 서비스는 자체적인 네트워크 및 가용성 종속 요소를 추가합니다.

Immich 2.2.0에 대한 OCR 리소스 보고서에서는 특정 모델과 환경에서 얼굴 및 스마트 검색 처리는 빠르지만 OCR 동작에는 훨씬 더 많은 리소스가 필요했다고 설명합니다. 이는 과거의 사례이며 현재 모든 환경에 적용되는 보편적인 결함은 아닙니다. 이 사례는 하나의 ML 작업의 속도나 메모리 요구량을 활성화된 모든 작업의 기준으로 삼을 수 없는 이유를 보여 줍니다.

메모리 압박으로 필수 서비스가 재시작되거나, 쿼리가 시간 초과되거나, 스토리지의 쓰기 가능 공간이 부족해지거나, 필요한 네트워크 경로에 연결할 수 없게 되면 가용성 주장은 성립하지 않습니다. 추론 속도만 높여서는 이러한 경계를 해결할 수 없습니다. 개인정보 보호도 별도로 고려해야 합니다. 로컬 처리가 지나치게 광범위한 계정 권한, 외부에 노출된 엔드포인트, 부적절한 백업 처리를 보완해 주지는 않습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

가정에서 ‘사용 가능’하다는 의미를 정의하세요

결과를 알고 있는 오래된 검색어 몇 가지와 식별하기 쉬운 대상을 포함한 새 가져오기 샘플을 정하세요. 검색 완료 시간, 오류, 그리고 샘플이 의도한 기능을 통해 검색 가능해질 때까지의 지연 시간을 기록하세요. 계정, 클라이언트, 네트워크 경로를 바꾸지 않고 한산한 시간대와 일반적인 가져오기 작업 중에 이를 반복하세요.

셀프 호스팅은 가정 내 운영 책임을 서버 소유자에게 이전합니다. 여기에는 서비스 가용성, 접근 권한, 백업 결정이 포함됩니다. 사용 가능한 검색을 정의할 때 이 차이가 중요한 이유입니다. 가끔 발생하는 색인 지연은 허용할 수 있어도 매일 밤 가져오기 작업 중 접근이 끊기는 것은 허용하기 어려울 수 있습니다. 클라우드 서비스와의 비교는 이러한 책임의 맥락을 제공할 뿐 Immich의 성능을 보장하지는 않습니다.

기존 검색의 지연 시간과 새 사진이 준비되는 시간에 대해 각각 허용 한도를 정한 다음, 업로드가 끝난 뒤 대기열이 줄어드는지 관찰하세요. 두 기준을 모두 충족해야 테스트한 작업량에서 계속 사용할 수 있다는 의미가 됩니다. 어느 하나라도 충족하지 못한다면 다음으로 판단해야 할 것은 모든 대규모 라이브러리에 동일한 하드웨어가 필요하다는 가정이 아니라, 어떤 종속 요소나 작업 일정의 중복이 해당 한도를 초과하게 만드는지입니다.