요약

  • 전 세계 백본 용량을 확인하려던 유지보수 명령이 페이스북 백본의 모든 연결을 끊고 데이터센터를 전 세계에서 분리했다.
  • 그런 명령을 걸러내야 했던 계층 자체가 프로그램이었고, 그 프로그램의 결함 때문에 명령이 멈추지 않았다.
  • DNS 서버들은 데이터센터에 닿지 못하자 스스로 BGP 광고를 철회했다. 이것은 부작용이 아니라 설계된 동작이었고, 장애를 내부 연결성에서 전 세계 도달성으로 옮겼다.

그 명령은 비상 상황이 아니라 일상에서 나왔다. 전 세계 백본에 용량이 얼마나 남았는지 확인하려는 것이었다. 대신 그것은 전부를 걷어갔다. "During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all the connections in our backbone network, effectively disconnecting Facebook data centers globally." 2021년 10월 5일 Engineering at Meta에 실린 설명이다.

이 문장이 말하지 않는 것도 말하는 것만큼 중요하다. 명령의 내용도, 범위도, 승인 경로도 읽을 수 있는 내부 문서로 확인되지 않는다. 누가 작성했고 어떤 매개변수를 담았으며 누가 승인했는지 — 그 어느 것도 내가 검토한 자료에는 없다. 그래서 판단은 운영사가 스스로 인정한 데서 멈춘다. 명령은 측정하려 했고, 대신 껐다.

명령 자체보다 흥미로운 것은 그것을 멈췄어야 할 계층이다. 페이스북은 이 계층을 바로 이런 종류의 개입을 위해 만든 것으로 설명한다. 그것은 작동하지 않았고, 이유는 아무도 예상 못 한 예외가 아니라 검사 도구 자체에 있었다. "Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command."

여기에 이 사건의 핵심이 있다. 조직은 위험한 행동 앞에 통제를 세우고 그것을 예방이라고 부른다. 그러나 그 통제 역시 실행되고, 읽고, 판단하고, 개입해야 하는 프로그램이며, 그 각 단계는 실패할 수 있다. 고장 난 검사기는 검사가 아니다. 그것은 아무것도 더 증명하지 못하는 또 하나의 시스템이다. 이 도구에 대한 읽을 수 있는 결함 보고서도, 시험 기록도 검토한 자료에는 없다. 가장 강한 단서는 오류 때문에 명령을 멈추지 못했다는 운영사의 문장이다.

그다음 두 번째 통제가 작동했고, 그것은 만들어진 목적대로 정확히 움직였다. 페이스북의 권위 DNS 서버는 데이터센터에 닿지 못하면 스스로 BGP 광고를 철회하도록 설정되어 있다. 연결이 건강하지 않다는 신호이기 때문이다. "To ensure reliable operation, our DNS servers disable those BGP advertisements if they themselves can not speak to our data centers, since this is an indication of an unhealthy network connection. In the recent outage the entire backbone was removed from operation, making these locations declare themselves unhealthy and withdraw those BGP advertisements."

백본이 통째로 사라졌기 때문에 그 모든 지점이 동시에 스스로를 unhealthy로 선언하고 물러났다. 장애는 네트워크 내부에서 바깥으로 옮겨갔다. 내부에서 닿지 못하던 것이 이제 나머지 인터넷에서도 해석되지 않았다. 이것은 안전장치의 실패가 아니다. 장애가 스스로 만들어낸 조건 아래에서 안전장치가 일한 것이다. 막으려는 피해가 곧 방아쇠인 보호 장치를 세우면, 비상시에 남는 것은 제동이 아니라 증폭이다.

얼마나 걸렸는지는 운영사 보고서가 아니라 외부 측정에서만 읽힌다. Cloudflare는 facebook.com이라는 이름이 1.1.1.1 리졸버에서 15:50 UTC 무렵 해석되지 않기 시작해 21:20 UTC 무렵 다시 나타났다고 관측했다. 15:58 UTC에서 21:00 UTC 사이에는 BGP를 통한 DNS 프리픽스 광고가 없었고, 21:17 UTC 무렵 다시 시작된 BGP 활동이 정점에 이르렀다. "At around 21:00 UTC we saw renewed BGP activity from Facebook's network which peaked at 21:17 UTC. ... This chart shows the availability of the DNS name 'facebook.com' on Cloudflare's DNS resolver 1.1.1.1. It stopped being available at around 15:50 UTC and returned at 21:20 UTC." Cloudflare는 장애를 대략 다섯 시간 반에서 여섯 시간으로 본다. 이는 Cloudflare의 해석이며, Meta가 밝힌 지속 시간이 아니다.

왜 그렇게 오래 걸렸는지가 이 이야기에서 가장 불편한 부분이다. 복구 경로는 콘솔이 아니었다. "Our primary and out-of-band network access was down, so we sent engineers onsite to the data centers to have them debug the issue and restart the systems. But this took time, because these facilities are designed with high levels of physical and system security in mind. They're hard to get into, and once you're inside, the hardware and routers are designed to be difficult to modify even when you have physical access to them."

두 원격 경로가 모두 사라졌다. 정규 경로와 대역 외 경로 모두. 남은 것은 장비 앞에 선 사람이었고, 그 건물은 바로 그런 성급한 물리적 개입을 막도록 지어져 있다. 이 강화는 잘못이 아니라 데이터센터의 존재 이유다. 다만 비상시에 그것은 그 장애를 고쳐야 하는 바로 그 조직을, 예외도 가속도 없이 맞이한다. 비상구는 닫혀 있었고, 건물은 그것을 옳게 닫아 두고 있었다.

그래서 이 사건이 드러내는 질문이 남는다. 누가 검사자를 검사하는가. 검사 도구는 그것의 행동이 시험되고 그것의 고장이 드러날 때만 통제가 된다. 내가 검토한 자료에는 둘 다 없다. 2021년 10월 5일의 두 문서에도, 추가 기술 기록에도 없다. 나는 운영사의 설명과 Cloudflare의 외부 측정을 읽었다. 그 문서들은 복구 계획도, 이행 상태도, 수리가 견고하다는 증거도 담고 있지 않다. 이는 검토한 자료의 한계이지, 그런 증거가 존재하지 않는다는 주장이 아니다.

장애 자체는 잘 기록되어 있다. 그것이 던지는 질문은 그렇지 않다. 가장 위험한 조작을 프로그램에 맡겨 걸러내는 회사라면, 그 프로그램이 스스로 틀렸을 때 어떻게 시험할지를 무엇보다 먼저 알아야 한다.