Incident Library

IL-0243 Google Cloud · 2021-11-16gcpnetworking

Google External Proxy Load Balancing 뒤의 HTTP/S 엔드포인트가 전 세계에서 Google 404 오류를 냈다

고객 설정 규칙을 GCLB 로 전파하는 설정 파이프라인에 6개월 전 들어간 결함이 있었다. 이 결함은 데이터에 접근하는 시점에 따라 동작이 달라지는 경쟁 상태를 만들었다. 이 경쟁 상태 때문에 아주 드물게 손상된 설정 파일이 GCLB 로 나갔다. 파이프라인에는 손상된 설정을 막는 검증이 많았지만, 이 경쟁 상태는 파이프라인 끝 무렵에 파일을 망가뜨릴 수 있었다. 11월 12일 Google 엔지니어가 이 결함을 찾았고, Google 은 우선순위가 높은 내부 장애를 선언했다. 팀은 설정 시스템 일부를 동결해 경쟁 상태가 일어날 가능성을 더 낮췄다. 결함이 이미 몇 달 동안 있었고 Black Friday/Cyber Monday 가 가까웠으므로, 당일 긴급 패치 대신 단계를 밟아 통제하며 배포하는 쪽을 택했다. 팀은 두 패치를 만들어 11월 13일까지 검증했다. 패치 A 는 경쟁 상태 자체를 없애고, 패치 B 는 설정을 받는 바이너리에 입력 검증을 더해 손상된 설정을 받지 않게 한다. 11월 15일부터 두 패치를 단계적으로 배포했고 패치 B 는 그날 저녁 배포가 끝났다.

11월 16일 패치 A 배포가 끝나기까지 30분도 남지 않았을 때, 패치되지 않은 클러스터에서 경쟁 상태가 실제로 일어나 09:35 PT 부터 장애가 시작됐다. 실제 경쟁 상태가 만든 설정 오류는 시험에서 본 입력 오류와 모양이 달라, 배포를 마친 패치 B 도 그 설정을 막지 못했다. 엔지니어들은 09:50 PT 에 자동 알림을 받았고 고객 지원 요청도 같은 시각에 들어왔다. 곧바로 마지막으로 정상이던 설정으로 롤백했고, 10:08 PT 에 롤백이 끝나 404 오류가 멈췄다. 재발을 막으려고 10:04 PT 부터 고객이 요청하는 GCLB 설정 변경을 멈췄고, 그동안 수정을 검증하고 감시를 더했다. 11:28 PT 에 고객 설정 배포를 다시 열어 서비스가 정상으로 돌아왔다. 영향은 모두 1시간 53분 이어졌다.

심각도
–
영향 범위
HTTP/S endpoints behind Google External Proxy Load Balancing returned 404 errors, including Cloud Run, App Engine, App Engine Flex, Cloud Functions, Apigee and Firebase behind GCLB; load balancer configuration changes did not take effect until 11:28 PT
영향 사용자
–
지역
Global; the preliminary report lists us-central, europe-west1 and global
감지까지
15m
복구까지
1h 53m

증상

2021년 11월 16일 09:35 PT 부터 Google External Proxy Load Balancing, 줄여서 GCLB 를 쓰는 고객의 HTTP/S 요청이 Google 404 오류를 받았다. 전역 GCLB 로드 밸런서가 서비스하는 엔드포인트 대부분이 웹 페이지 대신 404 오류 페이지를 냈다.

GCLB 를 프런트엔드로 쓰는 다른 서비스도 같은 404 를 냈다. 서버리스 네트워크 엔드포인트 그룹으로 Cloud Run, App Engine, App Engine Flex, Cloud Functions 를 연결한 고객과 Apigee, Firebase 고객이 서비스에 접근할 때 404 오류를 받았다. Apigee 는 런타임 요청이 404 를 받았고, App Engine Flex 는 고객 배포도 실패했다.

예비 보고서에 따르면 Cloud Run 은 us-central1 에서 트래픽이 25% 줄었고, App Engine 은 us-central 과 europe-west1 에서 트래픽이 80% 줄었다.

10:08 PT 무렵 404 오류는 멈췄지만, 그 뒤 11:28 PT 까지는 External Proxy Load Balancer 의 설정을 바꿔도 반영되지 않았다. 트래픽은 흘렀지만 고객은 로드 밸런서 설정을 바꿀 수 없었고, 이 상태가 1시간 20분 더 이어졌다.

증상 서비스 중단오류율 상승

원인

촉발
고객 설정 규칙을 GCLB 로 전파하는 설정 파이프라인에 경쟁 상태가 있었다. 이 경쟁 상태를 없애는 패치 A 가 아직 배포되지 않은 클러스터에서 경쟁 상태가 실제로 일어나, 손상된 설정 파일이 GCLB 로 올라갔다.

감지

09:50 PT 에 자동 알림이 엔지니어들에게 울렸고, 같은 시각 고객 지원 요청도 들어오기 시작했다.

조치

후속 조치

교훈

–

출처

관련 사례

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

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

AI 도구와 스크립트용

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