▲

AWS 장애로 전 세계 인터넷이 ‘소수 기업의 손아귀에 달렸다’는 우려 제기

 (theguardian.com)
6P by GN⁺ 3일전 | ★ favorite | 댓글 3개
  • 세계 최대 클라우드 서비스 AWS의 장애로 수천 개의 웹사이트와 앱이 멈추며, 인터넷 인프라가 소수 기업에 과도하게 의존하고 있다는 경고 제기
  • Snapchat, Roblox, Signal, Duolingo 등 주요 서비스와 Lloyds Bank, Ring, HMRC 같은 공공·금융기관까지 장애 영향권에 포함
  • AWS는 미국 동부 리전의 내부 시스템 오류를 원인으로 지목하며 사이버 공격 가능성은 배제, 몇 시간 만에 대부분 복구됨
  • 전문가들은 “민주적 담론과 저널리즘의 기반이 소수 기업에 종속되어선 안 된다”며, 클라우드 인프라 다변화 필요성 강조
  • 대형 클라우드 기업 중심 구조가 글로벌 인터넷의 취약성을 드러냈다는 평가, 공공 인프라의 기술 주권 논의 촉발

장애 개요

  • AWS의 미국 동부 리전(US-East-1) 에서 발생한 내부 오류로 인해 글로벌 서비스 대규모 중단 발생
    • 현지시간 월요일 오전 8시(영국시간 16시) 경부터 장애 발생
    • Amazon은 “API 오류율과 지연(latency)이 증가했다”고 발표
    • Downdetector에 따르면 전 세계 2,000여 개 기업이 영향을 받았으며, 미국 190만·영국 100만·호주 41만 명 이상이 문제 보고
  • AWS는 “내부 로드 밸런서 감시 서브시스템의 문제”를 원인으로 지목하며 사이버 공격 가능성은 배제함
    • AWS의 DynamoDB 관련 오류로 API 응답이 실패한 것으로 보고됨
    • 트래픽 폭주 방지를 위해 요청 수 제한을 일시적으로 도입
  • AWS는 저녁 무렵 “정상 운영 복귀”를 공식 발표했지만, 일부 서비스는 지속적인 장애 보고를 받음

영향 범위

  • 주요 서비스: Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton 등 다수
  • 영국 내에서는 Lloyds, Halifax, Bank of Scotland 등 금융 서비스와 HMRC(국세청) 웹사이트 접속 장애 발생
  • Ring 도어벨 이용자들은 문 열림 감시 서비스가 중단되었다며 불편 호소
  • Epic Games, Pokémon Go, Wordle 등 글로벌 플랫폼에서도 접속 불가 현상 보고

전문가 분석

  • Dr. Corinne Cath-Speth(Article 19): “민주주의 담론과 독립 언론의 기반이 소수 기업 인프라에 의존하는 건 위험함. 클라우드 다변화가 시급함”
  • Cori Crider(Future of Technology Institute): “영국은 미국 빅테크 의존에서 벗어나야 함. AWS 한 곳 장애로 현대 경제 전체가 멈춘 사례”
  • Madeline Carr(UCL): “대형 클라우드 기업의 자본력 덕에 보안과 확장성은 유지되지만, 전 세계가 같은 리스크에 묶이는 구조는 매우 위험함”
  • Steven Murdoch(UCL): “사이버 공격이 아닌 AWS 내부 운영상의 실수가 원인으로 추정됨”

정부 및 규제 대응

  • 영국 정부는 AWS와 긴급 연락 체계를 가동하고 복구 상황을 모니터링했다고 발표
  • 영국 하원 재무위원회는 AWS를 금융 부문 ‘중요 제3자(critical third party)’로 지정해야 한다고 촉구
    • 지정 시 금융 규제 기관의 감독 대상이 되며, 금융 인프라 안정성 확보 가능
    • 위원장 Meg Hillier는 “AWS가 ‘복원력’을 제공한다면서도 실제로는 취약성을 노출했다”고 비판

배경과 함의

  • AWS는 전 세계 클라우드 시장 점유율 30% 이상으로 1위를 차지
  • Microsoft Azure, Google Cloud와 함께 ‘3대 클라우드 독점 구조’ 형성 중
  • 2024년에도 CrowdStrike의 소프트웨어 오류로 전 세계 Windows PC ‘블루스크린 사태’ 가 발생한 바 있음
  • 이번 사태는 디지털 인프라의 집중화가 가져오는 시스템 리스크를 다시 부각시켰으며, 각국 정부의 기술 주권 및 클라우드 분산 전략 논의에 불을 붙임
▲
chickendreamtree 1일전  [-]

힘내라 네이버 클라우드!

답변달기
▲
kimjoin2 2일전  [-]

"클라우드 싫으면 알아서 구축해서 쓰십시오" 라서 뭐 논의가 가능은 한가 싶내요
멀티클라우드? 구축 및 관리는 조상님이 해주는것도 아니구요.

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

  • 현재 AWS us-east-1에서 여러 서비스가 다운 중임을 논의 중이며, 관련 긴 쓰레드가 여기 있음

  • 2021년 Fastly 장애 때에도 ‘전문가’들이 비슷한 비판을 했지만, 실제로 어떤 뚜렷한 변화는 없었음. 이런 이슈는 일주일 후면 신문에서도 언급되지 않음. 실무자들은 AWS 규모에서 운영하는 일이 얼마나 어려운지 알고 있음. 이런 상황을 대비한 진짜 보완책은 비용이 엄청나서 대다수 기업에선 실익이 극히 적음. 정말로 ‘치명적인’ 서비스라면 이런 장애에 대비하여 설계해야 함이 맞음. 포트나이트에 로그인 못 한다는 건, 이런 대비를 현실적으로 하기도 쉽지 않고 비용이 얼마나 드는지 보여줌. 신문들도 평소엔 멀티리전이나 멀티클라우드의 중요성을 다루지 않다가 사고 터질 때만 언급하고 금방 잊어버림. 결국 기술적인 원인이 뭔지 궁금해하는 정도임. 후속조치 없는 ‘전문가’의 비난은 별 의미 없음. 정작 중요한 건 후속 없는 비난보다 건설적인 사고와 블레임 없는 사후분석임

    • 여기서 말하는 '전문가'들은 실제 인프라나 클라우드 운영 경험이 없는 인물들임. 예를 들어 Dr Corinne Cath-Speth는 인류학 박사, Cori Crider는 변호사, Madeline Carr는 정치학 관련 교수임. 즉, 이들은 논문 쓰고 언론 인터뷰만 하는 사람들이며, 실제 호스팅 서비스 운영 경험이 없음

    • 클라우드 의존성을 비판하다 보면 결국 실질적으로 1년에 16시간 이상의 다운타임을 각오해야 한다는 부분에 동의하게 됨. 몇 시간짜리 장애가 있을 때 개인은 크게 체감하지만, 실제로는 성능 저하가 나머지 8,742시간에 더 치명적일 수 있음. 만약 16시간 다운타임만으로 회사가 망할 상황이면, 나나 상대방이 비즈니스를 잘 모르는 것임. 나는 고가용성, 지오 리던던시, 내구성이 높은 시스템에 더 관심이 있음

    • 꼭 막대한 비용을 들일 필요가 있는 게 아님. 서비스마다 다 견딜 필요도 없음. 서로 다른 공급자를 두면 모두가 동시에 영향을 받지 않게 만들 수 있음

    • 신문에서 다루는 멀티리전/멀티클라우드 리던던시는 실효성이 떨어짐을 강조함. 겉으론 한 리전만 문제인 것 같아도 실제로 여러 리전에 걸쳐 서비스가 영향을 받는 경우가 많음. 멀티클라우드 핫 스탠바이는 인프라가 복잡할수록 비용 부담이 상당함. 초기에 계획 없이 나중에 도입하기엔 매우 난이도가 높음

    • AWS도 스스로 발표하는 리포트를 보면 특정 리전, 특정 서비스(예: DynamoDB)에 지나치게 집중되어 있음. 이런 중앙 집중형 아키텍처가 10년 넘게 관찰되고 있음. 그럼에도 왜 바뀌지 않는지 의문임. 이번 사고로 2,000개가 넘는 서비스가 오랜 시간 다운되었음. AWS 상태 페이지 참고

  • "클라우드"나 "인터넷"이라는 말을 "버지니아의 창고"로 바꿔 말해보면 어떨지 생각해볼 필요가 있음. 예를 들어 “우리 서비스는 전적으로 버지니아의 창고에 있음”, “내 모든 파일이 버지니아의 창고에 있음”, “버지니아의 창고는 핵전쟁에도 견디도록 설계됨” 등등. 원문

    • 실제로 이 창고(버지니아의 창고)는 꽤 괜찮은 창고임. 클라우드를 둘러싼 농담이나 비유들은 현실의 대안을 무시함. 대부분의 비즈니스에게 클라우드의 현실적인 대안은 사무실 복도에 있는 선반임. 전엔 IT 담당자가 오기 전까지 누가 코드 뽑으면 회사 전체가 다운되는 일이 흔했음

  • 이미 다양한 VPS 업체들도 존재하고, 그런 쪽으로 옮기면 비용을 낮췄다는 사례가 꾸준히 올라오는 등, 실상은 클라우드 락인과 마케팅 이슈임

    • 요즘 기업들은 기본적인 EC2 같은 저수준 IaaS가 아니라, DynamoDB, RedShift 같은 AWS의 고수준 PaaS 서비스를 씀. Azure, Google Cloud도 비슷한 상황임. 이러한 고수준 서비스에 종속되면 Hetzner 같은 VPS나 셀프 호스팅으로 이관하는 건 AWS 스택을 직접 다시 설치/운영해야 하므로 엄청나게 복잡해짐. 그저 PostgreSQL만 깐다고 해결될 일이 아님

    • 항상 그런 VPS 쓰고 비용 줄였다는 글에는 ‘AWS는 웹스케일이라 절대 안 죽고, VPS는 한 달 내내 업타임 1일일 뿐’이라는 반론이 달림

    • 아마존도 EC2같은 VPS를 제공하는데, 이번 사고에서 EC2도 영향을 받았는지 궁금함

  • 전문가 의견은 사실 기술보단 지정학적 맥락(예: 국가 전체 시스템이 해외 기업에 실시간으로 의존하는 문제)에 더 초점이 맞춰짐. 보통 일반 회사가 단일 공급자에 의존하는 게 복잡함을 줄이고 장애 빈도상으로도 무리가 아님. 굳이 다중 클라우드를 쓰지 않아도 됨. 한쪽만 사용해도 다운타임 빈도가 더 나아질 수도 있음

    • 언론에 나오는 이런 전문가들은 실제 해결에는 전혀 기여하지 않음. 이슈가 터져야 등장하는 경우가 대부분임

  • 업계 전체가 클라우드 락인에 빠져 있다고 생각함. 이제부터 어떻게 되돌릴 수 있을지 의문임. Docker도 대형 클라우드 업체들과 마찬가지로 락인 문제의 원인 중 하나라 봄

    • 현업 엔지니어나 지원 인력 입장에서는 새벽 1시에 AWS 전체 장애 때문에 모든 게 무너졌다는 걸 발견했을 때, 아무도 이 상황을 바꾸려 하지 않는다는 점이 현실임

    • Docker가 왜 문제인지 궁금함

  • 클라우드 현업을 떠난 지 오래됐지만, 당시에 기본 기능(primitive)은 전 provider가 평준화되고 있었음. 멀티클라우드 리던던시는 너무 비용이 컸던 건지, 기술적 격차가 컸던 건지, 혹은 비즈니스적으로 따질 필요조차 없었던 건지 궁금함. pets vs cattle 슬라이드

    • 여러 클라우드에 배포/운영하는 건 팀 입장에서 관리/인지적 부담이 너무 큼. 두 개 이상의 클라우드 인프라에 대한 전문지식 유지에 인력도 많이 필요함. 작은 팀이나 빠른 팀에는 부적합함. 한 클라우드를 쓰는 단순함이 곧 업타임으로 연결됨. 큰 기업도 대부분 한 클라우드에서 대량 구매로 단가를 낮추는 게 메리트임. 그리고 아무도 AWS 선택했다고 해고당하지 않음

    • 아예 타 클라우드가 자신의 리전에 장애가 나도 대응 못 한다는 점에서 멀티클라우드가 실효성이 적음. 제공사가 여전히 100% 자체 표준을 고집하고 컨트롤 플레인도 kubernetes임. 결국 다들 kubernetes에 정착했음

    • 모든 클라우드가 컴퓨트는 저렴하게 주지만, 네트워크 이그레스는 터무니없이 비쌈. 멀티클라우드 구성하려면 트래픽 비용이 폭증함. 이건 아마도 의도적이라 봄

    • 실제로 클라우드들이 이그레스 요금으로 수익을 맞추는 것 같음. 그런 이유로 멀티클라우드 구성, 심지어 단일 클라우드 내 리전, AZ 간 리던던시조차도 많은 클라우드와 애플리케이션에서 너무 비쌈. 단일 클라우드 내 글로벌 시스템 장애면 리전 리던던시도 소용 없음. 게다가 한 클라우드가 다운됐을 때, 다른 클라우드로 트래픽 옮기는 것도 어렵고 이익 대비 노동이 너무 큼. 대부분의 애플리케이션엔 차라리 그 몇 시간 다운을 감수하고 돈과 노력을 다른 데 쓰는 편이 나음

    • 클라우드에 파일/데이터를 보유한 고객들이 많은데, 공급사와 다른 클라우드에 있다면 서비스 운용이 쉽지 않고 실제 고객유치에도 불리함. 공급사가 곧 시장 표준이 되어 고객들도 해당 클라우드에 데이터를 집중하다 보니, 두 클라우드 모두에 스토리지 사용하는 비용을 정당화하기 어려움. 나도 플랫폼 독립적으로 가려고 시작했지만, 실제로 모든 잠재 고객이 같은 클라우드를 쓰고 있다 보니 복잡성이 줄었음

  • 올해 ‘AWS us-east-1는 업타임 두 자리 9밖에 못 찍겠다’는 예상을 미리 할 수는 없었음

    • AWS를 20년 가까이 써온 사람으로서, 트래픽도 가장 많고 중요도가 높은 us-east-1을 굳이 선택할 이유를 이해할 수 없음. 가장 오래되고 불안정한 곳임

    • EC2 같은 인스턴스도 실제로 영향을 받았는지 궁금함

  • 모두가 다운되면 면책된다는 식으로 생각하지만, 실제로는 평범한 고객 상대 서비스라면 그런 건 통하지 않는 경험임

  • 이번 장애의 원인은 네트워크 로드밸런서 헬스 체크를 담당하는 내부 서브시스템에 문제가 있었음. AWS 서비스 상태 페이지

답변달기