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

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

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

배경 이야기는 됐으니 구축 내역이나 보여주세요!

이 프로젝트의 ‘이유’가 궁금하지 않다면 바로 구축 내역으로 건너뛰셔도 됩니다.

왜 굳이 VM 서버를 따로 만들까요?

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

Windows Update 때문에 강제로 재부팅해야 할 때도, 소프트웨어 설치를 마무리하려고 직접 재시작할 때도, 가끔 OS가 충돌할 때도 있었습니다. 그때마다 개발용 VM 전체를 한 달에 세 번에서 다섯 번은 다시 시작해야 했습니다.

전용 VM 서버를 쓰면 대부분의 재부팅을 피할 수 있습니다. VM 호스트에는 최소한의 소프트웨어만 돌리기 때문에 충돌이나 강제 재부팅이 거의 발생하지 않습니다.

왜 클라우드 컴퓨팅을 쓰지 않나요?

클라우드 서버도 같은 역할을 할 수 있고 하드웨어를 직접 유지보수하는 수고(재미!)를 덜 수 있지만, 비용이 너무 비쌉니다. 제 홈랩 서버와 비슷한 사양의 VM 리소스를 AWS EC2로 쓰면 연간 6,000달러가 넘게 듭니다:

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

지난 실수에서 배우기

2017년에 만든 서버는 제 역할을 잘 해주었지만, 3년간 쓰면서 꼭 개선해야 할 몇 가지 문제점이 분명해졌습니다.

1. 스토리지는 로컬에 두기

제 Synology NAS는 10.9TB의 저장 공간을 갖추고 있습니다. 네트워크 스토리지가 이렇게 넉넉하니 “호스트 OS 부팅에 필요한 최소 용량 이상으로 서버에 디스크를 달 필요가 있을까?”라고 생각했습니다.

결과적으로 어리석은 생각이었습니다.

첫째, VM을 네트워크 스토리지에서 돌리면 디스크 서버에 완전히 종속됩니다. Synology는 두세 달마다 OS 업그레이드를 내놓고, 패치할 때마다 재부팅이 필요합니다. VM이 Synology 스토리지에 올라가 있으니 Synology 업데이트를 적용하려면 VM 전체를 끄고 해야 했습니다. Windows 데스크톱에서 VM을 돌릴 때 겪던 재부팅 문제가 그대로 반복된 셈입니다.

둘째, 네트워크를 통한 랜덤 디스크 접근은 느립니다. 처음 서버를 만들 당시에는 주로 백엔드 Python과 Go 애플리케이션을 개발해서 디스크 I/O가 많지 않았습니다. 이후 프론트엔드 웹 개발까지 확장하면서 상황이 달라졌습니다. 요즘 웹 프레임워크는 대부분 Node.js를 쓰고, 프로젝트마다 의존성 트리에 1만 개에서 20만 개에 이르는 자바스크립트 파일이 무작위로 흩어져 있습니다. 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스레드로 당시 가장 핫한 신제품이었습니다. 하지만 이 구축을 레딧의 홈랩 커뮤니티인 /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 두 개가 조건에 딱 맞았습니다.

케이스

서버를 사무실 구석에 눈에 띄지 않게 두고 있어 투명 패널이나 화려한 LED가 있는 케이스는 원하지 않았습니다.

Fractal Design Meshify C Black은 평가가 좋았고 심플하고 조용한 케이스처럼 보였습니다.

그래픽

헤드리스 서버에서는 그래픽 카드가 크게 중요하지 않습니다. 그래도 초기 설치나 가끔 디버깅할 때 화면을 봐야 하므로 저렴하고 무난한 MSI GeForce GT 710을 선택했습니다.

원격 관리

원격 관리 솔루션을 알아보니 가격에 깜짝 놀랐습니다. 처음에는 Dell iDRAC을 쓰려 했지만 원격 콘솔을 쓰려면 300달러짜리 엔터프라이즈 라이선스가 필요하고 Dell 부품으로 구축이 제한됩니다. KVM over IP 솔루션도 알아봤지만 600달러에서 1,000달러로 더 비쌌습니다.

원격 관리를 구현하기 위해 다소 독특한 방법으로 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 용량이 몇 개 VM만 담을 정도로 작아 네트워크 스토리지에서 돌렸습니다. 아래 벤치마크에서는 세 가지 시나리오로 성능을 비교합니다:

• 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끼리 비교하면 오히려 이전 서버보다 느립니다. VM 복제는 디스크에 영향을 많이 받는 작업인데, 예전 M.2 SSD가 새 SATA SSD보다 빨랐기 때문으로 보입니다.

VM 부팅

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

기존 VM은 부팅에 48초가 걸렸습니다. 기존 시스템에서 SSD에 있던 일부 VM은 조금 더 빨라 32초 만에 로그인 프롬프트가 떴습니다. 새 서버는 이 두 경우를 모두 압도하며 단 18초 만에 VM을 부팅합니다.

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

제가 만든 주간 기록 앱 What Got Done에는 기능을 처음부터 끝까지 검증하는 자동화된 테스트가 있습니다. Go 백엔드 컴파일, Vue 프론트엔드 컴파일, 일련의 Docker 컨테이너 빌드, Chrome 자동화를 통한 앱 구동까지 포함된 가장 다양한 작업 중 하나입니다. 기존 VM에서 리소스를 고갈시키던 작업이라 큰 성능 향상을 기대했습니다.

놀랍게도 두 서버 간에 유의미한 성능 차이는 없었습니다. 콜드 스타트(모든 Docker 베이스 이미지를 다운로드하는 경우)에서는 새 서버가 오히려 2% 느렸습니다. 베이스 Docker 이미지가 로컬에 있을 때는 새 서버가 기존 서버를 이기긴 했지만 6% 차이에 불과했습니다. 병목이 주로 디스크와 브라우저 상호작용에 있는 듯해 새 서버가 큰 차이를 만들지 못하는 것으로 보입니다.

Is It Keto 빌드

제가 자주 하는 작업 중 하나는 키토 다이어터를 위한 자료 사이트인 Is It Keto를 빌드하는 것입니다. Gridsome이라는 Vue용 정적 사이트 생성기로 사이트를 생성합니다.

여기서도 큰 속도 향상을 기대했지만 오히려 빌드가 느려져 놀랐습니다. 기존 서버에서는 빌드가 주로 CPU에 의해 제한되는 것처럼 보였는데, 새 서버에서 CPU 리소스를 두 배로 늘려도 효과가 없었습니다. 다음으로 디스크 문제인가 싶어 파일을 RAM디스크로 옮겨 보았지만 빌드 속도는 그대로였습니다.

제 가설은 이 작업이 CPU 바운드이긴 하지만 병렬화가 잘 되지 않는다는 것입니다. 기존 서버는 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을 만들지 않았다면 Proxmox에 도전하기보다 ESXi를 ‘그럭저럭 쓸 만하다’며 계속 썼을지도 모릅니다.

1년 후

한 독자분이 돌이켜봤을 때 이 구축에서 바꾸고 싶은 점이 있는지 물어보셔서, 이 서버를 사용한 지 1년이 조금 넘은 시점에서 업데이트를 공유하려 합니다.

CPU - 과했습니다

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

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년 뒤에 구매했습니다.