▲

Google Cloud 장애 보고서 – 2025-06-13

 (status.cloud.google.com)
2P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • 2025년 6월 12일, Google Cloud와 Google Workspace 서비스에서 외부 API 요청 중 503 오류가 전 세계적으로 증가함
  • 오류 원인은 Service Control 시스템의 코드 변경과 정책 데이터에 빈 필드가 포함된 잘못된 정책 반영임
  • 핵심 바이너리의 에러 처리 미흡과 기능 플래그 미적용 등이 문제 확산을 키웠음
  • 복구는 2~3시간이 소요되었으며, us-central-1 지역은 인프라 과부하로 더 긴 복구 시간 발생함
  • Google은 아키텍처 분리, 에러 처리 개선, 데이터 검증 강화 등 재발 방지 대책을 발표함

전체 장애 개요

Google Cloud 및 Google Workspace 서비스 장애 요약

  • 2025년 6월 12일 오전 10시 49분(PDT)부터, Google Cloud, Google Workspace, Google Security Operations를 포함하는 여러 서비스에서 외부 API 요청에 대해 503 오류가 급증하는 현상 발생함
  • 고객 서비스와 신뢰에 심각한 영향을 주었음에 대해 Google 측은 깊은 사과 의사를 밝힘
  • Google API 관리 및 제어 플레인은 각 요청의 정책 및 쿼터 체크를 담당하며, 핵심 체크 시스템은 ‘Service Control’이라는 바이너리로 동작함

장애 원인 분석

변화된 시스템 구조 – Service Control

  • 2025년 5월 29일, Service Control에 쿼터 정책 검사를 강화하는 신규 기능이 추가됨
  • 지역별로 단계적 출시를 진행했으나, 문제의 코드는 정책이 실제로 반영되었을 때만 동작하며, 기존에는 트리거되지 않아 사전 테스트가 미흡했음
  • 해당 신기능 경로에 적절한 에러 처리와 기능 플래그가 부재하여, null 포인터 상황에서 바이너리가 연쇄적으로 크래시됨

장애 발생 경위

  • 2025년 6월 12일 오전 10시 45분(PDT), 정책 변경이 Regional Spanner 테이블에 삽입됨
  • 이 정책 데이터에는 의도하지 않은 빈 필드(Blank Field) 가 포함되어 있었으며, 이것이 전 세계적으로 거의 실시간 복제됨
  • Service Control이 이 정책을 처리하면서 null 포인터에 의한 크래시가 발생, 각 지역 인스턴스가 전역적으로 Crash Loop에 빠짐
  • 2분 만에 SRE팀이 인지를 시작했고, 10분 내에 원인을 파악 후 임시로 바이너리 경로를 차단(red-button), 40분 만에 대부분의 지역은 복구됨

추가 복구 이슈

  • 일부 대형 지역(us-central-1)은 Service Control 태스크 재시작 시 herd effect로 인프라(Spanner 테이블)가 과부하됨
  • Service Control이 무작위 지수적 백오프를 적용하지 않아 인프라 부담 가중됨
  • 해당 지역은 2시간 40분까지 복구 지연, 트래픽 우회 등으로 영향 최소화했으며, 전체적으로 서비스 복구 완료됨

고객 영향 및 장애 범위

  • 고객은 API 및 사용자 인터페이스 접속 장애 발생, 스트리밍 및 IaaS 리소스에는 영향 없음
  • 지연 및 백로그 영향은 최대 1시간 이상 일부 서비스에서 지속
  • 장애 영향을 받은 Google Cloud와 Google Workspace 제품 리스트가 광범위하게 제시됨
    • 예: IAM, Cloud Build, Cloud Storage, BigQuery, AppSheet, Gmail, Google Drive 등 수십여 개 서비스

향후 개선 방안

  • 서비스 아키텍처를 모듈화하여 각 기능 분리 및 장애 발생시 개방형(fail open) 처리 도입
  • 글로벌 데이터 복제 단계적 전파 및 실질적인 검증 과정 강화
  • 모든 주요 바이너리 변경 시 기능 플래그화 및 기본 비활성 처리 적용 정책 개편
  • 정적 분석과 테스트 개선을 통해 에러 감지 및 장애 시 fail open 가능하게 설계 검토
  • 무작위 지수적 백오프 정책 및 모니터링/커뮤니케이션 신뢰도 강화 예정
  • 장애 상황에서도 고객에게 신속하게 모니터링 및 정보 전달이 가능하도록 인프라 이중화와 자동화 커뮤니케이션 보완

장애 공지 및 커뮤니케이션

  • 사고 후 1시간 이내에 Cloud Service Health에 공지하였으나, 모니터링 인프라 자체도 장애 발생
  • 일부 고객은 Google Cloud 기반의 모니터링 시스템 자체가 정상 작동하지 않아 장애 신호 및 영향 파악 곤란함
  • Google은 향후 모니터링 및 대고객 커뮤니케이션 인프라 강화를 약속함

주요 장애 타임라인 (미니 리포트 요약)

  • 장애 시작: 2025년 6월 12일 10:49 (PDT)
  • 대부분 지역 복구: 2025년 6월 12일 12:48 (PDT)
  • 장애 종료: 2025년 6월 12일 13:49 (PDT)
  • 총 소요: 약 3시간
  • 영향 지역: 전세계

사후 대책 요약

  • API 관리 플랫폼의 데이터 오류나 손상 시 실패 방지 장치 마련 예정
  • 글로벌 메타데이터 전파전 검증·테스트·모니터링 강화
  • 유효하지 않은 데이터에 대한 시스템 에러 처리 및 종합 테스트 확대

영향 서비스 리스트 (발췌)

Google Cloud 주요 서비스

  • Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, BigQuery, Vertex Gemini API, Cloud Firestore, Looker, Cloud Run, Compute Engine 등

Google Workspace 주요 서비스

  • AppSheet, Gmail, Google Drive, Google Meet, Docs, Chat, Calendar 등

결론

  • 이번 장애는 정책/쿼터 관리 시스템 구조, 데이터 무결성 검증 부족, 에러 처리 체계 부재가 복합적으로 작용한 문제임
  • Google은 아키텍처 레벨에서의 개선 및 장애 대응력 강화를 약속함
▲
kunggom 1일전  [-]

GN+가 아닌 버전 글 링크입니다.

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 내부자 입장이라 임시 계정 사용 중임, 이번 사고의 근본 원인은 리더십이 속도를 내기 위해 원칙을 무시한 것임, 이런 관행이 수년 동안 지속되어 결국 한계에 도달하게 됨, 이번에 일어난 ‘query of death’는 서버가 특정 쿼리로 인해 크래시 나는 오래된 C++ 서버에서 불가피하게 발생하는 전형적인 실패 유형임, Service Control은 C++로 작성되었고 다양한 엔지니어링 가이드라인을 활용해 이런 실패를 최소화하려고 노력했음, 10년 동안 큰 사고 없이 운영되었으나 최근 리더십 압박 아래 빨리 만든 글로벌 쿼터 정책이 문제였음, 이런 신규 기능은 별도 서비스로 개발하거나 최소한 기존 가이드라인을 준수했어야 함, 공식 보고서에 언급된 대책보다 팀이 원래 지켜온 표준이 훨씬 높음, 팀은 할 수 있는 한 기존 기준을 유지하려고 노력하고 있음

    • 모든 책임을 리더십에만 돌릴 수 없음, 글로벌 전체 반경으로 배포를 극도로 신중히 검토하지 않은 것은 엔지니어링 문화의 실패임, 최소한 글로벌 정책은 지역별 서비스 컨트롤 배포보다 먼저 진행했어야 함

  • 사고 보고서가 흥미롭다는 생각임, SRE 팀이 2분 만에 빠르게 대응하고, ‘red button’ 롤아웃이 시작됐음, 문제는 us-central-1처럼 대규모 리전에서 Service Control 태스크가 재시작될 때 인프라(Spanner 테이블)에 과부하가 걸리는 ‘herd effect’가 나타났다는 점임, Service Control에 무작위 지수 백오프가 구현되어 있지 않아 2시간 40분까지 완전한 복구가 지연됨, 이런 상황에서는 정상적인 쿼터가 빨리 초과되며 새로운 장애로 이어짐, 이런 경우 인프라가 견딜 수 있다면 쿼터를 임시로 중단하거나 복구 작업을 느리게 제한하는 것도 좋다고 생각함

    • 이 상황에서는 지수 백오프가 적합한 대책이 아니었음, 서버 시작 시 중요한 데이터를 읽을 때 의도적으로 재시도 없이 처리되므로 백오프 적용이 안 됨, 더 좋은 방법은 기존에 존재하는 백업 데이터베이스로 부하를 빠르게 분산하는 것임, 다른 방법도 있음

  • 이건 정말 아마추어 같은 실수라는 생각임, NPE, 에러 핸들링 없음, 지수 백오프 없음, 테스트 커버리지 없음, 스테이징 환경에서 테스트 없음, 점진적 롤아웃 없음, 모두 심각한 실패임, SRE 책에 이미 다 나와 있는 내용임 Google SRE Book 목차, Building Secure and Reliable Systems TOC, 기준이 너무 낮아진 것인지 아니면 책이 그냥 마케팅 용인지 궁금함

    • 내 생각에는 인간이든 자동화든 방어책에 완벽함이란 없으며, 결국 트레이드오프의 연속임, 아무리 많은 유닛 테스트와 통합 테스트, 정적 분석, 순차적 배포를 해도 규모가 커지면 예기치 못한 빈틈이 생길 수밖에 없음, 책에서 말하는 “또 다른 9를 추가하는 데 훨씬 더 많은 노력이 드는 것”과 동일한 이유임, 최악의 경우 전체 스택을 복제해서 수개월치 트래픽을 모두 재생해야 할 수도 있는데, 이런 수준의 비용/혜택은 아무도 감당하지 못함, OpenZFS 작업에서도 코드 자체는 정상적으로 보였지만 10년 전에 쓰여진 데이터 엣지 케이스에서 문제가 드러난 경험 있음, 시스템이 충분히 복잡해지면 모든 변형을 테스트하는 건 불가능해지므로 현실적으로 비용 대비 효용을 기준으로 결정할 수밖에 없음, 참고로 구글 SRE지만 이 사건과는 관련 없는 팀이며 개인 의견임

    • 거의 모든 구글 글로벌 장애가 이와 비슷하게 전개됨, 즉 빠르게 글로벌로 배포된 맞춤 시스템이 잘못된 설정을 반영받음, 일반적인 바이너리 롤아웃이나 설정 푸시에선 점진적 롤아웃이 적용되는 게 보통임, 구글 클라우드에서도 예전엔 다양한 시스템이 글로벌로 묶여 있었으나 이젠 상당히 지역화되고 신뢰성이 높아짐, 이전에는 글로벌 장애가 종종 있었지만 공개되지 않아 대부분 사용자들은 자신의 ISP 문제로 인식했었음, 현재가 특별히 악화되고 있다고 생각하지 않음, 추가로 SRE 경험 있음

    • 외부인 입장에서 생각해보면 대규모 구조조정, CEO의 '게으름' 발언 등 이후로 모두 품질보다는 속도와 가시적 성과에 치중하게 됨, 점차 이런 문화를 문제 삼으면 되려 배척 받는 환경 변화가 생김

    • 더 자세한 정보가 공개되었으면 함, 본인은 여기에 언급된 대로 테스트가 안 된 게 아니라, 정책의 빈 필드(문제 되는 입력)에 대한 테스트가 없었다고 봄, 스테이징 환경에서 테스트가 없다는 설명도 아니고, 플래그가 있었다면 잡았을 것이란 언급임, 개인 의견임

    • “가장 위험한 도구도 익숙해지면 조심성을 잃고, 지침이 불필요하게 엄격하다고 여기게 된다”는 1864년 화약창고 보고서가 생각남

  • 나는 Cloud 내 다른 팀 소속임, 일반적으로 모든 코드엔 유닛 및 통합 테스트가 있음, 바이너리나 설정 변경은 작업별, 지역별로 며칠에 걸쳐 점진적으로 이루어짐, 카나리아 분석도 동반함, 심지어 롤백도 너무 급하게 하면 오히려 상황 악화 가능성 있어 천천히 진행함, 예를 들어 전역 데이터베이스를 일시에 과부하시키기보단 40분 정전이 4시간 장애보다 낫다고 판단함, 이번 사고에 직접 관여하지 않았지만 PM을 보면 코드는 테스트되었으나 이 엣지 케이스는 누락된 것임, 쿼터 정책 설정이 바이너리나 설정 파일이 아닌 데이터베이스 업데이트로 적용되어 전세계 모든 데이터베이스에 몇 초 만에 변경이 번진 것이 문제임, 널 포인터 문제는 다른 언어에도 assert()로 발생했을 가능성이 있음, 이런 핵심 서비스를 다른 언어로 재작성하는 위험보다 모든 정책 점검에 플래그 가드 적용, 쿼터 정책 점검은 오픈 실패, DB 변경을 지역별로 천천히 확산시키는 쪽이 더 합리적임, 개인 의견임

    • assert는 정책적으로 금지하기 훨씬 쉬운 구조임

    • 코드는 테스트됐지만 이 엣지 케이스는 누락된 거니까, 결국 테스트 안 한 셈이라는 반론임

    • DB 변경이 바이너리나 설정 변경이 아니라고 해서 문제가 달라지는 건 아님, 변경 자체가 동시에 전역에 퍼지면 어떤 종류든 재앙의 씨앗임, Crowdstrike 사태와 똑같은 흐름임

    • “언어를 바꿔 재작성하는 게 위험 부담이 너무 높다”는 의견이라면, 즉 서비스 요구사항이 제대로 파악되어 있지 않거나, 서비스가 신중한 마이그레이션이 필요할 만큼 중요하지 않은 것인지 궁금

  • 적절한 에러 핸들링 없이 널 포인터로 바이너리가 크래쉬 됐다는 내용임, 이쯤이면 '트릴리언 달러 실수'라는 농담이 나올 만함

    • 이번 사고로 몇 개의 SLA를 한 해 동안 날려버렸을지 궁금함

    • 이런 문제를 막아줄 언어가 있었다면 하는 생각에 /s(비꼬는 투)임

  • Service Control(Chemist)이 꽤 오래된 서비스이며, 여러 GCP API에서 인증, 권한, 감시, 쿼터 등 핵심적 역할을 함, 요청 흐름상 대부분의 GCP API가 Chemist를 경유함(그래서 fail open 완화책이 실효적이지 않다고 봄), Chemist와 프록시 모두 C++로 작성되어 있으며 수년간 레거시 코드가 많이 쌓였음, 각 팀은 정적 분석, 테스트, 점진적 배포, 피처 플래그, red button, 강력한 모니터링 및 경보시스템을 갖추고 있음, 특히 SRE팀은 뛰어남, Chemist에서 IAM, 쿼터 등 다양한 정책을 검증하다 보니 여러팀이 코드베이스에 기여함, 변경할 때마다 Chemist 승인 과정을 거치지 않으려고 단축 경로로 개발한 부분이 많아짐, 최근엔 조직 개편과 오프쇼어가 많아서 L8/L9급 주도 화려한 신규 프로젝트에 치중, 정작 품질·유지보수·신뢰성은 후순위가 되었음(이런 문화 변화 때문에 Cloud에서 떠났음), 구글 일반 서버/서비스 모범 사례가 여기선 지켜지지 않을 때가 많음, 이번 이슈는 코드와 코드리뷰의 부실 쪽에 가까움, 결함이 있던 코드를 승인하고 Spanner로 설정 변경을 즉시 반영시켜 문제가 커짐

  • 서비스 정책 데이터에 의도치 않은 빈 필드가 포함되었고, Service Control이 각 리전별로 쿼터 체크 시 빈 필드(널)를 읽어 예외가 발생했음, Hoare의 ‘십억 달러 실수’가 여러 구글 시스템에서 반복된 예시임, 애초에 이런 ‘빈 필드’(null)가 들어갈 수 있도록 허용한 게 문제인데, 스키마에서 null 불허(‘NOT NULL’)를 명시했어야 함, 불행히도 Spanner에서 기본값이 nullable이라 별도 지정 필요, 앱 코드 레벨에서 타입 시스템이나 스키마 언어를 통해 유효하지 않은 상태가 불가능하도록 설계할 기회가 또 있었음, 데이터스토어에서 앱 객체로 역직렬화하면서 스키마 강제 검증을 추가하는 방법도 있음, 본문 이슈가 새로운 코드 경로에서 터진 만큼 데이터 계층에서 걸러지지 않은 게 아닌가 싶음, Service Control 프로그램 자체가 널 포인터 참조를 허용하는 언어로 작성된 것도 문제임, 만약 내가 관리 담당자라면, 정책을 앱 코드에서 ‘태그드 enum 타입’ 등 null을 표현할 수 없는 구조로 바꾸는 최소 개입 플랜을 생각해보겠음, proto3에는 이런 제약이 없으나, 이런 예시는 있음

  • 멀티리전이 회복력과 가용성 수단으로 자주 언급되지만, 실제로는 장애 상황에서 대형 클라우드 제공자도 리전 간 강하게 얽혀 있다는 게 흥미로움

    • 이건 특히 GCP에서 두드러지는데, GCP는 리전을 타사보다 다르게 다룸, 회복성 관점에선 GCP를 다수 존이 묶인 단일 리전처럼 봐야 함

    • 그럼에도 불구하고 “우리가 모르는 장애”는 여전히 있을 수 있으므로 리전/존 샤딩의 효과를 지나치게 과소평가하면 곤란함

    • 멀티리전 배포 덕에 사고를 예방한 사례도 많으니 실제로 그런 케이스를 파악한 후 결론을 내리는 게 맞음

  • 구글 포스트모템의 디테일에 늘 놀람, 회사 안팎 모두에서 느껴짐, 실수 반복하지 않도록 배우고, 프로토콜과 에러 핸들링 보강해 더욱 강인한 시스템으로 진화함, 구글처럼 규모가 큰 곳에선 항상 무언가가 잘못되고 있지만 핵심은 고객/사용자와 다른 시스템에 영향 가지 않게 차단하는 것임, 내부에 있더라도 팀에 따라 보이지 않는 이슈가 다양함, 이는 인간이 만든 시스템 중 가장 복잡한 축에 속한다고 봄, AGI가 아니라면 인간이 더 잘할 수 없는 영역임

    • 하지만 이번 사고엔 주니어급 실수가 연달아 일어남, null 데이터 처리를 못 한 점, 테스트 부족, 신기능에 대한 테스트 커버리지 없음, 전면 배포 전 소규모 프로덕션에서 검증하지 않은 점 모두 문제임, 10년 전 구글에서라면 이런 실수에 다들 비웃었을 거라고 확신함

    • 내 이해로는 이번 장애 원인은 1) 전역적 기능이 한번에 전체 배포됨 2) 널 포인터 역참조 발생 3) 적절한 재시도 정책 부재로 'thundering herd' 문제 야기, 모두 업계 사람이라면 익숙한 실수임, 신기하거나 복잡한 분산 시스템 로직이 아니라 전형적인 ‘초보 실수’가 복합적으로 터진 셈임

    • “다시는 같은 실수 반복하지 않는다”는 말이 있지만, 실제론 피처 플래그 없이 변경을 롤아웃했고, 클라이언트엔 지수 백오프도, 서버에 로드 셰딩도 구현하지 않았음, 이 모두가 수년 전부터 google SRE book에 나온 내용임

    • 이 오류는 미처 잡지 못한 널 포인터 문제였음, 구글 정도 규모와 품질을 가진 회사가 이런 식으로 스택 대부분을 다운시키는 것은 심각한 이슈 재발 방지책이 부족하다는 신호로 읽힐 수 있음

    • 이건 수없이 반복된 동일한 실수임, “새 기능을 조심스럽게 배포하지만, 새로운 데이터가 들어와야만 드러나는 버그”가 대부분의 글로벌 장애를 요약하는 문구임, 완벽한 시스템은 존재하지 않음, FAANG 장애 논쟁에서만 무결점인 건 ‘HN의 armchair 전문가’뿐임

  • 대부분, 남의 다운타임을 볼 땐 ‘주니어급 실수’라고 쉽게 비판하지만, 정작 자기 일에선 불가피했다, 예측불가했다는 핑계가 남음, 인간 실수는 불가피하며 기대치 자체가 너무 높음, 오프라인 가게가 갑자기 문 닫아도 “죄송하다” 한마디에 끝남, 오직 IT 업계만 몇 시간짜리 장애로 과도하게 스트레스를 받는 데 모두 조금 더 여유를 갖길 바람

답변달기