2021.10.07

페이스북 서비스 중단 사태 “불운의 연속이 만들어낸 참사”

Tim Greene | Network World
잘못 작성된 명령어, 버그투성이 감사 툴, 네트워크 복구를 방해한 DNS 시스템, 엄격한 데이터센터 보안이 연쇄적으로 일어나며 페이스북을 어떻게 해 볼 수 없는 대혼란의 7시간에 빠뜨렸다.

페이스북은 최근 발생한 자사 서비스 중단 사태의 근본 원인은 정기적인 유지보수 작업이 잘못되어 DNS 서비스를 사용할 수 없게 된 것이지만, 처음에는 페이스북 전체 백본 네트워크가 붕괴되었다고 밝혔다.
 
ⓒ Ben Watts (CC BY 2.0)

문제를 더 악화시킨 것은 DNS 중단이다. 이 때문에 페이스북 엔지니어는 백업 네트워크를 가동하는 데 필요한 장비에 원격으로 액세스할 수 없었다. 담당 엔지니어들은 결국 수동으로 시스템을 재가동하기 위해 데이터센터로 직접 가야만 했다. 

이걸로 끝이 아니다. 늦어진 대응을 더욱 느리게 만든 것은 데이터센터의 경비원이었다. 이들은 그 누구도 데이터센터에 쉽게 접근하지 못하도록 했다. 페이스북 엔지니어링 및 인프라 담당 부사장 산토시 야나르단이 작성한 페이스북 블로그에 따르면, 엔지니어들은 데이터센터 안으로 들어가기 어려웠으며, 들어간 후에도 하드웨어와 라우터가 물리적으로 데이터센터에 액세스하더라도 고치기 어렵게 설계되어 있었다.  

시간이 걸렸지만, 일단 시스템이 복구된 다음에는 네트워크가 정상으로 돌아왔다.

복구한 네트워크를 통해 실행되는 고객들이 사용하는 서비스를 복구하는 것은 또 다른 긴 프로세스이다. 이들 서비스를 한꺼번에 재가동하면 다른 충돌이 발생할 수 있기 때문이다. 야나르단은 “각 데이터센터는 전략 사용량에 있어서 10메가와트 정도의 부족을 보고하고 있는 상태였고, 이런 상황에서 갑작스러운 가동은 전력 시스템에서 나오는 모든 것을 위험에 빠뜨릴 수 있다”고 설명했다.
 

정기적인 유지보수의 실패

서비스 중단을 촉발한 것은 오전 11시 39분에 이뤄진 유지보수 작업으로, 이 작업 중에 실수로 백본 네트워크 일부의 연결을 끊었다. 이 정기적인 유지보수 작업 중에 전 세계 백본 용량의 가용성을 검사하는 명령어를 실행하는데, 의도와는 달리 이 명령어가 백본 네트워크에서 모든 접속을 끊은 것이다. 사실상 페이스북의 전세계 데이터센터가 모두 네트워크 연결이 끊어진 것이다.

예기치 않은 일이었다. 게다가 페이스북은 이런 괴멸적인 장애를 일으킬 수 있는 명령을 걸러내는 툴도 보유하고 있었지만, 제대로 작동하지 않았다. 야나르단에 따르면, 페이스북의 시스템은 이런 실수를 방지하기 위해 명령어를 검사하도록 설계됐지만, 명령어 감사 툴의 버그로 인해 명령어 실행을 적절하게 방지하지 못했다. 이 명령어가 실행되자 DNS 시스템이 붕괴됐다.
 

SPOF는 역시 DNS

인터넷 트래픽과 충돌을 모니터링하고 분석하는 시스코 싸우전드아이즈(ThousandEyes)의 제품 마케팅 책임자 안젤릭 메디나에 따르면, DNS를 중단시킨 것은 백본 네트워크 장애에 대한 자동화된 대응 조치인 것으로 보인다. 

DNS, 즉 디렉토리 네임 서비스는 웹 주소를 IP 주소로 번역하는 것에 관한 쿼리에 응답한다. 그리고 페이스북은 자체 DNS 서버를 운영한다. 메디나는 “페이스북은 DNS 서비스가 서버 가용성에 따라 확장되거나 축소되는 아키텍처이다. 네트워크가 끊어지면서 서버 가용성이 0이 되었고, 모든 DNS 서버가 해제됐다”고 설명했다.

이 해제는 페이스북의 DNS 서버가 인터넷 BGP(Border Gateway Protocol) 라우터에 메시지를 보내면서 완료됐다. BGP 라우터는 특정 IP 주소에 도달하는 데 사용하는 경로에 관한 정보를 저장한다. 이 경로가 주기적으로 라우터에 공시되어 각 라우터가 트래픽의 방향을 적절하게 전달하는 방법을 유지한다.

페이스북 DNS 서버의 경로 철회 메시지는 기존에 공시된 경로를 스스로 사용할 수 없도록 만들었으며, 이 때문에 BGP 라우터는 트래픽 경로를 전송할 수 없게 됐다. 야나르단은 “결과적으로 DNS 서버는 작동을 하면서도 접속할 수 없게 됐다. 이 때문에 인터넷에서 페이스북 서버를 찾는 것이 불가능해졌다”라고 밝혔다.

물론 DNS 서버에 액세스할 수 있었다 해도 페이스북 사용자는 서비스를 이용할 수 없었는데, 접속하려고 하는 페이스북의 네트워크가 중단됐기 때문이다. 안타깝게도 페이스북의 엔지니어 역시 DNS 서버에 접속할 수 없었고, 이 때문에 중단된 백본 시스템에 접속하기 위해 필요한 원격 관리 플랫폼에도 접속할 수 없었다.

페이스북은 자체 DNS 서버를 서비스 사용자뿐만 아니라 내부 툴과 시스템에도 사용한다. 그런데 이 서버가 완전히 중단되면서 네트워크 관리자나 엔지니어가 고장 난 시스템을 고치는 데 필요한 시스템에 액세스할 수 없게 된 것이다. 결국 엔지니어들은 관리 콘솔로 문제를 해결하는 것이 아니라 데이터센터로 직접 가서 장비를 하나씩 하나씩 되살릴 수밖에 없었다.

참고로, 좀 더 견고한 아키텍처라면 DNS 서비스를 이중화한다. 대표적인 예로, 아마존은 두 개의 외부 DNS 서비스 Dyn과 울트라DNS를 사용한다. 
 

값비싼 교훈

이번 사고는 페이스북의 아키텍처가 네트워킹의 베스트 프랙티스가 제시하는 구성에 미치지 못했음을 드러냈다. 만약 백본 네트워크의 장애가 없었더라도 단일 DNS 시스템이 장애를 일으키면 전체 서비스가 중단되고 만다. 메디나는 “왜 페이스북의 DNS가 실제로 SPOF가 되었는가? 이번 사태로 여분의 DNS를 갖춰야 한다는 것을 배웠을 것이다”라고 지적했다. 

메디나는 이외에도 많은 서비스 업체의 중단 사태에 대한 한 가지 보편적인 특징을 지적했다. 이런 서비스 중단 사태를 보면, 흔히 네트워크 내의 상호 의존성이 있어서 전체 서비스 아키텍처의 일부에서 발생한 작은 문제가 이런 엄청난 파급 효과를 낳는다는 것. 메디나는 “많은 업체가 내부 서비스를 많이 이용하는데, 여기에는 예기치 않은 결과가 따를 수 있다”고 덧붙였다. editor@itworld.co.kr


2021.10.07

페이스북 서비스 중단 사태 “불운의 연속이 만들어낸 참사”

Tim Greene | Network World
잘못 작성된 명령어, 버그투성이 감사 툴, 네트워크 복구를 방해한 DNS 시스템, 엄격한 데이터센터 보안이 연쇄적으로 일어나며 페이스북을 어떻게 해 볼 수 없는 대혼란의 7시간에 빠뜨렸다.

페이스북은 최근 발생한 자사 서비스 중단 사태의 근본 원인은 정기적인 유지보수 작업이 잘못되어 DNS 서비스를 사용할 수 없게 된 것이지만, 처음에는 페이스북 전체 백본 네트워크가 붕괴되었다고 밝혔다.
 
ⓒ Ben Watts (CC BY 2.0)

문제를 더 악화시킨 것은 DNS 중단이다. 이 때문에 페이스북 엔지니어는 백업 네트워크를 가동하는 데 필요한 장비에 원격으로 액세스할 수 없었다. 담당 엔지니어들은 결국 수동으로 시스템을 재가동하기 위해 데이터센터로 직접 가야만 했다. 

이걸로 끝이 아니다. 늦어진 대응을 더욱 느리게 만든 것은 데이터센터의 경비원이었다. 이들은 그 누구도 데이터센터에 쉽게 접근하지 못하도록 했다. 페이스북 엔지니어링 및 인프라 담당 부사장 산토시 야나르단이 작성한 페이스북 블로그에 따르면, 엔지니어들은 데이터센터 안으로 들어가기 어려웠으며, 들어간 후에도 하드웨어와 라우터가 물리적으로 데이터센터에 액세스하더라도 고치기 어렵게 설계되어 있었다.  

시간이 걸렸지만, 일단 시스템이 복구된 다음에는 네트워크가 정상으로 돌아왔다.

복구한 네트워크를 통해 실행되는 고객들이 사용하는 서비스를 복구하는 것은 또 다른 긴 프로세스이다. 이들 서비스를 한꺼번에 재가동하면 다른 충돌이 발생할 수 있기 때문이다. 야나르단은 “각 데이터센터는 전략 사용량에 있어서 10메가와트 정도의 부족을 보고하고 있는 상태였고, 이런 상황에서 갑작스러운 가동은 전력 시스템에서 나오는 모든 것을 위험에 빠뜨릴 수 있다”고 설명했다.
 

정기적인 유지보수의 실패

서비스 중단을 촉발한 것은 오전 11시 39분에 이뤄진 유지보수 작업으로, 이 작업 중에 실수로 백본 네트워크 일부의 연결을 끊었다. 이 정기적인 유지보수 작업 중에 전 세계 백본 용량의 가용성을 검사하는 명령어를 실행하는데, 의도와는 달리 이 명령어가 백본 네트워크에서 모든 접속을 끊은 것이다. 사실상 페이스북의 전세계 데이터센터가 모두 네트워크 연결이 끊어진 것이다.

예기치 않은 일이었다. 게다가 페이스북은 이런 괴멸적인 장애를 일으킬 수 있는 명령을 걸러내는 툴도 보유하고 있었지만, 제대로 작동하지 않았다. 야나르단에 따르면, 페이스북의 시스템은 이런 실수를 방지하기 위해 명령어를 검사하도록 설계됐지만, 명령어 감사 툴의 버그로 인해 명령어 실행을 적절하게 방지하지 못했다. 이 명령어가 실행되자 DNS 시스템이 붕괴됐다.
 

SPOF는 역시 DNS

인터넷 트래픽과 충돌을 모니터링하고 분석하는 시스코 싸우전드아이즈(ThousandEyes)의 제품 마케팅 책임자 안젤릭 메디나에 따르면, DNS를 중단시킨 것은 백본 네트워크 장애에 대한 자동화된 대응 조치인 것으로 보인다. 

DNS, 즉 디렉토리 네임 서비스는 웹 주소를 IP 주소로 번역하는 것에 관한 쿼리에 응답한다. 그리고 페이스북은 자체 DNS 서버를 운영한다. 메디나는 “페이스북은 DNS 서비스가 서버 가용성에 따라 확장되거나 축소되는 아키텍처이다. 네트워크가 끊어지면서 서버 가용성이 0이 되었고, 모든 DNS 서버가 해제됐다”고 설명했다.

이 해제는 페이스북의 DNS 서버가 인터넷 BGP(Border Gateway Protocol) 라우터에 메시지를 보내면서 완료됐다. BGP 라우터는 특정 IP 주소에 도달하는 데 사용하는 경로에 관한 정보를 저장한다. 이 경로가 주기적으로 라우터에 공시되어 각 라우터가 트래픽의 방향을 적절하게 전달하는 방법을 유지한다.

페이스북 DNS 서버의 경로 철회 메시지는 기존에 공시된 경로를 스스로 사용할 수 없도록 만들었으며, 이 때문에 BGP 라우터는 트래픽 경로를 전송할 수 없게 됐다. 야나르단은 “결과적으로 DNS 서버는 작동을 하면서도 접속할 수 없게 됐다. 이 때문에 인터넷에서 페이스북 서버를 찾는 것이 불가능해졌다”라고 밝혔다.

물론 DNS 서버에 액세스할 수 있었다 해도 페이스북 사용자는 서비스를 이용할 수 없었는데, 접속하려고 하는 페이스북의 네트워크가 중단됐기 때문이다. 안타깝게도 페이스북의 엔지니어 역시 DNS 서버에 접속할 수 없었고, 이 때문에 중단된 백본 시스템에 접속하기 위해 필요한 원격 관리 플랫폼에도 접속할 수 없었다.

페이스북은 자체 DNS 서버를 서비스 사용자뿐만 아니라 내부 툴과 시스템에도 사용한다. 그런데 이 서버가 완전히 중단되면서 네트워크 관리자나 엔지니어가 고장 난 시스템을 고치는 데 필요한 시스템에 액세스할 수 없게 된 것이다. 결국 엔지니어들은 관리 콘솔로 문제를 해결하는 것이 아니라 데이터센터로 직접 가서 장비를 하나씩 하나씩 되살릴 수밖에 없었다.

참고로, 좀 더 견고한 아키텍처라면 DNS 서비스를 이중화한다. 대표적인 예로, 아마존은 두 개의 외부 DNS 서비스 Dyn과 울트라DNS를 사용한다. 
 

값비싼 교훈

이번 사고는 페이스북의 아키텍처가 네트워킹의 베스트 프랙티스가 제시하는 구성에 미치지 못했음을 드러냈다. 만약 백본 네트워크의 장애가 없었더라도 단일 DNS 시스템이 장애를 일으키면 전체 서비스가 중단되고 만다. 메디나는 “왜 페이스북의 DNS가 실제로 SPOF가 되었는가? 이번 사태로 여분의 DNS를 갖춰야 한다는 것을 배웠을 것이다”라고 지적했다. 

메디나는 이외에도 많은 서비스 업체의 중단 사태에 대한 한 가지 보편적인 특징을 지적했다. 이런 서비스 중단 사태를 보면, 흔히 네트워크 내의 상호 의존성이 있어서 전체 서비스 아키텍처의 일부에서 발생한 작은 문제가 이런 엄청난 파급 효과를 낳는다는 것. 메디나는 “많은 업체가 내부 서비스를 많이 이용하는데, 여기에는 예기치 않은 결과가 따를 수 있다”고 덧붙였다. editor@itworld.co.kr


X