AWS 서비스 중단: 마이크로소프트 은퇴 엔지니어가 설명하는 웹 장애의 모든 것
이 영상은 2025년 10월 20일 발생했던 AWS(Amazon Web Services)의 대규모 서비스 중단 사태에 대해 은퇴한 마이크로소프트 시스템 엔지니어 데이브가 자세히 설명합니다. 데이브는 이번 사고의 발생 원인, US East1 리전이 또다시 문제를 일으킨 이유, 예상과 달랐던 페일오버(failover)의 실상, 그리고 현대 인터넷의 획일성이 가져다주는 위험에 대해 깊이 있게 분석합니다. 그는 기술 용어를 쉽게 풀어 설명하며, 앞으로 유사한 사고를 방지하기 위한 실질적인 방안들을 제시합니다.
1. AWS 서비스 중단 사태 발생: 인터넷의 '전화번호부'가 멈춰 서다 🚫
영상은 2025년 10월 20일 월요일 새벽, 서부 시간 기준으로 밤늦게 시작된 AWS의 대규모 서비스 중단 사태에 대한 데이브의 경험담으로 문을 엽니다. 그는 마이크로소프트 시스템 엔지니어로서 과거 MS-DOS와 Windows 95 시절부터 인터넷 문제로 밤새워 씨름했던 경험을 언급하며, 이번 사태가 마치 그때처럼 인터넷이 말을 듣지 않던 답답한 아침이었다고 회상합니다. 😥
"오늘 아침도 그런 아침 중 하나였죠. 브라우저가 텅 비거나 스마트 초인종이 스마트함을 잃고, 좋아하는 게임이 갑자기 '서버 사용 불가' 레트로 시뮬레이터처럼 보였다면, 여러분은 메인 손님을 놓친 겁니다. 바로 아주 큰 AWS 서비스 중단 사태 말이죠."
이번 사태로 인해 데이브의 텔레프롬프터 소프트웨어까지 영향을 받았다고 언급하며, 클라우드(Cloud)가 결국에는 "다른 사람의 컴퓨터"에 불과하다는 사실을 다시 한번 상기시킵니다. 단순히 다른 사람의 컴퓨터를 사용하는 것 이상으로, 복잡한 라우팅(routing), 캐싱(caching), 제어 평면(control planes), 그리고 수많은 장애 모드(failure modes)가 얽혀 있다는 점을 강조합니다.
데이브는 이번 영상에서 다음 질문들에 대한 답을 찾고자 합니다.
- 무슨 일이 일어났는가? 😮
- US East1 리전이 왜 또다시 문제의 중심에 섰는가?
- 페일오버(failover)가 우리가 상상하는 할리우드 영화처럼 작동하지 않은 이유는 무엇인가?
- 이번 장애의 실제 영향 범위는 얼마나 넓었으며, 현대 인터넷의 획일성이 우리에게 무엇을 불편하게 드러내는가?
이러한 질문들에 답하면서, 그는 전문 용어를 쉽게 설명하고 시스템 아키텍처의 복잡한 부분을 벗겨내어 '뼈대'를 보여줄 것이라고 약속합니다. 특히 DNS(Domain Name System)처럼 "지루해 보이는" 요소가 어떻게 "독특하고 엄청난 단일 장애 지점"이 될 수 있는지 자신의 경험을 바탕으로 설명하겠다고 덧붙입니다. 🕵️♂️
2. US East1 리전의 연쇄 반응: 인터넷 전화번호부 마비와 광범위한 영향 🌐
이번 사태의 첫 징후는 서부 시간으로 한밤중에 나타났습니다. AWS는 버지니아 북부 지역(업계에서는 US East1으로 잘 알려진 곳)의 여러 서비스에서 오류율(error rates)과 지연 시간(latencies)이 증가했음을 인정했습니다. US East1은 AWS의 가장 오래되고 가장 큰 리전으로, 가장 많은 레거시 시스템과 AWS의 글로벌 제어 평면(global control plane) 코드 경로가 뿌리내리거나 의존성을 가지고 있는 곳입니다. 🌳
US East1에서 서비스 문제가 발생하자마자, AWS 서비스에 대한 낮은 지연 시간(low latency) 호출에 의존하는 앱들이 즉시 문제를 겪기 시작했습니다. 예를 들어, 스냅챗(Snapchat), 시그널(Signal), 로블록스(Roblox), 포트나이트(Fortnite), 그리고 다양한 금융 및 상거래 앱들이 제대로 작동하지 않았습니다. 심지어 아마존의 자체 서비스인 알렉사(Alexa)와 링(Ring)까지 다운되었습니다. 해가 뜰 무렵에는 수만 건의 장애 보고가 쏟아졌고, 다운되거나 기능이 저하된 사이트 목록은 마치 스마트폰의 홈 화면을 옮겨 놓은 듯했습니다. 📱💥
데이브는 이번 장애의 영향 범위(blast radius)를 구체적으로 설명합니다.
- 로이터(Reuters) 통신은 포트나이트, 로블록스, 스냅챗, 코인베이스, 로빈후드, 벤모, 아마존의 프라임 비디오와 알렉사가 영향을 받았다고 보도했습니다. 이는 실시간 게임 백엔드, 지갑 서비스, 웹소켓, 모바일 앱, IoT 제어 메시지 등 다양한 분야에 걸쳐 있었습니다. 데이브는 이러한 서비스에서 "몇 초의 지연도 영원과 다름없다"고 지적합니다.
- 가디언(The Guardian)은 플레이스테이션 네트워크, 듀오링고, 그리고 수많은 미국 은행과 통신사도 이번 사태에 연루되었다고 덧붙였습니다.
- AP(Associated Press) 통신은 동부 시간으로 새벽 3시 11분경에 사태가 시작되었고, 오전 6시경에 첫 복구가 감지되었다고 보도했습니다. 아마존은 초기 완화 조치가 태평양 표준시로 오전 2시 24분에 이루어졌다고 밝혔지만, US East1의 EC2(Elastic Compute Cloud) 인스턴스 시작 문제로 인해 일부 고객은 여전히 높은 오류율을 경험했다고 인정했습니다.
데이브는 이러한 수치들이 현장 운영자들이 느꼈던 상황과 일치한다고 설명합니다. "날카로운 절벽 같은 붕괴", "들쑥날쑥한 복구 과정", 그리고 "마치 작동하는 것 같지만 아직 완전히 안정되지 않은 듯한 답답함"이 이어졌다는 것이죠. 특히 캐시(caches) 워밍업, 연결 풀(connection pools) 재구성, 샤딩된 트래픽(sharded traffic) 재분배와 같은 '마지막 단계'의 작업 때문에 앱의 가동 시간 차트는 계단처럼 서서히 회복되는 모습을 보였다고 합니다. 📈
3. 심층 분석: DNS와 DynamoDB, 그리고 시스템의 취약성 💔
그렇다면 근본적으로 무엇이 잘못된 걸까요? AWS의 상태 업데이트는 DNS를 지목합니다. DNS는 기본적으로 인터넷의 전화번호부와 같은 역할을 합니다. 특히 US East1에서 DynamoDB API 엔드포인트를 해석하는 데 문제가 있었습니다. 📖
이것이 사소한 문제처럼 들릴 수 있지만, 데이브는 DynamoDB가 "엄청나게 많은 로그인 세션, 속도 제한기, 기능 플래그, 게임 상태 저장소, 그리고 3밀리초 내에 일관된 NoSQL(Not only SQL) 데이터가 필요한 임시 사용 사례"의 트랜잭션 엔진(transaction engine)이라는 점을 깨달으면 그 심각성을 알 수 있다고 설명합니다. 🤯
"만약 그 API에 대한 이름 해석(name resolution)을, 심지어 간헐적으로라도 중단시킨다면, 클라이언트 SDK(Software Development Kit)는 물러섰다가 재시도하고, 지터(jitter) 현상을 보인 후, 기하급수적인 파동(exponential waves)으로 다시 공격할 것입니다. 갑자기 탄력적인 부하(elastic load)를 흡수해야 할 것이 모든 마이크로서비스가 데이터베이스가 어디 숨어 있는지 다시 찾으려 애쓰면서 부하의 원천이 되는 거죠."
기본적으로 네트워크는 "월리를 찾아라!"를 외치는 클라이언트로 가득 차게 되지만, '월리'는 절대 대답하지 않는 상황이 발생한 것입니다. 데이브는 이렇게 "DNS의 작은 문제(paper cut)"가 어떻게 "서비스 거부(Denial of Service) 전화통화"로 번질 수 있는지 설명합니다. 📞
AWS는 기본적인 DNS 문제는 태평양 표준시로 오전 2시 24분에 완전히 완화되었다고 밝혔지만, 새로운 EC2 인스턴스를 시작하는 데 계속 문제가 있었고, 시스템이 다시 안정화되고 캐시가 풀리는 데 시간이 걸렸습니다. 만약 아침 식사 시간 이후에도 증상을 느꼈다면, 이는 오래된 DNS 정보(stale DNS), 차가운 용량(cold capacity), 그리고 부팅 시 의존성(boot-time dependencies)의 긴 꼬리에 잡힌 것일 가능성이 높다고 데이브는 설명합니다.
다른 언론들은 이번 사태의 근본 원인(root cause)에 대해 미묘하게 다른 강조점을 두었습니다. 어떤 곳은 DNS 문제를 광범위하게 지적했고, 다른 곳은 해당 리전에서 AWS 트래픽 로드 밸런서를 관리하는 내부 서브시스템(internal subsystem)의 문제를 언급했습니다. 데이브는 종종 두 가지 모두가 사실일 수 있다고 말합니다. US East1의 밸런서 제어 평면(balancer control plane)이 잠시 중단되고, 동시에 DynamoDB와 같은 핵심 관리 서비스에 대한 이름 해석이 잘못된다면, 입력 혼란(ingress confusion)과 상태 저장소 기억 상실증(state store amnesia)이 동시에 발생하여 "가용성에 대한 원투 펀치"를 날리는 것과 같다는 것이죠. 👊
중요한 점은 AWS와 외부 분석가들 모두 이번 사태가 사이버 공격(cyber attack)이 아니었다는 데 동의한다는 것입니다. 데이브는 이를 "우리의 오랜 친구, 복잡한 시스템(complex system)과 우리가 예상치 못한 곳에 있던 취약한 연결 고리(fragile link)" 때문이라고 표현합니다.
로이터와 AP의 집계는 마치 음악 페스티벌 라인업처럼 게임, 금융, 기술, 통신, 심지어 정부 포털까지 광범위하게 영향을 미쳤음을 보여줍니다. 영국에서는 재무위원회가 AWS를 금융 분야의 핵심 제3자(critical third party)로 취급하지 않는 이유를 묻기도 했습니다. ATM과 모바일 뱅킹이 제대로 작동하지 않을 때 사람들의 인내심이 바닥나는 것은 당연하다고 데이브는 말합니다.
"옛말을 빌리자면, 아마존이 재채기를 하면 다른 모든 사람이 감기에 걸리는 격이죠." 🤧
그러나 이는 AWS 전체가 글로벌하게 무너진 것이 아니라고 데이브는 강조합니다. US East1의 인프라에 의존하는 충분히 많은 핵심 서비스들(core services)이 동시에 마비되었고, 그 결과 전 세계 사용자들이 영향을 느꼈다는 것입니다. 현대 앱은 비동기 호출(asynchronous calls)로 이루어진 "루브 골드버그 장치(Rube Goldberg machine)"와 같아서, 모든 것이 100밀리초 안에 완료되어야 하지만, 그렇게 되지 않을 때 문제가 발생합니다.
4. 클라우드 페일오버의 오해와 현실 😵💫
많은 사람들이 궁금해하는 질문이 있습니다. "클라우드의 핵심은 페일오버(failover) 아닌가요?" 데이브는 "맞습니다. 하지만 이는 엔지니어링된 경계(boundaries) 내에서 작동합니다"라고 답합니다. AWS는 세 가지 동심원적인 중복성(redundancy)을 제공합니다. ⭕
- 가용 영역(availability zone) 내: 하나의 데이터 센터가 다운되더라도 다른 곳에서 처리.
- 리전 내 여러 가용 영역 간: 도시를 넘나드는 개념으로, 여러 데이터 센터에 분산.
- 여러 리전 간: 대륙 규모의 재해 복구를 위한 것으로, 지리적으로 멀리 떨어진 리전 간 분산.
데이브는 만약 US East1 내의 여러 가용 영역에만 서비스를 분산했다면, 해당 데이터 센터가 마비되는 것에는 대비할 수 있지만, 리전 단위의 제어 평면(regional control plane)이나 DNS 장애에는 취약하다고 지적합니다. 😥
"만약 앱의 제어 평면, 데이터 저장소, 그리고 ID 토큰이 모두 특정 리전 엔드포인트(regional endpoint)에 대한 하드 의존성(hard dependency)을 가지고 있고, 클라이언트가 다른 어떤 것과도 통신하기를 거부한다면, 여러분은 희망하거나 의지만으로는 오리건 리전으로 '핫 스왑(hot swap)'할 수 없습니다."
이는 곧 액티브-액티브(active-active) 멀티-리전 시스템을 구축하지 않았기 때문입니다. 단지 "하나의 리전을 세 가지 다른 방식으로 임대하고 하루를 마친 것"과 같습니다. 서류상으로는 중복성(redundant)을 갖춘 것처럼 보이지만, 실제로는 "몇 단계를 추가한 단일 리전 상태(single region state)"에 불과하다고 데이브는 꼬집습니다. 📄
그렇다면 AWS가 자동으로 다른 리전으로 라우팅해주지 않는 이유는 무엇일까요? 데이브는 "내가(MI) AWS 콘솔 페이지가 아니기 때문"이라고 대답합니다. "내가"는 곧 애플리케이션의 전체 상태를 가진 세계(entire stateful world)를 의미합니다. 물론 해결책은 있지만, 이는 옵트인(opt-in) 아키텍처이며, 비용, 지연 시간, 일관성 측면에서 트레이드오프(trade-offs)가 필요합니다. 💰
"데이터 모델과 제어 평면을 처음부터 리전 불가지론적(region agnostic)으로 설계해야 합니다. 그렇지 않으면 모놀리식 앱을 출시하고 위기 시에 다자간 관계를 기대하는 것과 같습니다."
만약 모바일 앱이 사용하는 OAuth 토큰이 US East1에만 저장된 키로 서명되었거나, 기능 플래그(feature flags)가 해당 리전의 테이블에 있거나, 속도 제한기 카운터(rate limiter counters)가 해당 리전에서만 강력하게 일관성을 유지한다면, US West2에서 컴퓨팅을 새로 시작하더라도 새로 생성된 인스턴스가 가장 먼저 하는 API 호출은 이미 문제를 겪고 있는 대륙 반대편의 의존성으로 돌아가는 것이 됩니다. 이것이 바로 "페일오버를 시도했지만, 계속해서 실패한" 상황으로 이어진다는 것이죠. 🔁
또 다른 미묘한 점은 AWS가 사실상 두 개의 얽혀 있는 우주라는 것입니다. 하나는 고객의 데이터 평면(EC2가 DynamoDB 테이블과 통신하는 것)이고, 다른 하나는 AWS의 서비스 제어 평면(리소스를 프로비저닝, 확장, 라우팅하는 보이지 않는 메커니즘)입니다. 역사적으로 AWS는 이러한 상황을 줄이기 위해 노력해왔지만, 일부 제어 평면은 US East1에 "홈 필드 가정(homefield assumptions)"을 가지고 있었다는 점을 지적합니다.
5. 미래를 위한 교훈: 시스템 견고성 확보를 위한 실질적인 조언 🛠️
데이브는 프로덕션 시스템을 구축하거나 운영하는 사람들이 이번과 같은 날에도 Slack이 조용할 수 있도록 견고한 플레이북(hard one playbook)을 제시합니다. 🤫
5.1. 의존성을 라이프라인 네트워크처럼 모델링하라 🔗
- 의존성을 단순한 라이브러리 목록이 아니라 생명줄 네트워크처럼 생각해야 합니다.
- 예를 들어, 사용자 ID가 US East1에 저장되어 있다면, 이 ID가 전 세계적으로 고유하고 10밀리초 내에 일관성을 유지해야 하는지, 아니면 리전별 일관성을 허용하고 나중에 조정할 수 있는지 지금 결정해야 합니다.
- "둘 다"라고 말하는 것은 스스로와 상사에게 거짓말을 하는 것이며, 결국 장애가 발생하면 강제로 결정하게 될 것이라고 경고합니다. ⚠️
5.2. 리전을 구성 변수로 취급하고 앱이 이를 받아들이게 하라 ⚙️
- 리전을 위기 시 변경할 수 있는 구성 변수(config variable)로 취급하고, 앱이 논쟁 없이 이를 실제로 받아들이도록 해야 합니다.
- 이는 컴파일된 엔드포인트(compiled in endpoints)나 특정 키 관리 시스템에만 존재하는 비밀 정보(secrets)가 없어야 한다는 것을 의미합니다. 숨겨진 리전 종속성을 찾아내야 합니다.
5.3. 클라이언트를 더 스마트하게 만들라 🧠
- SDK가 서비스 엔드포인트를 해석할 수 없을 때, 다른 리전에 있는 서명된 구성 버킷(signed config bucket)을 참조하여 대체 경로를 학습하도록 해야 합니다.
- "DNS가 멍청하다고 앱까지 멍청해지게 만들어서는 안 된다"는 것이 데이브의 조언입니다. 두 번째 경로(second path)에서 부트스트랩할 수 있도록 해야 합니다. 🚀
5.4. 실제 상황처럼 훈련하라 💪
- 카오스 엔지니어링(Chaos Engineering)을 통해 분기별로 US East1을 한 번씩 꺼보는 "수동 월요일(manual Monday)"을 연습해야 합니다.
- 실제 운영 환경이 아닌 스테이징 환경(staging)에서 어떤 부분이 실제로 고장 나는지 확인해야 합니다.
6. 과거 outage 사례와 복구의 난이도 🕰️
이번 AWS 장애가 크라우드스트라이크(CrowdStrike) 사태 이후 가장 큰 장애였는지 묻는다면, 데이브는 개인적인 경험에 따라 다를 것이라고 답합니다. 공항에서 비행기에 체크인하거나 탑승권을 받지 못했다면, 당신에게는 확실히 가장 큰 장애였을 것입니다. 대중의 인식 측면에서는 그렇게 느껴졌습니다. ✈️
하지만 두 사건의 기술적 메커니즘은 달랐습니다.
- 크라우드스트라이크 사태: 결함 있는 커널 드라이버(kernel driver) 업데이트가 윈도우 호스트를 블루스크린(blue screen)으로 만들었습니다. 거의 하드웨어 수준에서 시스템이 다운되었고, 문제가 해결된 후에도 많은 시스템이 자동으로 다시 시작되지 않았습니다. 따라서 복구 과정이 훨씬 더 수동적이고 복잡했습니다. 💙
- AWS DNS 장애: 이번 사태는 DNS 문제로 인해 핵심 관리 서비스에 대한 이름 해석이 실패하면서 모든 서비스가 타임아웃(time out)된 경우입니다.
두 경우 모두 "잘못된 것을 중앙 집중화하면 폭발의 영향도 집중된다"는 교훈을 줍니다. "실천하지 않는 복원력은 실제로는 없는 복원력"이라는 점을 강조하며, "월요일을 정해서 선을 뽑아보고 시스템이 어떻게 작동하는지 알아보라"고 조언합니다. 🔌
완전한 복구에 대한 전망에 대해 데이브는 AWS의 최신 공지에 따르면 DNS 문제는 태평양 표준시로 새벽녘에 완화되었고, 남아있는 문제들은 US East1에서 새로운 용량(fresh capacity)을 시작하는 데서 비롯되었다고 설명합니다. 즉, 사고 중에 앱이 스케일업(scale up)해야 했거나, 오토스케일링으로 스케일다운(scale down)된 후 다시 스케일업하려고 할 때, 제어 평면이 따라잡을 때까지 오류율을 계속 볼 수 있다는 뜻입니다. ⏳
이것이 바로 고객은 "아직 다운되어 있다"고 느끼는 반면, AWS는 "우리는 근본 원인을 완화했다"고 말하는 지점입니다. 데이브는 이 두 가지 인식이 각자의 관점에서 모두 사실이라고 설명합니다. 캐시가 자연적으로 만료되고, 클라이언트가 더 이상 몰려들지 않으며, 새로운 인스턴스가 정상 작동하기 시작하면서 긴 복구 꼬리(long tail)가 하루 종일 이어질 것으로 예상했습니다. 정오까지도 앱이 불안정했다면, 이는 제어 평면에 어딘가 강한 리전 종속성(hard regional assumption)이 있었을 가능성이 높다고 데이브는 지적합니다.
7. 인터넷의 '모노컬처'와 다각화의 필요성 🌍
데이브는 이번 사태를 통해 "사회학적인 관점"으로 시야를 넓혀야 한다고 말합니다. 가디언지는 전문가들의 말을 인용하여 "우리가 너무 소수의 공급자(too few providers)에게 의존하고 있다"고 지적했는데, 이는 틀린 말이 아닙니다. AWS, 마이크로소프트, 구글은 지난 세기 소수의 전력 회사들이 물리적 전력망을 운영했던 방식과 동일하게 디지털 전력망(digital grid)을 운영하고 있습니다. ⚡
과거에는 네트워크 계층에서 위험을 분산했지만, 이제는 API 엔드포인트(API endpoints)에서 위험을 집중시키고 있습니다. 영국 규제 당국은 금융 분야에서 이렇게 중요한 플랫폼을 핵심 인프라(critical infrastructure)로 지정해야 하는지 다시 한번 질문했습니다.
"제 생각에는, 한 팀이 루트(root)를 잘못 만져서 국가 앱 로그인 기능의 절반을 마비시킬 수 있다면, 그것은 모노컬처(monoculture)라고 불러야 마땅합니다."
이러한 모노컬처에 대한 해독제는 "평범하고 섹시하지 않은" 것들이라고 데이브는 말합니다. 💊
- 다양한 공급자(Diversity of providers)
- 멀티클라우드(Multicloud) (합리적인 경우)
- 적어도 돈, 안전, 시민 생활과 관련된 모든 것에는 멀티-리전(multi-region) 시스템을 구축해야 합니다.
만약 완전한 액티브-액티브 시스템을 감당할 수 없다면, 적어도 제어 평면(control plane)을 여러 리전에 느슨하게 연결(loosely coupled)하여, 무엇을 할지 결정하는 부분이 온라인 상태를 유지하도록 해야 합니다. 🔌
데이브는 제품 관리자(product managers)에게도 교훈을 전합니다. 멀티-리전은 단순히 데이터 복제(data replication)에 관한 것이 아니라 인적 복제(human replication)에 관한 것이라고 강조합니다. 이는 두 개의 온콜(on-call) 로테이션을 깨우고, 두 개의 클라우드 요금을 지불하며, 두 개의 런북(runbook)을 작성하는 것을 의미합니다. 😴
대부분의 경우 재무 부서는 "몇 년에 한 번 발생하는 이벤트에 대해 3배의 비용 증가는 너무 많다"며 거절합니다. 하지만 이번과 같은 날을 맞닥뜨리면, 브랜드 이미지가 나쁜 이유로 입방아에 오르게 되고, 자본 지출(capex)과 명성(reputation)의 차이를 깨닫게 된다고 데이브는 말합니다.
"노아의 방주처럼 모든 것을 다 만들 필요는 없습니다. 하지만 한 가지 주요 사용자 여정(single year user's journey)을 선택하세요. CFO의 눈을 빛나게 할 바로 그 여정을요. 그리고 그것이 어떤 AWS 단일 리전에도 승인 가능하게 독립적(approvably independent)이도록 만드세요. 벽 속에 숨어있는 '음, 이건 US East1이어야 해'라는 가정이 얼마나 많은지 알게 되면 깜짝 놀랄 겁니다." 😲
8. DNS의 역할 재조명 및 결론 💡
데이브는 DNS가 왜 그렇게 중요한 핵심 요소인지 다시 한번 설명합니다. 마이크로서비스(microservice) 세계에서 우리가 발견(discovery)이라고 부르는 것의 대부분은 "DNS에 현재 IP 주소를 물어보는 것"에 불과합니다. DynamoDB나 S3와 같은 관리형 서비스는 안정적인 호스트 이름을 제공하지만, 이 호스트 이름은 실제로는 움직이는 목표물(moving target), 즉 로드 밸런서 뒤에 있는 VIP(Virtual IP)와 여러 서버들을 가리킵니다. 간단히 말해, DNS는 여러분이 상상하는 것보다 훨씬 더 자주 배후에서 실제 IP 주소를 변경합니다. 🔄
데이터베이스 이름이 해석되지 않거나, TCP 핸드셰이크(TCP handshake)를 수락하지 않는 주소로 해석될 때 클라이언트는 "우아하게 저하(degrade gracefully)"되지 않고 발작(thrash)합니다. 좋은 SDK는 다른 주소 체계를 시도하고, 물러섰다가 리졸버(resolvers)를 순환합니다. 훌륭한 SDK는 서비스의 의미가 허용하는 경우 보조 리전(secondary regions)으로 폴백(fallback)합니다. 하지만 많은 스택의 기본 경로는 "여기서 더 크게 재시도(retry here louder)"입니다. 🗣️
규모가 커지면 이러한 "재채기"가 "떼 지어 도주하는 것(stampede)"으로 변합니다. 이것이 AWS가 DNS 캐시를 지우라고 권고했던 이유입니다. 데이브는 이를 "수백만 개의 작은 주머니 우주가 모두 잘못된 답을 잊어야 하는 것"으로 비유합니다. 💫
"US East1이 페일오버에 실패했나요? 음, 꼭 그렇지는 않습니다. 단일 리전 장애로 전 세계적인 결과를 초래하는 방식으로, 즉 허용된 대로 정확하게 실패했습니다. 너무나 많은 고객이 자신의 운명을 단일 리전의 이름 해석과 제어 평면에 묶었기 때문이죠."
중복성은 최우선 과제였지만, 이는 리전 내에서만 적용되었습니다. 앱이 US East1 내의 세 데이터 센터에 트래픽을 분산하여 다중 가용 영역 내구성(multi-availability zone durability)을 가졌다면, 계획했던 SLA(Service Level Agreement)는 충족한 것입니다. 하지만 "우리가 가장 좋아하는 서비스의 전화번호부가 새벽 3시에 고장 나면 어쩌지?"라는 계획은 없었습니다. 데이브는 이것이 AWS가 잘못한 것이 아니라 "지난번 장애를 위해 설계하고 다음번 장애를 위해 설계하지 않은 것"이라고 강조합니다.
인터넷이 실제로 다운되었는지에 대해 데이브는 기술적으로는 아니라고 말합니다. 핵심 라우팅은 유지되었고 전력도 계속 공급되었습니다. 다른 클라우드에서 실행되거나 현명하게 여러 리전에 분산된 많은 사이트들은 계속 작동했습니다. 심지어 X(구 트위터)도 흔들리지 않았다고 머스크는 말했습니다. 🐦
하지만 US East1에 O 상태나 결제를 위해 중요한 경로를 의존하는 엄청난 수의 앱이 일제히 흔들렸습니다. 일반 사용자에게는 이것이 "인터넷이 고장 난 것"과 구별할 수 없습니다. 이것이 바로 이러한 사건이 엔지니어링적 발자취보다 훨씬 크게 느껴질 수 있는 이유입니다. 이러한 인지 격차(perception gap)가 진정한 위험입니다. 😥
"시민들이 우리의 디지털 공유지(digital commons)에 대한 신뢰를 잃으면, 다음 번 실패는, 악의적이든 평범한 것이든, 훨씬 더 큰 충격으로 다가올 것입니다."
마지막으로 데이브는 AWS가 가장 바쁜 리전에서 좋지 않은 날을 보낸 것에 대해 비판하는 것은 공정하다고 말합니다. 그들의 일이니까요. 하지만 더 친절한 해석은 높은 가용성(high availability)이 "약속이 아니라 확률 분포(probability distribution)"라는 것입니다. 📉
올바른 교훈은 "클라우드가 나쁘다"가 아니라 "모든 의존성이 실패할 것이라고 가정하고, 그 실패가 지루하게 만들라"는 것입니다. 이번 사건은 몇 주 안에 "놀랍도록 읽기 쉬운 사후 분석 보고서(postmortem)"를 내놓을 것이고, 시애틀과 헌든의 아주 똑똑한 사람들이 우리가 보거나 걱정할 필요 없는 볼트들을 조일 것입니다. 데이브는 구독을 통해 시청자들이 그 소식을 들을 수 있을 것이라고 마무리하며, 구독과 좋아요를 부탁합니다. 👍
마무리
이번 AWS 서비스 중단 사태는 단순한 기술적 결함을 넘어, 현대 디지털 인프라의 취약성과 '모노컬처'의 위험성을 여실히 보여주었습니다. 데이브의 설명처럼, 클라우드가 제공하는 편리함 뒤에는 복잡한 의존성 네트워크가 존재하며, 이러한 시스템의 진정한 '복원력'은 사전에 철저히 설계하고 연습할 때만 확보될 수 있습니다. 미래의 장애를 예방하기 위해서는 기술적 접근뿐만 아니라, 시스템 설계 철학과 비즈니스 의사 결정 방식에도 근본적인 변화가 필요하다는 점을 강조하며 영상은 마무리됩니다. 🚀