사례2건

2건 중 1~2번째

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-0235 Azure OpenAI Service 의 GPT-5.2 모델 요청이 일곱 개 리전에서 HTTP 400 과 HTTP 429 오류로 실패했다

   Microsoft Azure2026

   증상

   2026-03-09 23:20 UTC 부터 Azure OpenAI Service 고객의 GPT-5.2 모델 요청이 HTTP 400 과 HTTP 429 오류로 실패했다. 다른 GPT 모델은 영향을 받지 않았다. 영향을 받은 리전은 Australia East, Central US, East US 2, Korea Central, Norway East, Sweden Central, UK South 였다.

   오류율 상승부하 불균형

   촉발

   Azure OpenAI 의 GPT-5.2 모델 업데이트에 든 구성 변경이 운영 중인 모델 엔진 코드 버전과 맞지 않았다. 업데이트가 효율과 복원력을 높이려고 일부 기능 설정을 켰는데, 배포된 엔진 버전은 그 설정을 아직 지원하지 않았다.

   원인

   설정 변경

   구성 요소

   모델 추론 서버모델 요청 라우팅

   기여 요인

   스테이징 불일치모니터링 사각지대장애 중첩

   감지

   3월 10일 00:19 UTC 에 서비스 모니터링이 문제를 잡았다. 고객 영향이 시작되고 약 1시간 뒤였다. 모니터링은 클라이언트 쪽 오류만 보고 서비스 쪽 HTTP 400 이상은 보지 않아 초기 감지가 늦었다.

   조치

   • 롤백이 핫픽스보다 빨리 완화할 수 있다고 판단하고 03:18 UTC 에 영향받은 모델의 롤백을 시작했다. 18:00 UTC 에 모든 영향 리전에서 롤백을 마쳤다.
   • 19:30 UTC 에 리전 전체의 용량 정보를 되살려 트래픽 분산을 정상으로 돌렸다.

   후속 조치

   • 비슷한 문제를 더 빨리 완화하도록 엔지니어에게 운영 절차 교육을 더 했다. 교육에는 어떤 상황에서 빠르게 롤백할 수 있는지가 들어갔다.
   • 의존 서비스가 리전 용량의 최신 정보를 주지 못할 때를 대비해, 검증된 트래픽 라우팅 정보를 캐시에 저장해 두게 했다.
   • 서비스 쪽 오류에 임계값을 두어 HTTP 400 오류 모니터링을 개선했다.
   • 평소 임계값에 닿지 않는 비정상 오류율에도 알림이 가도록 HTTP 4xx 오류의 이상 탐지를 개선한다. 2026년 4월에 마칠 예정이다.
   • 배포 시스템에 신호를 더 넣어 문제가 있는 배포를 자동으로 멈추게 한다. 2026년 5월에 마칠 예정이다.
   • Safe Deployment Practices 의 앞 단계에 백엔드 모델 인스턴스가 충분히 있게 해 이런 문제를 더 일찍 잡는다. 2026년 6월에 마칠 예정이다.

   사례 보기

원인별1