2012.05.02

아마존 정전 사고 1년, 클라우드 안전성을 생각한다

Brandon Butler | Network World

전문가들은 기업이 IT업체들의 정전 사태에서 안전하려면, 스스로 이를 점검하지 않으면 안된다고 경고했다.

지난해 4월 아마존 웹 서비스 중단 사고가 발생한 지 1년이 지났다. 당시로서는 역대 최악의 클라우드 서비스 중단 사고였다. 레디트(Reddit), 포스퀘어(Foursquare), 훗스위트(HootSuite), 쿠오라(Quora) 등 대형 고객들이 많게는 4일간 서비스를 사용하지 못했다.

그렇다면 1년이 지난 지금, 선도적인 IaaS 및 클라우드 서비스 제공업체들은 이런 대형 사고를 방지하기 충분할 만큼 변화를 이뤄냈을까? 또 만약 이런 대형 사고가 반복된다면, 기업들은 어떻게 대비를 해야 할까? 전문가들에 따르면, 여기에 대한 대답은 정해져 있지 않다.

부분적으로 이런 질문에 대한 대답이 어려운 이유는 AWS가 방대한 클라우드 운영과 관련해 수행한 내부 작업에 대한 정보를 공개하지 않고 있기 때문이다. 지난해 4월에만 서비스 중단 사고가 있었던 건 아니다. 8월에도 짧은 기간이었지만 서비스가 중단된 적이 있었다. 더 나아가, 클라우드 고객 각자가 어떤 준비를 하고 있는지 파악하기 어렵다. IDC의 스테판 헨드릭 애널리스트 같은 업계 전문가들은 많은 기업들이 제대로 준비를 갖추지 못한 상태라고 말하고 있다.

변화 1 : 기업 스스로 대비책 마련
헨드릭은 1년 전 AWS 서비스 중단 사태를 상기시키며 "일부는 서비스 중단에 대비하고 있다. 그러나 일부는 서비스가 중단되면 큰 타격을 입을게 분명하다. 학습 효과가 있었던 건 확실하다. 그러나 문제는 고객이 스스로를 보호하기 위해 해야 할 일을 하느냐다"라고 지적했다.

먼저, 지난해 사고를 되짚어보자. AWS는 서비스가 중단되고 몇 주 후 발표한 사후 보고서를 통해 사고 원인과 회사가 취한 조치를 설명했다. 기본적으로 사람의 실수가 연쇄반응을 불러왔다. 2011년 4월 21일 이른 아침, AWS 동부 해안 지역의 EBS(Elastic Block Storage) 서비스를 업그레이드하려 시도했다. EBS는 EC2(Elastic Cloud Computer) 서비스의 스토리지 기능이다. 이 EBS 네트워크를 용량이 적은 기반으로 이전하려 했다.

그러나 EBS 시스템의 트래픽을 처리할 준비가 되어 있지 않았다. EBS 노드는 독자적으로 문제를 고치려 했고, 이 과정에 네트워크 트래픽 잼 현상이 발생했다. 그리고 이는 다른 AWS 기능들인 RDS(Relational Database Service)와 로그 스토리지 기능으로 순식간에 확산됐다. 결과적으로 영향을 받은 지역에 위치한 EBS 노드 가운데 13%가 영향을 받았다. 또 4일 동안 영향을 받은 데이터 가운데 0.07%가 영구 손실됐다.

전문가들은 AWS가 이 사고 이후 시스템을 개선했지만, 어느 정도 제대로 개선했는지는 불확실하다고 말하고 있다. 예를 들어, AWS는 사후 보고서를 통해 변경 프로세스 일체를 조사했으며, 인적 요소에서 비롯되는 실수를 없애기 위해 자동화 툴에 기반을 둔 업그레이드를 늘렸다고 발표했다. 가트너에서 클라우드 산업과 AWS를 담당하는 애널리스트 드류 리브스는 1차와 2차 EBS 네트워크는 고용량의 네트워크를 처리할 수 있도록 개선됐다고 말했다. 그는 "EBS의 복원성이 개선됐다. AES는 이런 사고가 다시 발생하지 않도록 조치를 취했다. 그러나 또 다시 서비스가 중단되지 않는다는 보장은 없다"라고 전했다.

아마존은 특정 지역에서 문제가 발생했을 때 다른 서비스에 영향을 주지 않도록 조치를 취했다고 발표했다. 또 고객들이 AWS 제품을 이용해 내고장성 시스템을 구축하기가 더욱 쉬워졌다고 강조했다. 리브스에 따르면, 아마존은 클라우드 운영과 관련된 아키텍처를 비밀에 부치고 있다. 이런 이유로 보안 취약성을 평가하기가 쉽지 않다.




2012.05.02

아마존 정전 사고 1년, 클라우드 안전성을 생각한다

Brandon Butler | Network World

전문가들은 기업이 IT업체들의 정전 사태에서 안전하려면, 스스로 이를 점검하지 않으면 안된다고 경고했다.

지난해 4월 아마존 웹 서비스 중단 사고가 발생한 지 1년이 지났다. 당시로서는 역대 최악의 클라우드 서비스 중단 사고였다. 레디트(Reddit), 포스퀘어(Foursquare), 훗스위트(HootSuite), 쿠오라(Quora) 등 대형 고객들이 많게는 4일간 서비스를 사용하지 못했다.

그렇다면 1년이 지난 지금, 선도적인 IaaS 및 클라우드 서비스 제공업체들은 이런 대형 사고를 방지하기 충분할 만큼 변화를 이뤄냈을까? 또 만약 이런 대형 사고가 반복된다면, 기업들은 어떻게 대비를 해야 할까? 전문가들에 따르면, 여기에 대한 대답은 정해져 있지 않다.

부분적으로 이런 질문에 대한 대답이 어려운 이유는 AWS가 방대한 클라우드 운영과 관련해 수행한 내부 작업에 대한 정보를 공개하지 않고 있기 때문이다. 지난해 4월에만 서비스 중단 사고가 있었던 건 아니다. 8월에도 짧은 기간이었지만 서비스가 중단된 적이 있었다. 더 나아가, 클라우드 고객 각자가 어떤 준비를 하고 있는지 파악하기 어렵다. IDC의 스테판 헨드릭 애널리스트 같은 업계 전문가들은 많은 기업들이 제대로 준비를 갖추지 못한 상태라고 말하고 있다.

변화 1 : 기업 스스로 대비책 마련
헨드릭은 1년 전 AWS 서비스 중단 사태를 상기시키며 "일부는 서비스 중단에 대비하고 있다. 그러나 일부는 서비스가 중단되면 큰 타격을 입을게 분명하다. 학습 효과가 있었던 건 확실하다. 그러나 문제는 고객이 스스로를 보호하기 위해 해야 할 일을 하느냐다"라고 지적했다.

먼저, 지난해 사고를 되짚어보자. AWS는 서비스가 중단되고 몇 주 후 발표한 사후 보고서를 통해 사고 원인과 회사가 취한 조치를 설명했다. 기본적으로 사람의 실수가 연쇄반응을 불러왔다. 2011년 4월 21일 이른 아침, AWS 동부 해안 지역의 EBS(Elastic Block Storage) 서비스를 업그레이드하려 시도했다. EBS는 EC2(Elastic Cloud Computer) 서비스의 스토리지 기능이다. 이 EBS 네트워크를 용량이 적은 기반으로 이전하려 했다.

그러나 EBS 시스템의 트래픽을 처리할 준비가 되어 있지 않았다. EBS 노드는 독자적으로 문제를 고치려 했고, 이 과정에 네트워크 트래픽 잼 현상이 발생했다. 그리고 이는 다른 AWS 기능들인 RDS(Relational Database Service)와 로그 스토리지 기능으로 순식간에 확산됐다. 결과적으로 영향을 받은 지역에 위치한 EBS 노드 가운데 13%가 영향을 받았다. 또 4일 동안 영향을 받은 데이터 가운데 0.07%가 영구 손실됐다.

전문가들은 AWS가 이 사고 이후 시스템을 개선했지만, 어느 정도 제대로 개선했는지는 불확실하다고 말하고 있다. 예를 들어, AWS는 사후 보고서를 통해 변경 프로세스 일체를 조사했으며, 인적 요소에서 비롯되는 실수를 없애기 위해 자동화 툴에 기반을 둔 업그레이드를 늘렸다고 발표했다. 가트너에서 클라우드 산업과 AWS를 담당하는 애널리스트 드류 리브스는 1차와 2차 EBS 네트워크는 고용량의 네트워크를 처리할 수 있도록 개선됐다고 말했다. 그는 "EBS의 복원성이 개선됐다. AES는 이런 사고가 다시 발생하지 않도록 조치를 취했다. 그러나 또 다시 서비스가 중단되지 않는다는 보장은 없다"라고 전했다.

아마존은 특정 지역에서 문제가 발생했을 때 다른 서비스에 영향을 주지 않도록 조치를 취했다고 발표했다. 또 고객들이 AWS 제품을 이용해 내고장성 시스템을 구축하기가 더욱 쉬워졌다고 강조했다. 리브스에 따르면, 아마존은 클라우드 운영과 관련된 아키텍처를 비밀에 부치고 있다. 이런 이유로 보안 취약성을 평가하기가 쉽지 않다.


X