Incident Library

IL-0529 Google Cloud · 2024-05-16gcpnetworking

모든 Google Cloud 존에서 VPC 컨트롤러가 꺼져 새로 만든 VM 과 여러 제품의 새 인스턴스가 네트워크 없이 올라왔다

Google Cloud 는 존마다 VPC 컨트롤러를 따로 띄운다. 각 존의 VPC 컨트롤러는 그 존의 호스트를 프로그래밍해서, 그 위의 엔드포인트가 같은 VPC 네트워크의 다른 엔드포인트, VPN 이나 Interconnect 너머의 온프레미스, 인터넷에 닿게 한다. VPC 네트워크는 컨트롤 플레인이 없어도 데이터 플레인이 마지막으로 받은 상태를 계속 쓰는 구조여서, 영향은 주로 컨트롤 플레인을 거치는 네트워크 작업에 몰렸다.

2024-05-16 Google 인프라 팀은 한 존에서 쓰지 않는 VPC 컨트롤러 하나를 끄는 정기 유지보수를 실행했다. 그해 초 자동화 소프트웨어를 리팩터링할 때 유지보수 대상 존을 지정하는 매개변수가 바뀌었고, 그 때문에 대상 존 매개변수가 무시됐다. 테스트 환경은 이 실패를 잡았지만, 그 오류는 테스트 환경에서 예상되는 실패로 잘못 해석돼 변경이 운영 환경까지 갔다. 유지보수 범위를 제한하는 안전장치도 있었으나 자동화 프레임워크를 새 버전으로 옮기는 과정에서 모르는 사이에 꺼져 있었다. 결국 종료 작업이 모든 존의 VPC 컨트롤러에 적용됐다. 미국 태평양 시간 15:22 부터 새 VM 생성, 오토스케일, 고객 프로젝트의 설정 변경, VM 상태 변화 반영 같은 컨트롤 플레인 작업이 실패했다. 데이터 플레인에서는 VM 라이브 마이그레이션 중에 패킷이 사라졌고 일부 존에서 네트워크가 혼잡해졌다. VM 을 만들거나 네트워크 설정을 바꾸는 GKE, Cloud Run, Cloud SQL, Cloud NAT 를 비롯한 여러 제품이 함께 실패했다.

엔지니어들은 15:41 에 내부 모니터링 알림을 받았다. 재발을 막으려고 유지보수 작업을 곧바로 멈췄고, 동시에 영향을 받은 VPC 컨트롤러를 다시 서비스 상태로 되돌렸다. 대부분 존은 17:30 에, 모든 VPC 컨트롤러는 18:09 에 복구됐다. 데이터 플레인에 반영할 변경의 백로그는 18:40 에 해소됐다. 영향의 대부분은 2시간 48분 이어졌고, Cloud SQL, Memorystore for Redis, Apigee 같은 일부 제품은 그 뒤로도 몇 시간 더 걸려 회복했다.

심각도
–
영향 범위
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
영향 사용자
–
지역
Global (all Google Cloud zones)
감지까지
19m
복구까지
2h 48m

증상

새로 만든 VM 이 네트워크 연결 없이 올라와 아무 연결도 맺지 못했고, 마이그레이션되거나 재시작된 VM 은 연결을 잃었다. 방화벽이나 네트워크 로드 밸런서 같은 가상 네트워크 설정을 바꿀 수 없었다. GKE 노드와 노드 풀 생성이 실패했다.

상태 페이지의 제목은 "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 를 거치는 새 연결은 맺어지지 않을 수 있었다. 우회 방법은 없었다.

데이터 플레인에서도 손실이 보였다. 미국 태평양 시간 15:20 부터 18:40 까지 새 VM, VPN 게이트웨이, 로드 밸런서는 네트워크 프로그래밍을 받지 못해 대부분의 목적지로 가는 패킷을 잃었다. 장애 중에 마이그레이션된 VM 의 0.07% 는 장애 내내 연결을 잃었다. 몇몇 위치에서는 데이터 플레인 과부하로 오래 돌던 VM 도 패킷을 잃었고, 손실은 us-east1-c 에서 최대 3%, 전체 존 평균 0.05% 였다. 일부 GCE 존에서는 Google 서비스로 가는 TCP 연결 일부가 응답 없이 사라졌고, us-east4-c 에서는 그 비율이 최대 25% 였다. 다른 TCP 출발지 포트로 재시도하는 애플리케이션은 이 존에서도 영향이 적었다.

VM 을 만들거나 네트워크 설정을 바꾸는 제품이 함께 실패했다. 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% 실패했다.

네트워크 제품은 설정을 바꿀 수 없었다. Cloud Firewall 은 새 규칙과 규칙 변경이 모든 GCE 존에서 전파되지 않았다. Cloud Interconnect, Cloud VPN, Cloud Router, Cloud NAT 는 컨트롤 플레인과 관리 플레인이 내려가 리소스를 바꿀 수 없었다. 새로 학습한 BGP 경로의 변경도 데이터 플레인에 반영되지 않았다. 기존 BGP 세션은 대부분 유지됐다. Cloud NAT 의 Dynamic Port Allocation 은 할당에 실패했다. Cloud Load Balancing 은 네트워크 프로그래밍이 필요한 설정 변경을 할 수 없었다. 일부 고객은 오토스케일이 안 되거나 프로그래밍이 덜 끝난 워크로드에서 500 오류를 받았다. Apigee 고객 일부도 지연, 타임아웃, 500 오류를 겪었다.

데이터 저장소도 영향을 받았다. 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 연결 실패로 내려갔다.

회복은 단계적이었다. 대부분 존의 VPC 컨트롤러는 17:30 에 돌아왔고, 18:09 에 모든 VPC 컨트롤러가 복구됐다. 데이터 플레인에 반영할 변경의 백로그는 18:40 에 해소됐다. 그 뒤로도 늦게 회복한 제품이 있었다. Redis 인스턴스 일부는 20:05 에, Cloud SQL 의 남은 인스턴스는 22:30 에, 일부만 배포된 Apigee Edge 프록시는 2024-05-17 01:00 에 복구됐다. NAT 설정의 1% 미만은 컨트롤 플레인 변경이 적용되기까지 최대 두 시간이 더 걸렸다.

증상 네트워크 도달 불가패킷 손실클러스터·노드 생성 정체노드 증설 실패오류율 상승

원인

원인 소프트웨어 결함

구성 요소 네트워크 컨트롤 플레인클라우드 로드 밸런서NAT 게이트웨이
기여 요인 늦게 드러난 변경초기 신호 무시파괴적 변경 보호 장치 부재과도한 영향 범위
촉발
한 Google Cloud 존에서 쓰지 않는 VPC 컨트롤러 하나를 끄려던 정기 유지보수 자동화가 존 매개변수를 무시하고, 아직 쓰이던 모든 존의 VPC 컨트롤러를 껐다.

감지

엔지니어들은 미국 태평양 시간 15:41 에 내부 모니터링 알림으로 장애를 알았다.

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 네트워크 컨트롤 플레인, 클라우드 로드 밸런서, NAT 게이트웨이. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.