IL-0366 Google Cloud · 2026-10-08gcpdatabase
us-central1 의 Cloud Storage 업로드와 쓰기가 이틀에 걸쳐 18시간 넘게 느려지고 실패했다
10월 8일 장애 동안 us-central1 리전의 일부 스토리지 백엔드 노드는 트래픽이 늘어 국지적인 용량 부족을 겪었다. 이 용량 부족을 풀려고 Cloud Storage 부하 분산 계층에 트래픽 정렬 최적화 설정 업데이트를 배포했다. 그런데 이 설정이 용량을 보고 경로를 정하는 표준 로직을 의도치 않게 건너뛰었다. 그 결과 들어오는 쓰기 트래픽의 대부분이 남은 처리 용량이 적은 소수의 백엔드 노드로 몰렸다. 이 노드들의 자원이 바닥나자 객체 데이터를 받아들이는 백엔드 서비스가 타임아웃을 내기 시작했다. 이 노드로 간 업로드와 쓰기 요청은 느려지거나 끝나지 못했고, 고객에게는 오류로 보였다. 같은 시기에는 그 아래 데이터베이스 서비스에 별도 문제가 있어, 장애 시간 일부 동안 메타데이터 처리 오류도 났다.
엔지니어들은 리전에 비상 용량을 더하려 했지만 리전 용량 한도에 막혔다. 그래서 부하가 가장 큰 노드에서 트래픽을 빼고, 트래픽 정렬 최적화를 끄는 설정 변경을 배포했으며, 메타데이터 데이터베이스 서비스의 최근 업데이트를 롤백했다. 첫 발생은 16:30에 끝났다.
10월 9일 04:05에는 us-central1-b 존에서 문제가 다시 일어났다. 업로드 플래너 기능의 롤백이 완전하지 않아 부하 분산 메커니즘이 망가졌고, 작은 스토리지 백엔드 노드 몇 개에 과부하가 걸렸다. 엔지니어들은 트래픽을 더 돌리고 영향받은 스토리지 구성 요소에서 트래픽을 뺐다. 이어 문제의 부하 분산 설정 변경을 완전히 되돌려, 용량을 보고 경로를 정하던 이전 동작을 되살렸다. 트래픽이 리전에 고르게 퍼지고 자원 사용률이 평소로 돌아오자 트래픽을 뺐던 노드를 다시 서비스에 넣었고, 재발은 09:46에 끝났다. 두 번을 합친 장애 시간은 18시간 11분이었다.
- 심각도
- –
- 영향 범위
- Cloud Storage upload and write operations (WriteObject) in us-central1, with a minor impact on reads during the first occurrence
- 영향 사용자
- –
- 지역
- us-central1 (recurrence in us-central1-b)
- 감지까지
- 50m
- 복구까지
- 29h 46m
증상
us-central1 리전에서 Cloud Storage 업로드와 쓰기 요청의 지연과 오류율이 올라갔다. 고객은 주로 WriteObject 작업에서 HTTP 503 UNAVAILABLE 오류와 클라이언트 쪽 타임아웃을 봤다.
성공한 쓰기도 평소보다 지연이 크게 늘었다. 첫 발생 동안에는 읽기 요청 일부에서도 지연과 오류가 늘었다.
첫 발생은 10월 8일 04:00부터 16:30 US/Pacific 까지 us-central1 리전에서 12시간 30분 이어졌다. 내부 모니터링에서는 10:57 PDT 부터 오류율이 나아지기 시작했다. 다음 날인 10월 9일 04:05에 us-central1-b 존에서 같은 문제가 다시 일어나 09:46까지 5시간 41분 이어졌다. 다른 리전의 Cloud Storage 와 다른 Google Cloud 서비스는 영향을 받지 않았다.
엔지니어들은 먼저 영향받은 리전에 비상 용량을 추가로 배정하려 했지만, 리전 전체의 용량 한도에 막혀 할 수 없었다.
원인
- 촉발
- Cloud Storage 부하 분산 계층에 트래픽 정렬 최적화 설정 업데이트가 배포됐다. 이 설정은 용량을 보고 경로를 정하는 표준 로직을 의도치 않게 건너뛰었다.
감지
Google 엔지니어링 팀이 시스템 텔레메트리를 지켜보다가 10월 8일 04:50에 문제를 처음 알아챘다. 장애가 시작되고 50분 뒤였다.
조치
- 부하가 가장 큰 스토리지 백엔드 노드를 골라 트래픽을 뺐다.
- 트래픽 정렬 최적화를 끄는 설정 변경을 배포해 스토리지 백엔드의 자원 부담을 크게 줄였다.
- 같은 시기에 난 메타데이터 문제를 막으려고 메타데이터 데이터베이스 서비스의 최근 업데이트를 롤백했다.
- 부하 불균형이 다시 일어나자 트래픽을 더 돌리고 영향받은 스토리지 구성 요소에서 트래픽을 뺐다.
- 문제의 부하 분산 설정 변경을 완전히 되돌려 용량을 보고 경로를 정하던 이전 동작을 되살렸고, 트래픽이 리전 전체에 고르게 퍼졌다.
- 트래픽과 자원 사용률이 평소 수준으로 돌아온 뒤 트래픽을 뺐던 노드를 다시 서비스에 넣었다.
후속 조치
- 부하 분산 로직 변경은 사용률이 높은 큰 리전에 내보내기 전에 더 작은 다른 리전에서 먼저 엄격하게 검증하도록 배포 절차를 바꾼다.
- 스토리지 부하 분산 구조가 용량 제약을 반드시 지키게 한다. 트래픽 분배 로직이 Google 이 pre-spilling 이라고 부르는 안전장치를 건너뛰어 처리 자원이 모자란 클러스터로 트래픽을 보내는 일이 없게 한다.
- 사용률이 높은 스토리지 셀 안의 내부 데이터 이동을 빠르게 해, 일시적인 부하 급증을 더 잘 견디게 한다.
교훈
–
출처
- https://status.cloud.google.com/incidents/mSFVt6PiP557bjRyYsut · official-status · 보관본
관련 사례
IL-0574운영 환경의 DB 접속 경로를 Amazon RDS Proxy로 바꾼 지 몇 분 만에 Aurora MySQL writer CPU가 100%에 이르고 에러가 났다Safie · 2026같은 원인 · 공통 데이터베이스
IL-0179DEBUG 로그가 쏟아지자 동기 로깅을 하던 요청 스레드들이 가득 찬 stdout 파이프에서 멈춘 채 DB 커넥션을 쥐고 있어, HikariCP 커넥션 풀이 고갈되고 요청이 30초 주기로 한꺼번에 실패했다.MUSINSA · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0283Cloudflare 네트워크 전체에서 코어 프록시가 Bot Management 피처 파일을 읽다 실패해 사이트 방문자들이 HTTP 5xx 오류 페이지를 받았다Cloudflare · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0392데이터센터 전환을 앞두고 원형 복제를 설정하던 중 Wikimedia x1 섹션의 eqiad·codfw 사이 MariaDB 복제가 6분 멈췄다Wikimedia Foundation · 2024같은 원인 · 공통 데이터베이스
IL-0367Central US 의 Azure Storage 가 VM 디스크 요청을 거부해 VM 과 그 위의 SQL Database, Cosmos DB 가 멈췄다Microsoft Azure · 2024같은 원인 · 공통 데이터베이스
IL-0511Vault 가 새로 발급한 데이터베이스 자격 증명이 SCRAM 으로 만들어져 pgbouncer 가 RDS 에 로그인하지 못하고 xPro 운영 사이트가 멈췄다MIT Open Learning · 2023같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0366
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0366/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.