컴퓨팅, 스토리지 및 백업을 위한 완벽한 Jellyfin 홈 서버 토폴로지

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Complete Jellyfin Home Server Topology for Compute, Storage, and Backup - Zima Store Online

완전한 Jellyfin 토폴로지는 컴퓨팅, 활성 애플리케이션 데이터, 대용량 미디어, 백업을 분리하면서 재생 경로를 최대한 짧고 테스트하기 쉽게 유지합니다.

토폴로지는 하나의 섀시나 여러 대의 머신으로 구성할 수 있습니다. 중요한 것은 장비의 수가 아니라 역할입니다. 컴퓨팅은 클라이언트에 서비스를 제공하고 트랜스코딩을 수행할 수 있으며, 앱 스토리지는 지연 시간에 민감한 Jellyfin 상태를 보관하고, 미디어 스토리지는 대용량 파일을 제공하며, 백업은 장애 발생 후에도 보존해야 하는 데이터를 보호합니다. 공유 설계에서 측정 가능한 충돌이 발생할 때만 역할을 분리하세요. 호스트와 네트워크 홉이 하나씩 늘어날 때마다 의존성도 추가되기 때문입니다.

데이터가 어디에 위치할지 정하기 전에 네 가지 데이터 역할을 정의하세요

데이터를 원본 미디어, Jellyfin 영구 상태, 재구축 가능한 작업 데이터, 백업 사본의 네 가지 역할로 분류하세요. 원본 미디어는 대용량 저장 공간을 많이 차지하고, 영구 상태에는 데이터베이스와 사용자/서버 구성이 포함되며, 작업 데이터에는 캐시와 트랜스코딩 출력이 포함됩니다. 백업은 다른 역할을 복구하기 위해서만 존재합니다.

이러한 분류는 “스토리지”를 구분 없는 하나의 풀로 취급하는 일반적인 토폴로지 오류를 방지합니다. 대용량 HDD 어레이는 동영상 파일을 저장하기에는 훌륭할 수 있지만 사용량이 많은 메타데이터 데이터베이스를 보관하기에는 적합하지 않을 수 있습니다. 반면 빠른 SSD는 앱 데이터에 유용하지만 대규모 콜드 라이브러리에는 비용이 많이 들고 불필요합니다.

ZimaSpace의 메타데이터 배치 가이드도 동일한 역할 분리를 사용합니다. 활성 데이터베이스와 캐시는 빠른 스토리지에 보관하고, 마이그레이션을 위해 이동 가능한 사이드카나 아트워크를 미디어와 함께 저장할지는 별도로 결정하세요.

기본 재생 경로를 단순하게 유지하세요

핵심 경로는 클라이언트 → 네트워크 → Jellyfin 컴퓨팅 → 미디어 소스입니다. 컴퓨팅과 미디어가 같은 머신에 있으면 미디어 홉은 로컬입니다. 분리되어 있으면 컴퓨팅 노드는 제공하거나 트랜스코딩하는 모든 바이트를 네트워크를 통해 읽은 다음 그 결과를 클라이언트로 보내야 합니다.

컴퓨팅과 스토리지를 분리하는 설계에서는 최종 클라이언트 비트레이트만이 아니라 전체 원본 트래픽을 기준으로 노드 간 링크 용량을 정하세요. 트랜스코딩은 클라이언트에 낮은 비트레이트의 출력을 보내면서 스토리지에서 높은 비트레이트의 원본을 읽을 수 있으므로 스토리지 링크와 클라이언트 링크의 역할은 서로 다릅니다.

경쟁을 유발하는 관리, 실험, 선택적 서비스를 재생 경로에서 분리하세요. 두 번째 VLAN, 별도의 컨테이너 네트워크, 또는 백업 시간을 단순히 예약하는 것만으로 충분할 수 있습니다. 공유 경로가 서비스 성능을 측정 가능하게 저하시킬 때에만 완전히 별도의 물리적 네트워크를 추가하세요.

미디어 엔진과 서비스 격리를 쉽게 검증할 수 있는 곳에 컴퓨팅을 배치하세요

컴퓨팅은 실제로 수행하는 재생 작업을 기준으로 선택해야 합니다. 직접 재생에는 많은 비디오 컴퓨팅 성능이 필요하지 않지만, 호환되지 않는 클라이언트, 자막 삽입, HDR 변환, 원격 비트레이트 제한으로 인해 트랜스코딩이 주요 작업이 될 수 있습니다.

Jellyfin 하드웨어 선택 가이드는 소프트웨어 비디오 트랜스코딩이 매우 높은 성능을 요구할 수 있으므로 새 서버에는 최신 하드웨어 가속을 권장합니다. 또한 CPU의 역할과 GPU 미디어 엔진의 역할을 구분하는데, 이는 CPU 코어 수만으로 서버를 평가하는 것보다 유용합니다.

Jellyfin을 사진 인덱싱, 백업, 홈 오토메이션, AI 작업과 동일한 호스트에서 실행한다면 미디어 서비스에 명확한 CPU, 메모리, 장치 액세스 경계를 설정하세요. ZimaCube 2와 같은 더 큰 올인원 노드는 통합 토폴로지를 구현할 수 있지만, 하나의 섀시를 하나의 장애 도메인으로 취급하지 말고 앱 데이터, 미디어, 백업 역할을 여전히 분리해야 합니다.

-15% OFF

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

Single board computer zimaboard2

활성 Jellyfin 상태에는 SSD를, 라이브러리에는 대용량 미디어 스토리지를 사용하세요

Jellyfin 데이터베이스, 인덱스, 캐시 및 자주 액세스하는 기타 상태 데이터는 SSD 또는 이와 유사하게 지연 시간이 낮은 스토리지에 배치하세요. 대용량 동영상 라이브러리는 HDD, NAS 풀 또는 필요한 순차 읽기를 지속적으로 처리할 수 있는 다른 매체에 저장하세요.

Jellyfin은 이러한 작업을 명확히 구분합니다. 스토리지 가이드에 따르면 미디어 파일에는 주로 비트레이트를 초과하는 순차 처리량이 필요하지만, Jellyfin 자체 파일은 상당한 무작위 액세스를 수행하므로 SSD에 배치하는 것이 더 적합합니다.

라이브러리가 원격에 있다면 예측 가능한 방식으로 마운트하고 Jellyfin 서비스가 인식하는 경로를 문서화하세요. 앱 상태 경로와 미디어 경로를 문서화되지 않은 임시 마운트 체인에 포함하지 않고 독립적으로 복원할 수 있으면 복구가 훨씬 쉬워집니다.

백업을 동일한 장애 도메인의 다른 폴더가 아닌 별도의 대상으로 만드세요

라이브 Jellyfin 상태와 동일한 SSD 또는 동일한 디스크 풀에 저장된 백업은 해당 스토리지 장애를 보호하지 못합니다. 백업 대상은 복구하려는 장애 유형에서 살아남을 수 있어야 합니다. 이는 다른 디스크 세트, 다른 머신, 오프라인 또는 오프사이트 사본을 의미할 수 있습니다.

Jellyfin의 백업 및 복원 문서는 데이터베이스, 메타데이터, 자막, 트릭플레이를 별도의 백업 콘텐츠 범주로 구분합니다. 어떤 항목이 중요한지, 어떤 항목을 재구축할 수 있는지, 그리고 증가하는 데이터에 필요한 대상 용량이 얼마인지 결정하세요.

미디어 백업은 대용량 라이브러리가 애플리케이션 상태보다 훨씬 클 수 있으므로 별도의 정책 결정이 필요합니다. 대체 가능한 미디어보다 대체할 수 없는 홈 비디오를 더 강력하게 보호하고, 삭제·손상·운영자 오류까지 고려한다면 패리티나 RAID 중복만을 유일한 백업 사본으로 간주하지 마세요.

토폴로지를 분리하거나 확장하기 전에 먼저 복구를 검증하세요

확장하기 전에 세 가지 테스트를 실행하세요. 대표적인 로컬 스트림, 대표적인 강제 트랜스코딩, 깨끗한 위치 또는 예비 인스턴스로 Jellyfin 상태를 복원하는 테스트입니다. 이 테스트는 각각 기본 재생 경로, 컴퓨팅 예외 경로, 복구 경로를 점검합니다.

기존 구성에 변경할 이유가 있을 때만 컴퓨팅과 스토리지를 분리하세요. 용량 확장 인클로저의 필요성, 독립적인 유지 관리 시간, GPU 배치, 소음·열 제약, 지속적인 I/O 경합 등이 그 이유가 될 수 있습니다. 분리형 설계는 역할 격리를 개선할 수 있지만 네트워크와 원격 마운트를 모든 재생 과정의 일부로 만듭니다.

각 역할에 담당자가 지정되어 있고, 핵심 경로를 측정할 수 있으며, 백업이 목표 장애에서 살아남고, 다음 구성 요소가 알려진 병목을 제거하거나 복구 기능을 개선하지 못한다면 확장을 멈추세요. 이러한 경계가 있으면 홈 서버 토폴로지를 충분히 이해하기 쉬운 상태로 유지하여 긴급 상황에서도 수리할 수 있습니다.