Synology VMM Pro: AI를 활용한 프로덕션 VM 적정 규모 조정 (2026)

이 쇼핑몰을 운영하는 가상 머신은 몇 달 동안 필요한 하드웨어의 두 배를 탑재한 채로 운영되었습니다. 8개의 가상 CPU와 16GB의 메모리를 사용했지만, 실제 작업 부하는 이 중 4분의 1도 채 사용하지 않았습니다. 이는 드문 일이 아닙니다. 처음에는 필요한 용량을 정확히 알 수 없기 때문에 게스트 OS를 넉넉하게 구성하고, 일단 사이트가 잘 작동하면 아무도 설정을 변경하지 않습니다. 이 글은 바로 그 과정을 기록한 것입니다. 우리는 Synology를 사용하여 해당 게스트 OS를 4개의 가상 CPU와 8GB의 메모리로 줄였습니다. VMM Pro, AI 어시스턴트가 셸을 구동하는 상황에서 해당 스토어에 2분 7초 동안 접속할 수 없었습니다. 크기 조정 자체는 지루한 부분입니다. 대화 상자에서 두 개의 필드만 입력하면 되니까요. 흥미로운 부분은 8기가바이트면 충분하다는 것을 입증한 측정, 게스트 OS가 처음 부팅할 때 메모리 부족 현상을 겪지 않도록 하는 작업 순서, 그리고 이 모든 것을 되돌릴 수 있게 해주는 스냅샷입니다. VMM Pro는 이러한 모든 작업을 저렴하게 만들어주며, 이것이 바로 이 칩을 선택해야 하는 가장 확실한 이유입니다.

SynoPower Club 포인트:시스템 크기를 최적화하는 것은 셀프 호스팅에서 가장 화려하지 않은 작업이지만, 가장 큰 효과를 가져오는 작업입니다. 아무도 8기가바이트의 메모리를 절약했다는 이야기를 블로그에 쓰지는 않겠지만, 용량이 너무 큰 게스트 OS에서 유휴 상태로 있는 메모리는 아무런 도움이 되지 않습니다. Synology 스토리지에서는 해당 메모리가 고정되어 있어 시스템 내 다른 어떤 곳에서도 사용할 수 없습니다. 우리는 용량이 거의 꽉 차기 시작한 호스트에서 8기가바이트의 메모리를 확보했고, 덕분에 두 대의 게스트 OS를 위한 하드웨어를 추가로 구매할 필요가 없어졌습니다. 이 작업이 안전했던 이유는 바로 VMM Pro 스토리지 덕분입니다. 첫 번째 명령어를 실행하기 전의 스냅샷이 저장되어 있어, 문제가 발생하더라도 90초 안에 원래 상태로 복원할 수 있었습니다. 다행히 문제는 발생하지 않았지만, 이 스토리지가 없었다면 이 작업을 시작조차 하지 못했을 것입니다.

Synology VMM Pro란 무엇인가요?

Virtual Machine Manager는 Synology의 하이퍼바이저 패키지입니다. 패키지 센터에서 설치할 수 있으며 무료입니다. 단일 NAS에서 Linux, Windows 및 Virtual DSM 게스트 운영 체제를 로컬 스냅샷과 함께 문제없이 실행할 수 있습니다. VMM Pro 이 유료 업그레이드를 통해 단일 박스 하이퍼바이저를 소규모 클러스터로 전환할 수 있습니다. 여러 NAS 장치를 하나의 풀로 관리하고, 게스트가 장치 간에 이동할 수 있으며, 고가용성과 호스트 간 스냅샷 복제를 지원합니다.

이 글에서 중요한 점은 적정 규모 선정은 용량 결정이라는 것입니다. 그리고 용량은 여러 대의 NAS를 사용할 때 비로소 의미가 있습니다. 단일 NAS에서 확보한 메모리는 해당 NAS에서 사용되지 않고 남아 있는 메모리입니다. 하지만 VMM Pro 클러스터에서는 다른 호스트가 장애 조치 시 해당 메모리를 빌려 쓰거나, 추가 비용 없이 새로운 게스트 운영체제를 구축하는 데 사용할 수 있습니다.

A Virtual DSM 게스트(가상 머신으로 실행되는 완전한 DSM 설치 환경)가 여기서 크기를 조정한 워크로드입니다. 이 게스트는 컨테이너 관리자를 실행하고, 컨테이너 관리자는 이 스토어 뒤에서 두 개의 Docker 컨테이너를 실행합니다. 이러한 계층 구조는 의도적인 것이며, 덕분에 작업이 안전하게 진행될 수 있었습니다. 게스트 간 Docker 스택을 이동하는 방법에 대해서는 이전 글에서 다뤘습니다. VDSM Docker 마이그레이션 과정 안내; 이 글은 그 아래에 있는 손님을 적절한 크기로 만드는 것에 관한 것입니다.

VMM Pro와 무료 버전 비교: 업그레이드를 통해 얻을 수 있는 실질적인 이점은 무엇일까요?

무료 버전은 기능이 제한된 데모 버전이 아닙니다. 프로덕션 환경에서 게스트 OS를 실행할 수 있고, 스냅샷도 생성할 수 있으며, 단일 NAS 환경에서는 대부분의 사용자에게 필요한 모든 기능을 제공합니다. 무료 버전을 구매하시면 다음과 같은 혜택을 받으실 수 있습니다. VMM Pro 게스트의 특정 기능에 대한 것이 아니라, 호스트 전체에 걸친 기능입니다.

능력	무료 버전	VMM Pro
하나의 NAS에서 게스트 운영	예	예
로컬 스냅샷	예	예
여러 NAS 장치를 하나의 클러스터로 구성	아니요	예
호스트 간 게스트 이동	아니요	예
고가용성 장애 조치	아니요	예
스냅샷을 다른 호스트로 복제합니다.	아니요	예

구매하시기 전에 참고 자료에 링크된 공식 기능 페이지를 확인하세요. Synology는 DSM 릴리스에 따라 에디션 구분이 변경될 수 있습니다. 실제 사용 방법은 표보다 간단합니다. NAS를 하나만 보유하고 있고 스냅샷에서 수동으로 복원하는 데 문제가 없다면 무료 에디션으로 충분합니다. 하지만 두 번째 NAS를 보유하고 있고 첫 번째 NAS의 게스트 운영 체제가 고장 나더라도 계속 작동하도록 하려면 유료 에디션이 필요합니다. VMM Pro 라이센스.

저희 클러스터는 노드가 세 개인데, 그중 두 개만 대부분 켜져 있습니다. 세 번째 노드는 콜드 스탠바이 상태로, 정해진 스케줄에 따라 깨어나 복제된 스냅샷을 수신하고 다시 절전 모드로 들어갑니다. 이렇게 필요한 경우에만 전력 비용을 지불하는 이중화 패턴을 VMM Pro 패턴이라고 하며, 콘솔에 연결할 수 없는 호스트에 대한 경고가 계속 표시되는 이유도 바로 이 때문입니다. 이 경고는 설계상의 결함이 아니라 정상적인 작동 방식입니다.

제작 게스트가 필요 이상으로 두 배나 커지는 이유

게스트 크기를 늘리는 데에는 세 가지 요인이 있으며, 그 어떤 것도 게스트 크기를 줄이는 데 도움이 되지 않습니다. 첫째, 초기 크기는 추측에 불과하며, 첫날에는 넉넉하게 설정해도 비용이 들지 않습니다. 둘째, 모든 문제는 결국 누군가가 제한을 늘리는 것으로 해결됩니다. 저희 시스템에서는 한 주 동안 두 번의 메모리 부족 문제가 발생했는데, 두 경우 모두 공간을 더 확보해 줌으로써 해결되었고, 이후 다시는 문제가 발생하지 않았습니다. 셋째, 대시보드에서 메모리 사용량이 80%에 달하는 것은 위험해 보이기 때문에 아무도 자발적으로 메모리를 줄이려 하지 않습니다. 이 모든 것은 VMM Pro의 문제가 아닙니다. 이는 사람의 문제이며, 바로 이 때문에 게스트 크기가 과도하게 설정되는 것이 일반적입니다.

마지막 부분이 바로 함정인데, 분명히 말씀드리자면 대부분의 사람들이 컨테이너 용량 부족 여부를 판단할 때 참고하는 수치는 잘못된 수치입니다. 저희 시스템에서는 데이터베이스 컨테이너가 용량의 81%를 사용 중이라고 표시했지만, 실제로는 그렇지 않았습니다. 5절에서는 그 이유와 VMM Pro 컨테이너의 크기 조정을 단순한 희망적인 결정이 아닌 안전한 결정으로 만들어준 측정 방법에 대해 자세히 설명합니다.

VMM Pro를 사용하여 라이브 게스트 규모를 4단계로 최적화하는 방법

전체 작업은 4단계로 구성되며, 세 번째 단계에서만 사이트가 오프라인 상태가 됩니다. 컨테이너가 중지된 순간부터 게스트가 다시 접속하여 첫 번째 HTTP 200 응답을 받을 때까지의 총 다운타임은 2분 7초였습니다. VMM Pro 1단계와 3단계에는 관여하지만, 중간 단계는 고객 내부에서 이루어집니다.

Docker 통계가 정답을 놓치게 만드는 이유

크기 조정 전에는 컨테이너 대시보드가 마치 여유 공간이 전혀 없는 기계처럼 보였습니다.

docker stats WordPress 2.51 GiB / 7 GiB (35.9%) WordPress-DB 3.25 GiB / 4 GiB (81.1%) <-- 거의 꽉 찬 것 같습니다

저 내용을 읽고 데이터베이스에 4기가바이트가 필요하고 게스트 운영 체제는 12기가바이트 미만으로 내려가면 안 된다고 결론짓게 될 겁니다. 하지만 두 가지 결론 모두 틀렸습니다. 해당 도구들이 보고하는 메모리 사용량에는 페이지 캐시가 포함되어 있는데, 다른 프로세스가 메모리를 필요로 하는 순간 페이지 캐시는 자동으로 회수되기 때문입니다. 메모리 부족으로 인한 시스템 종료 여부를 결정하는 것은 익명 메모리 사용량입니다. 직접 확인해 보세요.

도커 실행 sh -c 'awk "/^(cache|rss) /{printf "%-8s %8.0f MBn", $1, $2/1048576}" /sys/fs/cgroup/memory/memory.stat' WordPress RSS 1305 MB 캐시 1609 MB WordPress-DB RSS 2553 MB 캐시 1543 MB

이제 상황이 반전됩니다. 애플리케이션 컨테이너는 실제로 2.5GB가 아닌 1.3GB를 사용하고 있습니다. 그리고 그 1.3GB 중 768MB는 모든 워커 프로세스가 복사하는 것이 아니라 매핑하는 단일 공유 오퍼코드 캐시입니다. 따라서 20개의 워커 프로세스는 각각 약 27MB의 메모리를 사용하며, 단순히 프로세스 메모리를 합산했을 때 나오는 250MB가 아닙니다. 데이터베이스의 2.5GB는 거의 대부분 663MB 데이터베이스에 대한 3GB 크기의 버퍼 풀입니다.

같은 계열의 또 다른 함정: 기록상 최고 사용량 카운터는 컨테이너가 한계에 도달했음을 보여주는데, 이는 해당 카운터에 페이지 캐시도 포함되기 때문입니다. 저희 컨테이너 두 대 모두 그랬습니다. 하지만 둘 다 메모리 부족으로 종료된 적은 없었습니다. 최고 사용량 기록이 아니라 메모리 부족 카운터를 확인하세요.

이 두 가지 사실을 확인한 후, 8기가바이트는 더 이상 위험한 수치가 아니었습니다. 버퍼 풀을 1기가바이트로 줄였는데, 이는 여전히 전체 데이터베이스보다 훨씬 큰 크기이며, 크기 조정에 필요한 것보다 훨씬 더 많은 실제 메모리를 확보할 수 있었습니다. 결국 VMM Pro에 입력한 값은 게스트 OS를 종료하기 전에 이미 검증된 값이었습니다.

소규모 팀이 VMM Pro를 사용하여 서버 전체를 복구하는 방법

Synology 게스트의 메모리는 고정되어 있습니다. 하이퍼바이저가 메모리를 잠그고 미리 할당하기 때문에 다른 플랫폼처럼 메모리를 과도하게 할당할 수 없습니다. 게스트에 할당된 16기가바이트는 해당 게스트가 사용 중이든 유휴 상태이든 다른 어떤 게스트도 사용할 수 없습니다. 이러한 제약 조건 때문에 메모리 적정 크기 조정이 중요합니다. VMM Pro 구체적으로 말하자면, NAS를 구입하지 않고 용량을 확보하는 유일한 방법은 메모리를 확보하는 것입니다.

총 46.83GB의 메모리를 가진 호스트에서 8GB의 응답이 왔습니다. 사용 가능한 메모리는 약 22GB에서 30.29GB로 줄었습니다. 실질적으로 이는 우리가 실제로 사용하는 크기의 게스트를 두 개 더 추가하는 것과 같습니다. 3개 노드로 구성된 클러스터에서 이는 또한 장애가 발생한 노드의 게스트를 나머지 호스트가 수용할 수 있는 여유 공간을 더 많이 확보한다는 것을 의미하며, 이는 VMM Pro를 구매하는 근본적인 이유입니다.

CPU 측면에서도 상황은 더욱 명확하게 드러났습니다. 게스트 운영체제는 8개의 가상 CPU를 가지고 있었지만, 유휴 상태에서는 코어 하나당 약 6분의 1 정도만 사용하고 있었습니다. 4개로 줄인 것은 타협이 아니었습니다. 4개도 여전히 충분한 용량이며, VMM Pro는 이를 단일 필드에 적용했습니다. 크기 조정 후 게스트 운영체제는 4개의 가상 CPU에 대해 평균 부하 1.36을 기록했는데, 이는 하루 중 가장 사용량이 많은 시간대에도 약 3분의 1 정도만 활용되고 있음을 의미합니다.

부팅 시 메모리 부족 루프를 방지하는 작업 순서

이 부분이 실수하기 쉽고, 실수하면 큰 비용이 드는 부분입니다. 컨테이너 메모리 제한과 VMM Pro에서 설정한 게스트 메모리는 서로 다른 상한선이며, 컨테이너 제한의 합이 게스트 메모리를 초과하면 컨테이너에게 시스템이 보유한 메모리보다 더 많은 메모리를 사용할 수 있다고 알려주는 셈이 됩니다. 부하가 걸리면 커널은 프로세스를 종료하여 이러한 불일치를 해결합니다.

변경 전 우리의 제한 용량은 애플리케이션 컨테이너의 경우 7기가바이트, 데이터베이스의 경우 4기가바이트였습니다. 16기가바이트 게스트 운영체제에서는 11기가바이트까지 허용되었는데, 이는 문제가 없었습니다. 하지만 8기가바이트 게스트 운영체제에서는 첫 번째 트래픽 급증만으로도 문제가 발생할 수 있었습니다. 따라서 컨테이너를 먼저 종료해야 했습니다.

환경	전에	후에
손님	8 vCPU / 16GB	4 vCPU / 8GB
애플리케이션 컨테이너 제한	7168MB	4096MB
데이터베이스 컨테이너 제한	4096MB	2048MB
데이터베이스 버퍼 풀	3GB	1GB
데이터베이스 최대 연결 수	300	100
아파치 워커 천장	50	35

해당 표에는 숨겨진 2차 규칙이 있습니다. 컨테이너의 메모리 제한을 현재 사용량보다 낮추면 커널이 이를 문제없이 처리할 것이라고 기대할 수 없습니다. 애플리케이션 컨테이너는 새 제한보다 적은 메모리를 사용하고 있었기 때문에 재시작이나 다운타임 없이 즉시 메모리 사용량이 제한되었습니다. 데이터베이스 컨테이너는 더 많은 메모리를 사용하고 있었기 때문에 버퍼 풀을 재구성하고 컨테이너를 먼저 재시작해야 했습니다. 그런 다음 낮은 제한을 적용할 수 있었습니다. VMM Pro 버전에서는 이러한 단계가 모두 수행되지 않습니다. 크기 조정 대화 상자를 열기 전에 두 단계 모두 완료해야 합니다.

작업자 수 제한은 전체 프로젝트에서 가장 큰 비용이며, 숨기기보다는 명확히 밝혀야 할 부분입니다. 애플리케이션 컨테이너 용량을 7기가바이트에서 4기가바이트로 줄이면 동시에 처리할 수 있는 요청 수가 50개에서 35개로 줄어들어 최대 동시 접속량이 30% 감소합니다. 평소에는 사이트가 11개의 작업자로 운영되므로 큰 변화는 없습니다. 광고 트래픽이 폭증하는 기간에는 변동될 수 있습니다. 이는 우리가 의도적으로 결정한 사항이며, 추후 시스템 장애 발생 시 담당자가 이를 다시 발견하지 않도록 기록해 두었습니다.

AI 비서가 실제로 한 일과 잘못된 점은 무엇일까요?

보조 기능은 인내심을 요구하는 부분들을 처리했습니다. 아무것도 건드리기 전에 VMM Pro 스냅샷을 찍고, 대시보드를 신뢰하는 대신 cgroup 통계를 읽고, 컨테이너 제한에 대한 순서 제약 조건을 계산하고, 실제 페이지를 가져와 가격이 올바른 통화로 표시되는지 확인하여 결과를 검증했습니다. 이는 약 40분 정도 걸리는 세심한 작업을 단 몇 분 만에 압축한 것으로, 실제로 매우 유용합니다.

한 번의 세션에서 세 번이나 틀렸다는 점도 이야기의 더 유용한 부분입니다.

• 사용자가 8기가바이트를 요청했는데도 프로그램은 10기가바이트를 권장했습니다. 사용자의 요청이 맞았지만, 이는 버퍼 풀 크기가 동시에 조정되었기 때문입니다. 프로그램은 측정값을 눈앞에 두고도 여전히 더 안전한 수치를 고수했습니다.
• 손님의 이름을 바꿨습니다. 성공: 참 API에서 이름을 변경하는 요청을 받았고, 변경이 완료되었다고 보고했습니다. 하지만 실제로는 이름이 변경되지 않았습니다. API에서 사용한 이름 변경 필드는 게스트를 식별하는 필드였지, 이름을 변경하는 필드가 아니었으며, API는 이름 변경 여부와 관계없이 성공을 반환합니다.
• 해당 시스템은 연결할 수 없는 호스트에 대한 VMM Pro 클러스터 경고를 감지하고 이를 성능 저하된 페일오버 경로로 표시했습니다. 해당 호스트는 의도적으로 전원이 꺼진 콜드 스탠바이 호스트였습니다. 이 경고는 설계상 몇 달 동안 표시되어 있었습니다.

세 가지 경우 모두 패턴은 동일합니다. 즉, 타당한 검증을 통해 확실한 결과를 얻는 것입니다. 따라서 실제로 중요한 안전장치는 그다지 화려하지 않습니다. 위험한 명령을 실행하기 전이 아니라, 첫 번째 명령을 실행하기 전에 항상 스냅샷을 찍으십시오. 반환 값을 증거로 절대 받아들이지 마십시오. 상태를 다시 읽고 변경하려던 필드를 확인하십시오. 그리고 설정이 아닌 동작을 검증하십시오. 페이지가 제대로 로드되고 가격이 정확한 것이 명령이 실패했다는 어떤 확인보다도 더 중요합니다.

그런 자질들은 인공지능에만 국한된 것이 아닙니다. 마치 루트 권한을 가진 새로운 동료에게 기대하는 것과 같은 자질이죠. 빠르고, 지칠 줄 모르고, 때로는 사실이 아닌 것에 대해 확신하는 모습도 보일 수 있으니까요.

더 많은 공식 자료를 찾을 수 있는 곳

VMM Pro로 이미지 크기를 조정하기 전에 꼭 봐야 할 영상 세 편입니다. 첫 번째 영상은 패키지 자체에 대한 가장 좋은 개요를 제공하고, 나머지 두 영상은 게스트 생성 및 라이선스 부여에 대한 내용인데, 대부분의 사용자가 처음 시도할 때 어려움을 겪는 부분입니다.

VMM Pro를 생산 현장에 투입하기 전에 알아야 할 한계점

메모리는 과도하게 할당할 수 없습니다. 할당하는 모든 기가바이트는 NAS의 다른 모든 데이터(사용 중인지 여부와 관계없이)와 완전히 분리되어 관리됩니다. 이러한 제약 조건 때문에 적정 용량으로 메모리를 할당하는 것이 중요하며, 초기 설정 단계에서 여유 있게 메모리를 할당하는 것이 과도한 할당이 가능한 플랫폼보다 오히려 비용 부담이 커지는 이유이기도 합니다.

메모리 크기를 줄이려면 재부팅이 필요합니다. VMM Pro는 실행 중인 게스트 운영 체제에서 메모리를 제거하지 않기 때문입니다. 가상 디스크 크기 증가는 실시간으로 이루어지며, 일부 리소스 크기 증가도 마찬가지입니다. 하지만 메모리 크기를 줄이려면 게스트 운영 체제를 종료해야 합니다. 따라서 짧은 시간 동안 시스템 중단이 발생할 수 있으므로 미리 일정을 계획하십시오. 2분 정도는 가능하지만, 완전히 중단되지는 않습니다.

가상 디스크는 커지기만 하고 줄어들지 않습니다. 메모리가 아닌 스토리지를 과도하게 할당한 경우, VMM Pro 돌려주지 않을 겁니다. 유일한 방법은 새로운 게스트를 생성하고 그곳으로 이동하는 것인데, 이는 오늘 오후보다 훨씬 더 긴 시간이 걸릴 겁니다.

컨테이너 내부의 CPU 제한이 전혀 작동하지 않을 수 있습니다. 이 게스트 운영체제에서는 커널에 CFS 대역폭 제어 기능이 없으므로 컨테이너 CPU 할당량이 완전히 거부됩니다. 더 심각한 문제는 메모리 제한과 CPU 할당을 같은 명령에서 설정하려고 하면 전체 명령이 오류 메시지 없이 실패한다는 것입니다. 따라서 메모리 제한과 애플리케이션 자체의 워커 메모리 제한만이 유일하게 사용 가능한 CPU 보호 수단입니다.

스냅샷은 백업이 아닙니다. 스냅샷은 보호 대상 게스트와 동일한 호스트 및 스토리지 풀에 저장됩니다. VMM Pro는 스냅샷을 더 가까운 다른 호스트로 복제할 수 있지만, 화재 발생 시 실제로 남는 것은 데이터 자체의 오프사이트 백업입니다.

마지막으로 콘솔에 표시되는 내용을 살펴보세요. 컨테이너 상세 페이지에는 환경 변수가 데이터베이스 암호를 포함하여 일반 텍스트로 표시됩니다. 이는 Docker 패키지의 결함이 아니라 Docker가 솔직하게 정보를 공개하는 방식이지만, 잘못된 페이지의 스크린샷 한 장만으로도 자격 증명이 노출될 수 있다는 의미입니다. 만약 이 점이 신경 쓰인다면(당연히 신경 써야 합니다), 암호 정보를 변수로 전달하는 대신 컨테이너가 읽는 파일에 저장하는 방법을 사용하세요.

참고문헌

• SynoPower Club, 저희 Synology NAS 가이드 및 카메라 리뷰도 확인해 보세요.
• Synology — Virtual Machine Manager, 공식 기능 및 에디션 비교
• Synology 지식 센터 — Virtual Machine Manager 도움말, 게스트 설정 및 클러스터 설정
• Docker — Docker 컨테이너 업데이트, 실행 중인 컨테이너의 메모리 제한을 변경하는 것
• 아파치 — MaxRequestWorkers, 제7절에서 논의된 근로자 상한선

자주 묻는 질문