가장 비효율적인 데이터센터 구축 가이드

구축할 대상

이 사이트의 모든 가이드는 올바른 작업 수행 방법을 가르칩니다. 순서대로 입력할 명령어, 올바른 결과의 모습, 그리고 발생 가능한 실패 유형을 다룹니다. 하지만 이 가이드는 다릅니다. 오늘 우리는 완전히 가상적인 상황을 가정하여, 돈과 전기, 그리고 오만함으로 만들 수 있는 가장 비효율적인 데이터센터를 설계해 보겠습니다.

측정 지표가 필요하므로 업계 표준인 PUE(Power Usage Effectiveness)를 차용하겠습니다. PUE는 전체 시설 전력량을 컴퓨팅 장비에 실제로 도달하는 전력량으로 나눈 값입니다. 하이퍼스케일 데이터센터는 약 1.1의 수치를 기록하며, 이는 거의 모든 와트가 유용한 작업에 사용됨을 의미합니다. 괜찮은 기업용 서버실은 1.5 정도를 유지합니다. 우리의 목표는 4.0 이상입니다. 즉, 컴퓨팅에 사용되는 1와트당 3와트의 전력이 아무런 의미 없이 사라지게 만드는 것입니다. 진지한 가이드에서 백업을 언급하듯, 우리는 이 수치를 자주 언급할 것입니다.

장소 선정: 열기가 핵심입니다

데이터 센터에서 냉각은 가장 큰 비용을 차지하는 요소이므로, 우리의 서버는 열역학 법칙과 정면으로 맞서야 합니다. 가장 이상적인 장소는 다락방입니다. 남향이어야 합니다. 서버에 햇빛이 직접 내리쬐도록 천창을 배치하면, 서버 자체에서 발생하는 열과 태양열이 합쳐져 전기 요금과 항성 에너지가 완벽하게 협업하게 됩니다.

겨울철 냉각은 창문을 열어 해결합니다. 실제 데이터 센터에서도 외부 공기를 활용하는 '프리 쿨링(free cooling)' 기법을 사용하지만, 이는 정밀하게 설계되고 필터링되며 습도가 제어됩니다. 우리는 창문을 통해 우연히 이 방식을 도입할 것이며, 창문으로는 빗물과 꽃가루, 그리고 분기마다 최소 한 마리 이상의 길을 잃은 새가 들어올 것입니다.

진정한 예술성을 추구한다면 에어컨을 설치한 뒤, 에어컨 온도 조절기에서 2피트 떨어진 곳에 온풍기를 두십시오. 온풍기 설정 온도는 에어컨 목표 온도보다 2도 높게 맞춥니다. 이제 두 기기는 영원히 멈추지 않고 완벽한 불일치 속에서 가동될 것입니다. 전력 회사에서 크리스마스 카드를 보내줄 것입니다.

하나의 서버, 거대하고 소중한 존재

중복성은 헌신을 희석합니다. 우리의 데이터 센터에는 정확히 하나의 서버만 존재하며, 그 크기는 매우 거대합니다. 512 GB RAM을 갖춘 단일 장비는 인프라처럼 느껴지지만, 작은 서버 4대는 그저 해야 할 일 목록처럼 느껴지기 때문입니다.

이 서버에는 이름이 있습니다. 호스트네임이 아니라, 진짜 '이름'입니다. 보통 Gandalf나 Odin이라고 부릅니다. Odin은 폐기할 수 없습니다. Odin은 5년 동안 가동되었습니다:

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

그 숫자는 자부심의 원천입니다. 그래서 스크린샷을 찍어 게시하는 것이며, 이를 본 모든 공격자 또한 그 숫자를 인상적으로 생각합니다. 1,847일의 가동 시간은 1,847일 동안 커널 취약점이 패치되지 않았음을 의미합니다. 재부팅은 고려 대상이 아닙니다. 재부팅을 하는 순간 2021년에 수동으로 시작되었고 systemd 유닛에 기록되지 않은 서비스들이 무엇인지 드러나기 때문입니다. 아무도 그것들을 기억하지 못합니다. 이제 이 서버는 조직도에서 하중을 지탱하는 핵심 요소가 되었습니다.

스토리지: 속도, 그리고 데이터를 잃는 다른 방법

디스크는 성능을 위해 RAID 0으로 구성합니다. 여기서 0은 고장 나도 되는 디스크의 개수를 의미합니다. 효과를 극대화하려면 출처가 불분명한 스토리지들을 섞어서 스트라이핑하십시오. 제대로 된 SSD 2개, 노후화된 HDD 1개, 그리고 컨퍼런스에서 받은 USB 메모리 1개를 사용합니다. 이 어레이의 신뢰성은 컨퍼런스에서 받은 USB 메모리의 신뢰성과 정확히 일치하며, 이것이 바로 설계 의도입니다.

백업은 동일한 어레이 내의 backup_final_v2_REAL이라는 디렉터리에서 처리하며, 여기에는 이전 명명 규칙으로 생성된 tarball이 포함되어 있습니다. 오프사이트 백업은 "오프사이트 백업 설정하기"라고 적힌 포스트잇으로 대신합니다. 이 포스트잇을 노트북 덮개에 붙여 집으로 가져가면 기술적으로는 오프사이트에 저장된 셈이 됩니다.

올바른 결과는 df가 97% 사용률을 보고하고, 다음 스프린트에 이를 처리할 계획을 세우는 것입니다.

네트워킹: 모든 것이 얽힌 단일 가닥

DNS 서버가 기기 자체에서 실행되므로, 서버가 다운되면 원인을 파악하는 데 필요한 DNS 레코드도 함께 사라집니다. 이를 통합이라고 부릅니다.

방화벽은 2021년에 무언가를 디버깅하기 위해 일시적으로 비활성화되었습니다. 디버깅은 끝났지만 방화벽은 돌아오지 않았습니다. "나중에 시간을 절약하기 위해" 라우터의 모든 포트는 서버로 포워딩되어 있으며, 라우터 관리자 페이지는 편리한 원격 관리를 위해 공장 초기 비밀번호 그대로 WAN 측에서 접근할 수 있습니다. 귀하의 것은 물론, 다른 사람들의 접근도 가능합니다.

서버는 최근 다락방 기준을 고려하더라도 비정상적으로 뜨겁게 동작하고 있으며, top를 확인하면 가장 바쁜 프로세스가 xmrig라는 이름의 무언가임을 알 수 있습니다. 우리는 이것이 우리가 사용하는 모니터링 도구라고 가정합니다. 우리가 직접 설치한 것은 아니지만, 포트 포워딩 직후 스스로 나타났으므로 생태계가 번성하고 있다는 신호로 받아들입니다. 이 프로세스는 24시간 내내 모니터링을 수행합니다.

전력은 차단기 패널까지 걸어가는 거리보다 긴 소비자용 멀티탭 체인을 통해 공급됩니다. 차단기 패널을 자주 방문하게 될 것이라는 점을 고려하면, 어떤 의미에서는 효율적입니다.

복잡성을 통한 이중화

중요한 부분의 이중화는 거부하면서, 정작 필요 없는 곳에 이중화를 추가합니다. 정적 HTML 파일 하나로 구성된 회사 홈페이지를 12개 노드의 Kubernetes 클러스터로 서비스합니다. 이는 엔지니어들이 말하는 이력서용 아키텍처(resume-driven architecture)를 달성합니다. 페이지 로딩 속도는 nginx가 처리했을 때와 같은 40밀리초지만, 이제는 컨설턴트가 필요한 방식으로 장애가 발생할 수 있습니다.

격리를 위해 클러스터 자체를 가상 머신 안의 가상 머신 안의 가상 머신 내부에서 실행합니다. 각 계층은 마치 터더킨(turducken)의 각 층이 새를 추가하는 것과 같은 방식으로 보안을 강화합니다. 문의 양식은 9개의 마이크로서비스로 구성됩니다. 그중 2개는 한 번도 호출된 적이 없습니다. 그중 하나는 부하를 지탱하고 있는데, 어느 것인지 아는 사람은 아무도 없습니다.

서비스로서의 난방

현대적인 서버는 전기를 연산과 열로 변환하며, 우리는 두 번째 결과물을 극대화하고자 합니다. GPU가 없는 미디어 서버는 가장 고전적인 방식입니다. 4K 스트림 하나를 CPU로 트랜스코딩하면 16개의 코어가 모두 점유되며 작은 침실을 덥힐 수 있습니다. 영화를 재생하는 온열기인 셈입니다. 더 야심 찬 운영자는 CPU에서 거대 언어 모델을 구동하는 단계로 나아갑니다. 이는 API를 갖춘 700억 파라미터 규모의 온열기로, 계절 단위로 측정하는 것이 적절할 만큼 느린 속도로 토큰을 생성합니다.

모니터링 도구의 자기 감시

관측 가능성은 중요하므로, 자체 호스팅 업타임 모니터링 도구를 모니터링 대상 서버와 동일한 서버에 배포합니다. Odin 서버가 중단되면 모니터링 도구도 함께 중단되며, 여기서 우아한 결과가 나타납니다. 경고가 발생하지 않습니다. 경고가 없다는 것은 사고가 없다는 뜻입니다. 사고가 없으므로 측정된 업타임은 완벽합니다. 월간 보고서의 수치는 그 어느 때보다 훌륭합니다.

완전성을 위해 경고 이메일은 Odin에서 실행 중인 메일 서버를 통해 릴레이됩니다. 따라서 경고 파이프라인은 뱀이 자신의 꼬리를 먹는 것처럼 완전히 자급자족하는 구조로 완성됩니다.

불편한 진실

지금까지 미뤄왔던 부분입니다. 이 내용은 모두 실화입니다. 대체 불가능하다고 믿는 소중한 서버, 같은 볼륨에 백업을 저장하는 RAID 0, "잠시" 꺼둔 방화벽, 단 하나의 페이지만 서비스하는 Kubernetes 클러스터, 자기 자신을 모니터링하는 모니터링 시스템까지, 저는 이 모든 것을 운영 환경에서 목격했습니다. 그중 일부는 올해에도 보았습니다. 한두 가지는 제 초기 경력 시절에 직접 만들기도 했습니다.

진정한 효율성은 지루한 법입니다. 그래서 당장 눈앞의 논쟁에서는 지지만, 10년이라는 긴 세월을 두고 보면 승리합니다. 누군가 이미 설계해 두었기에 신경 쓸 필요조차 없는 PUE, 소유자의 자아상이 아닌 실제 워크로드에 맞춰진 장비 규모, 폭발이 일어나기 전에 미리 고려된 영향 범위(blast radius)가 그렇습니다. 백업은 영웅적인 노력이 아니라, 캘린더 알림에 맞춰 정기적으로 복구 테스트를 수행하는 지루한 과정입니다. 중복성은 따분해야 합니다. 제가 호출(page)을 받았던 모든 장애 상황에서, 비싼 장비 한 대보다 저렴한 장비 두 대가 항상 더 나은 결과를 보여주었습니다.

가장 효율적인 데이터센터는 직접 운영하지 않는 데이터센터입니다. VPS를 사용하면 전력, 냉각, 중복성, 그리고 새벽 3시에 발생하는 하드웨어 장애를 대규모로, 그리고 지루할 정도로 묵묵히 처리하는 전문가들에게 맡길 수 있습니다. 이는 인프라가 받을 수 있는 최고의 찬사입니다. 덕분에 여러분은 그 위에서 직접 서비스를 운영하는 진정으로 즐거운 작업에 집중할 수 있습니다. 잃어도 괜찮은 장비 위에서 말입니다. 실험은 오직 그런 장비에서만 해야 합니다.

FAQ

이 작업을 실제로 수행해야 합니까?

아니요. 이 가이드의 모든 섹션은 수많은 주말을 희생시킨 것으로 기록된 안티 패턴입니다. 현재 설정이 두 개 이상의 섹션과 유사하다면, 이 FAQ의 마지막 질문으로 건너뛰어 순서대로 진행하십시오. 이 순서는 긴급도에 따른 분류입니다.

실제로 좋은 PUE 수치는 무엇입니까?

하이퍼스케일 데이터센터는 약 1.1, 잘 운영되는 기업용 전산실은 1.4에서 1.6 정도를 유지하며, 냉방 시설이 없는 벽장 수준의 공간은 3을 넘기기도 합니다. 가정에서 1.1이라는 수치와 경쟁하는 것은 사실상 불가능하며, 이것이 바로 전문 업체로부터 컴퓨팅 자원을 임대하는 것이 경제적으로 합리적인 이유입니다.

서버로 건물을 난방하는 것이 실제로 가능한 일입니까?

네, 제대로 설계한다면 가능합니다. 여러 국가의 지역 난방 프로젝트는 열교환기를 통해 데이터센터의 폐열을 회수하여 가정으로 공급하며, 이는 설계 단계부터 공학적 검토와 계약을 거쳐 이루어집니다. 위에서 언급한 풍자는 서버 열기로 방을 데울 수 없다는 것이 아니라, 우연히 발생한 열기를 전략이라고 포장하는 행태를 지적하는 것입니다.

제 서버가 이미 이런 상태입니다. 무엇부터 해야 합니까?

첫째, 오늘 밤 당장 서버 외부의 다른 곳으로 백업을 수행하고, 복구 테스트를 진행하십시오. 테스트하지 않은 백업은 소문에 불과합니다. 둘째, 계획된 작업 시간 내에 패치를 적용하고 그동안 미뤄왔던 재부팅을 수행하십시오. 그래야 문제가 발생했을 때 무엇이 원인인지 파악할 수 있습니다. 셋째, 단일 장애 지점을 분리하십시오. DNS와 모니터링 서비스를 해당 서버에서 외부로 옮기십시오. 다른 모든 작업은 더 여유로운 주까지 미룰 수 있지만, 앞서 언급한 세 가지는 미룰 수 없습니다.