사례4건

4건 중 1~4번째

1. IL-0366 us-central1 의 Cloud Storage 업로드와 쓰기가 이틀에 걸쳐 18시간 넘게 느려지고 실패했다

   Google Cloud2026

   증상

   us-central1 리전에서 Cloud Storage 업로드와 쓰기 요청의 지연과 오류율이 올라갔다. 고객은 주로 WriteObject 작업에서 HTTP 503 UNAVAILABLE 오류와 클라이언트 쪽 타임아웃을 봤다.

   지연 시간 증가오류율 상승부하 불균형

   촉발

   Cloud Storage 부하 분산 계층에 트래픽 정렬 최적화 설정 업데이트가 배포됐다. 이 설정은 용량을 보고 경로를 정하는 표준 로직을 의도치 않게 건너뛰었다.

   원인

   설정 변경

   구성 요소

   오브젝트 스토리지데이터베이스

   기여 요인

   여유 용량 부재장애 중첩

   감지

   Google 엔지니어링 팀이 시스템 텔레메트리를 지켜보다가 10월 8일 04:50에 문제를 처음 알아챘다. 장애가 시작되고 50분 뒤였다.

   조치

   • 부하가 가장 큰 스토리지 백엔드 노드를 골라 트래픽을 뺐다.
   • 트래픽 정렬 최적화를 끄는 설정 변경을 배포해 스토리지 백엔드의 자원 부담을 크게 줄였다.
   • 같은 시기에 난 메타데이터 문제를 막으려고 메타데이터 데이터베이스 서비스의 최근 업데이트를 롤백했다.
   • 부하 불균형이 다시 일어나자 트래픽을 더 돌리고 영향받은 스토리지 구성 요소에서 트래픽을 뺐다.
   • 문제의 부하 분산 설정 변경을 완전히 되돌려 용량을 보고 경로를 정하던 이전 동작을 되살렸고, 트래픽이 리전 전체에 고르게 퍼졌다.
   • 트래픽과 자원 사용률이 평소 수준으로 돌아온 뒤 트래픽을 뺐던 노드를 다시 서비스에 넣었다.

   후속 조치

   • 부하 분산 로직 변경은 사용률이 높은 큰 리전에 내보내기 전에 더 작은 다른 리전에서 먼저 엄격하게 검증하도록 배포 절차를 바꾼다.
   • 스토리지 부하 분산 구조가 용량 제약을 반드시 지키게 한다. 트래픽 분배 로직이 Google 이 pre-spilling 이라고 부르는 안전장치를 건너뛰어 처리 자원이 모자란 클러스터로 트래픽을 보내는 일이 없게 한다.
   • 사용률이 높은 스토리지 셀 안의 내부 데이터 이동을 빠르게 해, 일시적인 부하 급증을 더 잘 견디게 한다.

   사례 보기
2. IL-0561 DigitalOcean 의 Cloud Control Panel 과 공개 API 에서 두 차례에 걸쳐 요청이 최대 25% 실패했다

   DigitalOcean2026

   증상

   2026년 8월 24일 16:56 UTC 부터 DigitalOcean 의 Cloud Control Panel, 공개 API, 그리고 이 둘에 기대는 제품 관리 시스템에서 요청 오류율이 올라갔다. 여러 제품의 생성 요청을 포함한 모든 API 요청에서 5xx 오류가 늘었고, 사용자가 cloud.digitalocean.com 에 들어가지 못하기도 했다.

   오류율 상승지연 시간 증가

   촉발

   아이덴티티, 인증, 인가 서비스를 받치는 데이터베이스 계층을 계획에 따라 이전하는 인프라 작업을 하던 중이었다. 이 이전 작업 때문에 핵심 인가 쿼리 하나의 실행 지연이 늘었다.

   원인

   설정 변경

   구성 요소

   데이터베이스인증·인가 서비스

   기여 요인

   재시도 폭주수동 조치 악화

   감지

   16:58 UTC 에 자동 모니터링이 비정상적인 오류율과 지연을 잡아냈다. 보고서는 영향이 시작되고 5분 안에 감지했다고 적었다.

   조치

   • 인가 트래픽을 정상으로 동작하는 처리 경로 하나로 몰아 보냈다.
   • 주요 호출자의 hedging 을 잠시 껐다.
   • 두 번째 구간에서 나머지 영향받은 서비스 전체의 재시도와 요청 증폭 동작을 껐다.
   • 느린 인가 쿼리를 받을 읽기 용량을 더했다.

   후속 조치

   • 상위 서비스 전반에 자동 서킷 브레이커를 배포했다. 서킷 브레이커는 하위 의존 서비스가 나빠진 것을 감지하면 hedged retry 와 재시도 증폭을 자동으로 막는다.
   • 모든 컨트롤 플레인 서비스에 재시도 억제와 서킷 브레이커가 똑같이 적용되는지 아키텍처 전반을 점검하는 작업을 마쳤다.
   • 의존 서비스가 느려질 때 요청 큐가 포화되지 않도록 요청을 빠르게 실패시키는 로드 셰딩을 넣었다.
   • 고객이 영향을 받기 전에 큐가 쌓이기 시작한 것을 알아채는 텔레메트리 알림을 더했다.
   • 주 데이터베이스가 느려지면 핵심 인가 구성 요소가 기능을 줄인 모드로 동작하도록 설정했다. 이 모드에서는 비동기로 갱신되는 최종 일관성 복제본을 읽는다.

   사례 보기
3. IL-0283 Cloudflare 네트워크 전체에서 코어 프록시가 Bot Management 피처 파일을 읽다 실패해 사이트 방문자들이 HTTP 5xx 오류 페이지를 받았다

   Cloudflare2025

   증상

   11:20 UTC 부터 Cloudflare 네트워크가 내보내는 HTTP 5xx 오류가 치솟았다. 고객 사이트를 찾은 인터넷 사용자들은 Cloudflare 네트워크 안에서 실패했다는 오류 페이지를 봤다.

   오류율 상승서비스 중단지연 시간 증가응답 품질 저하

   촉발

   11:05 UTC 에 Cloudflare 는 ClickHouse 사용자들이 암묵적으로 갖고 있던 r0 데이터베이스 하위 테이블 접근 권한을 명시적으로 주는 변경을 배포했다. Bot Management 피처 파일을 만드는 쿼리는 데이터베이스 이름으로 거르지 않았고, 이 변경 뒤 쿼리 결과에 중복 행이 섞이기 시작했다.

   원인

   설정 변경

   구성 요소

   데이터베이스CDN 과 엣지 네트워크

   기여 요인

   미검증 가정부분 배포단계적 배포 부재설정 테스트 부재장애 중첩재시도 폭주

   감지

   11:31 UTC 에 첫 자동 테스트가 문제를 감지했고, 11:32 에 수동 조사가 시작됐으며, 11:35 에 장애 대응 통화가 열렸다.

   조치

   • 13:05 UTC 에 Workers KV 와 Cloudflare Access 를 내부 우회 경로로 돌려 이전 버전의 코어 프록시를 쓰게 했다. 이전 버전에도 같은 문제가 있었지만 영향이 작았다.
   • 14:24 UTC 에 새 Bot Management 설정 파일의 자동 배포를 멈췄다.
   • 알려진 정상 피처 파일을 피처 파일 배포 큐에 손으로 넣었다.
   • 코어 프록시를 강제로 재시작했다. 14:30 UTC 에 주된 영향이 풀렸다.
   • 쌓인 로그인 시도와 재시도로 느려진 대시보드를 컨트롤 플레인 동시성을 늘려 15:30 UTC 무렵 되살렸다.
   • 나쁜 상태에 빠진 나머지 서비스들을 재시작했고, 17:06 UTC 에 5xx 오류량이 평소로 돌아왔다.

   후속 조치

   • Cloudflare 가 직접 만든 설정 파일도 사용자 입력처럼 엄격하게 검증한 뒤 받아들인다.
   • 기능을 네트워크 전체에서 끌 수 있는 킬 스위치를 더 늘린다.
   • 코어 덤프나 다른 오류 보고가 시스템 자원을 다 써 버리지 못하게 한다.
   • 모든 코어 프록시 모듈이 오류가 났을 때 어떻게 실패하는지 검토한다.

   사례 보기
4. IL-0292 App Engine Memcache 가 글로벌 설정을 읽지 못해 모든 리전에서 1시간 50분 동안 멈췄다

   Google Cloud2017

   증상

   2017-11-06 12:33 US/Pacific 부터 App Engine Memcache 를 모든 리전의 애플리케이션에서 쓸 수 없었다. Google 은 12:34 에 자동 알림을 받았고, 상태 페이지는 Memcache 를 쓰는 모든 프로젝트가 영향을 받는다고 알렸다.

   서비스 중단데이터베이스 과부하지연 시간 증가오류율 상승

   촉발

   설정 업데이트 뒤 애플리케이션과 데이터센터의 매핑 설정을 담은 글로벌 데이터베이스의 엔티티를 읽을 수도 쓸 수도 없게 됐다.

   원인

   설정 변경

   구성 요소

   인메모리 캐시데이터베이스

   기여 요인

   롤백 무효과도한 영향 범위

   감지

   Google 은 장애가 시작된 1분 뒤인 12:34 US/Pacific 에 자동 알림을 받았다.

   조치

   • 14:21 에 데드라인을 충분히 길게 준 업데이트 요청으로 설정을 고쳤다. 데이터베이스의 모든 복제본이 동기화되고 클라이언트가 매핑 설정을 다시 읽을 수 있게 됐다.
   • Memcache 로 보내는 트래픽을 천천히 다시 늘렸고 오류율이 줄어들었다.

   후속 조치

   • 임시 완화로 글로벌 설정을 읽는 쪽의 수를 줄여 쓰기 때 경합이 생기지 않게 한다.
   • 이 설정을 리전 단위로 나눠 비슷한 실패가 번지는 범위를 줄인다.

   사례 보기

원인별1