최악의 클라우드 사고 10선 '값비싼 교훈들'

프란시스의 회사같이 작은 회사들만 피해를 입지도 않았다. 레디트(Reddit)와 포스퀘어(Foursquare)같은 큰 회사들도 아마존 클라우드 사고로 큰 피해를 입었다.

클라우드 제공기업인 랙스페이스(Rackspace)의 루이 무어맨 최고 전략 책임자는 "클라우드는 아주 신뢰할 수 있는 만사형통의 서비스로 홍보되고 있다. 그러나 클라우드 또한 컴퓨팅이다. 컴퓨팅이란 결함이 있을 수 밖에 없다. 따라서 이런 결함들 때문에 피해를 입지 않으려면 준비를 철저히 하는 수밖에 없다"라고 충고했다.

우리는 가장 심각했던 10가지 클라우드 사고를 통해 힘겹게 배울 수 있었던 교훈을 소개하고자 할까 한다. 기업들이 클라우드로 인한 고통을 줄일 수 있는 방법들이다.

최악의 사고 1: 아마존 웹 서비스
네크워크 유지라는 성가신 업무에서 벗어날 수 있다는 부분은 클라우드를 구매할 때 가장 솔깃하게 만드는 부분이다. 그러나 단점이 없을까? 당연히 있다. 예를 들어 클라우드 벤더들이 정기적으로 수행하는 설정 변경 업무 때문에 서비스가 중단되더라도 넋 놓고 서있어야만 한다는 것이다.

이는 지난 4월 아마존의 북 버지니아 데이터 센터에 문제가 발생했을 때 많은 AWS 고객들이 겪어야 했던 사례다. 아마존의 표현을 빌자면 '사소한 문제'에서 비롯된 서비스의 완전 중단 사고이다.

경로가 잘못된 트래픽 시프트가 아마존 EBS(Elastic Block Store)의 볼륨 클러스터에서 리미러링 문제를 발생시키고 이로 인해 백업을 할 수 있는 장소를 찾는 과정의 네트워크 업그레이드 동안 문제가 발생했었다. 이는 궁극적으로 아마존의 미국 동부 지역을 마비시키는 일련의 사고들을 촉발했다.

사실 간단하게 설명한 것이다. 어떻게 된 영문인지 제대로 알고 싶으면 47시간 정도 스케줄을 비운 후 아마존이 발표한 소설 분량의 설명을 읽어야 한다.

이런 상태는 4일 동안이나 지속됐다. 그러나 많은 기업들이 고통 받는 동안, 넷플릭스(Netflix)와 같이 폭풍을 버텨낸 기업들도 있었다.  생존의 비밀은 뭘까? 이런 유형의 문제를 염두에 두고 계획을 세워뒀기 때문이다.

넷플릭스의 엔지니어들은 'AWS 사고 중단에서 배운 교훈'이라는 블로그 포스트를 통해 "우리는 EBS를 주요 데이터 스토리지 서비스로 활용하지 않는 아키텍처를 보유하고 있다. 그리고 우리가 의존하고 있는 심플DB(SimpleDB), S3, 카산드라(Cassandra)는 사고에 영향을 받지 않았다"고 설명했다. 즉 가능한 전 지역에 걸쳐 데이터를 중복하고 특정 지역에서의 서비스 의존을 없앰으로써 AWS 클라우드의 사고로 인한 피해를 피할 수 있었다.

넷플릭스 정도의 규모를 가진 회사가 안전을 확보하려면 어떻게 해야 했을지 생각해보다. 꼼꼼히 생각해야 한다.

개발자들이 웹 앱에 커뮤니케이션을 통합할 수 있도록 지원하는 트윌로(Twilio) 또한 아마존 EC2에 핵심 기반을 호스팅하고 있었다. 그러나 지난 4월의 사고가 발생했을 때, 안정적인 서비스 운용에 는 전혀 문제가 없었다..

트윌로의 공동 설립자겸 CTO인 에반 쿠크는 "클라우드를 기반으로 계획을 수립할 때 네트워크에 작은 문제들이 있을 수 있다는 점을 가정하고 있다. 우리는 호스팅이 실패할 수도 있다는 전제 아래 기반을 구축한다. 따라서 핵심 아키텍처의 단일 컴퓨터나 컴포넌트에 의존을 하지 않는다"라고 설명했다.

최악의 사고 2: 사이트킥(Sidekick)
스마트폰을 이용하면 이동 중에 데이터에 쉽게 액세스할 수 있다. 그러나 여기서 '스마트'란 단어가 '바보가 되지 않는다'는 것을 뜻하지는 않는다. 2009년 가을 티모바일(T-Mobile) 사이트킥(Sidekick) 사고가 이를 입증해준다.

이 사고를 기억하는 이들이 많을 것이다. 마이크로소프트가 소유한 사이드킥의 서비스가 1주일 가까이 사고로 중단되면서, 사용자들이 이메일이나 일정, 기타 개인 데이터를 쓸 수 없었다. 여기에 더해 마이크로소프트는 클라우드에 저장해 놓은 데이터가 손실됐고 복구도 불가능하다고 털어놨다. 세상에나! 천하의 마이크로소프트가 백업을 안해놓은 것이다.

물론 이후 기술이 발전했다. 하지만 남아있는 교훈은 동일하다. 중요한 데이터라면 누군가 다른 사람이 자동으로 이를 보호해줄 것이라고 가정하지 말라는 것이다. 따라서 클라우드 제공자의 긴급 복구 절차를 습득한 후, 중요한 데이터는 개별적으로 백업할 계획과 약정을 수립하는게 좋다.

스마트베어(SmartBear)의 얼라트사이트(AlertSite) 제품 모니터링 부문 부사장인 켄 고즈카인드는 "클라우드에도 동일한 운영 규칙이 적용된다"라며 "클라우드를 이용하는 기업들은 클라우드이기 때문에 비즈니스 영속성 계획에 대한 책임도 클라우드 제공자에게 이관됐다고 가정해서는 안 된다"라고 충고하고 있다.