Synology NAS에서 Docker도 사용할 수 있고 Virtual Machine Manager로 Windows도 실행할 수 있다.
그래서 새로운 서비스를 구성할 때 “Docker로 할까, Windows VM으로 할까?”라는 선택이 생긴다.
기술적으로 둘 다 가능하다는 것과 운영적으로 둘 다 적절하다는 것은 다르다.
VM은 완전한 운영체제를 하나 더 실행하는 만큼 isolation과 호환성을 얻지만 더 많은 CPU, RAM, storage I/O와 운영관리 비용을 사용한다.
Docker와 VM의 가장 큰 차이는 OS를 공유하는가다
Container는 host kernel을 공유하면서 application process를 격리한다.
VM은 가상 hardware 위에 별도의 guest OS를 실행한다.
| 항목 | Container | Windows VM |
|---|---|---|
| Guest OS | 별도 전체 OS 없음 | Windows 전체 OS 실행 |
| RAM 사용량 | 상대적으로 작음 | OS 자체 RAM 필요 |
| Boot | 빠름 | OS boot 필요 |
| 격리수준 | Process/container 중심 | 가상 hardware/OS 중심 |
| Windows 전용 GUI 프로그램 | 대부분 부적합 | 적합 |
Linux 서버 애플리케이션이면 먼저 Container 가능성을 본다
Database, web server, automation worker, reverse proxy처럼 Linux container image가 잘 제공되는 서버 애플리케이션이라면 VM을 만드는 것보다 Container가 효율적일 가능성이 높다.
Windows VM을 하나 추가하면 애플리케이션뿐 아니라:
- Windows update
- antivirus/security
- OS disk
- Windows RAM
- guest networking
까지 관리해야 한다.
작은 service 하나 때문에 완전한 OS 한 대를 운영하는 셈이다.
Windows 전용 소프트웨어라면 VM의 존재이유가 명확해진다
반대로 다음 상황은 VM이 자연스럽다.
- Windows에서만 지원되는 application
- Desktop GUI가 필수인 업무프로그램
- Windows service·driver 환경이 필요한 software
- 독립된 Windows test environment
- 특정 Windows version과 application 조합을 장기간 보존해야 하는 경우
이때 VM은 inefficiency가 아니라 compatibility를 확보하기 위한 비용이다.
NAS RAM 20GB라고 VM에 16GB를 줘도 되는 것은 아니다
VM에 RAM을 많이 할당하면 guest는 편해질 수 있지만 DSM과 다른 NAS workload가 사용할 여유가 줄어든다.
NAS에는 동시에:
- DSM
- filesystem cache
- Container
- Database
- backup
- file service
등이 동작할 수 있다.
따라서 VM sizing은 “Windows가 원하는 RAM”과 “NAS 전체가 안정적으로 남길 RAM”을 동시에 봐야 한다.
Synology VMM은 Host를 위한 CPU도 남겨둔다
현재 Synology VMM 공식 사양은 Virtual Machine Manager가 host를 위해 최소 하나의 CPU thread를 예약한다고 명시한다.
따라서 4-thread NAS에서 Windows에 4 vCPU를 할당했다고 물리적으로 Windows 전용 CPU 네 개가 확보되는 식으로 이해하면 안 된다.
vCPU는 scheduler가 공유하는 자원이며 host와 다른 workload가 동시에 CPU를 사용한다.
Windows VM 체감성능은 CPU보다 Storage Latency에 더 민감할 수 있다
Windows는 boot, update, pagefile, antivirus, registry와 많은 작은 파일 접근을 반복한다.
HDD array에서 대용량 순차파일은 잘 처리돼도 작은 random I/O가 집중되면 VM desktop 반응이 답답해질 수 있다.
그래서 VM workload에서는 SSD/NVMe storage를 사용하는 것이 CPU 한 단계 상승보다 체감효과가 클 수 있다.
현재 Synology VMM은 VM data를 Btrfs volume에 저장해야 하므로 실제 배치 전에 model과 volume 구성을 확인해야 한다.
VM Snapshot은 Backup이 아니다
Snapshot은 업데이트 직전이나 configuration 변경 전 빠른 rollback에 매우 유용하다.
하지만 같은 NAS storage 안에 있는 snapshot만으로는:
- NAS 자체 장애
- Volume 손상
- 화재·도난
- 동일 storage 전체 손실
을 대비할 수 없다.
따라서 VM의 중요한 데이터는 별도의 backup 전략이 필요하다.
Guest Tool은 설치 후 성능과 일관성에 영향을 준다
Synology VMM은 Windows용 Guest Tool을 제공한다.
공식 문서에 따르면 VirtIO 기반 virtual disk와 network driver, host와 guest 간 통신지원 및 file-system consistent snapshot 관련 기능을 제공한다.
따라서 Windows 설치 후 기본 emulated device만 사용하는 것보다 지원되는 Guest Tool과 VirtIO 구성을 검토할 가치가 있다.
VM을 NAS의 핵심기능과 너무 강하게 묶지 않는다
NAS 한 대에서:
- 파일 저장
- database
- Docker
- Windows VM
- backup
을 모두 운영할 수 있다.
그러나 가능하다는 것과 failure domain을 한 곳에 모으는 것이 좋은지는 별개의 문제다.
NAS가 재부팅되면 storage뿐 아니라 VM과 container까지 동시에 중단될 수 있다.
따라서 서비스 중요도가 높을수록 “이 NAS 하나가 죽었을 때 함께 멈추는 것은 무엇인가?”를 정리해야 한다.
VM 사용 여부를 판단하는 네 질문
- 이 application은 Linux container로 안정적으로 운영 가능한가?
- Windows 전체 OS가 반드시 필요한 기능이 있는가?
- NAS가 VM에 충분한 RAM·CPU·I/O를 제공할 수 있는가?
- NAS 장애 때 이 VM도 함께 중단돼도 되는가?
첫 번째가 Yes이고 두 번째가 No라면 container가 더 단순할 가능성이 높다.
두 번째가 Yes라면 VM 비용을 받아들이고 안정적으로 분리하는 쪽이 자연스럽다.
결론
Synology VMM의 목적은 Docker 대신 모든 서비스를 Windows에 넣는 것이 아니다.
Container가 해결하기 어려운 운영체제 수준의 호환성·격리·Windows 전용 workload를 NAS 위에서 제공하는 것이다.
따라서 선택 순서는:
애플리케이션 요구사항 → OS 종속성 → resource budget → storage latency → failure domain → backup
이 되어야 한다.
Windows가 필요해서 VM을 만드는 것은 합리적이다. 단순히 익숙하다는 이유로 모든 서버 workload를 Windows VM에 넣으면 NAS 자원을 가장 비싼 방식으로 사용하는 결과가 될 수 있다.