Incident Library

IL-0530 Google Cloud · 2023-10-05gcpnetworkingkubernetes

us-central1 의 가상 네트워크 라우터 컨트롤러가 메모리 부족으로 재시작을 되풀이해 새 VM 과 마이그레이션된 VM 의 네트워크가 오래 끊겼다

근본 원인은 Google Cloud 전체에 천천히 배포되던 관리 플레인의 동작 변경이었다. 이 변경은 로드 밸런서 백엔드로 쓰는 GCP Instance Group 과 Network Endpoint Group 의 API 업데이트 처리를 더 잘 분리해 안정성과 성능을 높이려는 것이었다. 여러 리전에서는 문제없이 배포됐지만, us-central1 에 배포되자 이 리전의 큰 워크로드 규모 때문에 가상 네트워크 라우터 컨트롤 플레인의 메모리가 예상 밖으로 늘었다. 컨트롤러는 메모리를 다 써서 자동으로 재시작됐지만, 워크로드가 커서 메모리 부족과 재시작을 되풀이했다. 가상 라우터와 컨트롤러는 존마다 장애 도메인을 나눠 배포돼 있었으나, 이 변경이 리전 단위 API 에 영향을 주었기 때문에 리전의 모든 가상 라우터가 동시에 메모리 압박을 받았다.

컨트롤러를 쓸 수 없게 되자 가상 네트워크 라우터는 새 VM, 마이그레이션된 VM 의 새 위치, 동적 경로, 로드 밸런서 백엔드의 상태 같은 새 정보를 받지 못했다. 리전 안 트래픽과 리전 간 트래픽은 각자 컨트롤 플레인을 가진 별도의 라우터가 처리했다. 그중 리전 간 라우터가 먼저, 더 오래 영향을 받았다. 미국 태평양 시간 03:08 부터 us-central1 을 오가는 리전 간 패킷 손실이 시작됐고, 07:00 부터 08:15 까지는 리전 안 트래픽도 손실을 겪었다. 새 VM 을 만드는 GKE, Cloud SQL, Filestore, Dataproc, Dataflow 같은 제품이 함께 실패했다.

엔지니어들은 10월 4일 21:45 에 컨트롤 플레인이 느리다는 알림을 받고 조사했지만 느려짐은 간헐적이었다. 10월 5일 02:11 에 컨트롤러의 메모리 부족 알림이 오자 메모리를 더 할당하기 시작했고, 이 변경은 05:27 부터 운영 환경에 닿았다. 08:15 에 리전 안 패킷 손실이 가라앉은 것은 이 메모리 증설 덕분이었다. 엔지니어들은 08:22 에 메모리 증가를 관리 플레인 변경의 배포와 연결 지었다. 08:52 에 시작한 롤백이 09:35 에 us-central1 에서 끝나면서 메모리 부족은 모두 멈췄다. 업데이트를 받지 않던 라우터 몇 대는 손으로 재시작했다. 10:55 에 패킷 손실이 모두 멈췄고 컨트롤 플레인이 업데이트를 정상으로 처리했다. 장애는 7시간 47분 이어졌다.

심각도
–
영향 범위
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
영향 사용자
–
지역
us-central1
감지까지
–
복구까지
7h 47m

증상

us-central1 에서 새로 만든 VM 은 네트워크가 동작하기까지 오래 기다려야 했고, 라이브 마이그레이션된 VM 은 마이그레이션 뒤 오래 연결을 잃었다. us-central1 을 오가는 리전 간 트래픽에서 패킷 손실이 났다. 기존 VM 중 마이그레이션되지 않고 상태도 바뀌지 않은 VM 은 직접 영향을 받지 않았다.

상태 페이지의 첫 제목은 "Connectivity issue impacting newly created VM’s in us-central1" 이었고, 새 VM 의 네트워킹 스택이 완전히 동작하기까지 몇 분 늦어질 수 있다고 안내했다. 상태 페이지는 우회 방법으로 영향을 받지 않은 존에 VM 을 배포하라고 했다가, 나중에는 영향을 받지 않은 리전을 쓰라고 바꿨다. 제목은 그 뒤 "Multiple cloud products are experiencing networking issues in us-central1" 로 바뀌었다.

VM 의 헬스 체크 상태가 로드 밸런서에 제때 전달되지 않았다. 기존 VM 이 직접 영향을 받지 않았더라도 그 트래픽이 VPN 게이트웨이, 내부 로드 밸런서, 다른 VM 처럼 영향을 받은 장치를 거치면 함께 영향을 받았을 수 있다.

영향은 시간에 따라 바뀌었다. 미국 태평양 시간 03:08 부터 10:55 까지는 주로 리전 간 가상 네트워크 트래픽이 영향을 받았다. 07:00 부터 08:15 까지는 주로 us-central1-c 를 오가는 리전 안 트래픽에서도 큰 패킷 손실이 났다. 메모리 부족이 잦아질수록 라우터 상태 갱신이 늦어졌고, 끝내는 갱신이 사실상 진행되지 않았다.

VM 을 만드는 제품이 함께 실패했다. GKE 는 us-central1 클러스터의 최대 0.4% 가 재생성이나 업그레이드 중에 다운타임이나 지연을 겪었다. 클러스터 생성 시도의 24% 가 실패하거나 늦어졌다. 대부분은 최대 120분 뒤 저절로 성공했다. 다운타임 동안 Google Cloud Console 의 Clusters 페이지에는 일부 노드가 등록되지 않았고 클러스터가 비정상이라고 나왔다. Cloud SQL 은 새 VM 생성이 실패했다. 기존 인스턴스에 업데이트, 셀프 서비스 유지보수, 클론, 장애 조치처럼 새 VM 을 만드는 변경을 하면 데이터베이스를 쓸 수 없었다.

다른 데이터 제품도 영향을 받았다. 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" 지표가 치솟았다.

엔지니어들은 장애 전날인 10월 4일 21:45 에 us-central1 가상 네트워크 컨트롤 플레인이 느리다는 알림을 받았지만, 처음 조사에서는 느려짐이 간헐적이었다. 10월 5일 02:11 에 가상 네트워크 라우터 컨트롤러가 메모리를 다 써서 실패한다는 알림이 왔고, 엔지니어들은 먼저 메모리를 더 할당하는 방법으로 완화하려 했다. 메모리 증가가 관리 플레인 변경의 배포와 연결된 것은 08:22 에야 밝혀졌다.

증상 패킷 손실네트워크 도달 불가OOMKilled오래된 엔드포인트 라우팅클러스터·노드 생성 정체

원인

원인 배포 결함

구성 요소 네트워크 컨트롤 플레인클라우드 로드 밸런서
기여 요인 과도한 영향 범위한계 경보 부재
촉발
관리 플레인의 동작 변경이 us-central1 에 배포됐다. 이 변경은 로드 밸런서 백엔드로 쓰는 GCP Instance Group 과 Network Endpoint Group 의 API 업데이트 처리를 더 잘 분리하려는 것이었다. 이 리전의 큰 워크로드 규모 때문에 가상 네트워크 라우터 컨트롤 플레인의 메모리가 예상 밖으로 늘었다.

감지

엔지니어들은 10월 4일 미국 태평양 시간 21:45 에 us-central1 가상 네트워크 컨트롤 플레인이 느리다는 알림을 받았고, 10월 5일 02:11 에 가상 네트워크 라우터 컨트롤러가 메모리를 다 써서 실패한다는 알림을 받았다. 03:08 부터는 네트워크 텔레메트리가 us-central1 을 오가는 리전 간 패킷 손실을 보여 주었다.

조치

후속 조치

교훈

–

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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