프랑스의 데이터센터가 불탔습니다. 그리고 어떤 데이터는 끝내 돌아오지 않았습니다

2021년 3월 10일, 자정을 조금 넘긴 시각에 프랑스 스트라스부르의 데이터센터 단지에 화재 경보가 울렸습니다. 몇 시간 만에 단지 안 네 개 건물 중 하나가—서버로 가득 찬 5층 콘크리트 건물 SBG2가—걷잡을 수 없는 불길에 휩싸였습니다. 지역 곳곳에서 소방대가 모여 밤새 진화에 나섰지만, 동이 틀 무렵 SBG2는 폐허가 되어 있었습니다.

이건 이름 없는 영세 호스팅 업체 이야기가 아닙니다. 유럽 최대급 클라우드 사업자, OVHcloud입니다. 고객이 수백만입니다. 창업자 옥타브 클라바는 보도자료로는 도저히 따라잡을 수 없는 속도로 사태가 흘러가자, 밤새 트위터에 상황을 올렸습니다. 그의 말은 꾸밈이 없었습니다. "재해 복구 계획을 가동하십시오." 아침이 되자 수백만 개의 웹사이트가 멈췄습니다—정부 서비스, 게임 서버, 작은 회사의 홈페이지, 개인 프로젝트. 그리고 적지 않은 고객에게는 그보다 더 나쁜 일이 벌어져 있었습니다. 데이터가 그냥 사라진 것입니다. 일시적으로 닿지 않는 게 아니라, 사라졌습니다.

클라우드는 구름이 아니었습니다. 건물이었습니다. 그리고 건물은 불탑니다.

클라우드는 건물입니다

우리는 "클라우드"를 날씨처럼 말합니다—퍼져 있고, 어디에나 있고, 한 지역의 재난과는 무관한 것처럼. 그 비유는 업계를 위해 조용히 일합니다. 만질 수 없는 것은 부서지지도 않을 것 같은 느낌을 주기 때문입니다. 그러나 여러분이 "클라우드에 올린" 파일은 전부 특정한 방, 특정한 건물, 특정한 거리의 주소에 있는 회전하는 디스크나 플래시 칩 위에 있습니다. 그 건물에는 지붕이 있고, 전력 인입선이 있고, 배터리실이 있고—스트라스부르가 보여줬듯이—불탈 조건도 갖춰져 있습니다.

데이터센터는 화재에 대해 각별한 주의를 기울여 설계됩니다. 가스 소화 설비, 방화 구획, 이중화된 전력 경로, 정전 시 부하를 지탱하는 배터리. OVH의 시설도 예외가 아니었습니다. 현대적이고 잘 관리되는 시설이었습니다. 그런데도 불이 났습니다. 그런데도 번졌습니다. 그런데도 건물 한 동이 통째로 사라졌습니다. 조사는 몇 달에 걸쳐 원인을 추적했고, 건물의 전기 시스템에 초점이 모였습니다—서버를 살리는 그 시스템이 나쁜 시간에는 서버를 죽이는 것이 되기도 한다는 것. 이 아이러니는 OVH만의 것이 아닙니다. 모든 데이터센터는 막대한 전력을 한곳에 집중시킵니다. 대규모 연산에는 그게 필요하기 때문입니다. 집중이 곧 비즈니스 모델이고, 집중이 곧 위험입니다.

불탄 것과, 돌아오지 않은 것

많은 사람이 여기서 오해합니다. 데이터를 영원히 잃은 고객이 잃은 것은 OVH가 부주의해서가 아닙니다. 대개는 백업이 같은 건물 안에 있었기 때문입니다.

원본과 같은 시설에 있는 백업은 백업이 아닙니다. 같은 불을 기다리는 두 번째 복사본입니다. SBG2가 불탔을 때, "SBG2 안의 다른 랙"에 이중화를 해둔 고객은 이중화와 복제가 다른 것임을 알게 됐습니다. 진짜 복제는 분리를 뜻합니다—다른 건물, 다른 전력망, 다른 고장 방식. OVH 고객 중 적지 않은 수가 그 분리를 한 번도 하지 않았습니다. 사업자가 "생각하지 않아도 되게" 해줬기 때문입니다. 대시보드 하나, 청구서 하나, 장소 하나. 편리함이 어느새 회복력을 대신하고 있었습니다.

이 사건의 불편한 진실은, 대부분의 사람에게는 기술이 설계대로 작동했다는 점입니다. 같은 단지의 SBG3와 SBG4는 예방 차원에서 중단됐다가 나중에 복구됐습니다. 오프사이트 복사본이 있던 고객은 다시 세웠습니다. 전부 잃은 사람들이 잃은 건 버그 때문이 아니라 전제 때문이었습니다. "전문 시설에 맡기면, 그 자체가 보증이 된다"는 전제 말입니다.

그런 보증은 없습니다. 보증은 장소가 아니라 과정입니다.

3-2-1 규칙, 그리고 아무도 하지 않는 "1"

스토리지 업계에는 바로 이 사태를 위한 주문 같은 규칙이 있습니다. 3-2-1—복사본 3개, 서로 다른 매체 2종, 그중 1개는 오프사이트에. 업계 사람이라면 누구나 외울 수 있습니다. 그러나 개인이 실제로 실행하는 경우는 거의 없습니다.

처음 둘은 쉽습니다. 복사본 3개, 매체 2종—하드디스크와 클라우드 동기화, 혹은 NAS와 외장 디스크면 됩니다. 거기까지는 다들 합니다. 조용히 생략되는 것은 마지막 "1"—물리적으로 떨어진, 가능하면 오프라인인 오프사이트 복사본입니다. 생략되는 이유는, 그것이 지속적인 수고를 요구하는 유일한 부분이기 때문입니다. 두 번째 장소, 정기적인 손질, 여러분이 생각하지 않을 때 복사본을 돌봐줄 누군가.

스트라스부르가 벌한 것은 바로 그 생략된 "1"이었습니다. 가진 고객은 며칠 만에 재건했습니다. 없는 고객은 못 했습니다. 위협이 화재든, 홍수든, 랜섬웨어든, 광케이블을 끊는 굴착기든, 이 규칙은 신경 쓰지 않습니다. 신경 쓰는 건 여러분의 복사본들이 운명을 함께하느냐뿐입니다.

"사업자가 알아서 해주겠지"

우리가 가장 자주 듣는 반론은 이렇습니다. "제대로 된 사업자라면 리전을 넘어 복제하고 있을 테니, 내가 생각할 필요가 없지 않나." 그 말이 사실일 때도 있습니다—여러분이 그 요금을 내고, 설정하고, 검증했다면. 그러나 많은 사람은 기본 요금제에 있고, 거기서 복제란 "단지 안"을 뜻합니다. 그리고 단지는, 앞서 말했듯, 건물입니다.

생각 자체를 외주 주는 데는 더 깊은 문제가 있습니다. 사업자가 전부 해주면, 여러분은 질문을 멈춥니다—어느 버전이 어디 있는지, 오프사이트 복사본은 얼마나 오래됐는지, 올해 누군가 복원 테스트를 했는지. 사업자의 대시보드는 초록색입니다. 그러니 괜찮을 것입니다. 하지만 대시보드는 초록이 아니게 되는 순간까지만 초록입니다. 화재 뒤에, 일부 OVH 고객은 자신들의 "지리적 이중화" 구성이 한 번도 상상하던 것이 아니었음을 알았습니다. 사람들이 "내 구성은 이렇다"고 믿는 것과 실제로 그런 것 사이의 틈—데이터가 죽는 곳은 바로 거기입니다.

그래서 스토리지 업계의 베테랑들은 "검증"에 대해 지루할 만큼 시끄럽습니다. 사업자의 건물은 믿어도 좋습니다. 그러나 내 복사본은 직접 확인하십시오. 장인의 말로 하면, 단 한 번의 화재가 닿지 않는 곳에 복사본이 있다는 걸 자기 눈으로 확인하지 않았다면, 그건 백업이 아닙니다. 희망입니다.

누군가는 "기억하는 사람"이어야 합니다

세네카는 썼습니다. 불운을 예상하고 대비해야 한다고—비관해서가 아니라, 대비야말로 재앙을 "끝"에서 "중단"으로 바꾸기 때문입니다. OVH 화재는 그 구분에 대한 사례 연구입니다. 진짜 오프사이트 복사본이 있던 고객에게 3월 10일은 끔찍한 한 주였고, 그걸로 끝이었습니다. 없던 고객에게는 끝 그 자체였습니다.

교훈은 "클라우드를 쓰지 마라"가 아닙니다. 클라우드는 접근과 협업을 위한 훌륭한 도구입니다. 교훈은 이것입니다. 잃을 수 없는 것에는 원본과 운명을 함께하지 않는 복사본이 필요합니다—다른 건물, 다른 전력망, 다른 위협 모델. 그리고 그 복사본을 살아 있게 유지하는 정기적인 손질이 필요합니다. 가끔 전원을 켜고, 검증하고, 매체가 수명을 다하기 전에 교체하는 일 말입니다.

그 손질을 스스로 하는 사람은 거의 없습니다. 백업의 목적은 생각하지 않기 위해서이니까요. 그것이 역설이고, 보관이라는 직업이 존재하는 이유입니다. 대시보드도 동기화 클라이언트도 아닌, 여러분이 가본 적 없는 건물에 있는 한 사람. 그 일의 전부는 소박한 돌봄입니다. 번호 매기기, 봉인, 사진 촬영, 연 2회 봉인을 눈으로 점검하고 기록하기—그리고 매체 자체의 검증은 소유자가 서면으로 요청할 때만. 3-2-1의 "1"을, 그 외에는 아무것도 하지 않는 누군가가 하는 것. 그게 이 일입니다.

화재는 베테랑들이 이미 알던 것을 스트라스부르의 고객들에게 가르쳤습니다. 클라우드는 건물입니다. 건물은 불탑니다. 그렇게 생각하고 대비하십시오.

Everkeep은 고객이 직접 소유하고 직접 암호화한 드라이브의 오프라인 보관을 제공합니다. 모든 슬롯에는 연 2회의 상태 점검이 포함됩니다—봉인을 눈으로 확인하고, 사진을 찍고, 기록합니다. 드라이브에 전원을 넣는 것은 고객이 서면으로 요청했을 때뿐입니다. 두 개의 복사본을, 두 곳의 떨어진 장소에. 장치 슬롯당 연 $199.