사례3건

3건 중 1~3번째

1. IL-0366 us-central1 의 Cloud Storage 업로드와 쓰기가 이틀에 걸쳐 18시간 넘게 느려지고 실패했다

   Google Cloud2026

   증상

   us-central1 리전에서 Cloud Storage 업로드와 쓰기 요청의 지연과 오류율이 올라갔다. 고객은 주로 WriteObject 작업에서 HTTP 503 UNAVAILABLE 오류와 클라이언트 쪽 타임아웃을 봤다.

   지연 시간 증가오류율 상승부하 불균형

   촉발

   Cloud Storage 부하 분산 계층에 트래픽 정렬 최적화 설정 업데이트가 배포됐다. 이 설정은 용량을 보고 경로를 정하는 표준 로직을 의도치 않게 건너뛰었다.

   원인

   설정 변경

   구성 요소

   오브젝트 스토리지데이터베이스

   기여 요인

   여유 용량 부재장애 중첩

   감지

   Google 엔지니어링 팀이 시스템 텔레메트리를 지켜보다가 10월 8일 04:50에 문제를 처음 알아챘다. 장애가 시작되고 50분 뒤였다.

   조치

   • 부하가 가장 큰 스토리지 백엔드 노드를 골라 트래픽을 뺐다.
   • 트래픽 정렬 최적화를 끄는 설정 변경을 배포해 스토리지 백엔드의 자원 부담을 크게 줄였다.
   • 같은 시기에 난 메타데이터 문제를 막으려고 메타데이터 데이터베이스 서비스의 최근 업데이트를 롤백했다.
   • 부하 불균형이 다시 일어나자 트래픽을 더 돌리고 영향받은 스토리지 구성 요소에서 트래픽을 뺐다.
   • 문제의 부하 분산 설정 변경을 완전히 되돌려 용량을 보고 경로를 정하던 이전 동작을 되살렸고, 트래픽이 리전 전체에 고르게 퍼졌다.
   • 트래픽과 자원 사용률이 평소 수준으로 돌아온 뒤 트래픽을 뺐던 노드를 다시 서비스에 넣었다.

   후속 조치

   • 부하 분산 로직 변경은 사용률이 높은 큰 리전에 내보내기 전에 더 작은 다른 리전에서 먼저 엄격하게 검증하도록 배포 절차를 바꾼다.
   • 스토리지 부하 분산 구조가 용량 제약을 반드시 지키게 한다. 트래픽 분배 로직이 Google 이 pre-spilling 이라고 부르는 안전장치를 건너뛰어 처리 자원이 모자란 클러스터로 트래픽을 보내는 일이 없게 한다.
   • 사용률이 높은 스토리지 셀 안의 내부 데이터 이동을 빠르게 해, 일시적인 부하 급증을 더 잘 견디게 한다.

   사례 보기
2. IL-0293 us-central1 의 Cloud Bigtable 에서 지연과 연결 오류가 32시간 동안 이어졌다

   Google Cloud2023

   증상

   2023-12-04 19:50 US/Pacific 부터 us-central1 의 Cloud Bigtable 고객이 지연 증가와 낮은 수준의 연결 오류를 겪었다. 데이터플레인 요청의 약 0.06% 가 영향을 받았고, 자동 모니터링이 23:35 에 처음 잡아냈다.

   지연 시간 증가오류율 상승패킷 손실간헐적 연결 실패

   촉발

   Cloud Bigtable 서버를 돌리는 머신에 들어간 변경 하나 때문에 격리가 실패했다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   –

   감지

   2023-12-04 23:35 US/Pacific 에 자동 모니터링이 처음 잡아냈고 엔지니어가 바로 조사를 시작했다.

   조치

   • 12월 5일 14:40 에 영향받은 머신 일부에서 트래픽 일부를 다른 곳으로 돌려 영향을 일부 줄였다.
   • 격리 문제를 일으킨 변경을 찾아 롤백했고, 12월 6일 03:55 에 지연이 완전히 풀렸다.

   후속 조치

   • 같은 장애가 다시 나지 않도록 통제 장치를 둔다.

   사례 보기
3. IL-0292 App Engine Memcache 가 글로벌 설정을 읽지 못해 모든 리전에서 1시간 50분 동안 멈췄다

   Google Cloud2017

   증상

   2017-11-06 12:33 US/Pacific 부터 App Engine Memcache 를 모든 리전의 애플리케이션에서 쓸 수 없었다. Google 은 12:34 에 자동 알림을 받았고, 상태 페이지는 Memcache 를 쓰는 모든 프로젝트가 영향을 받는다고 알렸다.

   서비스 중단데이터베이스 과부하지연 시간 증가오류율 상승

   촉발

   설정 업데이트 뒤 애플리케이션과 데이터센터의 매핑 설정을 담은 글로벌 데이터베이스의 엔티티를 읽을 수도 쓸 수도 없게 됐다.

   원인

   설정 변경

   구성 요소

   인메모리 캐시데이터베이스

   기여 요인

   롤백 무효과도한 영향 범위

   감지

   Google 은 장애가 시작된 1분 뒤인 12:34 US/Pacific 에 자동 알림을 받았다.

   조치

   • 14:21 에 데드라인을 충분히 길게 준 업데이트 요청으로 설정을 고쳤다. 데이터베이스의 모든 복제본이 동기화되고 클라이언트가 매핑 설정을 다시 읽을 수 있게 됐다.
   • Memcache 로 보내는 트래픽을 천천히 다시 늘렸고 오류율이 줄어들었다.

   후속 조치

   • 임시 완화로 글로벌 설정을 읽는 쪽의 수를 줄여 쓰기 때 경합이 생기지 않게 한다.
   • 이 설정을 리전 단위로 나눠 비슷한 실패가 번지는 범위를 줄인다.

   사례 보기

원인별2