{"id":"IL-0529","org":"Google Cloud","date":"2024-05-16","docs":[],"title":{"en":"New Google Cloud VMs and other instances came up without network connectivity in all zones after VPC controllers stopped","ko":"모든 Google Cloud 존에서 VPC 컨트롤러가 꺼져 새로 만든 VM 과 여러 제품의 새 인스턴스가 네트워크 없이 올라왔다"},"domain":["gcp","networking"],"impact":{"scope":"Network programming for new, migrated and restarted VMs and for network configuration changes in all Google Cloud zones, and every product that creates VMs or changes network configuration, including GKE, Cloud Run, App Engine Flex, Cloud Functions, Cloud SQL, AlloyDB, Memorystore, Dataflow, Dataproc, Cloud Composer, Cloud Build, Filestore, Cloud NAT, Cloud Interconnect, Cloud VPN, Cloud Router and Cloud Load Balancing","users":"unknown","region":"Global (all Google Cloud zones)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.cloud.google.com/incidents/xVSEV3kVaJBmS7SZbnre","kind":"official-status","archived":"https://web.archive.org/web/20261103074921/https://status.cloud.google.com/incidents/xVSEV3kVaJBmS7SZbnre"}],"summary":{"en":"A separate instance of the VPC Controller runs in every Google Cloud zone and programs the hosts of that zone, such as GCE VM hosts, so that endpoints on them can reach other endpoints in their VPC networks, on-premises destinations through VPN or Interconnect, and the Internet. Within a zone the VPC control plane is split into components that each program a subset of traffic paths, so that a control plane outage stays inside one cluster. On 16 May 2024 maintenance automation was asked to shut down an unused VPC Controller in one zone. Earlier in the year a refactor of the automation software had modified the parameter that specifies the zone, so the target zone was ignored and the shutdown took effect on VPC controllers in all zones. The test environment had caught this failure mode, but the error was misread as an expected failure there, so the change reached production. The automation also had a safeguard that limits the scope of maintenance operations, and that safeguard had been disabled by mistake during a migration to a new version of the automation framework.\n\nThe VPC network follows a fail static design, so the data plane kept using the last programmed state and running VMs mostly kept working. Operations that need the control plane broke in all zones: creating new VMs, autoscaling, applying configuration changes to customer projects and reflecting changes in VM health. Because so many products create VMs or change network configuration, the outage spread to GKE, Cloud Run, App Engine Flex, Cloud Functions, Cloud SQL, AlloyDB, Memorystore, Dataflow, Dataproc, Cloud Composer, Cloud Build, Filestore, Cloud NAT, Cloud Interconnect, Cloud VPN, Cloud Router, Cloud Load Balancing and others. The data plane also lost packets during VM live migration and from congestion in some zones.\n\nInternal monitoring alerted engineers at 15:41 US/Pacific. Maintenance operations were paused at once, and in parallel the affected VPC Controllers were brought back into service. Controllers in most zones were working by 17:30, all of them by 18:09, and the backlog of changes to the data plane cleared by 18:40. The main impact lasted 2 hours and 48 minutes. Some products took longer: all remaining Cloud SQL instances were restored by 22:30, some Memorystore for Redis instances recovered at 20:05, some Apigee partial proxy deployments needed manual work until 01:00 on 17 May, several Cloud Composer environments that had started an image upgrade during the disruption were broken beyond recovery, and some NAT configurations took up to two more hours for control plane changes to take effect.","ko":"Google Cloud 는 존마다 VPC 컨트롤러를 따로 띄운다. 각 존의 VPC 컨트롤러는 그 존의 호스트를 프로그래밍해서, 그 위의 엔드포인트가 같은 VPC 네트워크의 다른 엔드포인트, VPN 이나 Interconnect 너머의 온프레미스, 인터넷에 닿게 한다. VPC 네트워크는 컨트롤 플레인이 없어도 데이터 플레인이 마지막으로 받은 상태를 계속 쓰는 구조여서, 영향은 주로 컨트롤 플레인을 거치는 네트워크 작업에 몰렸다.\n\n2024-05-16 Google 인프라 팀은 한 존에서 쓰지 않는 VPC 컨트롤러 하나를 끄는 정기 유지보수를 실행했다. 그해 초 자동화 소프트웨어를 리팩터링할 때 유지보수 대상 존을 지정하는 매개변수가 바뀌었고, 그 때문에 대상 존 매개변수가 무시됐다. 테스트 환경은 이 실패를 잡았지만, 그 오류는 테스트 환경에서 예상되는 실패로 잘못 해석돼 변경이 운영 환경까지 갔다. 유지보수 범위를 제한하는 안전장치도 있었으나 자동화 프레임워크를 새 버전으로 옮기는 과정에서 모르는 사이에 꺼져 있었다. 결국 종료 작업이 모든 존의 VPC 컨트롤러에 적용됐다. 미국 태평양 시간 15:22 부터 새 VM 생성, 오토스케일, 고객 프로젝트의 설정 변경, VM 상태 변화 반영 같은 컨트롤 플레인 작업이 실패했다. 데이터 플레인에서는 VM 라이브 마이그레이션 중에 패킷이 사라졌고 일부 존에서 네트워크가 혼잡해졌다. VM 을 만들거나 네트워크 설정을 바꾸는 GKE, Cloud Run, Cloud SQL, Cloud NAT 를 비롯한 여러 제품이 함께 실패했다.\n\n엔지니어들은 15:41 에 내부 모니터링 알림을 받았다. 재발을 막으려고 유지보수 작업을 곧바로 멈췄고, 동시에 영향을 받은 VPC 컨트롤러를 다시 서비스 상태로 되돌렸다. 대부분 존은 17:30 에, 모든 VPC 컨트롤러는 18:09 에 복구됐다. 데이터 플레인에 반영할 변경의 백로그는 18:40 에 해소됐다. 영향의 대부분은 2시간 48분 이어졌고, Cloud SQL, Memorystore for Redis, Apigee 같은 일부 제품은 그 뒤로도 몇 시간 더 걸려 회복했다."},"trigger":{"en":"Google's infrastructure team ran a routine maintenance action meant to shut down one unused VPC Controller in a single Google Cloud zone, and the automation shut down VPC controllers in all zones where the controllers were still in use.","ko":"한 Google Cloud 존에서 쓰지 않는 VPC 컨트롤러 하나를 끄려던 정기 유지보수 자동화가 존 매개변수를 무시하고, 아직 쓰이던 모든 존의 VPC 컨트롤러를 껐다."},"severity":"unknown","symptoms":["network-unreachable","packet-loss","cluster-creation-stuck","autoscaler-scale-up-failed","high-error-rate"],"timeline":{"detected_after":"19m","resolved_after":"2h 48m"},"date_kind":"incident","detection":{"en":"Internal monitoring alerts reached Google engineers at 15:41 US/Pacific, and the investigation started immediately.","ko":"엔지니어들은 미국 태평양 시간 15:41 에 내부 모니터링 알림으로 장애를 알았다."},"components":["network-control-plane","cloud-load-balancer","nat-gateway"],"root_cause":"software-bug","remediation":[{"text":{"en":"Paused maintenance operations to prevent the shutdown from repeating","ko":"재발을 막으려고 유지보수 작업을 곧바로 멈췄다."}},{"text":{"en":"Brought the affected VPC Controllers back into a serving state in every zone","ko":"유지보수 작업을 멈추는 동시에 영향을 받은 VPC 컨트롤러를 다시 서비스 상태로 되돌렸다. 대부분 존은 미국 태평양 시간 17:30 에, 모든 VPC 컨트롤러는 18:09 에 돌아왔다."}},{"text":{"en":"Stopped the automation responsible for the shutdown until safeguards are in place","ko":"이 변경을 일으킨 자동화를 찾아냈고, 알맞은 안전장치가 생길 때까지 그 자동화를 중단시켰다."}},{"text":{"en":"Recovered partial Apigee proxy deployments by hand","ko":"Apigee Edge 에서 일부만 배포된 프록시는 손으로 처리해 2024-05-17 미국 태평양 시간 01:00 까지 복구했다."}},{"text":{"en":"Cleaned up VMs left behind by failed Dataproc cluster deletions","ko":"클러스터 삭제 작업이 실패해 완전히 지워지지 않은 Dataproc VM 을 찾아냈고, 장애가 완화된 뒤 정리했다."}}],"action_items":[{"text":{"en":"Add safety measures that check that maintenance operations carry correctly scoped zone information","ko":"유지보수 작업에 존 정보가 알맞은 범위로 들어 있는지 검증하는 안전장치를 더한다."}},{"text":{"en":"Make the underlying tools reject maintenance operations that do not specify zones","ko":"하위 도구가 존을 지정하지 않은 유지보수 작업을 거부하게 해 심층 방어를 넓힌다."}},{"text":{"en":"Tighten on-demand access control so one maintenance invocation cannot work across multiple zones","ko":"필요할 때만 권한을 주는 접근 제어를 늘려, 유지보수 작업 한 번이 여러 존에 걸쳐 동작하지 못하게 한다."}},{"text":{"en":"Add safety checks, testing and validation for maintenance operations, including positive and negative test cases for the new safety measures","ko":"유지보수 작업에 필요한 안전 점검, 테스트, 검증 절차를 갖춘다. 회귀를 막도록 위의 세 안전장치마다 통과해야 할 경우와 막아야 할 경우의 테스트를 넣는다."}}],"contributing":["delayed-effect-change","early-signal-ignored","no-safeguard-on-destructive-change","blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"From 15:22 US/Pacific on 16 May 2024, new VMs and other new instances across Google Cloud came up without network programming, so the new instances could not open network connections, and VMs that were migrated or restarted lost connectivity. Changes to virtual network configuration, such as firewall rules and load balancers, were not applied. Internal monitoring alerted Google engineers at 15:41.\n\nThe impact reached every product that creates VMs or changes network configuration. All new firewall rules and firewall updates stopped propagating to VM instances in every GCE zone. GKE operations that create or update a VM failed, including cluster and node pool creation and deletion, node upgrades and scaling up an existing node pool. Cloud Run services using Direct VPC Egress could not be deployed or scale up, including from 0, and App Engine Flex deployments could not be created or scale. Batch jobs failed with elevated \"NO_VM_REPORT\" rates, Cloud SQL create, clone and restore operations failed, newly started Memorystore for Redis VM nodes were unreachable, and Cloud NAT Dynamic Port Allocation (DPA) had allocation failures. Customers of Cloud Interconnect, Cloud VPN, Cloud Router and Cloud NAT could not change those resources, and changes to learned BGP routes did not propagate.\n\nExisting workloads were mostly unaffected because the VPC data plane keeps using its last programmed state when the control plane is unavailable, but there was data plane loss as well. All new endpoints, such as VMs and VPN gateways, and new load balancers saw packet loss to a majority of destinations. 0.07% of VMs migrated during the outage lost connectivity. Long-running VMs in a few locations saw loss from data plane overload, peaking at 3% in us-east1-c and averaging 0.05% across all zones, and in a few GCE zones up to 25% of TCP connections to Google Services were blackholed (us-east4-c), so applications that retried with a different TCP source port saw only limited outages. Some Cloud Load Balancing and Apigee customers got 500 errors, latencies or timeouts.\n\nThe status page updates during the incident gave the start as 14:44 US/Pacific and described slow programming in the Cloud Networking control plane and delayed network programming for new and newly migrated VMs. The incident header and the mini incident report give 15:22 as the start.","ko":"새로 만든 VM 이 네트워크 연결 없이 올라와 아무 연결도 맺지 못했고, 마이그레이션되거나 재시작된 VM 은 연결을 잃었다. 방화벽이나 네트워크 로드 밸런서 같은 가상 네트워크 설정을 바꿀 수 없었다. GKE 노드와 노드 풀 생성이 실패했다.\n\n상태 페이지의 제목은 \"Multiple cloud products are experiencing network connectivity issues. New instances of several cloud products will come up without a network in many regions.\" 였다. 첫 상태 갱신의 제목은 \"Programming failures for New Virtual Private Cloud endpoints globally affecting New GCE VM network programming and Cloud Run using Direct VPC.\" 였다. 진단 안내에 따르면 Cloud Networking 컨트롤 플레인의 프로그래밍이 느렸다. 새 VM 이나 새로 마이그레이션된 VM 은 네트워크 프로그래밍이 늦어졌고, Google Cloud Load Balancer 를 거치는 새 연결은 맺어지지 않을 수 있었다. 우회 방법은 없었다.\n\n데이터 플레인에서도 손실이 보였다. 미국 태평양 시간 15:20 부터 18:40 까지 새 VM, VPN 게이트웨이, 로드 밸런서는 네트워크 프로그래밍을 받지 못해 대부분의 목적지로 가는 패킷을 잃었다. 장애 중에 마이그레이션된 VM 의 0.07% 는 장애 내내 연결을 잃었다. 몇몇 위치에서는 데이터 플레인 과부하로 오래 돌던 VM 도 패킷을 잃었고, 손실은 us-east1-c 에서 최대 3%, 전체 존 평균 0.05% 였다. 일부 GCE 존에서는 Google 서비스로 가는 TCP 연결 일부가 응답 없이 사라졌고, us-east4-c 에서는 그 비율이 최대 25% 였다. 다른 TCP 출발지 포트로 재시도하는 애플리케이션은 이 존에서도 영향이 적었다.\n\nVM 을 만들거나 네트워크 설정을 바꾸는 제품이 함께 실패했다. GKE 는 클러스터와 노드 풀의 생성과 삭제, 노드 업그레이드, 기존 노드 풀의 스케일 업, 네트워크 설정 변경이 모두 실패했다. Direct VPC Egress 를 쓰는 Cloud Run 은 새 서비스를 배포하지 못했다. 기존 서비스는 인스턴스가 0개인 상태에서 늘리는 것을 포함해 스케일 업을 하지 못했다. Cloud Functions 와 App Engine Flex 는 배포하지 못했다. VPC Access Connector 는 늘어나지 못해 네트워크가 느려졌을 수 있다. Batch 작업은 \"NO_VM_REPORT\" 실패율이 올랐다. Cloud Build 는 빌드 스케줄링이 늦어지거나 타임아웃이 났다. Cloud Deploy 는 렌더와 배포가 크게 늦어지거나 타임아웃이 났다. Cloud Composer 는 환경 생성의 80% 가 실패했다. Cloud Shell 세션의 약 15% 와 Cloud Workstations 의 약 25% 가 시작하지 못했다. Firebase Test Lab 의 x86 에뮬레이터 실행은 100% 실패했다.\n\n네트워크 제품은 설정을 바꿀 수 없었다. Cloud Firewall 은 새 규칙과 규칙 변경이 모든 GCE 존에서 전파되지 않았다. Cloud Interconnect, Cloud VPN, Cloud Router, Cloud NAT 는 컨트롤 플레인과 관리 플레인이 내려가 리소스를 바꿀 수 없었다. 새로 학습한 BGP 경로의 변경도 데이터 플레인에 반영되지 않았다. 기존 BGP 세션은 대부분 유지됐다. Cloud NAT 의 Dynamic Port Allocation 은 할당에 실패했다. Cloud Load Balancing 은 네트워크 프로그래밍이 필요한 설정 변경을 할 수 없었다. 일부 고객은 오토스케일이 안 되거나 프로그래밍이 덜 끝난 워크로드에서 500 오류를 받았다. Apigee 고객 일부도 지연, 타임아웃, 500 오류를 겪었다.\n\n데이터 저장소도 영향을 받았다. Cloud SQL 은 15:47 부터 16:30 까지 create, clone, restore 작업이 모두 실패했고 일부 인스턴스가 작업 실패로 영향을 받았다. AlloyDB 는 새 VM 생성 일부가 실패했고 us-central1 에서 약 10% 의 자동 장애 조치가 일어났다. Memorystore for Redis 는 새로 시작한 인스턴스 VM 노드에 네트워크가 닿지 않았다. 그 때문에 Basic 인스턴스는 쓸 수 없었고, Standard 인스턴스는 읽기 용량이 줄거나 아예 쓸 수 없었다. Memorystore for Memcached 는 기존 노드의 약 0.8% 가 재시작되며 약 50분 동안 내려가 있었다. Filestore 는 인스턴스 생성과 삭제가 느려지거나 실패했다. Looker 인스턴스의 0.2% 미만이 Cloud SQL DB 연결 실패로 내려갔다.\n\n회복은 단계적이었다. 대부분 존의 VPC 컨트롤러는 17:30 에 돌아왔고, 18:09 에 모든 VPC 컨트롤러가 복구됐다. 데이터 플레인에 반영할 변경의 백로그는 18:40 에 해소됐다. 그 뒤로도 늦게 회복한 제품이 있었다. Redis 인스턴스 일부는 20:05 에, Cloud SQL 의 남은 인스턴스는 22:30 에, 일부만 배포된 Apigee Edge 프록시는 2024-05-17 01:00 에 복구됐다. NAT 설정의 1% 미만은 컨트롤 플레인 변경이 적용되기까지 최대 두 시간이 더 걸렸다."},"updated_at":"2026-11-14T12:34:17.235207Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0529","org_slug":"google-cloud"}