MacBook 수백 대를 데이터센터에, macOS 가상머신은 한 대에 두 개

iOS 앱을 빌드하고 테스트하는 일은 Mac에서만 됩니다. 시뮬레이터가 macOS 위에서 돌고, App Store에 올리려면 최신에 가까운 Xcode가 필요합니다. Namespace는 이 작업을 데이터센터에서 처리하려고 MacBook 수백 대를 랙에 넣었고, 11월 3일 그 과정을 정리한 엔지니어링 글을 공개했습니다.

Mac mini가 데이터센터에 더 어울리는 기기인데도 노트북을 골랐습니다. 1월에 주문한 Mac mini가 7월에 도착했기 때문입니다.

이 글에서 배울 것은 하드웨어 선택이 아닙니다. Mac을 수십 대 이상 굴릴 때 실제 병목은 원격 관리, 디스크 잠금 해제, 이미지 배포라는 점입니다.

Mac mini를 기다릴 수 없어서 노트북을 골랐다

Mac mini는 데이터센터용으로 나온 기기는 아닙니다. 원격 관리 기능이 기초 수준이고, 전원이 이중화되지 않으며, 어느 방향으로 눕혀도 냉각이 까다롭습니다. 그래도 이 회사는 그 문제를 감당할 방법을 갖고 있었습니다. 발목을 잡은 것은 납기였습니다.

1월에 주문한 물량이 7월에 도착했습니다. Apple이 새 CPU를 모든 기기에 동시에 넣지 않는 점도 겹쳤습니다. Mac mini에는 M5 코어가 10개월 늦게 들어왔습니다.

노트북은 화면과 키보드, 배터리가 낭비처럼 보입니다. 대신 랙에 맞춰 준비할 것이 늘어납니다. 대당 IP KVM을 붙이고, 외장 10기가비트 이더넷을 달고, 전원과 관리 케이블을 넣습니다. 노트북 한 대에 케이블 4개, 선반 하나에 48개가 됩니다.

노트북 펌웨어는 화면이 있는 기기를 전제로 만들어졌습니다. 그래서 일부 유지보수는 GUI에서 버튼을 눌러야만 됩니다. 뚜껑이 닫힌 채 랙에 꽂힌 노트북에서는 IP KVM이 유일한 손이 됩니다.

냉각은 맞춤 홀더로 풉니다. 열점에서 열을 빼내 주변 기기로 불지 않고 밖으로 보내는 형상입니다. 서버처럼 전면 기류를 설계할 수 없는 폼팩터라 선반 단위로 다시 짜야 합니다.

예상 못 한 복병은 HDMI와 FileVault

MagSafe가 쉽게 빠질까 걱정했지만 실제로는 거의 없었습니다. 가장 불안정한 케이블은 HDMI였습니다. 두껍고 뻣뻣해서 선반을 건드릴 때마다 빠졌습니다. 결국 원하는 각도로 휘는 케이블을 찾아 아마존 재고까지 사들였습니다.

더 성가신 것은 디스크 암호화였습니다. 예정에 없이 재부팅하면 FileVault 잠금 해제 암호를 화면에 띄웁니다. 랙 안에서 뚜껑이 닫힌 노트북의 화면에 뜨는 셈입니다.

KVM으로 보려 해도 5분 동안 입력이 없으면 프롬프트가 사라집니다. macOS Tahoe가 넣은 SSH 원격 잠금 해제도 노트북에서는 5분 뒤 만료됩니다. 남은 방법은 물리 버튼을 눌러 재부팅한 뒤 시간 안에 잠금을 푸는 것입니다. 글은 이때 fdesetup authrestart를 쓰라고 팁을 남깁니다.

버그도 있습니다. 특정 조건에서 외장 USB 네트워크 어댑터가 전원이 없는 것처럼 멈춥니다. 케이블과 어댑터, 스위치 포트를 모두 바꿔도 그대로입니다. 네트워크 설정에서 해당 서비스를 지웠다 다시 만들면 살아납니다.

Mac 한 대에 macOS 가상머신은 두 개

가상화는 Apple의 Virtualization framework로 돌립니다. 구조는 Firecracker에 대응하고, 그 아래 Hypervisor framework는 KVM에 해당합니다. QEMU도 Hypervisor를 쓰지만 macOS 게스트는 실행하지 못합니다.

제약이 하나 있습니다. Apple은 물리 Mac 한 대에서 macOS 가상머신을 두 개까지만 허용합니다. 24코어에 192GB 메모리를 가진 Mac Pro라도 두 개입니다.

그래서 자원을 절반으로만 나눕니다. 14코어 Mac mini는 관리용 2코어를 빼고 6코어와 6코어로, 18코어 MacBook은 8코어와 16코어로 쪼갭니다. 가상머신마다 프로세스가 따로 서서 커스텀 장치를 붙일 때마다 프로세스 경계를 넘는 통신이 붙습니다.

네트워크는 고객 코드를 신뢰하지 않는 전제로 짰습니다. gVisor 프로젝트의 사용자 공간 TCP/IP 스택을 가져와 게스트가 주고받는 패킷을 전부 소프트웨어로 검사하는 게이트웨이와 방화벽을 둡니다. 대신 통신 비용이 붙어 측정 상향 속도는 4Gbps로, 회선 속도에는 못 미칩니다.

2테라바이트 이미지를 수백 대에 뿌리는 법

이미지는 금방 커집니다. iOS 런타임만 수백 기가바이트이고, 이전 macOS를 테스트하려면 또 한 벌이 필요합니다. Xcode 베타는 설치할 때 안정판이 쓰는 CoreDevice와 CoreSimulator의 전역 버전을 올려, 같은 기기에서 안정판 동작까지 흔듭니다. 그래서 베타가 들어간 이미지와 아닌 이미지를 따로 관리하게 되고, 합계가 2테라바이트가 됩니다.

빌드는 사람이 설치하듯 재현합니다. 셸 명령을 실행하고, UI 버튼을 누르고, 재부팅하고, VNC로 화면을 다루는 순서를 YAML 워크플로로 적어 반복합니다. 결과물은 리눅스·윈도 이미지와 같은 OCI 레지스트리에 넣습니다.

저장은 두 가지로 줄입니다. 비어 있는 구간은 몇 바이트만 차지하게 두고, 같은 계열 이미지는 베이스 레이어를 공유한 채 바뀐 블록만 델타로 쌓습니다.

배포가 더 큰 문제입니다. 네트워크 블록 장치로 원격 디스크를 붙이면 입출력마다 통신 비용이 붙어 느립니다. 그래서 각 노드의 SSD에 이미지를 직접 만듭니다. 노드마다 중앙에서 받으면 0.5페타바이트가 오가므로, 블록을 레지스트리에서 한 번만 받고 피어끼리 복제해 라운드마다 사본을 두 배로 늘립니다. 디스크에서는 APFS의 희소 파일과 clonefile로 블록을 공유합니다.

원문 반응: Apple이 서버를 팔아야 한다

GeekNews에 소개된 해커뉴스 의견은 Apple 쪽을 향합니다. "Apple 자체의 버그와 제약을 우회하려고 이렇게 많은 문제를 풀고 있다는 사실이 인상적"이라며, Mac mini와 성능은 같고 가격은 두 배인 새 Xserve가 나와도 살 사람이 있을 것이라고 봅니다.

구체적인 요구도 나옵니다. 2U에 Mac mini 8대, 듀얼 10기가비트 이더넷, 공용 이중화 전원, 데이터센터에 맞는 방열판을 갖추면 이상적인 CI 플랫폼이 된다는 것입니다. Apple 내부도 같은 도구를 쓰니 Xcode Cloud와 자동화 도구가 형편없다는 지적이 놀랍지 않다는 말도 붙습니다.

기기 값보다 운영 비용이 큽니다. IP KVM과 전원 이중화, 잠금 해제 정책, 이미지 배포 파이프라인을 갖추지 않으면 대수가 늘수록 사람이 직접 랙을 찾아가야 합니다.

새 Mac mini를 사서 랙에 넣을 계획이라면 세대 차이도 봐야 합니다. 글에 따르면 M5·M6 Mac mini는 내장 10기가비트 네트워크, 전원이 들어오면 자동 부팅, MDM만으로 초기 구성이 되는 특징이 있어 이전 세대보다 관리가 단순합니다.

Mac을 여러 대 굴릴 계획이라면 기기 선택보다 원격 관리와 이미지 배포 설계를 먼저 하세요.