Cloud, Cloud Computing 이 두 단어는 작년 하반기부터 IT계의 유행어입니다.
우리나라에서는 구글이 대명사이죠...
Public Cloud Hosting Service, 그러니까 기존의 웹호스팅이나 서버호스팅처럼 업체가 꾸려놓은 인프라에 사용료만 내고 입주하는 방식의 클라우드 호스팅 서비스의 강자는 보통 아마존 AWS (Amazon Web Services), Rackspace Cloud, Microsoft Azure 정도를 꼽습니다.
문제는 언론에서 워낙 클라우드의 장점인 유연성과 비용 절감 측면만을 강조하다보니 클라우드가 내재하고 있는 단점인 보안, 안정성은 아예 무시되는게 현실입니다...
며칠전인 2011년 4월 21일 01시 41분 PDT (= 2011년 4월 21일 17시 41분 KST) 아마존 AWS 서버중 미국 동부인 버지니아주에 위치한 서버들이 장애가 발생합니다.
AWS중 안타깝게도 버지니아주의 서버에 서비스를 몰아놓았던 원격 심장박동 모니터링 회사 한 곳은 이런 절박한 글을 남기기도 했고..
Heroku라는 SaaS 업체도 미 동부 서버의 문제로 이런 글을 남겼습니다.
AWS 장애 사태의 원인은 AWS의 서비스중 하나인 EBS (Elastic Block Storage)라는 저장소 서비스였습니다.
그동안에도 불안정하고 읽고쓰는 속도가 들쑥날쑥하다는 부정적인 평가가 많더니 결국 사고를 친 셈이죠...
다양한 해외 의견들을 첨부합니다.
http://blog.cloudharmony.com/2011/04/unofficial-ec2-outage-postmortem-sky-is.html
http://justinsb.posterous.com/aws-down-why-the-sky-is-falling
http://status.heroku.com/incident/151
만약 퍼블릭 클라우드 환경에서 서버를 구축할 예정인 분들께서는 사전에 아래의 여섯 가지를 꼭 확인하고 고려하셔야 합니다.
1. 클라우드는 기존의 호스팅 환경보다는 상대적으로 안전하지만 대신 문제가 생기면 오히려 복구는 더 어렵고 오랜 시간이 필요하다.
2. 클라우드 장애에 대비해 물리적으로 복수의 장소에 다중화를 해둬야 한다.
3. 복수의 서버중 어느 한 곳이 죽더라도 시스템 자체가 죽지 않도록 설계한다.
4. 물리적으로 별개의 장소에 수시로 백업을 하도록 정책을 세워야 한다.
5. 문제가 생기면 최대한 빨리 다른 클라우드나 다른 서버로 라우팅을 돌릴 수 있도록 준비해두어야 한다.
6. 일단 사고가 나더라도 대부분의 경우 데이터는 안전하게 남거나 복구 가능하니 너무 패닉에 빠지지 않는다.
물론 정말 중요하고 끊겨서는 안되는 데이터나 서비스는 왠만하면 클라우드를 사용하지 않는 것도 해답이 됩니다.
가상화 솔루션보다는 가상화 솔루션을 거치지 않고 직접 작동하는 시스템이 신뢰도는 더 높으니까요. ;)
댓글 없음:
댓글 쓰기