{"id":"IL-0530","org":"Google Cloud","date":"2023-10-05","docs":[],"title":{"en":"Virtual router controllers in us-central1 ran out of memory in a loop, cutting networking for new and migrated VMs","ko":"us-central1 의 가상 네트워크 라우터 컨트롤러가 메모리 부족으로 재시작을 되풀이해 새 VM 과 마이그레이션된 VM 의 네트워크가 오래 끊겼다"},"domain":["gcp","networking","kubernetes"],"impact":{"scope":"Networking for newly created and live migrated VMs, cross-region traffic to and from us-central1, intra-region traffic from 07:00 to 08:15, and load balancer health propagation; products that create VMs, including GKE, Cloud SQL, Filestore, Dataproc, Dataflow, Data Fusion, Datastream and Batch","users":"unknown","region":"us-central1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.cloud.google.com/incidents/U39RSGjaANJXtjHpRkdq","kind":"official-status","archived":"https://web.archive.org/web/20261103072354/https://status.cloud.google.com/incidents/U39RSGjaANJXtjHpRkdq"}],"summary":{"en":"Google Cloud had been slowly rolling out a management plane change that decoupled the processing of API updates to Instance Groups and Network Endpoint Groups used as load balancer backends. The change ran in several regions without problems, but in us-central1 the large workload sizes made the memory use of the control plane for the virtual network routers grow unexpectedly. The controllers ran out of memory, were restarted automatically and ran out of memory again, over and over. Virtual routers and their controllers sit in separate zonal failure domains, but the change acted through a regional API, so every virtual router controller in the region came under memory pressure at the same time. Without working controllers, the routers were not updated with new VMs, new locations of migrated VMs, dynamic routes or load balancer backend health. Intra-region and cross-region traffic use separate sets of virtual routers with their own control plane, and the cross-region routers were affected first and longer.\n\nEngineers were alerted to intermittent control plane slowness at 21:45 US/Pacific on 4 October and to out-of-memory failures of the controllers at 02:11 on 5 October, and started giving the controllers more memory. Cross-region packet loss began at 03:08. The larger memory allocation started to reach production at 05:27, and intra-region packet loss that started at 07:00 subsided at 08:15 as it rolled out. At 08:22 engineers linked the memory growth to the management plane change, started a rollback at 08:52 and completed it in us-central1 at 09:35, after which no more out-of-memory events happened. A small number of routers still did not accept updates and were restarted by hand without further packet loss. All packet loss had stopped by 10:55, 7 hours and 47 minutes after it started. The Filestore update backlog finished about a day later, on 6 October.","ko":"근본 원인은 Google Cloud 전체에 천천히 배포되던 관리 플레인의 동작 변경이었다. 이 변경은 로드 밸런서 백엔드로 쓰는 GCP Instance Group 과 Network Endpoint Group 의 API 업데이트 처리를 더 잘 분리해 안정성과 성능을 높이려는 것이었다. 여러 리전에서는 문제없이 배포됐지만, us-central1 에 배포되자 이 리전의 큰 워크로드 규모 때문에 가상 네트워크 라우터 컨트롤 플레인의 메모리가 예상 밖으로 늘었다. 컨트롤러는 메모리를 다 써서 자동으로 재시작됐지만, 워크로드가 커서 메모리 부족과 재시작을 되풀이했다. 가상 라우터와 컨트롤러는 존마다 장애 도메인을 나눠 배포돼 있었으나, 이 변경이 리전 단위 API 에 영향을 주었기 때문에 리전의 모든 가상 라우터가 동시에 메모리 압박을 받았다.\n\n컨트롤러를 쓸 수 없게 되자 가상 네트워크 라우터는 새 VM, 마이그레이션된 VM 의 새 위치, 동적 경로, 로드 밸런서 백엔드의 상태 같은 새 정보를 받지 못했다. 리전 안 트래픽과 리전 간 트래픽은 각자 컨트롤 플레인을 가진 별도의 라우터가 처리했다. 그중 리전 간 라우터가 먼저, 더 오래 영향을 받았다. 미국 태평양 시간 03:08 부터 us-central1 을 오가는 리전 간 패킷 손실이 시작됐고, 07:00 부터 08:15 까지는 리전 안 트래픽도 손실을 겪었다. 새 VM 을 만드는 GKE, Cloud SQL, Filestore, Dataproc, Dataflow 같은 제품이 함께 실패했다.\n\n엔지니어들은 10월 4일 21:45 에 컨트롤 플레인이 느리다는 알림을 받고 조사했지만 느려짐은 간헐적이었다. 10월 5일 02:11 에 컨트롤러의 메모리 부족 알림이 오자 메모리를 더 할당하기 시작했고, 이 변경은 05:27 부터 운영 환경에 닿았다. 08:15 에 리전 안 패킷 손실이 가라앉은 것은 이 메모리 증설 덕분이었다. 엔지니어들은 08:22 에 메모리 증가를 관리 플레인 변경의 배포와 연결 지었다. 08:52 에 시작한 롤백이 09:35 에 us-central1 에서 끝나면서 메모리 부족은 모두 멈췄다. 업데이트를 받지 않던 라우터 몇 대는 손으로 재시작했다. 10:55 에 패킷 손실이 모두 멈췄고 컨트롤 플레인이 업데이트를 정상으로 처리했다. 장애는 7시간 47분 이어졌다."},"trigger":{"en":"A management plane behaviour change, meant to decouple the processing of API updates to Instance Groups and Network Endpoint Groups used as load balancer backends, was deployed in us-central1 after rolling out to several other regions without incident.","ko":"관리 플레인의 동작 변경이 us-central1 에 배포됐다. 이 변경은 로드 밸런서 백엔드로 쓰는 GCP Instance Group 과 Network Endpoint Group 의 API 업데이트 처리를 더 잘 분리하려는 것이었다. 이 리전의 큰 워크로드 규모 때문에 가상 네트워크 라우터 컨트롤 플레인의 메모리가 예상 밖으로 늘었다."},"severity":"unknown","symptoms":["packet-loss","network-unreachable","oom-killed","stale-service-routing","cluster-creation-stuck"],"timeline":{"detected_after":null,"resolved_after":"7h 47m"},"date_kind":"incident","detection":{"en":"Engineers were alerted to slowness in the virtual network control plane in us-central1 at 21:45 US/Pacific on 4 October, before the packet loss started, and to controller failures from memory exhaustion at 02:11 on 5 October. Networking telemetry showed cross-region packet loss from 03:08.","ko":"엔지니어들은 10월 4일 미국 태평양 시간 21:45 에 us-central1 가상 네트워크 컨트롤 플레인이 느리다는 알림을 받았고, 10월 5일 02:11 에 가상 네트워크 라우터 컨트롤러가 메모리를 다 써서 실패한다는 알림을 받았다. 03:08 부터는 네트워크 텔레메트리가 us-central1 을 오가는 리전 간 패킷 손실을 보여 주었다."},"components":["network-control-plane","cloud-load-balancer"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Increased the memory allocated to the virtual network router controllers","ko":"컨트롤러에 메모리를 더 할당하는 변경을 배포했고, 이 변경은 미국 태평양 시간 05:27 부터 운영 환경에 닿았다. 08:15 에 리전 안 패킷 손실이 가라앉았다."}},{"text":{"en":"Rolled back the management plane change in us-central1","ko":"08:52 에 관리 플레인 변경의 롤백을 시작해 09:35 에 us-central1 에서 마쳤고, 이때 메모리 부족이 모두 멈췄다."}},{"text":{"en":"Restarted by hand the routers that were still not accepting updates","ko":"업데이트를 받지 않던 라우터 몇 대를 손으로 재시작했다. 이 재시작으로 패킷 손실이 더 생기지는 않았다."}}],"action_items":[{"text":{"en":"Alert proactively on memory risks and unexpected memory increases","ko":"메모리 위험과 예상 밖의 메모리 증가를 미리 알리는 알림을 만든다."}},{"text":{"en":"Refactor the deployment configuration so engineers can reallocate memory much faster","ko":"엔지니어가 메모리를 훨씬 빨리 다시 할당할 수 있도록 배포 설정을 다시 짠다."}},{"text":{"en":"Re-evaluate existing practices and add safety mechanisms for API reconciliation","ko":"API 조정 작업의 기존 관행과 안전장치를 다시 평가하고 새 관행과 안전장치를 만든다."}},{"text":{"en":"Make management plane changes more visible across teams so the changes can be correlated faster","ko":"관리 플레인 변경을 여러 팀이 더 잘 볼 수 있게 해 장애와 더 빨리 연결 짓게 한다."}},{"text":{"en":"Adjust the deployment footprint so a regional API change is less likely to exhaust memory across the region at once","ko":"리전 단위 API 변경 때문에 리전 전체의 메모리가 한꺼번에 바닥나는 일이 줄도록 배포 구성을 바꾼다."}},{"text":{"en":"Optimise memory use in the traffic routers and their controllers","ko":"트래픽 라우터와 컨트롤러의 메모리를 최적화해 불필요한 부담을 없앤다."}}],"contributing":["blast-radius-too-wide","no-alert-on-limit"],"recurrence_of":null,"symptoms_text":{"en":"On 5 October 2023 in us-central1, newly created VMs waited a long time before their networking worked, and VMs that had been live migrated lost connectivity for a long time after the migration. Networking telemetry showed cross-region packet loss to and from us-central1 from 03:08 US/Pacific. Health check state of VMs reached load balancers late.\n\nThe first signals came hours earlier. On 4 October at 21:45 US/Pacific engineers were alerted to slowness in the virtual network control plane in us-central1, which looked intermittent. At 02:11 on 5 October alerts reported failures in the controllers of the virtual network routers because the controllers ran out of memory. The controllers were restarted automatically but ran out of memory again, and as the out-of-memory events came more often, updates to router state, such as new VMs, new locations of migrated VMs, dynamic routes and health of load balancer backends, fell further behind until practically nothing progressed.\n\nFrom 03:08 to 10:55 the impact was largely limited to cross-region traffic, and the cross-region routers were hit first and for longer than the intra-region routers. From 07:00 to 08:15 intra-region traffic also lost packets, mainly to and from us-central1-c. Existing VMs that did not migrate or change health were not hit directly, but their traffic could pass through an affected VPN Gateway, internal load balancer or other VM.\n\nProducts that create VMs failed with it. 24 percent of GKE cluster creation attempts failed or were delayed, most of them succeeding after up to 120 minutes, and up to 0.4 percent of GKE clusters had downtime or delays during recreate and upgrade operations; in the Google Cloud Console Clusters page some Nodes showed as not registered and the cluster as unhealthy. New Cloud SQL VM creations failed, and Cloud SQL databases became unavailable when a change created a new VM for an existing instance. Filestore upgrades failed and were rolled back, Dataproc cluster creations failed for up to 5 percent, Dataflow jobs could not scale and container downloads from Artifact Registry failed, and Datastream streams showed spikes in the \"Data freshness\" and \"Total latency\" metrics.","ko":"us-central1 에서 새로 만든 VM 은 네트워크가 동작하기까지 오래 기다려야 했고, 라이브 마이그레이션된 VM 은 마이그레이션 뒤 오래 연결을 잃었다. us-central1 을 오가는 리전 간 트래픽에서 패킷 손실이 났다. 기존 VM 중 마이그레이션되지 않고 상태도 바뀌지 않은 VM 은 직접 영향을 받지 않았다.\n\n상태 페이지의 첫 제목은 \"Connectivity issue impacting newly created VM’s in us-central1\" 이었고, 새 VM 의 네트워킹 스택이 완전히 동작하기까지 몇 분 늦어질 수 있다고 안내했다. 상태 페이지는 우회 방법으로 영향을 받지 않은 존에 VM 을 배포하라고 했다가, 나중에는 영향을 받지 않은 리전을 쓰라고 바꿨다. 제목은 그 뒤 \"Multiple cloud products are experiencing networking issues in us-central1\" 로 바뀌었다.\n\nVM 의 헬스 체크 상태가 로드 밸런서에 제때 전달되지 않았다. 기존 VM 이 직접 영향을 받지 않았더라도 그 트래픽이 VPN 게이트웨이, 내부 로드 밸런서, 다른 VM 처럼 영향을 받은 장치를 거치면 함께 영향을 받았을 수 있다.\n\n영향은 시간에 따라 바뀌었다. 미국 태평양 시간 03:08 부터 10:55 까지는 주로 리전 간 가상 네트워크 트래픽이 영향을 받았다. 07:00 부터 08:15 까지는 주로 us-central1-c 를 오가는 리전 안 트래픽에서도 큰 패킷 손실이 났다. 메모리 부족이 잦아질수록 라우터 상태 갱신이 늦어졌고, 끝내는 갱신이 사실상 진행되지 않았다.\n\nVM 을 만드는 제품이 함께 실패했다. GKE 는 us-central1 클러스터의 최대 0.4% 가 재생성이나 업그레이드 중에 다운타임이나 지연을 겪었다. 클러스터 생성 시도의 24% 가 실패하거나 늦어졌다. 대부분은 최대 120분 뒤 저절로 성공했다. 다운타임 동안 Google Cloud Console 의 Clusters 페이지에는 일부 노드가 등록되지 않았고 클러스터가 비정상이라고 나왔다. Cloud SQL 은 새 VM 생성이 실패했다. 기존 인스턴스에 업데이트, 셀프 서비스 유지보수, 클론, 장애 조치처럼 새 VM 을 만드는 변경을 하면 데이터베이스를 쓸 수 없었다.\n\n다른 데이터 제품도 영향을 받았다. Filestore 는 업그레이드 중에 만든 새 VM 끼리 통신하지 못해 업그레이드가 실패하고 이전 버전으로 롤백됐다. 밀린 업데이트는 약 하루 뒤인 10월 6일에 끝났다. Dataproc 은 us-central1 의 새 클러스터 생성 중 최대 5% 가 실패했다. Dataflow 는 수평 확장에 실패하고 Artifact Registry 에서 컨테이너를 내려받지 못했다. Data Fusion 은 us-central1 요청의 약 27% 가 문제를 겪었다. Datastream 은 08:00 부터 10:10 까지 스트림의 파드가 자주 재시작돼 데이터 수집이 늦어졌고, 영향을 받은 스트림의 \"Data freshness\" 와 \"Total latency\" 지표가 치솟았다.\n\n엔지니어들은 장애 전날인 10월 4일 21:45 에 us-central1 가상 네트워크 컨트롤 플레인이 느리다는 알림을 받았지만, 처음 조사에서는 느려짐이 간헐적이었다. 10월 5일 02:11 에 가상 네트워크 라우터 컨트롤러가 메모리를 다 써서 실패한다는 알림이 왔고, 엔지니어들은 먼저 메모리를 더 할당하는 방법으로 완화하려 했다. 메모리 증가가 관리 플레인 변경의 배포와 연결된 것은 08:22 에야 밝혀졌다."},"updated_at":"2026-11-14T12:34:17.336839Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0530","org_slug":"google-cloud"}