지난 5년간 나는 모든 소프트웨어 개발을 가상 머신(VM)에서 진행해 왔다. 프로젝트마다 전용 VM을 하나씩 두어 의존성 충돌이나 TCP 포트 충돌 같은 골칫거리를 피할 수 있었다.

3년 전에는 한 단계 더 나아가 나만의 홈랩 서버를 직접 구축해 모든 VM을 올려두었다. 수많은 개발 작업의 속도가 빨라지고 안정성도 높아져 정말 훌륭한 투자였다.

지난 몇 달 동안 VM 서버의 한계에 부딪히기 시작했다. 프로젝트들이 점점 더 많은 리소스를 요구하게 되었고, 첫 번째 구축 때 저지른 실수들이 발목을 잡기 시작했다. 그래서 2020년을 위한 완전히 새로운 홈랩 VM 서버를 만들기로 했다.

배경 설명은 필요 없으니 구축 내역만 보여주세요!

이 프로젝트의 ‘왜’에 관심이 없다면 바로 구축 내역으로 건너뛰어도 된다.

왜 VM 서버를 통째로 구축하는가?

처음에는 Windows 데스크톱에서 VirtualBox로 VM을 돌렸다. 한동안은 괜찮았지만 재부팅이 큰 골칫거리가 됐다.

Windows Update로 인한 강제 재부팅, 소프트웨어 설치를 마무리하기 위한 자발적 재시작, 가끔씩 발생하는 OS 충돌까지 겹치면서 한 달에 세 번에서 다섯 번은 개발용 VM 전체를 다시 시작해야 했다.

전용 VM 서버는 이런 재부팅 대부분을 없애준다. VM 호스트에서는 최소한의 소프트웨어만 돌기 때문에 충돌이나 필수 재부팅이 거의 발생하지 않는다.

왜 클라우드를 쓰지 않는가?

클라우드 서버로도 같은 역할을 할 수 있고 직접 하드웨어를 유지보수하는 번거로움(재미!)을 덜 수 있지만, 비용이 터무니없이 비싸다. 내 홈랩 서버와 비슷한 VM 리소스를 AWS EC2 인스턴스로 쓰려면 연간 6000달러 이상이 든다:

필요할 때만 클라우드 인스턴스를 켜고 끄면 비용을 크게 줄일 수 있지만, 그러면 워크플로에 마찰이 생긴다. 로컬 VM 서버가 있으면 비용을 일일이 관리할 걱정 없이 10~20개의 VM을 항상 켜두고 바로 쓸 수 있다.

과거의 실수로부터 배우기

2017년에 구축한 서버는 제 역할을 잘 해냈지만, 3년간 쓰면서 개선이 시급한 몇 가지 핵심 문제점이 드러났다.

1. 스토리지는 로컬에 둬라

내 Synology NAS에는 10.9TB의 저장 공간이 있다. 그 많은 네트워크 스토리지 공간을 보고는 “호스트 OS 부팅에 필요한 최소한 이상으로 서버에 디스크를 달 필요가 있을까?”라고 생각했다.

어리석은 생각이었다.

첫째, 네트워크 스토리지에서 VM을 돌리면 디스크 서버에 완전히 종속된다. Synology는 두세 달마다 OS 업그레이드를 배포하고, 패치할 때마다 재부팅이 필요하다. Synology 스토리지에 VM을 올려둔 상태에서는 Synology 업데이트를 적용하기 전에 VM 전체를 종료해야 했다. Windows 데스크톱에서 VM을 돌릴 때 겪던 재부팅 문제가 그대로 재현된 셈이다.

둘째, 네트워크를 통한 랜덤 디스크 접근은 매우 느리다. 첫 구축 당시에는 백엔드 Python 및 Go 애플리케이션 위주로 개발했고, 디스크 I/O가 많지 않았다. 그 후 프론트엔드 웹 개발로 영역을 넓혔는데, 요즘 웹 프레임워크는 전부 Node.js를 쓰고 프로젝트 하나당 의존성 트리에 1만~20만 개의 랜덤한 JavaScript 파일이 들어간다. Node.js 빌드는 랜덤한 디스크 접근이 엄청나게 많이 일어나는데, 이는 네트워크 스토리지에는 최악의 시나리오다.

2. 더 나은 VM 관리 소프트웨어를 고르자

첫 서버에서는 VM 관리 툴로 Kimchi와 VMWare ESXi 두 가지를 검토했다. VMWare가 훨씬 더 세련되고 성숙했지만, Kimchi의 패기 넘치는 분위기와 오픈소스라는 점에 끌렸다.

설치하자마자 얼마 안 되어 Kimchi 개발이 중단됐다.

시간이 지나면서 Kimchi의 단점은 점점 더 뚜렷해졌다. VM의 ‘복제’나 ‘종료’ 버튼을 여러 번 클릭해야 겨우 동작하는 경우가 많았고, 클릭하려는 순간 버튼이 사라지거나 위치가 바뀌는 어이없는 UI 버그도 있었다.

3. 원격 관리를 염두에 둬라

위 내용을 읽고 “Kimchi는 그냥 소프트웨어인데, 왜 다른 VM 관리자를 설치하려고 서버 전체를 새로 만들었지?”라고 생각했다면, 그건 내가 원격 관리의 중요성을 간과했기 때문이다.

내 VM 서버는 사무실 구석에 놓인, 모니터나 키보드도 연결되지 않은 그냥 PC 한 대다. SSH나 웹 인터페이스로 접속할 수 있는 99%의 시간에는 문제가 없다. 하지만 서버가 부팅에 실패하거나 새 호스트 OS를 설치하려는 나머지 1%의 순간에는 엄청난 고생이 된다. 서버를 책상까지 끌고 와서 데스크톱 키보드와 모니터를 분리하고, 문제를 고친 뒤 사무실의 모든 것을 원래대로 되돌려야 한다.

다음 구축에서는 전원이 켜지는 순간부터 물리적으로 직접 접근하는 것과 같은 수준의 가상 콘솔을 갖추고 싶었다. Dell의 iDRAC이나 HP의 iLO 같은 것을 염두에 두었다.

부품 고르기

CPU

첫 VM 서버의 CPU는 Ryzen 7 1700이었다. 8코어 16스레드로 당시 가장 핫한 CPU였다. 하지만 내 구축기를 /r/homelab, 레딧의 홈랩 커뮤니티에 자랑했을 때, 컨슈머 부품을 썼다고 ‘어설픈 초보’ 취급을 받으며 조롱당했다. 진짜 고수들은 엔터프라이즈 장비를 쓴다는 것이다.

다시는 /r/homelab에서 놀림당하지 않겠다고 다짐하며 엔터프라이즈 서버 하드웨어의 세계로 발을 들였다. 멋도 부려 물리 CPU가 두 개 달린 시스템을 구축하기로 했다.

가성비를 최대한 끌어올리기 위해 4~8년 전에 출시된 중고 CPU로만 검색 범위를 좁혔다. 후보마다 PassMark에서 벤치마크 점수를 조회한 뒤, eBay에서 해당 모델의 최근 중고 거래 가격을 확인했다.

가장 비용 대비 성능이 좋은 것은 Intel Xeon E5 v3 제품군, 그중에서도 2600 모델인 듯했다. 나는 E5-2680 v3로 정했다. 평균 벤치마크가 15,618점이었고 eBay 중고가는 약 130달러였다.

참고로 이전 구축에 썼던 Ryzen 7의 벤치마크는 14,611점이었다. 그러니 듀얼 E5-2680으로 가면 기존 서버보다 처리 성능이 두 배 이상이 되는 셈이다.

메인보드

듀얼 CPU 시스템의 단점은 메인보드 선택지가 제한된다는 것이었다. 듀얼 Intel 2011-v3 CPU를 지원하는 메인보드는 몇 개 되지 않았고, 가격도 300달러에서 850달러까지로 내가 예상했던 것보다 훨씬 비쌌다.

나는 SuperMicro MBD-X10DAL-I-O를 골랐다. 비슷한 메인보드들보다 저렴한 320달러였지만, 그래도 지난번에 샀던 제품보다 다섯 배나 비쌌다.

메모리

서버용 메모리는 선택에 도움이 될 정보가 훨씬 적은 것 같다. 컨슈머 하드웨어라면 여러 웹사이트에서 다양한 RAM 스틱에 대한 리뷰와 벤치마크를 내놓지만, 서버용 RAM에서는 그런 걸 거의 보지 못했다.

믿을 만한 브랜드라는 이유로 Crucial CT4K16G4RFD4213 64GB (4 x 16GB)를 골랐다. 이전 구축에서는 32GB였는데 일부 워크플로가 그 한계에 근접하고 있어서, 앞으로 몇 년은 커버할 수 있도록 용량을 두 배로 늘렸다.

스토리지

M.2 SSD를 좋아한다. 작고 성능도 뛰어나며 케이블 없이 메인보드에 깔끔하게 들어가기 때문이다. 안타깝게도 MBD-X10DAL은 M.2 인터페이스를 지원하지 않는다.

그래서 전통적인 SATA 방식을 고수했다. 1TB Samsung 860 EVO를 샀다. 보통 VM 하나당 40GB를 할당하므로 1TB면 충분히 여유가 있다. 나중에 더 필요하면 디스크를 추가하면 된다.

파워

파워 서플라이(PSU) 고르기는 별로 재미있는 일이 아니라서, 이번에도 믿을 만한 브랜드 위주로 골라 Corsair CX550M 550W 80 Plus Bronze를 선택했다.

내 부품들의 소모 전력을 합치면 400W였으니 450W면 충분했다. 하지만 550W 제품이 10달러밖에 더 비싸지 않아서, 100W의 여유를 위해 그 정도 추가 비용은 합리적이라고 봤다.

내게 중요했던 다른 기능은 세미 모듈러 케이블링이었다. 지난 구축에서는 비모듈러 케이블링을 쓰는 실수를 했는데, 그러면 모든 PSU 케이블이 영구적으로 붙어 있게 된다. 서버 내부 부품이 거의 없으니 남는 전원 케이블이 어지럽게 뒹굴었다. 세미 모듈러 케이블링을 쓰면 쓰지 않는 케이블을 PSU에서 분리해 깔끔하게 정리할 수 있다.

쿨러

듀얼 CPU 구축 때문에 쿨링이 예상치 못한 난관이 됐다. MBD-X10DAL은 두 CPU 소켓 사이 간격이 그리 넓지 않아서, 나란히 들어갈 만큼 얇은 쿨러를 신중하게 찾아야 했다. Cooler Master Hyper 212 두 개가 조건에 딱 맞았다.

케이스

내 서버는 사무실 구석에 눈에 띄지 않게 놓여 있어서 투명 패널이나 화려한 조명이 있는 케이스는 원하지 않았다.

Fractal Design Meshify C Black은 평가가 좋고 심플하고 조용한 케이스 같았다.

그래픽

헤드리스 서버에서는 그래픽 카드가 크게 중요하지 않다. 그래도 초기 설치나 가끔 하는 디버깅 때 화면을 봐야 하니 필요는 해서, 저렴하고 간단한 선택지인 MSI GeForce GT 710으로 정했다.

원격 관리

원격 관리 솔루션을 알아봤는데 가격이 상상을 초월할 정도로 비쌌다. 처음에는 Dell iDRAC을 쓰려고 했지만 원격 콘솔을 쓰려면 300달러짜리 엔터프라이즈 라이선스가 필요하고, 구축도 Dell 부품으로 제한된다. KVM over IP 솔루션을 찾아보니 더 비싸서 600달러에서 1000달러 사이였다.

원격 관리를 구현하기 위해 다소 특이한 방법으로 Raspberry Pi로 직접 KVM over IP 장치를 만들었다. 이름은 TinyPilot이라 지었다.

TinyPilot은 HDMI 출력을 캡처하고 브라우저에서 키보드와 마우스 입력을 전달한다. 실제 키보드, 마우스, 모니터를 직접 연결했을 때와 동일한 접근성을 제공한다. 소프트웨어는 오픈소스이며, 완성된 제품도 구매할 수 있다.

나의 2020년 서버 구축 내역

VM 관리: Proxmox

VM 관리를 위해 Proxmox VE를 쓰고 있다.

지난번에 Kimchi 때문에 데인 뒤로 무료 솔루션을 다시 쓰는 게 내키지 않았다. Proxmox는 12년이나 된 프로젝트라 충분히 믿을 만하다고 느꼈다. 그래픽 측면에서는 Kimchi보다 훨씬 발전했지만, 매끈함에서는 ESXi에 뒤처진다.

Proxmox에서 가장 마음에 드는 부분은 스크립트로 자동화할 수 있다는 점이다. 내가 자주 하는 일 중 하나는 템플릿에서 새 VM을 만들고 Ansible로 추가 소프트웨어를 설치하는 것이다. ESXi에서는 매번 웹 UI에서 버튼을 직접 클릭하지 않으면 이 작업을 할 방법을 찾을 수 없었다. Proxmox에서는 CLI가 강력해서 스크립트로 ./create-vm whatgotdone-dev 한 줄이면 What Got Done 개발용 VM을 새로 만들어낼 수 있다.

가장 큰 불만은 Proxmox가 직관적이지 않다는 것이다. Craft Computing의 설치 튜토리얼을 찾기 전까지는 설치 방법조차 알 수 없었다. 하지만 요령을 익히고 나면 쓰기 쉽다.

벤치마크

구형 VM 서버를 폐기하기 전에 흔히 하는 워크플로에 대해 간단한 벤치마크를 모아 성능 향상을 측정했다.

구형 VM 대부분은 로컬 SSD에 2~3개만 올려두고 나머지는 네트워크 스토리지에 올려뒀기 때문에, 아래 벤치마크에서는 세 가지 시나리오를 비교한다:

• 2017년 서버 (NAS): 네트워크 스토리지에 두던 일반적인 VM
• 2017년 서버 (SSD): 로컬 스토리지에 두던 소수의 VM
• 2020년 서버: 모든 VM이 로컬 SSD에서 돌아가므로 NAS와 SSD 구분 없음

새 VM 프로비저닝

첫 번째로 측정한 벤치마크는 새 VM 프로비저닝이었다. 거의 모든 VM에 쓰는 표준 Ubuntu 18.04 VM 템플릿이 있다. 새 VM이 필요할 때마다 다음 단계를 수행하는 셸 스크립트를 실행한다:

1. 기본 템플릿에서 VM을 복제한다.
2. VM을 부팅한다.
3. 호스트 이름을 ubuntu에서 VM 이름으로 변경한다.
4. 새 호스트 이름을 적용하기 위해 VM을 재부팅한다.
5. apt update && apt upgrade로 최신 소프트웨어를 받아온다.

새 서버 덕분에 이 워크플로가 엄청 빨라졌다. VM 복제 시간은 구형 서버에서 15분이 걸리던 것이 신형 서버에서는 4분 미만으로 줄었다.

패키지 업그레이드 단계를 생략하면 속도 향상이 조금 덜 인상적이다. 그래도 신형 서버는 NAS 스토리지 대비 압도적이어서 8분에서 2분 30초 이내로 단축됐다. SSD 대 SSD로 비교하면 오히려 이전 서버보다 느렸다. VM 복제는 디스크에 영향을 많이 받는데, 구형 M.2 SSD가 신형 SATA SSD보다 빨랐기 때문일 가능성이 크다.

VM 부팅

VM의 전원을 켠 순간부터 로그인 프롬프트가 나타나기까지 얼마나 걸리는가?

구형 VM은 부팅에 48초가 걸렸다. 구형 시스템에서 SSD에 있던 소수의 VM은 32초로 조금 더 빨랐다. 신형 서버는 둘 다 압도하며 VM을 단 18초 만에 부팅했다.

What Got Done 엔드투엔드 테스트 실행

내 주간 기록 앱인 What Got Done에는 기능을 엔드투엔드로 검증하는 자동화된 테스트가 있다. Go 백엔드 컴파일, Vue 프론트엔드 컴파일, 일련의 Docker 컨테이너 빌드, Chrome을 자동화해 앱을 구동하는 등 가장 다양한 작업이 섞인 워크플로 중 하나다. 구형 VM에서 리소스가 바닥났던 워크플로 중 하나라 큰 성능 향상을 기대했다.

놀랍게도 두 서버 사이에 유의미한 성능 차이는 없었다. 콜드 스타트(모든 Docker 베이스 이미지를 다운로드하는 경우)에서는 신형 서버가 구형보다 2% 느렸고, 베이스 Docker 이미지가 로컬에 있을 때는 신형 서버가 구형을 이겼지만 6% 차이에 불과했다. 병목은 주로 디스크와 브라우저 상호작용인 듯해 신형 서버가 큰 차이를 만들지 못했다.

Is It Keto 빌드

자주 하는 워크플로 중 하나는 케토 식단을 위한 내 사이트 Is It Keto를 빌드하는 것이다. Vue용 정적 사이트 생성기인 Gridsome으로 사이트를 생성한다.

상당한 속도 향상을 기대했는데 오히려 빌드가 느려져서 놀랐다. 구형 서버에서는 대부분 CPU에 묶여 있는 것처럼 보였는데, 신형 서버에서 CPU 리소스를 두 배로 늘려도 아무 효과가 없었다. 다음으로 디스크 문제인가 싶어 파일을 RAM 디스크로 옮겨봤지만 빌드 속도는 그대로였다.

내 가설은 이 워크플로가 CPU 바운드이긴 하지만 병렬화가 잘 안 된다는 것이다. 구형 서버는 코어 수는 적지만 코어당 속도가 더 빠르다. 빌드가 5~6개 스레드로 제한된다면 신형 서버의 48코어를 활용할 수 없다.

새로운 Zestful 모델 학습

Zestful은 레시피 재료를 파싱하는 내 머신러닝 기반 API다. 몇 달에 한 번씩 새 데이터로 학습시킨다. 가장 CPU를 많이 쓰는 워크플로라 새 시스템에서 어떻게 처리하는지 궁금했다.

드디어 48개 CPU 코어가 빛을 발하는 경우다! 신형 서버는 구형을 압도하며 모델 학습을 절반 이하의 시간 만에 끝냈다. 아쉽게도 1년에 몇 번만 실행하는 워크플로다.

되돌아보며

컨슈머 하드웨어도 부끄러운 게 아니다

/r/homelab에서 절대 인정을 못 받더라도, 다음 구축 때는 컨슈머 하드웨어로 돌아갈 생각이다.

서버 부품의 가장 큰 장점은 서버 소프트웨어와의 호환성이 더 좋다는 점이라고 본다. 2017년에는 CPU의 멀티스레딩을 끄기 전까지는 ESXi를 설치조차 할 수 없어 성능이 크게 저하됐다. 하지만 그건 리눅스 커널의 한계였고, 이후 업데이트에서 수정됐다.

서버 하드웨어가 프리미엄을 받는 이유는 신뢰성이 더 높기 때문이다. 사용자 대면 서비스에서는 이 특성이 의미가 있지만, 개발 서버에서는 그 중요도가 훨씬 낮다. 개발 서버에서 가끔 충돌이나 비트 플립이 일어난다고 해서 하루가 망치지는 않는다.

듀얼 CPU의 전체 비용을 고려하라

듀얼 CPU 컴퓨터를 직접 만든 건 이번이 처음이었다. 흥미로운 경험이었지만 그만한 가치는 없었다고 생각한다.

벤치마크를 보면 CPU가 워크플로의 병목이 되는 경우는 거의 없었다. 가장 결정적인 증거는 Proxmox의 시간대별 CPU 사용량 그래프다. 지난 몇 달 동안 CPU 부하가 11%를 넘은 적이 한 번도 없어서, 엄청나게 과다 프로비저닝된 셈이다.

듀얼 CPU 요구사항 때문에 메인보드 비용이 크게 올라갔고 선택지도 제한됐다. 듀얼 Intel 2011-v3 CPU를 지원하는 메인보드는 몇 개 되지 않아 다른 메인보드 기능 측면에서도 선택의 폭이 좁았다.

원격 관리는 유연성을 제공한다

TinyPilot으로 서버를 관리하기 전까지는 내가 얼마나 변화를 꺼리는지 몰랐다. BIOS나 네트워크 설정을 바꾸는 것만으로도 앞으로 몇 시간을 기계들을 물리적으로 옮기고 주변 기기를 다시 연결해 디버깅하고 문제를 고치는 데 허비할 위험이 있었다. 그런 걸 아니까 그런 설정을 절대 건드리고 싶지 않았다.

가상 콘솔이 생기니 실패할 자유가 생겼고 다양한 운영체제를 실험하는 데 더 개방적이 됐다. 새로운 OS를 설치하고 배우는 데는 항상 상당한 노력이 들겠지만, 기계를 이리저리 끌고 다니지 않아도 된다는 걸 아니까 훨씬 더 시도해 볼 마음이 생긴다. TinyPilot을 만들지 않았다면 그냥 ‘충분히 괜찮다’며 ESXi에 머물렀을지 모른다. Proxmox에 도전하지 않았을 것이다.

1년 후

이 구축에서 되돌아봤을 때 바꿀 점이 있는지 묻는 독자가 있어서, 서버를 1년 넘게 써본 뒤 업데이트를 공유하고자 한다.

CPU - 과했다

듀얼 E5-2680 v3는 확실히 과했다.

1년간 사용하면서 CPU 사용률이 100%에 도달한 적은 한 번도 없었고, 50%를 넘은 적도 손에 꼽을 정도라 CPU 하나로도 충분했을 것이다.

SSD - 부족했다

1TB Samsung SSD가 거의 꽉 차서 2TB Samsung 870 Evo를 하나 더 구매해 총 3TB의 SSD를 갖추게 됐다. 케이스에는 SSD를 더 장착할 공간이 충분하다.

기본적으로 VM마다 40GB의 디스크를 할당하는데, 가끔은 부족하다. Docker로 작업할 때는 컨테이너 이미지가 디스크를 금방 채운다. 몇 주마다 VM 디스크가 가득 차서 docker system prune --all을 실행해야 했는데, 디스크를 추가하면 그런 중단을 피할 수 있을 것이다.

RAM - 살짝 부족했다

64GB RAM은 대부분 충분했지만, 더 많은 메모리를 확보하려고 VM을 꺼야 했던 경우가 몇 번 있었다. 리소스를 관리하느라 워크플로를 중단하고 싶지 않아 같은 RAM 스틱 64GB를 추가로 주문했다.

Proxmox - 여전히 훌륭하다

VM 관리자로서 Proxmox는 여전히 마음에 든다. 라이선스도 구매했는데, 내가 쓰는 기능 중 새로 추가된 게 있는지는 잘 모르겠지만 프로젝트를 후원한다는 마음으로 기꺼이 구매했다.

짜증나게도 라이선스 가격이 CPU당으로 책정돼서, CPU를 과하게 산 부끄러움에 더해 Proxmox 비용도 두 배로 내야 했다.

부품 목록 (2021-12-05 기준)

* 원래 구축 후 1년 뒤에 구매.