{"id":"IL-0366","org":"Google Cloud","date":"2026-10-08","docs":[],"title":{"en":"Cloud Storage uploads and writes in us-central1 slowed and failed with HTTP 503 as traffic piled onto a few backends","ko":"us-central1 의 Cloud Storage 업로드와 쓰기가 이틀에 걸쳐 18시간 넘게 느려지고 실패했다"},"domain":["gcp","database"],"impact":{"scope":"Cloud Storage upload and write operations (WriteObject) in us-central1, with a minor impact on reads during the first occurrence","users":"unknown","region":"us-central1 (recurrence in us-central1-b)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.cloud.google.com/incidents/mSFVt6PiP557bjRyYsut","kind":"official-status","archived":"https://web.archive.org/web/20261107110624/https://status.cloud.google.com/incidents/mSFVt6PiP557bjRyYsut"}],"summary":{"en":"Google Cloud Storage spreads incoming data over a large, distributed set of storage backend nodes. During the incident window, some backend nodes in us-central1 were short of capacity because traffic had grown. A configuration update to the Cloud Storage load balancing layer added a traffic sorting optimization meant to address local capacity constraints, but it unintentionally bypassed the normal capacity-aware routing logic. A small fraction of backend nodes with little free serving capacity then received a very large share of incoming write traffic and ran out of resources, and the backend services that ingest object data began to time out. Uploads and writes routed to those nodes became slow and failed. At the same time, a separate problem in the underlying metadata database service caused additional metadata processing errors for part of the incident.\n\nEngineers detected the problem at 04:50 from system telemetry. Adding emergency capacity was blocked by regional capacity limits, so engineers drained traffic from the most overloaded backend nodes, deployed a configuration change that disabled the traffic sorting optimization, and rolled back a recent update to the metadata database service. The first occurrence ended at 16:30 on 8 October, after 12 hours, 30 minutes. On 9 October an incomplete rollback of an upload planner feature broke the load balancing again and overloaded a few smaller backend nodes in us-central1-b from 04:05 to 09:46. That recurrence needed more traffic redirection and draining, and it ended when engineers fully reverted the load balancing configuration change, which brought back capacity-aware routing and an even spread of traffic across the region. The drained nodes were returned to service once traffic and resource use were back to their normal baseline. The total duration was 18 hours, 11 minutes.","ko":"10월 8일 장애 동안 us-central1 리전의 일부 스토리지 백엔드 노드는 트래픽이 늘어 국지적인 용량 부족을 겪었다. 이 용량 부족을 풀려고 Cloud Storage 부하 분산 계층에 트래픽 정렬 최적화 설정 업데이트를 배포했다. 그런데 이 설정이 용량을 보고 경로를 정하는 표준 로직을 의도치 않게 건너뛰었다. 그 결과 들어오는 쓰기 트래픽의 대부분이 남은 처리 용량이 적은 소수의 백엔드 노드로 몰렸다. 이 노드들의 자원이 바닥나자 객체 데이터를 받아들이는 백엔드 서비스가 타임아웃을 내기 시작했다. 이 노드로 간 업로드와 쓰기 요청은 느려지거나 끝나지 못했고, 고객에게는 오류로 보였다. 같은 시기에는 그 아래 데이터베이스 서비스에 별도 문제가 있어, 장애 시간 일부 동안 메타데이터 처리 오류도 났다.\n\n엔지니어들은 리전에 비상 용량을 더하려 했지만 리전 용량 한도에 막혔다. 그래서 부하가 가장 큰 노드에서 트래픽을 빼고, 트래픽 정렬 최적화를 끄는 설정 변경을 배포했으며, 메타데이터 데이터베이스 서비스의 최근 업데이트를 롤백했다. 첫 발생은 16:30에 끝났다.\n\n10월 9일 04:05에는 us-central1-b 존에서 문제가 다시 일어났다. 업로드 플래너 기능의 롤백이 완전하지 않아 부하 분산 메커니즘이 망가졌고, 작은 스토리지 백엔드 노드 몇 개에 과부하가 걸렸다. 엔지니어들은 트래픽을 더 돌리고 영향받은 스토리지 구성 요소에서 트래픽을 뺐다. 이어 문제의 부하 분산 설정 변경을 완전히 되돌려, 용량을 보고 경로를 정하던 이전 동작을 되살렸다. 트래픽이 리전에 고르게 퍼지고 자원 사용률이 평소로 돌아오자 트래픽을 뺐던 노드를 다시 서비스에 넣었고, 재발은 09:46에 끝났다. 두 번을 합친 장애 시간은 18시간 11분이었다."},"trigger":{"en":"A configuration update to the Cloud Storage load balancing layer turned on a traffic sorting optimization that was meant to deal with local capacity constraints. The recurrence on 9 October came from an incomplete rollback of an upload planner feature.","ko":"Cloud Storage 부하 분산 계층에 트래픽 정렬 최적화 설정 업데이트가 배포됐다. 이 설정은 용량을 보고 경로를 정하는 표준 로직을 의도치 않게 건너뛰었다."},"severity":"unknown","symptoms":["high-latency","high-error-rate","uneven-load"],"timeline":{"detected_after":"50m","resolved_after":"29h 46m"},"date_kind":"incident","detection":{"en":"Google engineering teams monitoring system telemetry detected the problem at 04:50 US/Pacific on 8 October, 50 minutes after it began.","ko":"Google 엔지니어링 팀이 시스템 텔레메트리를 지켜보다가 10월 8일 04:50에 문제를 처음 알아챘다. 장애가 시작되고 50분 뒤였다."},"components":["object-storage","database"],"root_cause":"config-change","remediation":[{"text":{"en":"Drained traffic from the most overloaded storage backend nodes","ko":"부하가 가장 큰 스토리지 백엔드 노드를 골라 트래픽을 뺐다."}},{"text":{"en":"Deployed a configuration change that disabled the traffic sorting optimization","ko":"트래픽 정렬 최적화를 끄는 설정 변경을 배포해 스토리지 백엔드의 자원 부담을 크게 줄였다."}},{"text":{"en":"Rolled back a recent update to the metadata database service","ko":"같은 시기에 난 메타데이터 문제를 막으려고 메타데이터 데이터베이스 서비스의 최근 업데이트를 롤백했다."}},{"text":{"en":"Redirected traffic and drained affected storage components again during the recurrence","ko":"부하 불균형이 다시 일어나자 트래픽을 더 돌리고 영향받은 스토리지 구성 요소에서 트래픽을 뺐다."}},{"text":{"en":"Fully reverted the load balancing configuration change, restoring capacity-aware routing","ko":"문제의 부하 분산 설정 변경을 완전히 되돌려 용량을 보고 경로를 정하던 이전 동작을 되살렸고, 트래픽이 리전 전체에 고르게 퍼졌다."}},{"text":{"en":"Returned the drained nodes to service once resource use was back to normal","ko":"트래픽과 자원 사용률이 평소 수준으로 돌아온 뒤 트래픽을 뺐던 노드를 다시 서비스에 넣었다."}}],"action_items":[{"text":{"en":"Validate load balancing logic changes in smaller regions before rolling them out to large, highly utilized regions","ko":"부하 분산 로직 변경은 사용률이 높은 큰 리전에 내보내기 전에 더 작은 다른 리전에서 먼저 엄격하게 검증하도록 배포 절차를 바꾼다."}},{"text":{"en":"Make the storage load balancing enforce capacity constraints so traffic cannot bypass pre-spilling safeguards","ko":"스토리지 부하 분산 구조가 용량 제약을 반드시 지키게 한다. 트래픽 분배 로직이 Google 이 pre-spilling 이라고 부르는 안전장치를 건너뛰어 처리 자원이 모자란 클러스터로 트래픽을 보내는 일이 없게 한다."}},{"text":{"en":"Speed up internal data movement within highly utilized storage cells to absorb temporary load spikes","ko":"사용률이 높은 스토리지 셀 안의 내부 데이터 이동을 빠르게 해, 일시적인 부하 급증을 더 잘 견디게 한다."}}],"contributing":["no-spare-capacity","overlapping-failures"],"recurrence_of":null,"symptoms_text":{"en":"From 04:00 US/Pacific on 8 October 2026, Google Cloud Storage upload and write operations in the us-central1 region became slow and failed. Clients mostly saw HTTP 503 UNAVAILABLE errors on WriteObject operations and client-side timeouts.\n\nWrite operations that did succeed took much longer than normal. During the first occurrence a smaller share of read operations also saw higher latency and errors. Cloud Storage in every other region and all other Google Cloud services were not affected.\n\nThe status page updates posted on 8 October gave 05:19 PDT as the start of the problem, and the final report gives 04:00. Error rates in Google's internal monitoring began to improve at 10:57 PDT after the first mitigations, and the first occurrence ended at 16:30. The problem came back on 9 October from 04:05 to 09:46, this time in the us-central1-b zone.\n\nGoogle engineers first tried to add emergency capacity to the region, but systemic regional capacity limits blocked it. Draining the most overloaded backend nodes and disabling a traffic sorting optimization gave relief, but only for a while: the load imbalance returned the next day.","ko":"us-central1 리전에서 Cloud Storage 업로드와 쓰기 요청의 지연과 오류율이 올라갔다. 고객은 주로 WriteObject 작업에서 HTTP 503 UNAVAILABLE 오류와 클라이언트 쪽 타임아웃을 봤다.\n\n성공한 쓰기도 평소보다 지연이 크게 늘었다. 첫 발생 동안에는 읽기 요청 일부에서도 지연과 오류가 늘었다.\n\n첫 발생은 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 서비스는 영향을 받지 않았다.\n\n엔지니어들은 먼저 영향받은 리전에 비상 용량을 추가로 배정하려 했지만, 리전 전체의 용량 한도에 막혀 할 수 없었다."},"updated_at":"2026-11-14T12:34:01.863232Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0366","org_slug":"google-cloud"}