Incident Library

IL-0222 Google Cloud · 2019-06-02gcpnetworking

유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다.

Google 의 네트워크 제어 평면은 클러스터 관리 소프트웨어의 여러 인스턴스 위에서 돈다. 이 소프트웨어는 전력 설비 변경이나 네트워크 증설 같은 데이터 센터 유지보수를 자동화하며, 작업마다 유지보수 때 다른 기계로 옮길지, 멈췄다가 다시 띄울지를 표시해 둔다. 평소에는 문제가 없던 잘못된 설정 둘과 소프트웨어 버그 하나가 겹쳐 장애가 시작됐다. 피해 리전의 네트워크 제어 작업과 지원 인프라는 유지보수 때 멈추도록 설정돼 있었다. 네트워크 제어 평면을 돌리는 클러스터 관리 소프트웨어 인스턴스들은 비교적 드문 유지보수 유형의 대상에 들어 있었다. 유지보수를 시작하는 소프트웨어에는 서로 다른 물리 위치에 있는 독립된 클러스터 여럿을 한 번에 내릴 수 있는 버그가 있었다.

2019-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 과 유럽, 아시아 리전에는 리전 네트워크 혼잡이 없었다.

엔지니어는 장애 2분 뒤 알림을 받고 가장 심각한 사고에 쓰는 절차를 시작했지만, 혼잡한 네트워크 때문에 도구가 실패해 디버깅이 늦어졌다. 13:01 에 근본 원인을 찾아 유지보수 자동화를 멈추고 네트워크 제어 평면을 다시 켜기 시작했다. 여러 위치에서 제어 평면 인스턴스가 모두 내려가 설정 데이터가 사라졌기 때문에 설정을 다시 만들고 배포해야 했다. 새 설정은 14:03 부터 나가기 시작했다. 그동안 여러 팀이 각자 서비스의 트래픽을 피해 리전 밖으로 돌렸다. 네트워크 용량은 15:19 부터 돌아오기 시작했고 16:10 에 전체 서비스가 재개됐다. 일부 리전의 Cloud VPN 은 fail-safe 상태에서 빼내는 추가 조치를 거쳐 16:30 에 회복됐다. Cloud Endpoints 는 2019-06-04 11:30 까지 서비스 설정 푸시의 50% 가 실패했고, 그 뒤에도 설정이 반영되는 데 최대 한 시간이 걸렸다.

심각도
–
영향 범위
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
영향 사용자
–
지역
us-central1, us-east1, us-east4, us-west2, northamerica-northeast1, southamerica-east1
감지까지
2m
복구까지
4h 25m

증상

2019-06-02 US/Pacific 11:47~11:49 부터 미국 여러 리전의 Google Cloud 프로젝트에서 패킷 손실이 늘고, 지연이 커지고, 간헐적 오류와 인스턴스 연결 끊김이 나타났다. us-west1 과 유럽, 아시아 리전에는 리전 네트워크 혼잡이 없었다. Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았다.

us-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% 의 오류를 냈다.

네트워크 위의 서비스들도 함께 망가졌다. 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 는 피해 리전에서 게시와 구독 요청이 실패했다.

Cloud Endpoints 는 2019-06-02 12:00 부터 2019-06-04 11:30 까지 서비스 설정 푸시의 50% 가 실패했다. 장애 시작 뒤 만든 새 Endpoints 서비스로 가는 요청은, 기본값이 꺼져 있는 ESP 플래그 service_control_network_fail_open 을 켜지 않으면 500 오류로 실패했다.

모니터링과 콘솔도 영향을 받았다. Stackdriver Monitoring 의 초당 요청 수는 5% 에서 10% 줄었다. Cloud Console 페이지는 느리게 뜨거나, 일부만 뜨거나, 아예 뜨지 않았다. Stackdriver Monitoring 프런트엔드 로그인 실패율은 평균 8.4% 였고, UI 구성 요소에서 데이터를 불러올 때 3.5% 의 오류가 났다. 모니터링 통계가 서로 맞지 않아 Interconnect 의 패킷 손실은 나중에 추정해야 했다.

디버깅은 혼잡해진 네트워크를 두고 다투던 도구들이 실패하면서 크게 늦어졌다. 백업 계획을 쓰는 데에도 시간이 들었다. 엔지니어가 가장 심각한 장애에도 견디도록 만든 보안 시설로 이동했고, 덜 중요한 네트워크 트래픽 등급의 우선순위를 낮췄다. 장애의 범위가 넓고 도구까지 망가져, 처음에는 영향을 정확히 파악하고 고객에게 정확히 알리기 어려웠다.

상태 페이지에는 12:53 에 Google Cloud Networking 문제를 조사하고 있다는 첫 공지가 올라왔다. 13:45 공지는 미국 동부의 심한 네트워크 혼잡이 Google Cloud, G Suite, YouTube 의 여러 서비스에 영향을 주고 있다고 알렸다. 15:04 공지까지도 미국 동부에서 혼잡이 이어지고 있었다.

증상 패킷 손실네트워크 도달 불가지연 시간 증가오류율 상승모니터링 중단

원인

원인 소프트웨어 결함

구성 요소 네트워크 컨트롤 플레인BGP 라우팅백본망
기여 요인 과도한 영향 범위순환 의존디버그 접근 제한롤백 무효
촉발
US/Pacific 11:45 에 비교적 드문 유형의 데이터 센터 유지보수 이벤트가 물리 위치 한 곳에서 시작됐다. 자동화 소프트웨어가 내릴 작업 목록에 네트워크 제어 작업을 돌리는 논리 클러스터를 넣었다. 이 클러스터에는 다른 물리 위치의 네트워크 제어 작업도 들어 있어, 여러 위치의 네트워크 제어 평면과 지원 인프라가 한꺼번에 내려갔다.

감지

Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았고, 가장 심각한 운영 사고에 쓰는 사고 관리 절차를 곧바로 시작했다. 고객용 상태 페이지에는 US/Pacific 12:53 에 첫 공지가 올라왔다.

조치

후속 조치

교훈

–

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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