Google Cloud GCVE 사고 세부 사항 공개

 (cloud.google.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Google Cloud의 2024년 5월 사고는 호주 고객 UniSuper의 GCVE 환경 일부를 삭제한 사건으로, 내부 검토 후 원인과 복구 조치가 공개됨
  • 영향 범위는 한 고객·한 리전·한 서비스와 고객의 여러 GCVE Private Cloud 중 하나로 제한됐으며, 다른 고객과 Google Cloud 서비스는 영향받지 않음
  • 초기 배포 과정에서 내부 도구의 입력값 하나가 비어 있었고, 시스템이 이를 고정 1년 기간으로 처리하면서 기간 종료 후 Private Cloud가 자동 삭제됨
  • 고객과 Google 팀은 며칠간 24x7 복구를 진행했으며, GCS에 있던 백업과 서드파티 백업 소프트웨어가 복원에 활용됨
  • Google Cloud는 해당 내부 도구 폐기, 전체 GCVE Private Cloud 수동 점검, 삭제 동작 수정으로 같은 유형의 사고가 재발하지 않도록 조치함

사고 범위

  • 이번 사고는 Google Cloud 고객 UniSuper에 영향을 줬으며, Google Cloud는 고객 시스템 복구 뒤 내부 검토를 완료함
  • 영향은 Google이 관리하는 서비스 기준으로 제한됨
    • 한 고객
    • 한 클라우드 리전
    • 고객의 Google Cloud VMware Engine(GCVE) 사용
    • 고객이 보유한 여러 GCVE Private Cloud 중 두 개 존에 걸친 한 개 Private Cloud
  • 영향받지 않은 항목도 구분됨
    • 다른 Google Cloud 서비스
    • GCVE 또는 다른 Google Cloud 서비스를 쓰는 다른 고객
    • 해당 고객의 다른 GCVE Private Cloud, Google Account, Orgs, Folders, Projects
    • 같은 리전에 있는 Google Cloud Storage(GCS) 데이터 백업

원인: 내부 도구의 빈 파라미터

  • 2023년 초 Google 운영자는 특정 용량 배치 요구를 맞추기 위해 내부 도구로 고객의 GCVE Private Cloud 중 하나를 배포함
  • 이 도구는 용량 관리를 위한 예외 프로세스에 쓰였고, 2023년 4분기에 폐기·완전 자동화되어 더 이상 사람의 개입이 필요하지 않음
  • 운영자는 내부 통제 절차를 따랐지만, Private Cloud 프로비저닝 과정에서 입력 파라미터 하나가 비어 있었음
  • 빈 파라미터 때문에 시스템은 당시 알려지지 않았던 기본값인 고정 1년 기간을 해당 파라미터에 할당함
  • 시스템이 할당한 1년 기간이 끝나자 고객의 GCVE Private Cloud가 삭제됨

고객 알림이 없었던 이유

  • 삭제는 고객 요청이 아니라 Google 운영자가 내부 도구를 사용할 때 남긴 빈 파라미터에서 비롯됨
  • 고객이 직접 삭제를 요청했다면 사전 알림이 있었지만, 이번 삭제에는 고객 알림이 발송되지 않음
  • Google Cloud는 사고를 촉발한 조건과 하위 시스템 동작을 수정해 같은 일이 다시 발생하지 않도록 했다고 설명함

복구 과정

  • 고객과 Google 팀은 며칠 동안 24x7로 협력해 복구 작업을 진행함
    • 고객의 GCVE Private Cloud 복구
    • 네트워크와 보안 구성 복원
    • 애플리케이션 복원
    • 전체 운영 복구를 위한 데이터 복구
  • 고객의 견고하고 복원력 있는 아키텍처 접근이 복구를 도왔음
  • 같은 리전의 Google Cloud Storage에 저장된 데이터 백업은 삭제 영향을 받지 않음
  • 해당 백업과 서드파티 백업 소프트웨어가 빠른 복원에 중요한 역할을 함

재발 방지 조치

  • Google Cloud는 사고 재발을 막기 위해 여러 조치를 수행함
    • 사고 흐름을 촉발한 내부 도구를 폐기함
    • 특정 용량 관리가 필요하더라도 이제는 사용자 인터페이스를 통해 고객이 제어하며, 관련 부분은 완전 자동화됨
    • 시스템 데이터베이스를 정리하고 모든 GCVE Private Cloud를 수동 검토해 다른 GCVE 배포가 위험에 노출돼 있지 않은지 확인함
    • 해당 배포 워크플로에서 GCVE Private Cloud를 삭제 대상으로 설정하던 시스템 동작을 수정함
  • Google Cloud는 이번과 같은 성격의 사고가 이전에 없었고, 시스템적 문제가 아니라고 평가함
  • Google Cloud 서비스에는 필요에 따라 soft delete, 사전 알림, human-in-the-loop 조합의 보호 장치가 있으며, 해당 보호 장치가 계속 유지되고 있음을 확인함
  • 고객과의 긴밀한 협력이 빠른 복구에 중요했으며, 예상치 못한 사고에 대비한 복원력 있는 위험 관리와 fail-safe가 빠른 복구에 필수적임
  • Google Cloud는 이번 일회성 사고에도 자사 업타임과 복원력이 주요 클라우드 중 최고 수준으로 독립 검증됐다고 밝힘

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 사건의 영향 규모를 보면 개선책이 더 깊지 않아서 놀라움. 같은 문제가 같은 방식으로 재발하지 않게 한 정도가 전부라서, 나중에 어딘가에서 동등한 결함이 생기면 비슷하거나 더 나쁜 결과가 날 수 있음
    예를 들어 서비스 종료 시 바로 지우지 말고 며칠간 데이터는 보존한 채 버튼 하나로 복구 가능한 상태에 두거나, 모든 서비스의 삭제 흐름을 감사해 어떤 이유로든 종료 전에 고객에게 알리거나, 일정 규모 이상의 활성 서비스 종료에는 수동 검토를 넣었어야 함
    이런 폭넓은 조치가 없다면 이 사후 분석은 전혀 안심이 되지 않음. 이 정도로 어처구니없는 사고라면, 자기 서비스에 조금이라도 자부심이 있거나 평판을 지키려는 공급자라면 다시는 이런 일이 없도록 과할 정도로 보여줬어야 하는데, Google Cloud는 최소한만 한 것으로 보임

    • 서비스 종료 시 데이터를 즉시 지우지 않는 건 너무나 명백한 엔터프라이즈 소프트웨어 기본기라서, Google이 2024년에 이걸 갖추지 않았다는 점이 많은 걸 말해줌
      신입 시절부터도 더 이상 필요 없는 데이터를 즉시 삭제한다는 발상은 말이 안 됐음. 데이터베이스에서는 삭제 표시용 열을 두는 소프트 삭제를 쓰고, 디스크의 데이터는 정말 지워도 된다고 확신할 때까지 이동하거나 이름을 바꾸며, 그래도 백업은 남겨두는 식이 기본이었음
    • 강하게 동의함. GCP 운영자가 플랫폼을 관리하는 방식에 시스템적 문제가 없다는 점을 강조하는 데 더 관심이 있어 보였고, 오히려 그 점 때문에 시스템적 문제가 있다는 느낌이 강하고 불안하게 읽힘. 사후 분석에 상식적인 조치가 빠져 있다는 건 고칠 생각이 없다는 뜻처럼 보임
    • 실제 삭제를 삭제 플래그로 바꾸면 “Google Cloud가 고객 데이터를 삭제하지 못해 EU 규정을 위반했다” 같은 또 다른 재미있는 버그가 생길 수 있음. Google은 우발적 미삭제보다 우발적 삭제 쪽을 택할 것 같고, 적어도 EU에서는 그럴 듯함
    • 이런 걸 안 한다는 건 농담 같음. 거대 클라우드 제공자가 데이터 삭제에 안전장치를 둘 생각을 안 한다는 게 말이 안 됨. 현실적으로는 여러 번 생각했지만 비용이 든다는 이유로 구현하지 않았을 듯함
    • Google의 “사후 분석”이 정말 이해가 안 됨. 온라인 서비스를 운영해 본 사람이라면 명백히 부족하다는 걸 알 수 있을 뿐 아니라, 결론도 오만함으로 가득함. “일회성 사고였고, 다시는 안 일어나며, 정말 미안하지만 우리는 훌륭하고 계속 훌륭하다”는 식이라서 Google Cloud의 얼굴을 감싸쥐게 만드는 순간을 전혀 만회하지 못함

  • GCP 고객이고 TAM이 있다면 이렇게 물어보면 곤란해할 것임. GCP가 관리 실수를 했을 때 내 계정의 대량 리소스를 실수로 삭제하지 못하게 막는 보호 장치가 무엇인지 물어보면 됨
    특정 문제는 해당 도구 폐기와 더 많은 자동화로 완화됐다고 답할 텐데, “그건 고친 걸 알고 있다. 그렇다면 대규모 삭제 전에 사람이 검토하느냐”라고 이어가면 됨
    예전에 GCP에서 일했고 AWS는 더 오래 적극적으로 써 온 입장에서 보기엔, GCP의 사람 기반 보호 조치는 거의 없고 AWS보다 훨씬 적어 보임. 어쨌든 TAM에게 이 실제 위험을 물어볼 가치는 충분함

    • 제대로 몰아붙이면 됨. 그러면 TAM들이 내부 시스템을 더 잘 다루는 법을 배우게 됨. 혼자서 바꾸지는 못하겠지만, 때로는 상향 보고 경로 약속이나 비공식 합의를 얻을 수 있음
      충분히 많은 TAM이 소리를 지르면 언젠가는 위쪽 누군가가 움직일 수도 있음
    • 고객 자산이 삭제 예정일 때 Google 직원이 연락해 고객 유지를 시도할 기회라고 포장하면 내부에서 더 잘 먹힐 듯함. 부수적으로 모두에게 곧 뭔가가 날아간다는 사실을 명확히 알리는 효과도 있음

  • “Google 팀이 며칠 동안 24x7로 일했다”는데, 여기서 7이 무슨 뜻인지 모르는 것 같음

    • 엔지니어 24명이 하루 7시간 일했다는 뜻일 듯. 마사지와 셰프가 만든 무료 구내식당 음식 포함
    • 완전히 문자 그대로 받아들이면 좀 말이 안 되는 건 맞음. 하지만 x7은 당연히 주 7일 일했다는 뜻이니, 목요일 오후부터 화요일 아침까지도 24x7로 일할 수 있음. 주말을 쉬지 않았다는 의미임
    • 너무 많이 일해서 며칠이 몇 주처럼 느껴졌나 봄
    • 완화 작업이 주말에 걸쳤다면 그래도 말이 될 수는 있음
    • 팀원들이 교대해서 야간이나 주말 중단 없이 계속 작업했다는 뜻일 수도 있음. 개인적으로는 이런 대형 프로젝트라면 항상 표준으로 그래야 한다고 봄

  • 와, 내가 틀렸음. Terraform 같은 데서 복구 기간 없이 즉시 삭제가 기본값이었고, UniSuper 쪽 누군가가 테스트하다 삭제 범위를 잘못 잡은 일일 줄 알았음. 그래도 기본값 문제이긴 한데, 서드파티 도구와 UniSuper 쪽 실수일 거라고 봤음
    실제로 Google 쪽 문제였다는 게 미쳤음. UniSuper는 “대체 뭐야?” 싶었을 듯함

    • 글에 무슨 일이 있었는지 나와 있고 UniSuper와는 상관없음. Google이 내부 도구로 프라이빗 클라우드를 배포했고, 그 Google 내부 도구가 1년 뒤 자동 삭제되도록 설정했음
    • Google이 GCP 청구서에 막대한 크레딧을 주거나, 아예 별도 보상금을 지급했을 거라고 봄

  • 관련 글: UniSuper members go a week with no account access after Google Cloud misconfig[0](186 points, 16 days ago, 42 comments), Google Cloud accidentally deletes customer's account [1](128 points, 15 days ago, 32 comments)
    [0]: https://news.ycombinator.com/item?id=40304666
    [1]: https://news.ycombinator.com/item?id=40313171

  • 특정 도구나 절차 조사에서 멈추지 않고, 나머지도 자동 삭제 문제가 없는지 살펴보고 소프트 삭제 동작도 확인했다는 점에서는 꽤 철저한 검토처럼 들림
    한 걸음 더 나아가 놀랄 만한 기본 동작이 있는지 모든 기본값 사례를 검토할 수도 있었음. 다만 무엇이 “놀라운지” 판단하기는 어려울 수 있음. 도구나 API를 가장 잘 모르는 사람들이 기본값을 그대로 쓰는 경우가 많기 때문임

    • “소프트 삭제 동작도 확인했다”는 부분이 정확히 어디에 나옴? 이 특정 자동 삭제 시나리오가 더는 발생하지 않도록 보장했다는 말뿐이고, 주된 이유도 “이제 배포가 자동화됐다”는 것처럼 보임
      전에도 자동화돼 있었고 이제 더 자동화됐다는 건데, 그건 삭제 메커니즘이 일관되게 안전하다는 안심을 전혀 주지 않음. 운전석에 운영자가 없어졌다는 뜻일 뿐임
    • 이런 사고는 그냥 AWS를 쓰자는 훌륭한 이유가 되니, 내부에서는 꽤 식겁했을 듯함
      “시스템이 부여한 1년 기간이 끝난 뒤 고객의 GCVE Private Cloud가 삭제됐다. 내부 도구를 쓰던 Google 운영자가 매개변수를 비워 둔 결과로 삭제가 트리거됐고, 고객의 삭제 요청이 아니었기 때문에 고객 알림은 발송되지 않았다. 고객이 직접 시작한 삭제라면 사전 알림이 있었을 것이다.”
      짜잔! 우리는 인간 검토 없이 거대한 삭제가 일어나게 둘 정도로 무능함. 다행히 이 고객은 우리를 믿지 않고 GCP 밖 백업을 가지고 있어서 완전히 망하지 않았음
      “Google Cloud에서 이런 성격의 사고는 이전에 없었다. 시스템적 문제는 아니다.”
      번역하면 “맙소사, AWS와 Azure 영업사원들이 우리의 엄청난 실패를 인용해 잠재고객 모두에게 이메일을 세 통씩 보냈다”는 뜻임

  • 이런 사건이 처음 일어난 대상이 수십억 달러 규모의 뮤추얼 펀드였다고 말하는 건 믿기 어려움. UniSuper 문제가 해결돼서 다행이지만, 무시해도 될 만큼 작은 다른 사례들이 아마 있었을 것 같음
    이 일이 GCP에 필요한 자극이 되기를 바랄 뿐임

    • GCVE, 즉 관리형 VMware는 꽤 obscure한 서비스임. 기존 VMware 집합을 그대로 클라우드로 들어 올려 옮기려는 수십억 달러 규모 기업 정도만 쓰는 서비스임
    • 이 사고의 핵심은 대부분 고객이 갖고 있거나 쓰지 않는 특수 맞춤 설정이 있었고, 그게 일부 안전 검사를 우회했다는 점임. 그래서 “일반적인” 작은 고객에게는 영향을 줄 수 없었음
    • 작은 고객이라도 언론에 가져갔을 테고, 언론이 분명히 다뤘을 것이므로 그렇게 보긴 어려움
      “Google이 우리 클라우드 서비스를 삭제했다”는 건 어떤 규모의 기업이든 큰 뉴스임

  • “고객의 CIO와 기술팀은 Google Cloud 팀과 긴밀히 협력하며 24x7 복구를 빠르고 정확하게 수행한 점에서 칭찬받아 마땅하다”라는데, 블로그 글에서 칭찬만 받은 건지 아니면 Google Cloud 크레딧을 왕창 받아낸 건지 궁금함

    • 유능한 고객이라면 Google이 이 비용을 내도록 만들지 않을 현실은 없음. 올해 청구서가 아예 없어도 놀랍지 않음
    • 징벌적 손해배상도 있었어야 함

  • 호주의 UniSuper 고객임. 당시엔 무슨 일인지 몰랐지만 해결하려고 하는 동안 매일 이메일을 받았음. 실제로 무슨 일이 있었는지는 뉴스로 알게 됨. 전체를 시스템 다운타임 정도로 축소해서 말한 느낌임
    사람들의 돈과 연금 펀드로 모인 수십억 달러에 실제로 무슨 일이 생겼다고 상상하면 아찔함

    • 다른 사람들이 받은 것과 같은 이메일을 받은 건가? 거의 매일 이메일이 왔고 “disruption”, “apologies”, “frustration” 같은 단어가 여러 번 쓰였음
      며칠 뒤에는 “A letter from the CEO”라는 제목의 이메일도 왔음
      “서비스 중단에 대한 업데이트를 드리고자 합니다.”
      “먼저 이번 장애에 대해 개인적으로 사과드리며, 저희 팀이 시스템을 순차적으로 다시 온라인 상태로 복구하기 위해 밤낮없이 작업하는 동안 기다려 주신 데 감사드립니다.”
      당시 상황에서 더 명확한 커뮤니케이션이나 Google Cloud 내부에서 무슨 일이 있었는지 더 분명한 설명을 요구하기는 어렵다고 봄

  • 이 사건에 대한 초기 발표는 꽤 오해를 불렀음. Google이 GCP 계정 전체를 실수로 삭제한 것처럼 들렸음. 이번 글을 읽어보니 좀 안심됨. 잃은 건 한 리전 규모의 가상 머신뿐인 것 같고, 그런 일은 실제로 일어날 수 있으며 내 시스템은 큰 문제 없이 감당할 수 있다고 봄
    원래 글은 모든 리전의 GCS 버킷, SQL 데이터베이스 등이 전부 사라진 것처럼 들렸는데, 그건 완전히 다른 문제이고 Google이 그런 일은 하지 않는다고 믿을 수 있기를 바람

    • UniSuper가 계정이 아니라 구독이 삭제됐다고 했을 때 위험 신호였음. 많은 사람이 거기서 성급히 결론을 냈음
답변달기