{"id":"IL-0222","org":"Google Cloud","date":"2019-06-02","docs":["https://cloud.google.com/blog/topics/inside-google-cloud/an-update-on-sundays-service-disruption"],"title":{"en":"Google Cloud US regions had heavy packet loss and some went unreachable after the network control plane was descheduled","ko":"유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다."},"domain":["gcp","networking"],"impact":{"scope":"Google Cloud services on Google's US network, including Compute Engine, App Engine, Cloud Endpoints, Cloud Interconnect, Cloud VPN, Cloud Console, Stackdriver, Cloud Pub/Sub, BigQuery, Cloud Spanner and Cloud Storage, plus G Suite and other Google services","users":"unknown","region":"us-central1, us-east1, us-east4, us-west2, northamerica-northeast1, southamerica-east1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.cloud.google.com/incident/cloud-networking/19009","kind":"official-status","archived":"https://web.archive.org/web/20261103103714/https://status.cloud.google.com/incident/cloud-networking/19009"}],"summary":{"en":"In each Google datacenter location, the network control plane runs on several instances of Google's cluster management software, so the failure of one instance does not affect network capacity. The cluster management software also automates maintenance events, and every job is labelled with what to do during one: move to another machine, or stop and be rescheduled afterwards. Three things combined. Network control plane jobs and their supporting infrastructure in the affected regions were configured to stop during a maintenance event. The cluster management instances running the network control plane were eligible for a rare maintenance event type. And the software that starts maintenance events had a bug that let it deschedule several independent software clusters at once, even in different physical locations.\n\nWhen the maintenance event started at 11:45 in one location, the automation descheduled the network control jobs and their supporting infrastructure in multiple locations. The network is designed to fail static, that is, to keep running for a while without its control plane, and it ran normally for several minutes. Then BGP routing between specific affected locations was withdrawn, which sharply cut network capacity and made some Google Cloud regions inaccessible; user impact began between 11:47 and 11:49. Packet loss lasted between 3 hours 19 minutes and 4 hours 25 minutes depending on the region, and Compute Engine, App Engine, Cloud Endpoints, Cloud Interconnect, Cloud VPN, Cloud Console, Stackdriver Metrics, Cloud Pub/Sub, BigQuery, regional Cloud Spanner instances, regional Cloud Storage buckets and G Suite in those regions were affected.\n\nBy 13:01 the root cause was known and engineers halted the maintenance automation. Bringing the network control plane back took longer because, in the locations where every instance had been descheduled, its configuration data was lost and had to be rebuilt and redistributed during a large network event. The new configuration began rolling out at 14:03, while other Google teams moved their services' traffic away from the affected regions. Network capacity started to recover at 15:19 and full service resumed at 16:10 US/Pacific. Cloud VPN in us-west2, northamerica-northeast1 and southamerica-east1 needed extra work to bring its control plane out of a fail-safe state and recovered at 16:30. Cloud Endpoints configuration pushes failed for 50% of workflows until 4 June 11:30, and after that still took up to an hour to take effect.","ko":"Google 의 네트워크 제어 평면은 클러스터 관리 소프트웨어의 여러 인스턴스 위에서 돈다. 이 소프트웨어는 전력 설비 변경이나 네트워크 증설 같은 데이터 센터 유지보수를 자동화하며, 작업마다 유지보수 때 다른 기계로 옮길지, 멈췄다가 다시 띄울지를 표시해 둔다. 평소에는 문제가 없던 잘못된 설정 둘과 소프트웨어 버그 하나가 겹쳐 장애가 시작됐다. 피해 리전의 네트워크 제어 작업과 지원 인프라는 유지보수 때 멈추도록 설정돼 있었다. 네트워크 제어 평면을 돌리는 클러스터 관리 소프트웨어 인스턴스들은 비교적 드문 유지보수 유형의 대상에 들어 있었다. 유지보수를 시작하는 소프트웨어에는 서로 다른 물리 위치에 있는 독립된 클러스터 여럿을 한 번에 내릴 수 있는 버그가 있었다.\n\n2019-06-02 일요일 US/Pacific 11:45 에 유지보수 이벤트가 한 위치에서 시작됐고, 자동화가 여러 물리 위치의 네트워크 제어 작업과 지원 인프라를 내렸다. 네트워크는 제어 평면 없이도 한동안 그대로 도는 fail static 방식으로 설계돼 몇 분 동안은 정상이었다. 그 뒤 특정 위치 사이의 BGP 라우팅이 철회되면서 네트워크 용량이 크게 줄고 일부 Google Cloud 리전에 닿을 수 없게 됐다. 사용자 영향은 11:47~11:49 에 시작됐다. us-central1, us-east1, us-east4, us-west2, northamerica-northeast1, southamerica-east1 에서 패킷 손실이 리전에 따라 3시간 19분에서 4시간 25분 이어졌다. Compute Engine, App Engine, Cloud Endpoints, Cloud Interconnect, Cloud VPN, Cloud Console, Stackdriver Metrics, Cloud Pub/Sub, BigQuery, 리전 Cloud Spanner 인스턴스, 리전 Cloud Storage 버킷과 이 리전의 G Suite 서비스가 영향을 받았다. us-west1 과 유럽, 아시아 리전에는 리전 네트워크 혼잡이 없었다.\n\n엔지니어는 장애 2분 뒤 알림을 받고 가장 심각한 사고에 쓰는 절차를 시작했지만, 혼잡한 네트워크 때문에 도구가 실패해 디버깅이 늦어졌다. 13:01 에 근본 원인을 찾아 유지보수 자동화를 멈추고 네트워크 제어 평면을 다시 켜기 시작했다. 여러 위치에서 제어 평면 인스턴스가 모두 내려가 설정 데이터가 사라졌기 때문에 설정을 다시 만들고 배포해야 했다. 새 설정은 14:03 부터 나가기 시작했다. 그동안 여러 팀이 각자 서비스의 트래픽을 피해 리전 밖으로 돌렸다. 네트워크 용량은 15:19 부터 돌아오기 시작했고 16:10 에 전체 서비스가 재개됐다. 일부 리전의 Cloud VPN 은 fail-safe 상태에서 빼내는 추가 조치를 거쳐 16:30 에 회복됐다. Cloud Endpoints 는 2019-06-04 11:30 까지 서비스 설정 푸시의 50% 가 실패했고, 그 뒤에도 설정이 반영되는 데 최대 한 시간이 걸렸다."},"trigger":{"en":"At 11:45 US/Pacific a relatively rare type of datacenter maintenance event started in one physical location, and the automation that runs it descheduled logical clusters that also held network control plane jobs in other physical locations.","ko":"US/Pacific 11:45 에 비교적 드문 유형의 데이터 센터 유지보수 이벤트가 물리 위치 한 곳에서 시작됐다. 자동화 소프트웨어가 내릴 작업 목록에 네트워크 제어 작업을 돌리는 논리 클러스터를 넣었다. 이 클러스터에는 다른 물리 위치의 네트워크 제어 작업도 들어 있어, 여러 위치의 네트워크 제어 평면과 지원 인프라가 한꺼번에 내려갔다."},"severity":"unknown","symptoms":["packet-loss","network-unreachable","high-latency","high-error-rate","monitoring-down"],"timeline":{"detected_after":"2m","resolved_after":"4h 25m"},"date_kind":"incident","detection":{"en":"Google engineers were alerted to the failure two minutes after it began and started the incident process used for the most serious production incidents. The first customer notice appeared on the status page at 12:53 US/Pacific.","ko":"Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았고, 가장 심각한 운영 사고에 쓰는 사고 관리 절차를 곧바로 시작했다. 고객용 상태 페이지에는 US/Pacific 12:53 에 첫 공지가 올라왔다."},"components":["network-control-plane","bgp","backbone-network"],"root_cause":"software-bug","remediation":[{"text":{"en":"Lowered the priority of less critical network traffic classes to reduce congestion","ko":"혼잡을 줄이려고 덜 중요한 네트워크 트래픽 등급의 우선순위를 낮췄다."}},{"text":{"en":"Halted the datacenter automation software responsible for the maintenance event","ko":"US/Pacific 13:01 에 근본 원인을 찾고, 유지보수 이벤트를 일으킨 자동화 소프트웨어를 멈췄다."}},{"text":{"en":"Rescheduled the network control plane and its supporting infrastructure in each location","ko":"네트워크 제어 평면과 지원 인프라를 위치마다 다시 스케줄해 켰다."}},{"text":{"en":"Rebuilt and redistributed the lost network control plane configuration, rolling it out from 14:03","ko":"제어 평면 인스턴스가 모두 내려가면서 사라진 설정 데이터를 여러 위치에 다시 만들어 배포했다. 새 설정은 14:03 부터 나가기 시작했다."}},{"text":{"en":"Directed service traffic away from the affected regions","ko":"Google 안의 여러 팀이 서비스별 완화 조치로 트래픽을 피해 리전 밖으로 돌려 다른 곳에서 계속 서비스했다."}},{"text":{"en":"Moved the Cloud VPN control plane in three regions out of its fail-safe state","ko":"us-west2, northamerica-northeast1, southamerica-east1 에서 장애 때문에 fail-safe 상태에 들어간 VPN 제어 평면을 손으로 빼냈다. 이 리전의 VPN 게이트웨이는 16:30 에 회복됐다."}}],"action_items":[{"text":{"en":"Keep the maintenance automation off until safeguards stop it descheduling jobs in several physical locations at once","ko":"유지보수 때 작업을 내리는 데이터 센터 자동화 소프트웨어를 즉시 멈췄고, 여러 물리 위치에서 동시에 작업을 내리지 않게 하는 안전장치를 갖춘 뒤에만 다시 켠다."}},{"text":{"en":"Harden the cluster management software to reject such requests whatever their origin","ko":"클러스터 관리 소프트웨어가 요청의 출처와 상관없이 여러 물리 위치의 작업을 한꺼번에 내리는 요청을 거부하도록 강화한다."}},{"text":{"en":"Reconfigure the network control plane to reject maintenance requests of the type involved","ko":"네트워크 제어 평면 소프트웨어와 지원 인프라가 이번 사고에 얽힌 유형의 유지보수 요청을 거부하도록 다시 설정한다."}},{"text":{"en":"Make the network control plane in each location persist its configuration","ko":"위치마다 네트워크 제어 평면이 설정을 영구 저장하게 바꿔, 모든 작업이 내려가도 설정을 다시 만들고 배포할 필요가 없게 한다. 이렇게 하면 복구 시간이 열 배쯤 줄어든다."}},{"text":{"en":"Let the network stay in fail static mode longer when the control plane is lost","ko":"제어 평면을 잃었을 때 네트워크가 fail static 모드로 더 오래 버티게 해, 사용자 영향 없이 복구할 시간을 충분히 둔다."}},{"text":{"en":"Review, update and test emergency response tooling and procedures, including customer communication tooling, for such network failures","ko":"고객 소통 도구를 포함한 비상 대응 도구와 절차를 검토하고 고치고 시험해, 이번과 같은 네트워크 장애에도 견디게 한다."}},{"text":{"en":"Extend continuous disaster recovery testing to this and similarly catastrophic failures","ko":"상시 재해 복구 시험의 범위를 넓혀 이번 장애와 이와 비슷한 수준의 큰 장애를 넣는다."}}],"contributing":["blast-radius-too-wide","circular-dependency","limited-debug-access","revert-did-not-restore"],"recurrence_of":null,"symptoms_text":{"en":"On Sunday 2 June 2019, with user impact beginning between 11:47 and 11:49 US/Pacific, Google Cloud projects in several US regions saw elevated packet loss from network congestion, and some regions became unreachable. Customers saw higher latency, intermittent errors and lost connectivity to instances in us-central1, us-east1, us-east4, us-west2, northamerica-northeast1 and southamerica-east1, while us-west1, Europe and Asia had no regional congestion.\n\nCompute Engine instances in us-east4, us-west2, northamerica-northeast1 and southamerica-east1 were inaccessible for the whole incident. Between instances, us-east1 had up to 33% packet loss from 11:38 to 12:17 and up to 8% until 14:50, and us-central1 had a 9% spike that subsided by 12:05. Compute Engine admin operations returned an average of 1.2% errors. Cloud Interconnect attachments in the four inaccessible regions reported 50% to 100% packet loss and some BGP sessions went down, attachments connecting through east coast Interconnects saw 10-50% loss from backbone congestion, and Cloud VPN gateways in those regions were unreachable, while us-central1 VPN endpoints reported 25% packet loss and us-east1 endpoints 10%.\n\nServices that depend on Google's US network failed with it. App Engine apps in the four regions were unavailable, us-central saw a 23.2% drop in requests per second, and requests that did not reach App Engine returned client timeout errors; BigQuery jobs.insert calls had a 27% error rate between 11:47 and 12:02; Cloud Pub/Sub publish and subscribe requests failed in the affected regions; Cloud Spanner in us-east4, us-west2 and northamerica-northeast1 was unavailable from 11:48 to 15:44; Cloud Console pages loaded slowly, partially or not at all; and Cloud Storage average error rates were 96.2% for us-west2, 79.3% for southamerica-east1, 62.4% for us-east4 and 43.4% for northamerica-northeast1 buckets. Stackdriver Monitoring had a 5-10% drop in requests per second, login failures to its frontend averaged 8.4%, UI components hit a 3.5% error rate when loading data, and monitoring statistics were inconsistent during the disruption. Cloud Endpoints configuration pushes failed for 50% of workflows until 4 June 11:30, and new Endpoints services returned 500 errors unless the ESP flag service_control_network_fail_open was enabled.\n\nGoogle engineers were alerted two minutes after the failure began, but debugging was slowed because their tools competed for the congested network. The backup plans for that case, engineers travelling to secure facilities and lowering the priority of less critical traffic classes, added time, and the damage to tooling made it hard at first to measure impact and tell customers accurately.\n\nOn the status page, the first notice at 12:53 said Google was investigating an issue with Google Cloud Networking. The 13:45 notice reported high levels of network congestion in the eastern USA affecting multiple services in Google Cloud, G Suite and YouTube, and the 15:04 notice said the congestion was continuing.","ko":"2019-06-02 US/Pacific 11:47~11:49 부터 미국 여러 리전의 Google Cloud 프로젝트에서 패킷 손실이 늘고, 지연이 커지고, 간헐적 오류와 인스턴스 연결 끊김이 나타났다. us-west1 과 유럽, 아시아 리전에는 리전 네트워크 혼잡이 없었다. Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았다.\n\nus-east4, us-west2, northamerica-northeast1, southamerica-east1 의 Compute Engine 인스턴스는 장애 내내 접근할 수 없었다. 사설 IP 트래픽과 인터넷 트래픽에서 인스턴스 사이 패킷 손실은 us-east1 에서 11:38 부터 12:17 까지 최대 33%, 그 뒤 14:50 까지 최대 8% 였다. us-central1 은 11:38 직후 9% 로 튀었다가 12:05 에 가라앉았다. Compute Engine 관리 작업은 평균 1.2% 의 오류를 냈다.\n\n네트워크 위의 서비스들도 함께 망가졌다. Cloud Interconnect 는 피해 리전에서 10% 에서 100% 사이의 패킷 손실을 보고했고 일부 BGP 세션이 내려갔다. 동부 해안의 Interconnect 를 거쳐 연결하는 us-west1, us-east1, us-central1 의 Interconnect Attachment 도 백본 혼잡으로 10% 에서 50% 의 패킷 손실을 보였다. Cloud VPN 게이트웨이는 같은 네 리전에서 닿지 않았고, us-central1 은 25%, us-east1 은 10% 의 패킷 손실을 보였다. 네 리전의 App Engine 애플리케이션은 쓸 수 없었고, us-central 에서는 초당 요청 수가 23.2% 줄었으며 App Engine 에 닿지 못한 요청은 client timeout 오류를 냈다. Cloud Storage 버킷 위치별 평균 오류율은 us-west2 96.2%, southamerica-east1 79.3%, us-east4 62.4%, northamerica-northeast1 43.4% 였다. BigQuery 는 11:47 부터 12:02 사이에 jobs.insert API 호출의 오류율이 27% 였다. Cloud Spanner 는 us-east4, us-west2, northamerica-northeast1 에서 11:48 부터 15:44 까지 쓸 수 없었다. Cloud Pub/Sub 는 피해 리전에서 게시와 구독 요청이 실패했다.\n\nCloud Endpoints 는 2019-06-02 12:00 부터 2019-06-04 11:30 까지 서비스 설정 푸시의 50% 가 실패했다. 장애 시작 뒤 만든 새 Endpoints 서비스로 가는 요청은, 기본값이 꺼져 있는 ESP 플래그 service_control_network_fail_open 을 켜지 않으면 500 오류로 실패했다.\n\n모니터링과 콘솔도 영향을 받았다. Stackdriver Monitoring 의 초당 요청 수는 5% 에서 10% 줄었다. Cloud Console 페이지는 느리게 뜨거나, 일부만 뜨거나, 아예 뜨지 않았다. Stackdriver Monitoring 프런트엔드 로그인 실패율은 평균 8.4% 였고, UI 구성 요소에서 데이터를 불러올 때 3.5% 의 오류가 났다. 모니터링 통계가 서로 맞지 않아 Interconnect 의 패킷 손실은 나중에 추정해야 했다.\n\n디버깅은 혼잡해진 네트워크를 두고 다투던 도구들이 실패하면서 크게 늦어졌다. 백업 계획을 쓰는 데에도 시간이 들었다. 엔지니어가 가장 심각한 장애에도 견디도록 만든 보안 시설로 이동했고, 덜 중요한 네트워크 트래픽 등급의 우선순위를 낮췄다. 장애의 범위가 넓고 도구까지 망가져, 처음에는 영향을 정확히 파악하고 고객에게 정확히 알리기 어려웠다.\n\n상태 페이지에는 12:53 에 Google Cloud Networking 문제를 조사하고 있다는 첫 공지가 올라왔다. 13:45 공지는 미국 동부의 심한 네트워크 혼잡이 Google Cloud, G Suite, YouTube 의 여러 서비스에 영향을 주고 있다고 알렸다. 15:04 공지까지도 미국 동부에서 혼잡이 이어지고 있었다."},"updated_at":"2026-11-14T05:53:43.596298Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0222","org_slug":"google-cloud"}