요약

  • 유지보수 명령이 백본 연결을 끊자 DNS 서버로 가는 경로도 철회됐다. 서버가 작동하고 있다는 사실만으로는 이용자가 접속할 수 없었다.
  • 망 연결의 회복과 앱의 정상화는 서로 다른 단계였다. 외부에서 관측한 시간 간격을 모든 이용자의 장애 시간이나 기술자의 이동 시간으로 볼 수는 없다.

끊긴 연결을 되살렸다면 이제 서비스를 모두 켜면 될까. 2021년 10월 4일 Facebook의 복구 과정에서는 그 마지막 동작도 조심스러웠다. 서비스가 한꺼번에 돌아오면 트래픽과 전력 수요가 급증할 수 있었다. 연결을 복구한 뒤 또 다른 문제를 만들지 않으려면 재시작 자체를 관리해야 했다.

회사가 다음 날 공개한 기술 설명은 이 대목을 전한다. 이 사고를 단순히 몇 시간 동안 꺼졌다가 다시 켜진 일로 읽으면, 복구가 왜 어려웠는지를 놓치게 된다.

용량을 알아보려던 명령이 연결을 끊었다

회사의 설명에 따르면 시작은 정기 유지보수였다. 전 세계 데이터센터를 잇는 백본의 여유 용량을 확인하려던 명령이 뜻하지 않게 연결을 끊었다. 이런 명령을 막도록 설계된 검사 도구에도 버그가 있어 실행을 저지하지 못했다.

이어서 DNS 서버가 자신의 경로 정보를 철회했다. DNS는 서비스 이름으로 접속할 주소를 찾는 데 쓰인다. 이 서버들은 백본을 통해 데이터센터에 도달하지 못하면 BGP 경로 광고를 거두도록 설계돼 있었다. BGP는 네트워크끼리 어떤 목적지로 가는 길을 제공할 수 있는지 알리는 방식이다.

서버 자체는 계속 작동했다. 하지만 인터넷에서 그 서버로 가는 길을 찾을 수 없었다. Facebook, Instagram, WhatsApp을 열려는 사람에게는 둘 다 접속 실패로 보이지만, 고쳐야 할 대상은 달라진다. 작동 중인 서버를 다시 켠다고 사라진 경로가 자동으로 돌아오는 것은 아니다.

고칠 사람도 들어갈 길이 필요했다

문제는 이용자 쪽에만 있지 않았다. 회사는 일반적인 네트워크 접근과 별도로 마련한 관리용 접근 수단을 모두 잃었다고 밝혔다. 일반 연결이 끊겼을 때 쓰는 별도 수단을 아웃오브밴드 접근이라고 한다. DNS가 사라지면서 내부 조사 도구도 영향을 받았다.

다만 두 사실을 하나의 단정으로 묶어서는 안 된다. 보고서는 DNS 의존 도구의 장애를 설명하지만, DNS 손실이 별도 관리 접근의 실패를 직접 일으켰다고 입증하지는 않는다.

접근을 되찾기 위해 기술자들이 현장으로 파견됐다. 물리적 보안과 시스템 보안 장치가 진입과 장비 변경을 어렵게 했다는 설명도 있다. 그렇다고 기술자 한 명의 이동 경로를 그리거나, 장애 시간을 전부 현장에 도착하는 데 쓴 시간으로 바꿔 쓸 근거는 없다.

망을 다시 연결한 다음에는 부하를 살피며 서비스를 재시작했다. 기존 장애 훈련이 복구에 도움이 됐지만, 전 세계 백본 전체가 끊기는 상황은 미리 연습하지 않았다고 회사는 설명했다.

바깥의 시계로 알 수 있는 것

Cloudflare의 관측 기록은 외부에서 보인 변화를 보여 준다. UTC 15시 40분 무렵 라우팅 변경이 급증했고, 15시 58분에는 Facebook의 DNS 주소 대역에 대한 경로 철회가 관측됐다. 다른 Facebook 주소 대역의 경로는 남아 있었다. 회사의 모든 주소가 동시에 사라진 것은 아니다.

21시 무렵 BGP 활동이 다시 나타났고, 21시 17분에 정점을 보였다. 21시 28분에는 전 세계 연결과 DNS가 돌아온 것으로 보였다. 그러나 앱이 정상적으로 동작하기까지는 더 시간이 걸릴 수 있었다.

15시 58분부터 21시 28분까지는 330분이다. 이는 두 관측 시점 사이의 간격이지, 모든 지역과 이용자에게 똑같이 적용되는 장애 시간은 아니다. 기술자의 이동 시간도 아니다. 처음 두 시점 사이의 18분 역시 내부에서 문제를 발견할 수 있었던 유일한 기회였다고 볼 수 없다.

앱과 DNS 리졸버의 반복 요청은 다른 시스템의 처리량도 늘렸다. 그렇지만 Cloudflare는 1.1.1.1 리졸버의 대부분 요청이 여전히 10밀리초 안에 처리됐다고 밝혔다. 느린 쪽의 응답 지연은 커졌지만, 인터넷 전체가 멈췄다는 뜻은 아니다.

외부 관측은 회사 설명과 맞아떨어지는 증상을 보여 준다. 내부 명령과 검사 도구, 경보 과정을 직접 확인해 주지는 않는다. 두 자료를 함께 읽으면 2021년의 복구가 왜 여러 단계를 거쳐야 했는지는 이해할 수 있다. Meta Platforms가 이후 무엇을 바꿨고 오늘 어떤 구조를 쓰는지는 별도의 증거가 필요한 질문이다.

2026년 10월 21일 정정: 관리 접근의 상실과 DNS 의존 도구의 장애를 구분했다. 외부 관측 간격을 이동 시간이나 모든 서비스의 동일한 중단 시간으로 표현한 부분, 2021년 자료만으로 현재 구조를 판단한 부분을 바로잡았다.