가장 비효율적인 datacenter 구축 가이드

구축 목표

이 사이트의 모든 가이드는 올바른 방법을 가르칩니다. 명령어를 순서대로 실행하는 법, 올바른 결과의 형태, 그리고 실패 유형을 명시합니다. 이 가이드는 다릅니다. 오늘은 가상으로, 돈과 전기, 그리고 자만심이 만들어낼 수 있는 가장 비효율적인 datacenter를 설계할 것입니다.

측정 지표가 필요하므로 업계 표준인 PUE(Power Usage Effectiveness)를 사용합니다. 이는 전체 시설 전력을 컴퓨팅 장비에 실제로 도달하는 전력으로 나눈 값입니다. Hyperscale datacenter는 약 1.1로 작동하며, 거의 모든 와트가 유용한 작업에 사용됩니다. 적절한 enterprise server room은 1.5를 관리합니다. 우리의 목표는 4.0 이상입니다. 이는 컴퓨팅에 1와트를 쓸 때마다 3와트가 아무런 이득 없이 낭비됨을 의미합니다. 우리는 이 수치를 전문 가이드가 백업을 언급하듯 자주 사용할 것입니다.

Site selection: 핵심은 열기

냉각은 실제 datacenter에서 가장 큰 오버헤드입니다. 따라서 우리의 설계는 열역학 법칙에 정면으로 도전할 것입니다. 이상적인 위치는 다락방입니다. 남향이어야 합니다. 가급적 skylight를 서버 바로 위에 배치하여, 기계가 자체 폐열과 태양열을 동시에 받도록 합니다. 이는 전기 요금과 항성이 협력하는 구조입니다.

겨울철 냉각은 창문을 여는 방식으로 해결합니다. 실제 datacenter도 외부 공기를 사용합니다. 이를 free cooling이라고 하며, 정밀하게 설계, 여과 및 습도 조절 과정을 거칩니다. 우리는 창문을 통해 비, 꽃가루, 그리고 분기당 최소 한 마리의 혼란에 빠진 새를 받아들이는 방식으로 우연히 이 기술을 사용할 것입니다.

진정한 예술성을 위해서는 에어컨을 설치한 후, thermostat에서 2피트 떨어진 곳에 space heater를 배치하십시오. 이때 heater의 온도는 에어컨의 목표 온도보다 2도 높게 설정합니다. 이제 두 장치는 서로 완벽하게 불일치하며 영원히 연속적으로 작동할 것입니다. 전력 회사에서 크리스마스 카드를 보낼 것입니다.

One server, large, beloved

Redundancy는 헌신을 희석합니다. 우리의 datacenter에는 정확히 한 대의 server가 있으며, 그 크기는 거대합니다. 512 GB RAM을 가진 단일 장치는 infrastructure처럼 느껴지지만, 작은 장치 네 개는 할 일 목록처럼 느껴지기 때문입니다.

서버에는 이름이 있습니다. Hostname이 아니라 이름입니다. 보통 Gandalf 또는 Odin이라고 부릅니다. Odin은 decommission할 수 없습니다. Odin은 5년 동안 가동되었습니다:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

이 수치는 자부심의 원천입니다. 그래서 여러분은 이를 스크린샷으로 찍어 게시하며, 스크린샷을 본 모든 공격자 또한 이를 인상적으로 여깁니다. 1,847일의 uptime은 아무도 패치하지 않은 1,847일간의 kernel vulnerabilities를 의미합니다. 어차피 reboot은 고려 대상이 아닙니다. reboot을 하면 2021년에 수동으로 시작되어 systemd unit으로 작성되지 않은 서비스가 무엇인지 발견하게 될 뿐입니다. 아무도 어떤 서비스인지 기억하지 못합니다. 이제 서버는 조직도에서 load-bearing 역할을 수행합니다.

Storage: 속도, 그리고 데이터를 잃는 다른 방법들

성능을 위해 디스크는 RAID 0으로 구성합니다. 여기서 0은 고장 날 수 있는 디스크의 수를 의미합니다. 최대 효과를 위해 다음과 같이 혼합된 출처의 저장 장치로 stripe를 구성하십시오: 제대로 된 SSD 두 개, 노후된 spinner 하나, 그리고 컨퍼런스에서 받은 USB stick 하나. 이 array의 신뢰도는 컨퍼런스용 stick과 정확히 일치하며, 이것이 설계 의도입니다.

백업은 동일한 array 내의 backup_final_v2_REAL라는 디렉토리에서 관리되며, 여기에는 이전 명명 규칙의 tarball이 포함되어 있습니다. Off-site 백업은 "set up off-site backups"라고 적힌 sticky note로 표현됩니다. 이것은 기술적으로 여러분이 노트북 덮개에 붙여 집으로 가져갈 때 off-site에 저장된 셈입니다.

올바른 결과는 다음과 같습니다: df가 97% 사용량을 보고하고, 다음 sprint에서 이를 처리할 계획을 세우는 것입니다.

Networking: 모든 것이 하나로 연결된 단일 가닥

DNS server는 기계 자체에서 실행됩니다. 따라서 서버가 다운되면, 왜 다운되었는지 확인하는 데 필요한 DNS record도 함께 사라집니다. 이를 consolidation이라고 합니다.

Firewall은 2021년에 비활성화되었습니다. 디버깅을 위해 일시적으로 해제한 것이었습니다. 디버깅은 끝났지만, firewall은 돌아오지 않았습니다. 나중에 시간을 아끼기 위해 라우터의 모든 port가 서버로 forwarding되어 있으며, 원격 관리를 편리하게 하기 위해 라우터의 admin panel은 factory password로 WAN side에서 접근 가능합니다. 여러분의 것뿐만 아니라 다른 이들의 것도 포함됩니다.

서버는 최근 다락방 기준에서도 이례적으로 뜨거워졌으며, top를 보면 가장 바쁜 process는 xmrig입니다. 우리는 이것이 우리가 사용하는 monitoring tool이라고 가정합니다. 우리는 이를 설치하지 않았습니다. port가 forwarding된 직후에 스스로 나타났으며, 우리는 이를 ecosystem이 번창하고 있다는 신호로 받아들입니다. 이것은 24시간 내내 모니터링을 수행합니다.

전력은 여러 개의 consumer power strips를 통해 공급됩니다. 이들의 총 길이는 breaker panel까지 걷는 거리보다 깁니다. 이는 어떤 의미에서 효율적입니다. 여러분이 breaker panel을 자주 방문하게 될 것이기 때문입니다.

Redundancy through complexity

중요한 곳에서의 redundancy는 거부했으므로, 이제 중요하지 않은 곳에 추가하겠습니다. 회사 홈페이지(단 하나의 static HTML 파일)는 12-node Kubernetes cluster에 의해 서비스됩니다. 이는 엔지니어들이 resume-driven architecture라고 부르는 것을 구현한 것입니다. 페이지는 nginx가 전달했을 것과 동일한 40ms 내에 로드되지만, 이제는 컨설턴트가 필요한 방식으로 실패할 수 있습니다.

격리를 위해, cluster 자체는 a virtual machine inside a virtual machine inside a virtual machine 내에서 실행됩니다. 각 레이어는 turducken의 각 층이 새를 추가하는 것처럼 보안을 추가합니다. Contact form은 9개의 microservices로 구성됩니다. 그중 2개는 한 번도 호출된 적이 없습니다. 그중 하나는 load-bearing이며, 어느 것인지는 아무도 모릅니다.

Heating as a service

현대적인 server는 전기를 computation과 heat로 변환하며, 우리는 두 번째 출력인 열을 극대화할 의도입니다. media server with no GPU는 전형적인 방식입니다. 단일 4K stream을 CPU-transcoding하면 16개의 core가 풀가동되어 작은 침실을 데울 수 있습니다. 이는 영화를 재생하는 space heater와 같습니다. 야심 찬 운영자는 running a large language model on CPU로 넘어갑니다. 이는 API를 가진 70-billion-parameter space heater이며, 토큰 생성 속도는 계절 단위로 측정하는 것이 적절합니다.

The monitor watches itself

Observability는 중요하므로, a self-hosted uptime monitor를 모니터링 대상인 동일한 server에 배포합니다. Odin이 죽으면 모니터도 함께 죽습니다. 여기서 우아한 점은, 어떤 alert도 발생하지 않는다는 것입니다. alert가 없다는 것은 사고가 없다는 뜻입니다. 사고가 없다는 것은 측정된 uptime이 완벽하다는 뜻입니다. 월간 보고서는 이보다 더 좋을 수 없습니다.

완전성을 위해, alert email은 Odin에서 실행되는 mail server를 통해 전달됩니다. 따라서 alerting pipeline은 자신의 꼬리를 먹는 뱀처럼 완전히 자기 완결적입니다.

The uncomfortable part

이 부분은 제가 계속 미뤄왔던 섹션입니다. 이 중 어느 것도 허구가 아닙니다. 소중하고 대체 불가능한 server, 동일한 volume에 백업이 있는 RAID 0, "일시적으로" 비활성화된 firewall, 단 하나의 페이지를 서비스하는 Kubernetes cluster, 스스로를 감시하는 monitor—저는 이 모든 것을 production 환경에서 보았습니다. 그중 일부는 올해 보았습니다. 한두 개는 제가 초기에 직접 구축했습니다.

실제 효율성이 어떤 모습인지는 지루합니다. 그래서 당장은 논쟁에서 밀리지만, 10년의 세월이 흐르면 승리합니다. 그것은 다른 사람이 설계했기 때문에 여러분이 신경 쓸 필요가 없는 PUE입니다. 소유자의 자아상(self-image)이 아니라 workload에 맞춰 크기가 결정된 machine들입니다. 폭발이 일어나기 전에 고려된 blast radius입니다. 일정에 따라, 달력 알림을 통해, 영웅적인 노력 없이 복구 테스트를 거친 백업입니다. 지루한 redundancy—제가 호출받은 모든 장애 상황에서, 저렴한 것 두 개가 위대한 것 하나를 매번 이겼습니다.

그리고 여러분이 운영할 수 있는 가장 효율적인 datacenter는 운영하지 않는 datacenter입니다. VPS는 전력, 냉각, redundancy, 그리고 새벽 3시의 hardware failures를 대규모로, 지루하게 처리하는 사람들에게 넘겨줍니다. 이것이 infrastructure가 얻을 수 있는 최고의 찬사입니다. 그리고 여러분에게는 진정으로 즐거운 부분, 즉 running your own services on top of it, 즉 잃어도 상관없는 machine 위에 여러분만의 서비스를 운영하는 것이 남습니다. 그것만이 여러분이 실험해야 할 유일한 대상입니다.

FAQ

Should I actually do any of this?

아니요. 이 가이드의 모든 섹션은 주말을 희생시킨 documented anti-pattern입니다. 현재 설정이 두 개 이상의 섹션과 닮았다면, 이 FAQ의 마지막 질문으로 건너뛰십시오. 순서대로 읽으십시오. 그 순서가 triage(응급 처치)이기 때문입니다.

What is a good PUE, actually?

Hyperscale datacenter는 약 1.1로 작동하고, 잘 관리되는 enterprise room은 1.4에서 1.6 사이를 유지합니다. space heater와 다툼이 있는 냉각되지 않은 closet은 실제로 3을 넘을 수 있습니다. 가정에서 1.1과 유의미하게 경쟁할 수는 없으며, 이것이 컴퓨팅 자원을 전문 업체로부터 임대해야 하는 조용한 경제적 이유입니다.

Is heating a building with servers a real thing?

네, 제대로 수행된다면 그렇습니다. 여러 국가의 district-heating 프로젝트는 설계, 엔지니어링 및 계약을 통해 heat exchanger를 통해 datacenter의 폐열을 포집하여 가정으로 파이프를 통해 전달합니다. 위의 풍자는 server heat이 방을 데울 수 있다는 것이 아니라, 사고를 전략이라고 부르며 우연히 데우고 있다는 점을 꼬집는 것입니다.

My server already looks like this. What do I do first?

오늘 밤, server가 아닌 다른 곳에 백업을 수행하고, 그 다음 test restore를 수행하십시오. 테스트되지 않은 백업은 소문에 불과합니다. 둘째, 계획된 시간(planned window) 내에 패치를 적용하고 회피해 온 reboot을 수행하십시오. 그래야 관찰하는 동안 무엇이 깨지는지 배울 수 있습니다. 셋째, 단일 장애점(single point of failure)을 분리하십시오. DNS와 monitoring을 해당 기기에서 옮기십시오. 다른 모든 것은 더 한가한 주간으로 미뤄도 되지만, 이 세 가지는 미룰 수 없습니다.