IL-0396 Google Cloud · 2017-01-30gcpnetworking
새로 만들거나 라이브 마이그레이션한 GCE 인스턴스, Cloud VPN 터널, 네트워크 로드 밸런서가 2시간 8분 동안 공인 IP 주소로 연결되지 않았다
GCE 인스턴스, 로드 밸런서, VPN 터널로 들어오는 네트워크 트래픽은 모두 여러 자원이 함께 쓰는 layer 2 load balancer 를 지난다. 이 로드 밸런서에 자원의 IP 주소 변경을 넣으면, 먼저 canary 배포로 자동 시험하고 그다음 전 세계로 퍼뜨린다. 2017년 1월 30일 드물게 쓰는 로드 밸런싱 구성에 대량의 변경이 들어갔고, 이 변경이 비효율적인 코드 경로를 드러내 canary 가 타임아웃됐다. 그 뒤로 들어온 모든 공인 주소 변경은 시험 단계를 넘지 못한 이 변경이 끝나기를 기다리며 쌓였다. 그래서 그동안 만들거나 라이브 마이그레이션한 GCE 인스턴스, Cloud VPN 터널, GCE 네트워크 로드 밸런서는 공인 IP 주소로 닿을 수 없었고, 밖으로 나가는 트래픽과 로드 밸런싱 헬스 체크도 실패했다.
엔지니어는 네트워크 로드 밸런서에 변경을 반영하는 작업을 재시작했다. 재시작 뒤 문제의 변경은 한 묶음으로 처리되면서 비효율적인 코드 경로를 타지 않았고, 변경이 다시 처리되면서 트래픽이 정상으로 돌아왔다. 이 조치는 11:36 부터 12:42 까지 존마다 차례로 적용됐다. 2월 8일에 올린 보고서 본문은 영향 시간을 10:36 부터 12:42 PDT 까지 2시간 8분으로 적었다. 반면 상태 페이지 맨 위의 사고 정보에는 사고가 10:54 에 시작해 12:50 에 끝났다고 적혀 있었다.
- 심각도
- –
- 영향 범위
- GCE instances, Cloud VPN tunnels and GCE network load balancers created or live migrated between 10:36 and 12:42 PDT were unreachable on public IPs and could not send outbound traffic; existing resources were unaffected
- 영향 사용자
- –
- 지역
- all GCE regions; europe-west1 was the last to clear
- 감지까지
- –
- 복구까지
- 2h 8m
증상
2017년 1월 30일 새로 만든 GCE 인스턴스에 네트워크 연결이 되지 않았다. 라이브 마이그레이션 중인 인스턴스, 새로 만든 Cloud VPN 터널과 GCE 네트워크 로드 밸런서도 공인 IP 주소로 닿을 수 없었다. 이미 만들어져 있고 라이브 마이그레이션을 겪지 않은 인스턴스, 로드 밸런서, VPN 터널은 영향이 없었다.
영향을 받은 인스턴스는 밖으로 나가는 트래픽도 보내지 못했고, 로드 밸런싱 헬스 체크도 통과하지 못했다.
상태 페이지는 11:13 에 조사 중이라고 처음 알렸다. 11:40 에는 문제가 10:54 에 시작됐고 완화 작업 중이라고 알렸다. 12:07 에는 대부분의 GCE 리전에서 완화됐다고 했다. 12:40 에는 europe-west1 을 뺀 모든 리전에서 완화됐지만 새 VPN 은 아직 영향을 받는다고 했다. 마지막 공지는 새 인스턴스는 12:45 에, VPN 은 12:50 에 완전히 완화됐다고 했다.
원인
원인 소프트웨어 결함
- 촉발
- 드물게 쓰는 로드 밸런싱 구성에 대량의 변경이 들어갔다. 이 변경이 비효율적인 코드 경로를 타면서 canary 배포가 타임아웃됐다.
감지
–
조치
- 네트워크 로드 밸런서에 변경을 반영하는 작업을 재시작했다. 재시작 뒤 문제의 변경이 한 묶음으로 처리되면서 비효율적인 코드 경로를 타지 않았고, 변경이 다시 처리됐다.
- 이 조치를 11:36 부터 12:42 까지 존마다 차례로 적용했다.
후속 조치
- canary 타임아웃을 늘려, 비효율적인 코드 경로를 타는 변경이 네트워크 변경을 완전히 멈추지 않고 늦추기만 하게 한다.
- 비효율적인 코드 경로를 개선한다.
- 더 넓은 범위의 구성에서 동작을 확인하는 테스트를 새로 쓴다.
- 주소 구성을 전 세계로 퍼뜨리는 방식을 분산 라우팅으로 바꾸는 작업을 앞당겨, 이 계층의 문제가 전 세계에 영향을 주지 않게 한다.
- 이런 문제를 더 빨리 알아보고 더 빨리 해결할 수 있도록 지표와 알림을 더 만든다.
교훈
–
출처
- https://status.cloud.google.com/incident/compute/17003 · official-status · 보관본
관련 사례
같은 원인 · 공통 네트워크 컨트롤 플레인, 클라우드 로드 밸런서
IL-0150DynamoDB DNS 자동화의 경쟁 조건이 us-east-1 리전 엔드포인트의 DNS 레코드를 비워 DynamoDB 와 EC2 인스턴스 시작이 실패했고, 그 여파로 EKS, ECS, Fargate 의 컨테이너 시작과 클러스터 스케일링이 14시간 넘게 막혔다Amazon Web Services · 2025같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 네트워크 컨트롤 플레인
같은 원인 · 공통 네트워크 컨트롤 플레인
IL-0131새로운 형태의 GenerateContent 요청이 Vertex AI 예측 API 서버에 세그폴트를 일으켰고, 동시에 재시작하는 서버가 늘자 서빙 용량이 모자라 여러 리전에서 오류가 치솟았다.Google Cloud · 2024같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 클라우드 로드 밸런서
IL-0243Google External Proxy Load Balancing 뒤의 HTTP/S 엔드포인트가 전 세계에서 Google 404 오류를 냈다Google Cloud · 2021같은 원인 · 공통 클라우드 로드 밸런서
IL-0106잘못된 IngressRoute 매니페스트가 Traefik v2 버그를 건드려 Traefik 파드가 모두 재시작된 뒤 Kubernetes 의 모든 서비스가 404 를 냈다DFDS · 2021같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 클라우드 로드 밸런서
IL-0222유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다.Google Cloud · 2019같은 원인 · 공통 네트워크 컨트롤 플레인
같은 원인 · 공통 클라우드 로드 밸런서
IL-0338Google Cloud 의 HTTP(S) 로드 밸런서와 TCP/SSL Proxy 로드 밸런서가 32분 동안 요청의 33~87% 에 502 나 연결 재설정을 냈다Google Cloud · 2018같은 원인 · 공통 클라우드 로드 밸런서
IL-0395Google Cloud HTTP(S) Load Balancer 가 한참 오래된 구성으로 되돌아가 요청의 25%가 22분 동안 502 오류로 실패했다Google Cloud · 2017같은 원인 · 공통 클라우드 로드 밸런서
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0396
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0396/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.