사례11건

11건 중 8~11번째

1. IL-0254 내부 DNS 서버가 무너져 Square 의 제품과 서비스가 약 15시간 멈추고 결제가 되지 않았다

   Square2023

   증상

   2023년 9월 7일 오후 1:54 ET 부터 Square 의 제품과 서비스를 쓸 수 없었다. 오후 2:02 ET 에 엔지니어들이 인프라 문제 알림을 받고 DNS 부터 조사하기 시작했다.

   DNS 조회 실패서비스 중단

   촉발

   Square 는 2023년 9월 7일 오전 11:04 ET 에 리전 간 통신을 열려고 호스트 방화벽 규칙 변경을 배포했고, 오후 1:56 ET 에는 DNS 영역 변경이 있었다. 작은 정책 변경이 노드에서 훨씬 큰 규칙 묶음으로 펼쳐졌다.

   원인

   설정 변경

   구성 요소

   DNS 서버와 레코드노드 iptables 규칙

   기여 요인

   단계적 배포 부재캐시로 가려진 장애순환 의존

   감지

   오후 2:02 ET 에 엔지니어들이 인프라 문제 알림을 받았다. 장애가 시작되고 8분 뒤였다.

   조치

   • DNS 서버로 가는 네트워크 트래픽을 덜고, 새 DNS 서버를 손으로 띄우기 시작했다.
   • 인증과 접근 서비스를 되살리려고 네트워크 변경을 손으로 배포했다.
   • 모든 데이터센터에 네트워크 변경을 손으로 배포했다.
   • DNS 서버를 다시 만들었다.
   • 되돌린 방화벽 규칙 묶음으로 새 설정을 만들어 DNS 호스트에 내보냈다.

   후속 조치

   • DNS 인프라를 격리된 인프라로 옮긴다.
   • 핵심 네트워크 인프라에 모니터링과 최적화를 더한다.
   • 가능한 곳에서 배포 인프라와 플랫폼 인프라 사이의 의존 관계를 최적화한다.
   • 오프라인 모드 지원을 넓히고, 오프라인 모드를 쓸 수 있는지 판매자에게 더 잘 알린다.

   사례 보기
2. IL-0221 유지보수 명령이 Facebook 백본 네트워크의 연결을 모두 끊어 데이터 센터와 DNS 서버가 인터넷에서 닿지 않게 됐다.

   Meta2021

   증상

   Facebook 데이터 센터 사이의 서버 연결과 데이터 센터와 인터넷 사이의 서버 연결이 한꺼번에 완전히 끊겼다. DNS 서버는 동작하고 있었지만 인터넷에서 닿지 않아 누구도 Facebook 서버를 찾을 수 없었다. 백본이 통째로 빠지자 DNS 서버가 있는 작은 시설들이 스스로 비정상이라고 판단해 BGP 광고를 거둬들였기 때문이다.

   서비스 중단DNS 조회 실패네트워크 도달 불가

   촉발

   일상적인 유지보수 작업 중에 전 세계 백본 용량의 가용성을 평가하려고 내린 명령이 의도치 않게 백본 네트워크의 모든 연결을 끊었다. 이런 명령을 검사해 실수를 막는 감사 도구가 버그 때문에 이 명령을 멈추지 못했다.

   원인

   운영 실수

   구성 요소

   백본망BGP 라우팅DNS 서버와 레코드

   기여 요인

   자동화 증폭순환 의존디버그 접근 제한

   조치

   • 주 네트워크 접근과 out-of-band 접근이 모두 끊겨, 팀은 엔지니어를 데이터 센터 현장에 보내 문제를 디버깅하고 시스템을 다시 시작하게 했다.
   • 보안 접근 절차를 거쳐 현장 인력이 서버를 다룰 수 있게 된 뒤 문제를 확인하고 백본을 다시 온라인으로 올렸다.
   • storm 훈련에서 얻은 경험을 살려 서비스를 다시 켜면서 늘어나는 부하를 조심스럽게 관리했다.

   후속 조치

   • 전 세계 백본이 끊기는 상황을 storm 훈련으로 시뮬레이션할 방법을 찾는다.
   • 테스트와 훈련, 전반적인 복원력을 강화해 이런 사고가 최대한 드물게 일어나게 한다.

   교훈

   무단 접근을 막으려고 강화한 보안이, 공격이 아니라 스스로 낸 실수에서 비롯된 장애의 복구를 늦췄다. Meta 는 드문 사고에서 복구가 느려지더라도 평소의 보안을 크게 높이는 편이 낫다고 봤다. 서비스, 데이터 센터, 리전 전체를 내리는 storm 훈련이 부하를 다시 올리는 데 도움이 됐지만, 전 세계 백본이 끊기는 상황은 훈련해 본 적이 없었다.

   사례 보기
3. IL-0229 손상된 SmartEdge 데이터 파일을 받은 bunny.net 의 전 세계 DNS 서버가 크래시를 되풀이해 플랫폼 대부분이 2시간 넘게 멈췄다.

   bunny.net2021

   증상

   2021-06-22 UTC 8:25 에 업데이트를 내보내고 몇 분 만에 전 세계에 있는 100대 가까운 bunny.net DNS 서버가 거의 모두 죽었다. bunny.net 은 트래픽의 60% 넘게 잃었고, 수백 Gbit 의 처리량이 사라졌으며, 750,000개가 넘는 웹사이트가 영향을 받았다.

   컨테이너 재시작 반복DNS 조회 실패서비스 중단요청 오라우팅부하 불균형

   촉발

   2021-06-22 UTC 8:25 에 최적화 데이터베이스의 다운로드 크기를 줄이려는 업데이트가 손상된 파일을 Edge Storage 에 올렸다. DNS 서버가 이 파일을 읽자 BinaryPack 직렬화 라이브러리가 stack overflow 예외를 일으켰고, 예외 처리를 건너뛴 채 DNS 프로세스가 종료됐다.

   원인

   배포 결함

   구성 요소

   DNS 서버와 레코드CDN 과 엣지 네트워크오브젝트 스토리지

   기여 요인

   순환 의존단일 장애점자동화 증폭롤백 무효수동 조치 악화

   감지

   팀은 무슨 일인지 알아채는 데 시간이 걸렸다. 업데이트 10분 뒤에야 DNS 서버가 다시 시작했다가 죽기를 되풀이하고 있고, 이 상태로는 되살릴 방법이 없다는 것을 알았다.

   조치

   • UTC 8:45 에 SmartEdge 시스템을 끄는 업데이트를 DNS 노드에 손으로 배포했다. 하지만 손상된 GeoDNS 데이터베이스 때문에 요청이 Madrid 로 몰렸다.
   • 9:40 무렵 임시 조치로 모든 요청을 가장 큰 리전인 Frankfurt 로 보내는 라우팅 업데이트를 준비해 DNS 서버 몇 대에 손으로 배포했다. 트래픽의 상당 부분이 돌아왔다.
   • 자체 시스템을 쓰지 않으려고 배포 시스템과 파일을 모두 외부 클라우드 스토리지 서비스로 옮겼다.
   • 10:15 에 배포 시스템과 DNS 소프트웨어를 새 스토리지에 연결하도록 바꾸고 배포했다. 10:30 에 트래픽이 돌아왔지만 잘못된 GeoDNS 데이터베이스 버전 때문에 요청은 여전히 Madrid 로 갔다.
   • 10:45 에 외부 서비스를 거쳐 데이터베이스를 동기화하고 최신 파일 세트를 배포해 서비스를 되살렸다. 11:00 에 상황이 안정되기 시작했다.

   후속 조치

   • 긴급 수정으로 BinaryPack 라이브러리를 단계적으로 걷어 낸다.
   • 앞으로 쓰는 외부 라이브러리를 더 폭넓게 시험한다.
   • 내부 API 를 외부의 독립 서비스로 완전히 옮긴다. 그 서비스가 내려가면 업데이트를 못 하지만, bunny.net 시스템이 내려가도 무너지는 인프라에 갇히지 않고 빠르게 대응할 수 있다.
   • 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 걸친 단일 장애 지점이 되지 않게 하는 방법을 조사한다.
   • DNS 시스템이 모든 백업 데이터의 로컬 사본을 갖추고 장애를 자동으로 감지하게 해, 시스템끼리 최대한 독립시키고 장애가 연쇄로 번지지 않게 한다.

   교훈

   bunny.net 은 내부 인프라의 핵심 부분까지 모든 시스템이 서로 기대도록 설계했다. 그 때문에 손상된 파일 하나가 여러 겹의 이중화를 무너뜨리고 복구할 길까지 막았다. 자체 인프라를 자기 생태계 안에 지으면 한 곳의 장애가 연쇄로 번질 수 있다. 업데이트는 카나리 방식으로 잘게 배포하려 했지만, 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 동시에 걸친 단일 장애 지점이 됐다. 급하게 고치는 동안 오타와 실수가 늘었고, 결국 침착하게 모든 것을 다시 확인한 뒤의 마지막 배포로 복구했다.

   사례 보기
4. IL-0278 주간 소프트웨어 업데이트 뒤 GCP 의 Redis Cloud 클러스터 노드 대부분이 동시에 응답하지 않아 그 클러스터의 데이터베이스가 내려갔다

   Redis2016

   증상

   2016년 2월 8일 17:45 UTC 에 Google Cloud Platform 의 Redis Cloud 클러스터 us-central1-1-1.gce.garantiadata.com 에서 큰 장애가 났다. 데이터베이스 엔드포인트가 us-central1-1-1.gce.garantiadata.com 으로 끝나는 사용자들이 데이터베이스를 쓰지 못했다.

   서비스 중단장애 조치 실패

   촉발

   2016년 2월 8일 17:30 UTC 에 서비스 소프트웨어의 주간 업그레이드가 GCP 클러스터 us-central1-1-1.gce.garantiadata.com 에 처음 배포됐다.

   원인

   배포 결함

   구성 요소

   인메모리 캐시데이터베이스 장애 조치 관리자DNS 서버와 레코드

   기여 요인

   장애 중첩

   조치

   • 클러스터의 모든 노드를 내리고 종료했다.
   • 클러스터의 모든 엔드포인트를 클러스터의 DNS 영역에서 지웠다. DNS 제공자가 삭제 요청을 스로틀링해 남은 항목은 손으로 지웠다.
   • 주간 업데이트를 뺀 새 클러스터 노드를 처음부터 만들었다.
   • 원래 노드가 쓰던 저장소를 새 노드에 다시 붙여, 영속성이 있는 데이터베이스를 복구할 수 있게 했다.
   • 데이터베이스를 모두 띄웠고, 영속성이 있는 데이터베이스는 저장소에서 복구했다.

   후속 조치

   • 이번 같은 장애를 막는 절차를 갖출 때까지 자동 주간 업그레이드를 모두 멈춘다.
   • DevOps 코드 배포의 QA 절차를 다시 검증한다.
   • DNS 요청이 스로틀링될 때 도구가 이를 처리하도록 개선한다.

   사례 보기

원인별5