IL-0395 Google Cloud · 2017-04-05gcpnetworking
Google Cloud HTTP(S) Load Balancer 가 한참 오래된 구성으로 되돌아가 요청의 25%가 22분 동안 502 오류로 실패했다
HTTP(S) Load Balancer 의 구성 갱신은 master 서버가 맡는다. master 역할이 다른 서버로 넘어가면 새 master 는 평소처럼 다음 구성을 일부 로드 밸런서에서 먼저 시험한다. 시험이 통과하면 전 세계 모든 로드 밸런서에 배포하고, 시험이 실패하면 모든 로드 밸런서를 마지막으로 정상이 확인된 "known good" 구성으로 되돌린다. 2017년 4월 5일 master 복제본 하나가 Google 분산 파일 시스템에 접근하지 못해 최근 구성 파일을 읽지 못했는데, master 역할이 바로 그 서버로 넘어갔다. 새 master 의 첫 시험이 실패했고, 구성 갱신 과정의 버그 때문에 로드 밸런서는 master 가 읽을 수 있던 가장 최근 구성으로 되돌아갔다. 그 구성은 한참 오래된 것이었다.
오래된 구성이 들어가자 Google Frontend 서버에서 삭제된 구성의 메모리를 비우는 가비지 컬렉션이 돌았다. 삭제된 구성이 많아 서버는 CPU 의 상당 부분을 가비지 컬렉션에 썼고, 헬스 체크에 실패해 재시작됐다. 재시작 중인 서버가 받은 요청은 502 오류로 끝났고, 01:13 부터 01:35 PDT 까지 22분 동안 요청의 25%가 실패했다.
엔지니어는 01:22 에 호출을 받았고 01:34 에 구성 갱신 과정이 다른 master 서버를 쓰도록 바꿨다. 대부분의 서비스는 1분 안에 회복했다. 근본 원인을 확인하는 동안 05:16 까지 구성 갱신을 멈췄고, 그동안 App Engine Flexible 앱 배포가 실패했다.
- 심각도
- –
- 영향 범위
- Google Cloud HTTP(S) Load Balancer: 25% of requests failed with 502 for 22 minutes, 100% on some recently modified load balancers; App Engine Flexible deployments failed during the 3 hours 41 minutes configuration pause
- 영향 사용자
- –
- 지역
- –
- 감지까지
- 9m
- 복구까지
- 22m
증상
2017년 4월 5일 01:13 부터 01:35 PDT 까지 22분 동안 Google Cloud HTTP(S) Load Balancer 로 들어온 요청의 25%가 실패했고, 클라이언트는 실패한 요청에 502 오류를 받았다. 최근에 구성을 바꾼 일부 로드 밸런서는 오류율이 100%였다.
502 오류는 재시작 중인 Google Frontend 서버가 받은 요청에서 났다. Google Frontend 서버는 삭제된 구성이 쓰던 메모리를 비우는 가비지 컬렉션에 CPU 를 많이 썼다. 그러다 헬스 체크에 실패했고, 결국 재시작됐다.
장애가 끝난 뒤에도 근본 원인을 파악할 때까지 3시간 41분 동안 HTTP(S) Load Balancer 구성 변경을 멈췄다. 그동안 App Engine Flexible 앱 배포가 실패했다.
원인
원인 소프트웨어 결함
- 촉발
- 구성 갱신을 맡은 master 서버의 복제본 하나가 Google 분산 파일 시스템에 접근하지 못해 최근 구성 파일을 읽지 못한 채 master 역할을 넘겨받았다. 새 master 의 첫 구성 시험이 실패하자 모든 로드 밸런서가 그 master 가 읽을 수 있던 한참 오래된 구성으로 되돌아갔다.
감지
01:22 PDT 에 Google 엔지니어가 호출을 받았다.
조치
- 01:34 에 구성 갱신 과정이 다른 master 서버를 쓰도록 바꿨고, 대부분의 서비스가 1분 안에 회복했다.
- 근본 원인을 확인하는 동안 05:16 까지 HTTP(S) Load Balancer 구성 갱신을 멈췄다.
후속 조치
- master 서버가 몇 시간 넘게 지난 HTTP(S) Load Balancer 구성은 절대 배포하지 않도록 설정한다.
- Google Frontend 서버가 몇 시간 넘게 지난 구성 파일을 읽어 들이지 않고 거부하게 한다.
- 새 HTTP(S) Load Balancer 구성을 시험하는 과정을 개선해, 오래된 구성이 운영에 배포되기 전에 잡아낸다.
- master 서버가 Google 분산 파일 시스템에서 파일을 읽다가 실패한 문제를 고친다.
- 가비지 컬렉션이 많을 때 Google Frontend 의 헬스 체크가 실패하는 문제를 고친다.
교훈
–
출처
- https://status.cloud.google.com/incident/compute/17007 · 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-0338Google Cloud 의 HTTP(S) 로드 밸런서와 TCP/SSL Proxy 로드 밸런서가 32분 동안 요청의 33~87% 에 502 나 연결 재설정을 냈다Google Cloud · 2018같은 원인 · 공통 클라우드 로드 밸런서
IL-0396새로 만들거나 라이브 마이그레이션한 GCE 인스턴스, Cloud VPN 터널, 네트워크 로드 밸런서가 2시간 8분 동안 공인 IP 주소로 연결되지 않았다Google Cloud · 2017같은 원인 · 공통 클라우드 로드 밸런서
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0395
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0395/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.