AWS use1-az4 열 사건과 Coinbase 7시간 중단, 데이터센터 물리 인프라 SPOF가 만든 결과

5월 7일 오후 4시 20분, 한 데이터센터의 온도 상승에서 시작됐습니다

같은 클라우드 안에서 여러 AZ에 분산했다고 안심하고 계셨다면, 5월 7일 사건을 한 번 보셔야 하죠. 미국 Northern Virginia에 위치한 AWS US-EAST-1 리전의 한 데이터센터 안에서 온도가 올라간 게 출발점이었습니다. 그리고 그 결과 use1-az4 가용영역의 EC2 인스턴스와 EBS 볼륨이 전력 손실로 멈췄습니다.

AWS가 공식적으로 인지하고 Health Dashboard에 등록한 시각은 PDT 오후 5시 25분(The Register 보도)이었고, 한국 시간으로는 5월 8일 오전 9시 25분이었습니다. 사건 자체는 그보다 약 한 시간 앞선 PDT 오후 4시 20분에 시작됐어요(Yahoo Finance 보도). 같은 날 PDT 오후 8시 6분, AWS는 복구 진행이 예상보다 느리다고 안내했고, 오후 9시 12분에는 영향 인프라 일부의 전력이 복구됐습니다. 오후 10시 11분에는 추가 냉각 용량이 가동됐고, 일부 랙이 회복됐죠. 냉각 시스템이 완전히 복구된 시점은 다음 날인 5월 8일 PDT 오후 1시 50분, 한국 시간 5월 9일 오전 5시 50분이었습니다. 사건 시작부터 약 21시간 30분 만에 마무리된 셈입니다.

IT Pro가 인용한 AWS Health Dashboard 안내문은 명확합니다. 단일 데이터센터 내에서 온도가 상승했고, 일부 케이스에서 장애가 발생했다는 표현이었습니다. IT Pro는 사건이 use1-az4 한 가용영역에 한정됐다는 점을 명시했고, Network World도 use1-az4 영역으로 사건을 식별했습니다. 이 한 줄이 이번 사건의 핵심 구조를 보여주는 셈이죠. 한 AZ 안의 한 데이터센터에서 시작된 물리적 사건이 그 AZ 안의 자원에 동시 영향을 만든 구조였습니다.

가용영역은 하나 이상의 데이터센터로 구성되고, 그 시설의 전력·냉각이 SPOF입니다

AWS 공식 정의에 따르면 가용영역(AZ)은 같은 리전 안에서 물리적으로 분리된 시설이며, 한 AZ는 하나 이상의 데이터센터로 구성됩니다. 그래서 같은 리전 안의 여러 AZ에 워크로드를 분산하면 한 AZ의 장애로부터 보호받을 수 있다는 게 다중 AZ 설계의 전제입니다. 그런데 이번 사건에서 흔들린 건 AZ 자체가 아니라 AZ를 구성하는 데이터센터 한 곳의 물리 인프라였습니다. 구체적으로는 냉각 시스템이었습니다.

Network World가 인용한 AWS 측 설명에 따르면, 냉각 시스템이 실패한 가용영역 안에서 온도가 운영 임계값을 초과했고, 서버는 하드웨어 보호를 위해 자동으로 셧다운됐습니다. 사람이 끈 게 아니라 하드웨어가 스스로 꺼진 거죠. 그리고 그 자동 셧다운이 EC2 인스턴스와 EBS 볼륨 모두에 동시 적용되면서, 사용자 시각에서는 use1-az4에 있던 자원이 동시에 멈춘 결과가 됐습니다.

여기서 보이는 SPOF는 두 겹입니다. 첫째는 단일 AZ 의존입니다. 사용자가 의도했든 안 했든 use1-az4 한 곳에만 워크로드를 둔 경우에는 이번 사건의 영향을 그대로 받았습니다. 둘째는 AZ를 구성하는 한 데이터센터의 물리 인프라입니다. AZ를 신뢰하더라도 그 AZ를 떠받치는 전력·냉각 시설 중 한 곳이 흔들리면 그 시설이 떠받치던 자원이 한꺼번에 함께 흔들리는 구조죠. 단일 클라우드 SPOF의 일반 구조는 5월 4일(월) 블로그 단일 클라우드 SPOF 글에서 더 자세히 정리했습니다.

Coinbase 7시간 중단이 보여준 것은 다중 AZ 설계의 한계입니다

이번 사건에서 가장 가시적인 피해는 Coinbase였습니다. 거래 서비스가 약 7시간 중단됐고, 싱가포르 현지 시각 기준 오전 9시부터 오후 4시까지 영향이 이어졌습니다. IT Pro는 FanDuel과 CME Group의 거래 플랫폼도 이번 사건의 영향을 받았다고 전했습니다. 인도주의 데이터 수집 도구인 KoboToolbox는 Network World 보도에 따라 UTC 5월 8일 0시 32분, 한국 시간으로는 5월 8일 오전 9시 32분부터 글로벌 인스턴스가 오프라인이 됐습니다.

여기서 짚을 부분은 한 가지죠. 이들 모두 글로벌 규모로 운영되는 서비스입니다. 그럼에도 7시간이 걸렸다는 사실은 다중 AZ 설계가 있다고 해도 실제 트래픽이 한 AZ에 쏠려 있거나 페일오버 임계값이 느슨하면 같은 결과가 나온다는 점을 보여줍니다. The Register 보도에 따르면 AWS는 사건 진행 중 고객이 평소보다 긴 프로비저닝 시간을 경험할 수 있다고 안내했습니다. 모두가 같은 시각에 같은 방향으로 움직이면 백업 경로도 함께 줄을 서게 되는 구조죠.

한국 기업이 지금 점검할 5지점

AWS US-EAST-1을 사용하지 않는 한국 기업에도 이번 사건은 같은 질문을 던집니다. 같은 구조가 다른 클라우드에서도 똑같이 작동할 수 있기 때문입니다. 다음 5가지가 지금 당장 점검할 수 있는 항목입니다.

1. 실제 AZ 분포 점검

설계는 다중 AZ인데 실제 트래픽은 한 AZ에 몰려 있는 경우가 흔합니다. EC2·RDS·ELB·ASG의 AZ 배치를 콘솔에서 일괄 추출하고, 매출 동선에 있는 서비스가 두 개 이상의 AZ에 실제로 떠 있는지 확인합니다.

2. EBS 스냅샷 보관 위치와 복원 테스트

EBS 스냅샷이 같은 AZ에만 있다면 이번 같은 사건에서는 무의미해요. 다른 AZ 또는 다른 리전에 복원 가능한 상태로 보관되고 있는지, 그리고 실제로 복원을 테스트해본 적이 최근 3개월 안에 있는지 확인합니다. CDN·DNS 레벨 다중화 가이드는 5월 6일(수) 블로그 멀티 CDN·DDoS 이중 방어 글에서 함께 참고하면 좋아요.

3. DNS 페일오버 임계값

Route 53 health check의 기본 간격은 standard 30초·fast 10초이고, 페일오버 임계값은 일반적으로 60초 이내 전환을 목표로 설정하는 경우가 많아요. 임계값이 길거나 health check 빈도가 낮으면 분 단위 다운타임이 그대로 사용자에게 노출됩니다. 비정상 응답 임계 횟수와 정상 복귀 임계 횟수를 분리해 설정하면 false positive를 줄일 수 있어요.

4. 외부 합성 모니터링 이중화

모니터링 시스템 자체가 같은 클라우드 위에 있으면 클라우드가 멈췄을 때 우리가 멈췄다는 사실조차 알 수 없습니다. Datadog Synthetic Monitoring, Pingdom, UptimeRobot 같은 외부 합성 모니터링을 별도 회선으로 두는 것이 가장 자주 빠뜨리는 항목입니다.

5. AZ 의존 워크로드 명시 매핑

어떤 서비스가 어느 AZ에 있는지 한눈에 보이는 매핑 문서가 운영 안전망의 기본입니다. 장애 발생 시 어디부터 페일오버해야 하는지 판단하는 데 분 단위로 차이가 납니다. CloudFormation·Terraform 코드에 AZ 분포를 강제하는 항목을 포함하면 운영 중 누락 위험을 줄일 수 있어요.

이것만 기억하세요

자주 묻는 질문 (FAQ)