2021.10.07

"엔지니어도 손대기 힘들었다"··· 페이스북 서비스 장애 원인은?

Tim Greene | Network World
지난 4일 발생한 접속 장애의 근본 원인이 정기적인 유지보수 작업에 따른 DNS 서버 오류였지만, 그보다 앞서 페이스북의 백본 네트워크 전체가 마비된 것이 문제였다고 페이스북이 밝혔다.
 
ⓒ Ben Watts (CC BY 2.0)

페이스북에 따르면 설상가상으로 DNS에 장애가 발생하면서 페이스북 엔지니어들이 네트워크 백업을 위해 필요한 기기에 원격으로 접속할 수 없었다. 엔지니어들은 결국 수동으로 시스템을 재가동하기 위해 데이터센터로 직접 가야만 했다.

늦어진 대응을 더 느리게 만든 건 아무나 접근할 수 없도록 고안된 안전장치였다. 페이스북의 엔지니어링 인프라 담당 부사장 산토시 야나르단은 "데이터센터에 접근하기가 어려웠다. 하드웨어와 라우터에 물리적으로 액세스할 수 있어도 고치기 어렵게 설계돼 있다"라고 공식 블로그에 적었다.

시간은 걸렸지만 시스템이 복구되면서 네트워크가 정상화됐다.

네트워크를 통해 실행되는 고객 대면 서비스를 복구하는 것은 시간이 오래 걸리는 프로세스다. 이들 서비스를 한꺼번에 재가동하면 또 다른 서비스 다운이 발생할 수 있기 때문이다. 야나르단은 "각 데이터센터가 수 십 메가와트 범위의 전력 사용량 감소를 보고하고 있었고, 이런 상황에서 갑작스러운 가동은 전기 시스템부터 (데이터 임시저장소인) 캐시까지 모든 것을 위험에 빠뜨릴 수 있었다”라고 설명했다.

이번 사태로 페이스북은 총 7시간 5분 동안 다운됐다.

유지보수의 실패
페이스북의 서비스 중단을 촉발한 것은 정기적인 유지보수 작업으로, 이 과정에서 백본 네트워크 일부가 끊어졌다.

야나르단은 "정기적인 유지보수 작업 도중에 전 세계 백본 용량의 가용성을 검사해달라는 명령어를 실행했는데 의도와는 달리 이 명령어가 백본 네트워크에서 모든 접속을 끊었다"라며, "사실상 전 세계 페이스북 데이터센터 접속이 중단됐다"라고 설명했다.

이는 예상하기 어려운 상황이었다. 페이스북은 심각한 서비스 중단을 초래할 수 있는 명령어를 걸러내는 도구를 갖추고 있었지만 이번에 이 도구가 제대로 작동하지 않았다.

야나르단은 "시스템이 이러한 실수를 방지하기 위해 명령어를 검사하도록 설계돼 있지만 검사 도구에서 버그가 발생해 명령어 실행을 적절히 중단하지 못했다"고 부연했다.

이 명령어가 실행되자 DNS가 불능 상태가 됐다.

단일 장애점(Single Point of Failure)으로 지목된 DNS
시스코 사우전아이즈(Cisco ThousandEyes)의 제품 마케팅 책임자 안젤리크 메디나는 “백본 네트워크 장애에 대한 자동화된 대응 조치가 DNS 고장을 일으킨 것으로 보인다”라고 말했다.

DNS는 웹 주소를 IP 주소로 변환하는 쿼리에 응답하며, 페이스북은 자체 DNS 네임서버를 호스팅한다. 메디나는 "페이스북은 서버 가용성에 따라 DNS 서비스가 확장 또는 축소되는 아키텍처를 갖고있다"라며 "네트워크가 다운돼 서버 가용성이 ‘0’으로 떨어지면서 페이스북이 모든 DNS 서버를 해제했다"라고 말했다.

이러한 해제 절차는 페이스북의 DNS 네임서버가 인터넷 경계 경로 프로토콜(BGP) 라우터에 메시지를 보내면서 완료됐다. BGP 라우터는 특정 IP 주소 도달을 위해 이용할 경로에 관한 정보를 저장하는 곳이다. 이 경로가 주기적으로 라우터에 전해지면서 트래픽 방향을 적절히 유지할 수 있게 된다.

페이스북 DNS 서버의 '경로 철회' 메시지는 기존에 전달된 경로를 무력화했고, 이 때문에 BGP 라우터가 트래픽을 올바른 경로로 전송할 수 없었다. 야나르단은 "결과적으로 DNS 서버가 가동되고 있었지만 접속을 할 수 없었다. 따라서 인터넷에서 서버를 찾을 수 없었다"라고 설명했다.

인터넷에서 여전히 DNS 서버에 액세스할 수 있었다고 해도 페이스북 사용자는 서비스를 이용할 수 없었다. 접속하려고 하는 페이스북 네트워크가 중단됐기 때문이다. 페이스북 엔지니어 역시 DNS 서버에 접속할 수 없었고, 이 때문에 고장난 백본 시스템에 접속하기 위해 필요한 원격 관리 플랫폼도 사용할 수 없었다.

메디나는 "엔지니어들이 고객 대면 웹 속성(Web Property)을 위해 DNS 서비스를 사용하진 않는다"라며, "그들의 내부 도구 및 시스템을 위해 사용한다"라고 말했다. 이어 그는 "DNS 서버가 완전히 차단되면서 네트워크 사업자 또는 엔지니어가 문제 해결에 필요한 시스템에 액세스할 수 없다"라고 말했다.

그 결과, 엔지니어들이 관리 콘솔에서 문제를 해결하기보다는 데이터센터 장치 하나 하나에 손을 대며 복구해야 했다.

한편, 이보다 좀 더 견고한 아키텍처에서는 DNS 서비스를 이중화한다. 예를 들어 DNS 서비스를 제공하는 아마존의 AWS는 자체 DNS를 위한 두 개의 외부 서비스 'Dyn'과 'UltraDNS'를 활용한다.

이번 사태에서 얻은 교훈
이번 사태는 페이스북 아키텍처가 네트워킹의 베스트 프랙티스에서 제시하는 구성에 미치지 못했음을 보여줬다. 메디나는 "페이스북의 DNS가 사실상 단일 장애점인 이유는 무엇인가?"라며, "백본 네트워크 고장이 없어도 단일 DNS 시스템이 장애를 일으키면 서비스가 중단될 수 있다. 그래서 이중으로 DNS를 갖추는 것이 중요하다"라고 말했다.

메디나는 이외에도 많은 서비스 업체의 중단 사태에 관한 보편적인 특징을 한 가지 지목했다. 그는 "네트워크 내에서 상호의존성이 너무 커서 전체 서비스 아키텍처의 한 부분에서 발생한 작은 문제가 엄청난 파급효과를 낳는다"라며 "다수의 기업들이 내부 서비스를 많이 사용하는데, 이 때문에 예기치 않은 결과가 초래될 수 있다"라고 말했다. ciokr@idg.co.kr
 



2021.10.07

"엔지니어도 손대기 힘들었다"··· 페이스북 서비스 장애 원인은?

Tim Greene | Network World
지난 4일 발생한 접속 장애의 근본 원인이 정기적인 유지보수 작업에 따른 DNS 서버 오류였지만, 그보다 앞서 페이스북의 백본 네트워크 전체가 마비된 것이 문제였다고 페이스북이 밝혔다.
 
ⓒ Ben Watts (CC BY 2.0)

페이스북에 따르면 설상가상으로 DNS에 장애가 발생하면서 페이스북 엔지니어들이 네트워크 백업을 위해 필요한 기기에 원격으로 접속할 수 없었다. 엔지니어들은 결국 수동으로 시스템을 재가동하기 위해 데이터센터로 직접 가야만 했다.

늦어진 대응을 더 느리게 만든 건 아무나 접근할 수 없도록 고안된 안전장치였다. 페이스북의 엔지니어링 인프라 담당 부사장 산토시 야나르단은 "데이터센터에 접근하기가 어려웠다. 하드웨어와 라우터에 물리적으로 액세스할 수 있어도 고치기 어렵게 설계돼 있다"라고 공식 블로그에 적었다.

시간은 걸렸지만 시스템이 복구되면서 네트워크가 정상화됐다.

네트워크를 통해 실행되는 고객 대면 서비스를 복구하는 것은 시간이 오래 걸리는 프로세스다. 이들 서비스를 한꺼번에 재가동하면 또 다른 서비스 다운이 발생할 수 있기 때문이다. 야나르단은 "각 데이터센터가 수 십 메가와트 범위의 전력 사용량 감소를 보고하고 있었고, 이런 상황에서 갑작스러운 가동은 전기 시스템부터 (데이터 임시저장소인) 캐시까지 모든 것을 위험에 빠뜨릴 수 있었다”라고 설명했다.

이번 사태로 페이스북은 총 7시간 5분 동안 다운됐다.

유지보수의 실패
페이스북의 서비스 중단을 촉발한 것은 정기적인 유지보수 작업으로, 이 과정에서 백본 네트워크 일부가 끊어졌다.

야나르단은 "정기적인 유지보수 작업 도중에 전 세계 백본 용량의 가용성을 검사해달라는 명령어를 실행했는데 의도와는 달리 이 명령어가 백본 네트워크에서 모든 접속을 끊었다"라며, "사실상 전 세계 페이스북 데이터센터 접속이 중단됐다"라고 설명했다.

이는 예상하기 어려운 상황이었다. 페이스북은 심각한 서비스 중단을 초래할 수 있는 명령어를 걸러내는 도구를 갖추고 있었지만 이번에 이 도구가 제대로 작동하지 않았다.

야나르단은 "시스템이 이러한 실수를 방지하기 위해 명령어를 검사하도록 설계돼 있지만 검사 도구에서 버그가 발생해 명령어 실행을 적절히 중단하지 못했다"고 부연했다.

이 명령어가 실행되자 DNS가 불능 상태가 됐다.

단일 장애점(Single Point of Failure)으로 지목된 DNS
시스코 사우전아이즈(Cisco ThousandEyes)의 제품 마케팅 책임자 안젤리크 메디나는 “백본 네트워크 장애에 대한 자동화된 대응 조치가 DNS 고장을 일으킨 것으로 보인다”라고 말했다.

DNS는 웹 주소를 IP 주소로 변환하는 쿼리에 응답하며, 페이스북은 자체 DNS 네임서버를 호스팅한다. 메디나는 "페이스북은 서버 가용성에 따라 DNS 서비스가 확장 또는 축소되는 아키텍처를 갖고있다"라며 "네트워크가 다운돼 서버 가용성이 ‘0’으로 떨어지면서 페이스북이 모든 DNS 서버를 해제했다"라고 말했다.

이러한 해제 절차는 페이스북의 DNS 네임서버가 인터넷 경계 경로 프로토콜(BGP) 라우터에 메시지를 보내면서 완료됐다. BGP 라우터는 특정 IP 주소 도달을 위해 이용할 경로에 관한 정보를 저장하는 곳이다. 이 경로가 주기적으로 라우터에 전해지면서 트래픽 방향을 적절히 유지할 수 있게 된다.

페이스북 DNS 서버의 '경로 철회' 메시지는 기존에 전달된 경로를 무력화했고, 이 때문에 BGP 라우터가 트래픽을 올바른 경로로 전송할 수 없었다. 야나르단은 "결과적으로 DNS 서버가 가동되고 있었지만 접속을 할 수 없었다. 따라서 인터넷에서 서버를 찾을 수 없었다"라고 설명했다.

인터넷에서 여전히 DNS 서버에 액세스할 수 있었다고 해도 페이스북 사용자는 서비스를 이용할 수 없었다. 접속하려고 하는 페이스북 네트워크가 중단됐기 때문이다. 페이스북 엔지니어 역시 DNS 서버에 접속할 수 없었고, 이 때문에 고장난 백본 시스템에 접속하기 위해 필요한 원격 관리 플랫폼도 사용할 수 없었다.

메디나는 "엔지니어들이 고객 대면 웹 속성(Web Property)을 위해 DNS 서비스를 사용하진 않는다"라며, "그들의 내부 도구 및 시스템을 위해 사용한다"라고 말했다. 이어 그는 "DNS 서버가 완전히 차단되면서 네트워크 사업자 또는 엔지니어가 문제 해결에 필요한 시스템에 액세스할 수 없다"라고 말했다.

그 결과, 엔지니어들이 관리 콘솔에서 문제를 해결하기보다는 데이터센터 장치 하나 하나에 손을 대며 복구해야 했다.

한편, 이보다 좀 더 견고한 아키텍처에서는 DNS 서비스를 이중화한다. 예를 들어 DNS 서비스를 제공하는 아마존의 AWS는 자체 DNS를 위한 두 개의 외부 서비스 'Dyn'과 'UltraDNS'를 활용한다.

이번 사태에서 얻은 교훈
이번 사태는 페이스북 아키텍처가 네트워킹의 베스트 프랙티스에서 제시하는 구성에 미치지 못했음을 보여줬다. 메디나는 "페이스북의 DNS가 사실상 단일 장애점인 이유는 무엇인가?"라며, "백본 네트워크 고장이 없어도 단일 DNS 시스템이 장애를 일으키면 서비스가 중단될 수 있다. 그래서 이중으로 DNS를 갖추는 것이 중요하다"라고 말했다.

메디나는 이외에도 많은 서비스 업체의 중단 사태에 관한 보편적인 특징을 한 가지 지목했다. 그는 "네트워크 내에서 상호의존성이 너무 커서 전체 서비스 아키텍처의 한 부분에서 발생한 작은 문제가 엄청난 파급효과를 낳는다"라며 "다수의 기업들이 내부 서비스를 많이 사용하는데, 이 때문에 예기치 않은 결과가 초래될 수 있다"라고 말했다. ciokr@idg.co.kr
 

X