사례20건

20건 중 16~20번째

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

   사례 보기
2. IL-0398 GOV.UK 가 쓰는 주 CDN 에 전 세계 장애가 나서, 1시간이 안 되는 동안 GOV.UK 방문자가 오류 페이지만 봤다

   Government Digital Service2021

   증상

   2021년 6월 8일 1시간이 안 되는 동안 GOV.UK 방문자가 정보와 서비스에 접근하지 못하고 오류 페이지를 봤다. 팀은 장애가 시작되고 4분 뒤에 알아챘다.

   서비스 중단

   원인

   의존성 장애

   구성 요소

   CDN 과 엣지 네트워크

   기여 요인

   –

   감지

   장애는 시작되고 4분 뒤에 감지됐다. 팀은 장애 책임자를 정했고, 장애 책임자는 커뮤니케이션 책임자와 함께 공식 장애 대응 절차를 시작했다.

   조치

   • 감지하고 15분이 지나도 상태가 바뀌지 않자 보조 CDN 으로 페일오버하기로 했다.
   • 30분 안에 DNS 레코드 변경을 배포했고, 트래픽이 보조 CDN 으로 가기 시작했다.
   • 주 CDN 이 회복되는 것을 몇 분 지켜본 뒤 주 CDN 으로 되돌렸고, 1시간을 더 지켜본 뒤 장애 종료를 선언했다.

   후속 조치

   • 공식 장애 리뷰를 열어 무슨 일이 있었는지, 대응이 어땠는지, 다음에 더 잘하려면 무엇을 해야 하는지 논의한다.
   • 장애 중에 더 빠르고 투명하게 소통할 방법을 검토한다.
   • 이미 계획한 플랫폼 기술과 절차의 변경으로 앞으로 장애가 났을 때 더 빨리 복구할 수 있는 방법을 검토한다.

   교훈

   어떤 인프라도 100% 믿을 수는 없고, 네트워크 엣지에 있는 CDN 이 망가지면 사이트 전체가 내려가므로 예비 계획이 있어야 한다고 팀은 말했다. 보조 CDN 으로는 기능이 줄어든 서비스만 할 수 있어서 페일오버는 큰 결정이고, 주 CDN 장애가 빨리 끝나면 너무 이른 페일오버가 오히려 장애를 키울 수 있다고 했다. 이런 장애에서는 침착하게, 목적을 분명히 하고 움직이는 것이 중요하다고 했다. 방문자가 본 오류 페이지는 GOV.UK 가 손댈 수 없는 페이지였고, 아무 정보도 주지 못해 GOV.UK 의 콘텐츠 기준에 크게 못 미쳤다고 했다.

   사례 보기
3. IL-0491 CDN 원본 서버군의 정상 노드가 안전 수준 아래로 줄어 Squarespace 일부 사이트가 이미지, 스크립트, 스타일시트를 불러오지 못했다

   Squarespace2019

   증상

   2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. static.squarespace.com과 static1.squarespace.com 도메인이 영향을 받아 일부 사이트가 이미지, 스크립트, 스타일시트를 불러오지 못했다.

   오류율 상승

   촉발

   2019-02-11 오후 10시 30분 ET에 한 엔지니어가 Squarespace CDN 원본 서버군 전체에 유지보수 작업을 시작했다. 엔지니어는 작업을 멈췄다고 생각했지만 작업은 백그라운드에서 계속 돌았고, 2019-02-12 오전 12시 10분에 CDN 원본 서비스 장애를 일으켰다.

   원인

   운영 실수

   구성 요소

   CDN 과 엣지 네트워크

   기여 요인

   과도한 영향 범위모니터링 사각지대

   감지

   2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. 알림은 서버군이 핵심 가용성 기준 아래로 떨어진 뒤에야 왔고, 고객 영향이 크다는 것은 나중에야 분명해졌다.

   조치

   • 오전 2시 15분 ET까지 추가 복구 조치로 CDN 원본 서버군 일부를 되살렸고, 2시 20분에 서비스가 정상으로 돌아왔다.

   후속 조치

   • 장애 대응 플레이북을 고쳐 이 서버군에 영향을 주는 문제 대부분을 빨리 해결할 점검과 조치를 넣는다. 첫 점검에서 고객 영향을 판단하고 인시던트 커맨더를 바로 부르게 한다.
   • CDN 협력사와 원본 서비스의 문제가 고객에게 주는 영향을 더 빨리 판단할 수 있도록 외부 모니터링을 개선한다.
   • 엔지니어가 유지보수 명령을 내리는 방식의 운영 정책을 고치고 안전장치를 더한다. 그런 명령이 작업할 수 있는 서버군의 범위를 제한한다.
   • 사람이 직접 하는 유지보수 작업이 필요한 경우를 줄인다.
   • 독립된 장애 도메인을 만들고, 상태가 나쁜 부분을 피해 요청을 자동으로 보내도록 해 인프라의 복원력을 높인다.

   사례 보기
4. IL-0338 Google Cloud 의 HTTP(S) 로드 밸런서와 TCP/SSL Proxy 로드 밸런서가 32분 동안 요청의 33~87% 에 502 나 연결 재설정을 냈다

   Google Cloud2018

   증상

   2018년 7월 17일 12시 17분 PDT 부터 Google Cloud App Engine, HTTP(S) 로드 밸런서, TCP/SSL Proxy 로드 밸런서를 쓰는 고객의 요청이 502 응답 코드나 연결 재설정으로 실패했다. 오류 비율은 32분 동안 33% 에서 87% 사이를 오갔다.

   오류율 상승연결 리셋지연 시간 증가

   촉발

   두 번째 계층 GFE 코드에는 아직 쓰지 않던 새 기능이 들어가 있었고, 이 기능에 버그가 있었다. 운영 환경의 설정 변경이 이 버그를 간헐적으로 건드렸고, 버그는 GFE 를 재시작시켰다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서CDN 과 엣지 네트워크

   기여 요인

   자동 테스트 공백과도한 영향 범위

   감지

   12시 19분에 자동 모니터링이 Google 엔지니어링 팀에 알림을 보냈다. 엔지니어는 장애가 시작되고 3분 안에 알림을 받고 바로 조사를 시작했다.

   조치

   • 12시 44분 PDT 에 원인을 찾고 문제의 설정 변경을 곧바로 되돌렸다. 영향받은 GFE 들이 재시작을 멈추고 모두 서비스에 돌아오자 트래픽이 평소 수준과 동작을 되찾았다.

   후속 조치

   • 아직 쓰지 않는 기능을 꺼 두는 안전장치를 더한다.
   • 작업을 재시작시킬 수 있는 잠재 버그가 운영 바이너리에 남을 위험을 줄이도록 GFE 테스트 스택을 더 단단하게 만든다.
   • 장애가 미치는 범위를 줄이도록 GFE 풀의 샤드끼리 더 격리한다.
   • 진단을 빠르게 하도록 GFE 풀의 모든 설정 변경을 한곳에 모은 대시보드를 만들어, 엔지니어가 문제를 일으킨 변경을 쉽게 보고 대조해 찾아내게 한다.

   사례 보기
5. IL-0388 Redis 고가용 클러스터의 primary 노드가 내려간 뒤 Discord API 가 느려지고 길드 일부가 오프라인으로 보이며 접속이 실패했다

   Discord2017

   증상

   2017년 10월 13일 14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. API 서비스가 쓰는 Redis 고가용 클러스터에서 primary 노드가 완전히 사라졌다. 클러스터는 secondary 노드로 제대로 failover 했지만, 일부 API 인스턴스가 failover 를 제대로 처리하지 못했다.

   장애 조치 실패지연 시간 증가서비스 중단

   촉발

   14:01 PDT 쯤 Google Cloud Platform 이 API 서비스용 Redis 고가용 클러스터의 primary 인스턴스를 자동으로 마이그레이션했다. 이 마이그레이션으로 노드가 잘못 오프라인이 되면서 클러스터가 재조정됐고, API 인스턴스의 Redis failover 처리에 있던 알려진 문제가 드러났다.

   원인

   소프트웨어 결함

   구성 요소

   인메모리 캐시데이터베이스CDN 과 엣지 네트워크

   기여 요인

   미패치 알려진 버그장애 중첩모니터링 사각지대

   감지

   14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. 15:41 에 모니터링에서 다시 이상이 보였고, 15:42 에 서버 일부가 오프라인으로 보인다는 사용자 신고가 엔지니어링 팀에 들어왔다.

   조치

   • Redis 연결 문제를 풀려고 14:11 PDT 에 모든 API 인스턴스를 롤링 재시작했다. 재시작은 14:15 에 끝났지만 API 지연은 계속 높았다.
   • 비용이 큰 API 경로에 잘못 걸린 엣지 캐시 규칙을 고쳤다.
   • 엔드포인트를 쓸 수 없는 동안에는 응답을 캐시할 수 없어서, 문제를 일으킨 API 엔드포인트를 상위 엣지 네트워크에서 막았다.
   • 부하로 쓰러진 Cassandra 클러스터를 되살려 정상 서비스로 돌렸다.
   • Cassandra 클러스터 문제로 생긴 지연을 풀려고 모든 API 인스턴스를 다시 롤링 재시작했다. 14:57 에 API 가 정상으로 돌아왔다.
   • 15:50 PDT 에 이상하게 동작하는 "guilds" 노드를 서비스 해시링에서 강제로 빼서, 그 서버가 스스로 제대로 내려가기를 기대했다.
   • 15:52 PDT 에 그 guilds 노드를 강제로 재시작했고, 재시작은 성공했다.
   • 16:07 PDT 에 전체 서비스를 재시작하기로 하고, 모든 사용자를 다시 접속시켜 여러 서비스의 잘못된 상태를 초기화했다.
   • "push" 구성 요소의 부하를 줄이려고 이 구성 요소에 기대는 트래픽 여러 갈래를 차단 목록에 넣었다.
   • 사용자가 빠르고 안전하게 다시 접속하게 해 주는 API 설정이 사람의 실수로 잘못 들어가 있던 것을 고쳤다. 16:33 부터 서비스가 천천히 회복했다.

   후속 조치

   • Redis failover 의 알려진 문제를 고치는 일의 우선순위를 올려, 앞으로 몇 주 안에 끝내려 한다. 노드 하나의 장애로 문제가 더 생기지 않게 하려는 것이다.
   • 캐시가 잘못 걸렸던 경로의 동작을 바꿔, 앞으로 이런 오류가 나도 다른 서비스를 망가뜨리지 않고 제대로 처리하게 했다.
   • 연쇄 장애를 미리 알려 줄 수 있었던 신호 일부에 모니터링을 더했다. 엔지니어가 조사하고 대비할 시간을 벌려는 것이다.
   • 이번 장애에 영향을 받은 서비스들의 전반적인 신뢰성과 장애 처리를 개선할 계획을 이어 간다.
   • 문제가 된 서비스가 쓰는 라이브러리에서 결함으로 보이는 것을 찾았고, 이를 고칠 것으로 보는 업데이트를 배포하고 있다.

   사례 보기

원인별8