IL-0292 Google Cloud · 2017-11-06gcpdatabase
App Engine Memcache 가 글로벌 설정을 읽지 못해 모든 리전에서 1시간 50분 동안 멈췄다
App Engine Memcache 는 트래픽이 다른 데이터센터로 넘어갈 때도 강한 일관성을 지켜야 한다. 그래서 애플리케이션마다 지금 어느 데이터센터가 서비스하는지를 모든 곳에서 같은 값으로 봐야 한다. 애플리케이션과 데이터센터의 매핑 설정은 글로벌 데이터베이스에 있다. 2017-11-06 설정 업데이트 뒤 이 설정을 담은 엔티티를 읽을 수도 쓸 수도 없게 됐다. Memcache 는 20초 안에 설정을 새로 읽지 못하면 그 설정을 유효하지 않다고 보도록 만들어져 있다. 그래서 클라이언트가 설정을 가져오지 못하자 Memcache 가 멈췄다. 글로벌 설정을 읽는 쪽이 많아 쓰기 때 경합이 생긴 것이 엔티티를 쓸 수 없게 만든 원인이었다.
Google 은 12:34 에 자동 알림을 받았다. 엔지니어는 최근 변경을 찾아 12:59 에 설정 파일의 마지막 변경을 되돌리려 했지만, 이 롤백도 글로벌 데이터베이스의 설정을 고쳐야 해서 실패했다. 14:21 에 데드라인을 충분히 길게 준 업데이트 요청으로 설정을 고치자 데이터베이스의 모든 복제본이 동기화되고 클라이언트가 매핑 설정을 읽을 수 있게 됐다. Memcache 는 12:33 부터 14:23 까지 모든 리전에서 멈춰 있었다. 그동안 일부 고객은 Memcache 대신 몰린 Datastore 요청 때문에 지연과 오류를 겪었고, Managed VMs 고객은 모든 HTTP 요청과 App Engine API 호출이 실패했다. 복구 뒤에도 몰린 트래픽으로 Datastore 부하가 올랐다. 엔지니어가 Memcache 로 보내는 트래픽을 천천히 늘렸고, 15:30 에 모든 프로젝트에서 문제가 해결됐다. 임시 완화로 글로벌 설정을 읽는 쪽의 수를 줄였고, 이 설정을 리전 단위로 나누는 작업을 진행하고 있다.
- 심각도
- –
- 영향 범위
- App Engine Memcache unavailable in all regions; all HTTP requests and App Engine API calls failed on Managed VMs; higher Datastore latency and errors for some customers
- 영향 사용자
- All projects using Memcache
- 지역
- All regions
- 감지까지
- 1m
- 복구까지
- 1h 50m
증상
2017-11-06 12:33 US/Pacific 부터 App Engine Memcache 를 모든 리전의 애플리케이션에서 쓸 수 없었다. Google 은 12:34 에 자동 알림을 받았고, 상태 페이지는 Memcache 를 쓰는 모든 프로젝트가 영향을 받는다고 알렸다.
Memcache 가 멈춘 동안 일부 고객은 Datastore 지연과 오류가 늘었다. Memcache 가 실패한 애플리케이션이 특정 엔티티나 키 범위로 Datastore 작업을 몰아 보내면 Datastore 에서 경합이나 핫스팟이 생길 수 있었다.
Managed VMs 를 쓰는 고객은 장애 내내 모든 HTTP 요청과 App Engine API 호출이 실패했다. 후속 제품인 App Engine Flexible Environment 는 영향을 받지 않았다.
장애가 끝난 14:23 에는 트래픽이 몰리며 Datastore 서버 부하가 올랐다. 미국의 일부 애플리케이션은 14:23 부터 14:31 까지 get 지연이, 14:23 부터 15:04 까지 put 지연이 늘었다. 상태 페이지는 Memcache 로 보내는 트래픽을 천천히 늘리고 있고 오류율이 줄고 있다고 알렸고, 15:30 에 모든 프로젝트에서 해결됐다고 알렸다.
엔지니어는 평소 절차대로 최근 변경부터 찾았고 12:59 에 설정 파일의 마지막 변경을 되돌리려 했다. 이 롤백도 글로벌 데이터베이스의 설정을 고쳐야 해서 똑같이 실패했다.
원인
- 촉발
- 설정 업데이트 뒤 애플리케이션과 데이터센터의 매핑 설정을 담은 글로벌 데이터베이스의 엔티티를 읽을 수도 쓸 수도 없게 됐다.
감지
Google 은 장애가 시작된 1분 뒤인 12:34 US/Pacific 에 자동 알림을 받았다.
조치
- 14:21 에 데드라인을 충분히 길게 준 업데이트 요청으로 설정을 고쳤다. 데이터베이스의 모든 복제본이 동기화되고 클라이언트가 매핑 설정을 다시 읽을 수 있게 됐다.
- Memcache 로 보내는 트래픽을 천천히 다시 늘렸고 오류율이 줄어들었다.
후속 조치
- 임시 완화로 글로벌 설정을 읽는 쪽의 수를 줄여 쓰기 때 경합이 생기지 않게 한다.
- 이 설정을 리전 단위로 나눠 비슷한 실패가 번지는 범위를 줄인다.
교훈
–
출처
- https://status.cloud.google.com/incident/appengine/17007 · official-status · 보관본
참고 문서
관련 사례
IL-0574운영 환경의 DB 접속 경로를 Amazon RDS Proxy로 바꾼 지 몇 분 만에 Aurora MySQL writer CPU가 100%에 이르고 에러가 났다Safie · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0179DEBUG 로그가 쏟아지자 동기 로깅을 하던 요청 스레드들이 가득 찬 stdout 파이프에서 멈춘 채 DB 커넥션을 쥐고 있어, HikariCP 커넥션 풀이 고갈되고 요청이 30초 주기로 한꺼번에 실패했다.MUSINSA · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0063Redis 스테이트풀셋을 다시 만들자 Redis 클러스터가 한꺼번에 재시작되며 일부가 망가졌고, 재연결 폭주로 백엔드가 OOM 으로 죽어 AdGuard VPN 이 약 50분 멈췄다.AdGuard VPN · 2025같은 원인 · 공통 인메모리 캐시
IL-0283Cloudflare 네트워크 전체에서 코어 프록시가 Bot Management 피처 파일을 읽다 실패해 사이트 방문자들이 HTTP 5xx 오류 페이지를 받았다Cloudflare · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0392데이터센터 전환을 앞두고 원형 복제를 설정하던 중 Wikimedia x1 섹션의 eqiad·codfw 사이 MariaDB 복제가 6분 멈췄다Wikimedia Foundation · 2024같은 원인 · 공통 데이터베이스
IL-0367Central US 의 Azure Storage 가 VM 디스크 요청을 거부해 VM 과 그 위의 SQL Database, Cosmos DB 가 멈췄다Microsoft Azure · 2024같은 원인 · 공통 데이터베이스
IL-0511Vault 가 새로 발급한 데이터베이스 자격 증명이 SCRAM 으로 만들어져 pgbouncer 가 RDS 에 로그인하지 못하고 xPro 운영 사이트가 멈췄다MIT Open Learning · 2023같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 인메모리 캐시
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 인메모리 캐시
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0292
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0292/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.