현재 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 서비스 상태 페이지
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 상태 페이지 참고
"클라우드"나 "인터넷"이라는 말을 "버지니아의 창고"로 바꿔 말해보면 어떨지 생각해볼 필요가 있음. 예를 들어 “우리 서비스는 전적으로 버지니아의 창고에 있음”, “내 모든 파일이 버지니아의 창고에 있음”, “버지니아의 창고는 핵전쟁에도 견디도록 설계됨” 등등. 원문
이미 다양한 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 서비스 상태 페이지