사례2건
2건 중 1~2번째
- 증상
us-central1 리전에서 Cloud Storage 업로드와 쓰기 요청의 지연과 오류율이 올라갔다. 고객은 주로 WriteObject 작업에서 HTTP 503 UNAVAILABLE 오류와 클라이언트 쪽 타임아웃을 봤다.
- 촉발
Cloud Storage 부하 분산 계층에 트래픽 정렬 최적화 설정 업데이트가 배포됐다. 이 설정은 용량을 보고 경로를 정하는 표준 로직을 의도치 않게 건너뛰었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
Google 엔지니어링 팀이 시스템 텔레메트리를 지켜보다가 10월 8일 04:50에 문제를 처음 알아챘다. 장애가 시작되고 50분 뒤였다.
- 조치
- 부하가 가장 큰 스토리지 백엔드 노드를 골라 트래픽을 뺐다.
- 트래픽 정렬 최적화를 끄는 설정 변경을 배포해 스토리지 백엔드의 자원 부담을 크게 줄였다.
- 같은 시기에 난 메타데이터 문제를 막으려고 메타데이터 데이터베이스 서비스의 최근 업데이트를 롤백했다.
- 부하 불균형이 다시 일어나자 트래픽을 더 돌리고 영향받은 스토리지 구성 요소에서 트래픽을 뺐다.
- 문제의 부하 분산 설정 변경을 완전히 되돌려 용량을 보고 경로를 정하던 이전 동작을 되살렸고, 트래픽이 리전 전체에 고르게 퍼졌다.
- 트래픽과 자원 사용률이 평소 수준으로 돌아온 뒤 트래픽을 뺐던 노드를 다시 서비스에 넣었다.
- 후속 조치
- 부하 분산 로직 변경은 사용률이 높은 큰 리전에 내보내기 전에 더 작은 다른 리전에서 먼저 엄격하게 검증하도록 배포 절차를 바꾼다.
- 스토리지 부하 분산 구조가 용량 제약을 반드시 지키게 한다. 트래픽 분배 로직이 Google 이 pre-spilling 이라고 부르는 안전장치를 건너뛰어 처리 자원이 모자란 클러스터로 트래픽을 보내는 일이 없게 한다.
- 사용률이 높은 스토리지 셀 안의 내부 데이터 이동을 빠르게 해, 일시적인 부하 급증을 더 잘 견디게 한다.
- 증상
2017-11-06 12:33 US/Pacific 부터 App Engine Memcache 를 모든 리전의 애플리케이션에서 쓸 수 없었다. Google 은 12:34 에 자동 알림을 받았고, 상태 페이지는 Memcache 를 쓰는 모든 프로젝트가 영향을 받는다고 알렸다.
- 촉발
설정 업데이트 뒤 애플리케이션과 데이터센터의 매핑 설정을 담은 글로벌 데이터베이스의 엔티티를 읽을 수도 쓸 수도 없게 됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
Google 은 장애가 시작된 1분 뒤인 12:34 US/Pacific 에 자동 알림을 받았다.
- 조치
- 14:21 에 데드라인을 충분히 길게 준 업데이트 요청으로 설정을 고쳤다. 데이터베이스의 모든 복제본이 동기화되고 클라이언트가 매핑 설정을 다시 읽을 수 있게 됐다.
- Memcache 로 보내는 트래픽을 천천히 다시 늘렸고 오류율이 줄어들었다.
- 후속 조치
- 임시 완화로 글로벌 설정을 읽는 쪽의 수를 줄여 쓰기 때 경합이 생기지 않게 한다.
- 이 설정을 리전 단위로 나눠 비슷한 실패가 번지는 범위를 줄인다.
내 클러스터에도 있는지 확인하기
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스, 인메모리 캐시. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.