사례8건

8건 중 3~7번째

1. IL-0233 eu-west1 에서 Managed Kubernetes 의 거의 모든 파드가 네트워크 연결을 잃었고 롤백으로도 돌아오지 않았다

   Nebius2025

   증상

   2025-03-13 eu-west1 리전에서 Managed Services for Kubernetes 고객의 파드가 거의 모두 13:36 에서 18:11 UTC 사이에 적어도 한동안 네트워크 연결을 잃었다. Nebius 팀은 15:13 UTC 에 문제를 알아챘다. eu-north1 리전은 영향을 받지 않았다.

   네트워크 도달 불가

   촉발

   eu-west1 에 배포한 VPC 컨트롤 플레인 구성 요소의 릴리스가 새 기능에 필요한 route distinguisher 값을 바꿨다. 이 변경으로 오래전부터 코드에 있던 버그가 실제로 드러났다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 컨트롤 플레인BGP 라우팅

   기여 요인

   롤백 무효자동 테스트 공백모니터링 사각지대

   조치

   • 문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾고, 영향을 받은 모든 노드에서 구성 요소를 한 번에 한 노드씩 재시작하기 시작했다.
   • 17:57 UTC 에 구성 요소 재시작만으로 고쳐진다고 확신하고 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다.

   후속 조치

   • 버그 자체를 바로잡는다.
   • 경로 수가 어긋나면 울리는 알림을 더한다.
   • 데이터 플레인의 패킷 drop 수를 보는 알림을 더한다.
   • 호스트 VPC 구성 요소를 재시작하지 않고도 엔드포인트를 초기화하는 방법을 만든다.
   • VPC 의 상시 e2e 테스트 가상 머신을 카나리 호스트로 옮긴다.
   • Managed Services for Kubernetes 용 상시 e2e 테스트를 더한다.
   • e2e 테스트를 더 자주 돌린다.
   • 중요하지 않은 내부 서비스가 가장 먼저 업데이트를 받는 배포 단계를 새로 둔다.

   교훈

   문제를 재현하려면 두 조건이 함께 맞아야 해서 테스트 환경과 카나리의 e2e 테스트로는 잡지 못했다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응이 늦어졌다. 이번 경우에는 경로 수와 패킷 drop 수가 민감하게 반응한 지표였다.

   사례 보기
2. IL-0340 Cloudflare 1.1.1.1 리졸버가 4시간 동안 일부 유효한 DNS 질의에 SERVFAIL 을 냈다

   Cloudflare2023

   증상

   2023년 10월 4일 07:00 UTC 부터 1.1.1.1 을 직접 쓰거나 WARP, Zero Trust, 또는 1.1.1.1 을 쓰는 다른 회사의 DNS 리졸버를 거치는 일부 사용자가 유효한 질의에 SERVFAIL DNS 응답을 받았다. 07:57 에 예상하지 못한 SERVFAIL 을 알리는 외부 신고가 처음 들어왔다.

   DNS 조회 실패오류율 상승

   촉발

   9월 21일 루트 존에 ZONEMD 라는 새 리소스 레코드 형식이 처음 들어왔고, 1.1.1.1 리졸버가 이 레코드를 파싱하지 못해 새 루트 존을 쓰지 못했다. 10월 4일 07:00 UTC 에 계속 쓰던 9월 21일 판 루트 존의 DNSSEC 서명이 만료됐다.

   원인

   소프트웨어 결함

   구성 요소

   재귀 DNS 리졸버 서비스

   기여 요인

   캐시로 가려진 장애안전하지 않은 실패 동작모니터링 사각지대자동 테스트 공백

   감지

   07:57 UTC 에 예상하지 못한 SERVFAIL 을 알리는 외부 신고가 처음 들어왔고, 08:03 에 Cloudflare 내부 장애가 선언됐다. static_zone 이 오래된 루트 존을 내주는 상황을 알리는 알림은 없었다.

   조치

   • 08:50 UTC 에 override 규칙으로 1.1.1.1 이 오래된 루트 존 파일로 응답하지 않게 하려 했다. 다른 노드로 넘긴 질의에는 rec_disable_static 태그가 실리지 않아 static_zone 앱이 계속 오래된 정보로 답했다.
   • 10:30 UTC 에 1.1.1.1 이 루트 존 파일을 아예 미리 읽지 않게 했다. 10:32 에 응답이 정상으로 돌아왔다.

   후속 조치

   • static_zone 이 오래된 루트 존 파일을 내줄 때 알리는 알림을 더한다.
   • 루트 존을 받아 와 내부에 배포하는 방식을 다시 검토해, 새 RRTYPE 을 문제없이 다루고 파이프라인이 잠깐 끊겨도 최종 사용자에게 보이지 않게 한다.
   • 루트 존 파싱이 실패할 때 어떻게 되는지 충분히 테스트하지 않았으므로 테스트 범위와 관련 절차를 개선한다.
   • RFC 8806 이 설명하는 대로 캐시한 루트 존 데이터의 수명을 관리해, 일정 시점이 지난 오래된 루트 존 사본을 쓰지 않게 한다.

   교훈

   Cloudflare 는 무엇이든 바뀌지 않으리라고 가정하지 말라는 것을 이 사고의 분명한 교훈으로 꼽았다. 최종 실행 파일에 들어가는 긴 라이브러리 사슬 어디에든 버그가 있거나, 입력이 바뀔 때 제대로 동작할 만큼 일찍 갱신되지 않은 것이 있을 수 있다고 했다. 회귀를 잡아내는 테스트와 입력이 바뀌어도 부드럽게 실패하는 시스템이 중요하다고 했다. DNS 와 BGP 처럼 인터넷에서 가장 중요한 시스템의 형식 변경은 영향을 줄 것이라고 늘 가정해야 한다고 했다. 오래된 루트 존을 내주는 것을 더 잘 감시했다면, 이미 있는 캐시 덕분에 영향이 없었을 것이라고 했다.

   사례 보기
3. IL-0253 Firefox 가 네트워크 스레드의 무한 루프에 빠져 전 세계에서 2시간 가까이 웹 페이지를 열지 못했다

   Mozilla2022

   증상

   2022년 1월 13일 07:28 UTC 직후 크래시 리포터로 들어오는 크래시가 갑자기 늘었고, Mozilla 안팎에서 브라우저가 멈춘다는 신고가 여럿 들어왔다. 전 세계 사용자의 Firefox 가 2시간 가까이 웹 콘텐츠를 불러오지 못하고 쓸 수 없는 상태가 됐다.

   서비스 중단

   촉발

   2022년 1월 13일 07:28 UTC 에 GCP 가 예고 없이 로드 밸런서의 HTTP/3 를 기본으로 켰다. Mozilla 의 로드 밸런서는 "Automatic (default)" 설정이어서 Firefox 가 Telemetry 서비스로 여는 연결 일부가 HTTP/2 대신 HTTP/3 를 쓰게 됐다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서HTTP·RPC 클라이언트 라이브러리

   기여 요인

   기본 설정 방치자동 테스트 공백

   감지

   크래시 리포터로 들어오는 크래시가 갑자기 늘었고, Mozilla 안팎에서 브라우저가 멈춘다는 신고가 여럿 들어왔다.

   조치

   • 09:12 UTC 에 GCP 에서 HTTP/3 를 명시적으로 껐다.

   후속 조치

   • GCP 와 함께 예고 없는 기본값 변경 문제를 개선한다.
   • 비슷한 실수를 막으려고 모든 서비스의 설정을 다시 검토한다.
   • HTTP 버전을 바꿔 가며 시스템 테스트를 더 돌린다.
   • 이런 문제에 브라우저가 더 잘 견디고 사고 대응이 더 빨라지도록 할 조치를 찾는다.

   교훈

   문제는 처음 보기보다 훨씬 복잡했고 여러 요인이 함께 작용했다. GCP 가 HTTP/3 기본값 변경을 예고했다면 사고를 완전히 막지는 못했어도 스테이징 환경 같은 곳에서 더 통제된 실험과 배포를 할 수 있었을 것이다. 로드 밸런서를 명시적인 값 대신 "Automatic (default)" 로 둔 탓에 변경이 저절로 적용됐다. Firefox Desktop 에서 HTTP/3 와 viaduct 를 함께 쓰는 조합은 CI 가 시험하지 않았다. 모든 조합을 시험할 수는 없어도 HTTP 버전 선택이나 viaduct 같은 추가 네트워크 계층은 시험했어야 했다. HTTP 버전을 바꿔 가며 시스템 테스트를 더 돌렸다면 이 문제를 찾았을 것이다.

   사례 보기
4. IL-0345 Render Oregon 리전의 많은 서비스가 4시간 동안 503 오류를 평소보다 많이 냈다

   Render2020

   증상

   2020년 12월 6일 13:34 PST 부터 Render 의 Oregon 리전에서 많은 서비스가 높은 비율로 503 Service Unavailable 응답을 냈다. 모니터링 시스템이 바로 문제를 알렸다.

   오류율 상승

   촉발

   13:34 PST 에 Oregon 리전에 올라간 고객 API 하나가 들어온 요청을 붙잡고 있다가 타임아웃 오류로 끝내기 시작했다. 이 서비스는 Oregon 리전에서 요청을 가장 많이 받는 축에 들었다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서

   기여 요인

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

   감지

   13:34 PST 에 장애가 시작되자 모니터링 시스템이 바로 Render 팀에 알렸다.

   조치

   • 이번 같은 장애를 막는 수정을 모든 로드 밸런서에 내보냈다.

   후속 조치

   • Render 의 라우팅 계층과 로드 밸런싱 계층에서 서비스끼리 더 격리하는 장치를 만든다.
   • 로드 밸런싱 코드의 테스트 범위를 넓힌다.
   • 예상하지 못한 일이 생겨도 플랫폼이 버티도록, CI 테스트 스위트에 가상의 장애 상태를 더 넣는다.
   • 카오스 엔지니어링에 다시 힘을 쏟는다.

   사례 보기
5. 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 풀의 모든 설정 변경을 한곳에 모은 대시보드를 만들어, 엔지니어가 문제를 일으킨 변경을 쉽게 보고 대조해 찾아내게 한다.

   사례 보기

원인별1