7분간의 카운트다운이 된 전력 차단
화요일 오전 07:08(BST)경, 런던의 Google Cloud europe-west2-b 영역에서 지역 전력망 장애가 발생했습니다. UPS 배터리가 즉시 작동하여 교과서적인 대응을 보였습니다. 그러나 주 발전기와 보조 발전기 제어 장치 모두 디젤 발전기를 가동하지 못했고, 시설은 배터리 전력에만 의존하게 되었습니다.
그 7분이라는 시간은 치명적이었습니다. 데이터 센터는 배터리 전력으로 약 7분간 가동된 후 전력이 소진되어 전체 영역이 암흑에 빠졌습니다. 결정적으로 배터리 자체가 고장 난 것이 아니라 발전기 가동 시스템이 작동하지 않으면서 예상치 못한 연쇄적인 서비스 중단이 발생했습니다.
수백만 명의 고객을 보유한 핀테크 거물 Revolut는 즉각적인 타격을 입었습니다. 사용자들은 다음과 같은 광범위한 문제를 보고했습니다:
- 로그인 실패
- 송금 차단
- 카드 결제 거부
Revolut는 처음에 "서비스 중단"을 언급했다가 이후 광범위한 다운타임의 원인을 Google Cloud 탓으로 돌렸습니다. 이번 사건은 발전기 제어 장치와 같은 단일 장애 지점이 어떻게 심각한 혼란을 초래할 수 있는지 보여주며, 가장 정교한 클라우드 인프라에 의존하는 것이 얼마나 취약한지를 강조했습니다.
두 개의 정상 영역도 충분히 안전하지 않았습니다
멀티 영역 리전은 회복 탄력성을 보장합니다. 즉, 한 영역이 실패하면 워크로드가 다른 영역으로 전환됩니다. 런던의 Google Cloud europe-west2 리전에는 세 개의 영역(a, b, c)이 있습니다. b 영역이 마비되었을 때 시스템은 a와 c로 원활하게 페일오버되어 서비스를 유지했어야 했습니다.
대신, 갑작스러운 트래픽 급증이 남은 인프라에 과부하를 일으켰습니다. 이는 단순한 전환이 아니라 용량 문제이자 조정의 악몽이었습니다. 영역 간 의존성으로 인해 a와 c 영역의 일부 서비스는 오프라인 상태인 b 영역과 관련된 구성 요소나 상태를 기다리며 멈춰 서게 되었습니다.
엔지니어링 측면의 교훈은 명확합니다. 이중화는 영역이 진정으로 독립적이고 현실적인 페일오버 스톰을 흡수할 충분한 여유 용량을 갖추고 있을 때만 효과적입니다. 속도 제한, 단계적 성능 저하, 엄격하게 테스트된 복구 계획은 "천둥 떼(thundering herd)" 현상이 전체 리전을 마비시키는 것을 방지하는 데 필수적입니다.
Google은 Revolut보다 먼저 복구되었습니다
Google의 빠른 인프라 복구가 고객의 즉각적인 서비스 정상화로 이어지지는 않았습니다. Google은 대부분의 고객이 사고 발생 후 약 6~8시간 뒤인 13:00~15:00(BST) 사이에 온라인으로 복귀했다고 보고했습니다. 그러나 Revolut는 18:40(BST)이 되어서야 전체 서비스 복구를 발표했으며, 이는 몇 시간의 상당한 격차를 의미합니다.
이러한 차이는 중요한 차이점을 드러냅니다. 클라우드 용량을 복구한다고 해서 고객의 운영 백로그가 즉시 해결되는 것은 아닙니다. 컴퓨팅과 스토리지를 사용할 수 있게 되더라도 Revolut와 같은 금융 기관은 복잡한 과제에 직면합니다. 거래 상태를 조정하고, 결제 백로그를 처리하며, 카드 결제부터 로그인 서비스에 이르기까지 모든 애플리케이션 의존성을 정상화하는 데는 시간과 세심한 순서 조정이 필요합니다.
이번 장애는 Revolut를 넘어섰습니다. 보고서에 따르면 다음과 같은 다른 영국 기관 및 서비스 전반에 걸쳐 광범위한 혼란이 발생했습니다:
- Lloyds
- Halifax
- 원격 법원 심리 영상 링크
이러한 광범위한 영향은 공유 클라우드 인프라의 근본적인 취약성을 강조합니다. europe-west2-b의 단일 영역 장애가 광범위한 서비스 문제로 확산되면서, 상호 연결된 종속성이 어떻게 국지적인 전력 문제를 국가적 골칫거리로 바꿀 수 있는지 보여주었습니다. 사고 상태에 대한 자세한 내용은 Google Cloud Service Health Dashboard를 참조하십시오. 흥미롭게도 규제 당국이 이를 주목하고 있으며, Bank of England와 FCA는 해당 사고의 통지 일정에 관한 문의를 받았습니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
클라우드 중단은 이제 금융 리스크입니다
7월에 Google Cloud가 영국 금융 시스템의 중요 제3자(critical third party)로 지정된 것은 판도를 근본적으로 바꾸어 놓았습니다. 사고 발생 후, 재무위원회 위원장은 즉시 Bank of England와 FCA에 통지 일정에 관한 답변을 요구했습니다. 이는 단순한 기술적 결함이 아니라 시스템적 리스크입니다.
금융 회사들은 이제 '어느 정도의 복원력이 충분한가?'라는 냉혹한 질문에 직면해 있습니다. 클라우드 제공업체, 전체 리전, 또는 애플리케이션 자체 아키텍처가 집중 지점이 될 때, 기업은 자신의 노출 정도를 면밀히 조사해야 합니다. 멀티 리전 설계는 리스크를 줄이는 경로를 제공하지만 비용, 지연 시간, 복잡한 데이터 관리 측면에서 상당한 상충 관계를 초래합니다.
고객과 개발자에게는 실질적인 교훈이 남았습니다. 사고 발생 시 항상 Google Cloud의 service health dashboard를 확인하십시오. 가장 최신 정보를 제공합니다. 엔지니어링 팀은 가정에서 벗어나야 합니다. 영역 손실을 테스트하고, 장애 조치(failover) 용량을 검증하며, 성능이 저하된 운영 모드를 시뮬레이션해야 합니다. 멀티 영역 배포만으로는 연속성을 보장할 수 없습니다.
자주 묻는 질문
Google Cloud 중단 사태 동안 Revolut은 왜 다운되었나요?
런던 데이터 센터에서 주 발전기와 예비 발전기 컨트롤러가 모두 고장 나면서 전력이 차단되었습니다. 트래픽이 나머지 영역으로 이동했으나, 해당 영역들 역시 과부하와 오프라인 상태인 영역에 대한 종속성으로 인해 영향을 받았습니다.
Google Cloud 런던 중단 사태는 얼마나 지속되었나요?
Google은 사고 시작 후 약 6~8시간이 지나 대부분의 영향을 받은 고객이 복구되었다고 밝혔습니다. Revolut은 서비스가 더 늦은 BST 기준 약 18:40에 복구되었다고 전했습니다.
Google Cloud의 다른 런던 영역들은 왜 중단을 막지 못했나요?
나머지 영역들은 갑작스러운 장애 조치 트래픽 급증에 직면했으며, 일부 서비스는 여전히 장애가 발생한 영역과 연결된 구성 요소에 의존하고 있었습니다.
이번 중단 사태가 영국 금융 서비스에 의미하는 바는 무엇인가요?
주요 클라우드 제공업체의 중단이 금융 서비스에 어떤 영향을 미칠 수 있는지, 그리고 왜 규제 당국이 중요한 제3자 제공업체를 면밀히 조사하고 있는지를 보여줍니다.