NAS에 Jellyfin을 설치한 뒤 영상이 끊기면 CPU 성능부터 의심하기 쉽다.
하지만 같은 4K 영상이라도 어떤 client에서는 NAS가 파일만 전달하고, 다른 client에서는 NAS가 영상을 실시간으로 다시 인코딩할 수 있다.
이 두 상황의 서버 부하는 전혀 다르다.
그래서 Jellyfin 운영에서 가장 먼저 구분할 것은 Direct Play와 Transcoding이다.
Direct Play는 NAS가 미디어 파일을 거의 그대로 전달한다
client가 파일의 video codec, audio codec, container와 subtitle 등을 직접 지원하면 Jellyfin은 원본 media를 그대로 전달할 수 있다.
이 경우 주요 병목은:
- disk read
- network bandwidth
- client decoding capability
쪽에 가깝다.
서버 CPU가 영상을 다시 encode하지 않기 때문에 비교적 낮은 사양 NAS에서도 고해상도 원본을 재생할 수 있는 경우가 있다.
Transcoding은 NAS가 실시간으로 새로운 영상을 만드는 작업이다
client가 원본 codec을 지원하지 않거나 bandwidth가 부족하거나 subtitle burn-in 등이 필요하면 server-side transcoding이 발생할 수 있다.
이때 Jellyfin은 FFmpeg를 이용해:
- decode
- scale
- tone mapping
- subtitle processing
- encode
등을 수행할 수 있다.
4K HEVC를 software transcoding해야 하는 상황은 단순 파일공유보다 훨씬 무거운 workload다.
재생이 느릴 때 CPU 사용률보다 먼저 Playback Info를 확인한다
CPU가 100%라면 원인은 이미 어느 정도 보인다.
그러나 운영에서는 먼저 해당 session이:
- Direct Play
- Direct Stream
- Video Transcoding
- Audio Transcoding
중 무엇인지 확인하는 것이 좋다.
Direct Play인데 끊긴다면 CPU upgrade보다 network 또는 storage를 조사해야 한다.
Transcoding 중이라면 왜 transcode가 발생했는지 확인한다.
Hardware Acceleration은 GPU가 ‘있다’고 자동으로 되는 것이 아니다
Jellyfin 공식 문서는 Intel QSV, NVIDIA NVENC/NVDEC, Linux의 Intel/AMD VA-API 등 여러 hardware acceleration 방식을 지원한다.
하지만 hardware가 지원된다는 것과 container가 실제 device에 접근할 수 있다는 것은 별개다.
Linux container 환경에서는 해당 render device를 container에 전달하고 필요한 permission과 driver 조건을 갖춰야 한다.
따라서 NAS에서 HWA를 계획한다면 먼저 host에서 실제 GPU/render device가 존재하고 지원되는지 확인해야 한다.
지원 hardware가 없으면 설정 화면에서 HWA를 켜는 것으로 성능이 생기지 않는다.
Hardware Acceleration이 되어도 모든 작업이 GPU로 가는 것은 아니다
Jellyfin 공식 문서에서도 transcoding pipeline의 일부 단계는 hardware와 driver에 따라 acceleration되지 않을 수 있다고 설명한다.
예를 들어 특정 subtitle burn-in이나 codec 조합에서 CPU 작업이 남을 수 있다.
따라서 “GPU 사용 중”이라는 표시만 보고 CPU load가 0에 가까워질 것이라고 기대하면 안 된다.
Media와 Jellyfin의 상태데이터를 같은 것으로 백업하지 않는다
Jellyfin container 운영에서는 최소한 세 종류의 데이터를 구분할 수 있다.
| 데이터 | 예시 | 성격 |
|---|---|---|
| Media | 영화·음악·개인영상 | 대용량 원본 데이터 |
| Config | DB·사용자·library 설정·metadata 상태 | 작지만 중요 |
| Cache/Transcode | 임시 cache·변환 segment | 재생성 가능 |
이 셋을 모두 같은 backup policy로 처리하면 비효율적이다.
Cache까지 장기 backup할 이유는 작고, config DB를 media와 함께 수 TB 단위 backup 속에 묻어두는 것도 복구가 느려질 수 있다.
Container에서도 Config와 Cache를 Persistent Storage로 분리한다
Jellyfin 공식 container 설치문서도 config와 cache용 persistent storage를 별도로 만들도록 안내한다.
이는 container image를 교체해도:
- 사용자 계정
- library 설정
- server configuration
등이 유지되도록 하기 위한 것이다.
반면 transcoding temporary data는 다시 만들 수 있으므로 fast storage를 사용하되 장기보존 대상으로 볼 필요는 적다.
Transcode Cache가 HDD 성능을 잡아먹을 수도 있다
원본 media를 읽으면서 동시에 temporary segment를 같은 HDD volume에 계속 쓰면 random I/O가 늘어날 수 있다.
Jellyfin 공식 hardware acceleration 문서도 high-throughput transcoding에서 HDD I/O가 병목이 될 수 있으며 SSD나 RAM disk를 cache에 활용할 수 있다고 설명한다.
따라서 NVMe가 있다면 media 전체를 NVMe로 옮기기보다:
- Jellyfin config
- metadata
- transcode cache
같은 active small-I/O workload에 먼저 사용하는 전략을 검토할 수 있다.
Media는 가능하면 Read-only로 제공하는 편이 안전하다
Jellyfin server가 영화파일 자체를 수정할 필요가 없다면 container에는 media directory를 read-only로 mount하는 방식도 고려할 수 있다.
이렇게 하면 application 또는 container의 예상하지 못한 동작이 원본 media를 수정·삭제할 수 있는 범위를 줄일 수 있다.
단, subtitle이나 metadata를 media folder에 직접 저장하도록 사용하는 경우에는 workflow에 맞게 별도 설계가 필요하다.
Remote Streaming은 NAS Upload Bandwidth도 계산해야 한다
집 안에서는 4K 원본이 잘 재생되는데 외부에서는 계속 transcoding이 발생한다고 하자.
client 호환성뿐 아니라 집 인터넷의 upload bandwidth가 원본 bitrate보다 낮을 수 있다.
예를 들어 평균 60Mbps 정도의 media stream을 외부에 전달하려는데 실제 안정적인 upload가 30Mbps라면 원본 전송은 지속하기 어렵다.
이 경우 server는 낮은 bitrate로 transcoding해야 할 수 있다.
따라서 원격 Jellyfin의 성능은 NAS CPU만이 아니라:
Media bitrate → NAS uplink → remote downlink → client codec support
전체 경로로 봐야 한다.
DLNA 때문에 Network Mode를 바꾸기 전에 필요성을 먼저 본다
Jellyfin 공식 Docker 문서에서는 일반적인 container networking은 bridge가 기본이며 DLNA를 사용할 경우 host networking이 필요할 수 있다고 설명한다.
하지만 DLNA를 사용하지 않는다면 단지 인터넷의 예제를 그대로 복사하기 위해 host networking을 사용할 이유는 없다.
network mode는 필요한 discovery 기능과 exposure 범위를 이해하고 선택하는 것이 좋다.
Jellyfin에서 정말 백업해야 하는 것은 무엇인가
최소 복구관점에서는 다음을 분리한다.
- Jellyfin configuration/database
- 필요한 custom metadata
- Container/Compose configuration
- 원본 media의 별도 backup 정책
그리고 실제 restore test에서 새 container가 기존 config와 media를 연결해 정상 library를 복원하는지 확인한다.
“Docker container가 백업됐다”는 표현만으로는 충분하지 않다.
결론
Jellyfin NAS 운영에서 중요한 것은 설치 성공이 아니다.
먼저 Direct Play인지 Transcoding인지를 구분하고, transcoding이 필요한 경우 CPU와 HWA 조건을 본다.
그 다음 storage를:
Media / Config / Cache-Transcode
로 나눠 각기 다른 성능과 backup 정책을 적용한다.
이렇게 하면 HDD에 대용량 media를 경제적으로 보관하면서도 SSD/NVMe는 작은 active workload에 집중할 수 있다.
좋은 Jellyfin 서버는 가장 강력한 CPU를 가진 서버가 아니라 가능한 재생은 Direct Play로 처리하고, 피할 수 없는 transcoding만 적절한 hardware와 storage에 맡기는 서버다.