[칼럼]아마존 '클라우드 장애'로 얻은 교훈

농협 전산 장애로 국내의 모든 시선이 쏠려있는 동안, 미국에서 대형 IT 장애가 발생했다. 지난 4월21일에 온라인 서점으로 잘 알려진 아마존의 클라우드 서비스가, 장애로 인해 짧게는 1일에서 최장 4일 동안 이 서비스를 사용하는 기업들에게 피해를 입혔다.

아마존은, 구글과 마이크로소프트와 함께 클라우드 서비스 분야에서 치열한 경쟁을 벌이고 있는 기업이다. 이 회사는 클라우드 서비스의 안정성을 최대의 장점으로 내세우며 고객을 유치해왔던 터라 이번 클라우드 서비스의 장애로 다소 머쓱해하는 모양새다.

이번 장애에 대한 개략적인 정보는 인터넷 검색을 통해 충분한 정보를 얻을 수 있으리라고 보고, 아마존이 장애 이후에 공개한 장애원인 및 재발방지에 대한 발표 자료를 통해 얻을 수 있는 몇 가지 시사점을 이야기해 보겠다.

■견고한 변경 계획의 중요성

아마존에서 공개한 자료에 따르면, 장애의 최초 원인은 네트워크 구성의 변경작업과 관련돼있다고 한다. 네트워크 회선의 용량을 늘리기 위한 변경작업을 수행하는 중에 실수가 발생했다라는 것이다. (실수가 무엇인지는 밝히지 않았고, 변경프로세스에 대한 감사에 착수했다라고 한다.)

네트워크 용량을 늘이기 위해 1차 네트워크(primary network)를 다른 1차 네트워크로 넘긴다는 것이, 노드 간에 통신용도로 사용되는 저용량의 2차 네트워크(secondary network)으로 전환되는 바람에 장애가 시작되었다고 한다.

개인적인 경험에서 볼 때, 국내의 IT조직내의 상당수 네트워크 담당자들은 변경작업을 수행하는 경우 변경계획을 견고하게 작성하지 않는 경향이 있다. 여기서 견고하지 않다는 것의 의미는 변경작업에 사용되는 명령어들을 순서대로, 명확하게 기술하지 않는다는 것이다.

변경 계획을 견고하게 작성하지 않는 가장 근본적인 이유는 네트워크의 기술적인 부분을 IT조직의 네트워크 담당자 1인만 알고 있기 때문이다. 따라서 견고하게 변경계획을 작성하더라도 내부에서는 이를 검토해줄 사람이 없다.

최악의 경우는 IT조직 내부에는 해당 네트워크 작업의 상세한 내용을 아는 사람이 없고 외부 벤더에 전적으로 의존하는 경우다. 외부 벤더가 제시하는 변경계획에 대한 검토의 끈을 놓는 경우, 모든 네트워크 변경의 위험은 외부 벤더의 손에 놓여지게 된다.

그리고 외부 벤더에서 베테랑이 아닌 갓 교육을 마친 신참을 변경작업에 배치시키는 경우 변경작업의 위험은 급격하게 증가한다.

네트워크 담당자가 변경계획을 견고하게 작성하지 않는 또 하나의 이유는 관행이다. 지금까지 개략적인 변경계획으로 변경을 잘 수행해 왔기 때문에 명령어 수준까지의 변경계획은 불필요하다는 것이다.

■변경계획의 적절한 수준?

과거의 관행을 고수하고자 하는 IT조직은 도대체 어느 수준까지 상세하게 변경계획을 작성해야 하는지에 대해서 불만 섞인 투로 반문하곤 한다. 거기에 덧붙여서 그렇게까지 하는 데가 어떤 곳이 있는지 알려달라고 한다.

변경계획의 수준은 IT조직이 스스로 결정하는 것이다. IT조직이 제공하는 IT서비스가 얼마나 민감한 것인지에 달려있기 때문이다. 본인의 IT서비스가 어느 정도 민감한 것인지에 대한 확신이 없는 IT조직은 결국 변경계획의 수준을 결정하는 데 머뭇거릴 수 밖에 없다.

변경 작업의 종류에 따라서도 변경계획의 수준이 달라질 수 있다. 아마존의 네트워크 담당자는 이번 장애를 유발한 네트워크 회선 증설이 잘못될 경우, 어떤 피해가 발생할 것인지를 예측하는 데 실패했을 수 있다.

변경의 영향을 과소 평가한 결과는 견고하지 않은 변경계획으로 이어지며, 담당자의 경험에 의존하는 네트워크 전환작업이 수행되었고, 이 과정에서 담당자 실수가 발생했으리라는 추측을 해볼 수 있다.

■고가용성 솔루션에 대한 과신

아마존은 클라우드 서비스가 고가용성(High Availability) 아키텍처로 구성되어 있어 특정 하드웨어나 소프트웨어의 장애가 발생하더라도 즉각적으로 대체돼 고객에게 제공되는 클라우드 서비스에는 영향이 없다고 자랑해왔다.

그러나 이번 장애를 통해 아마존이 자랑하던 고가용성 아키텍처에도 결함이 존재한다는 것을 인정하게 되었다.

일반적으로 고가용성 아키텍처라는 것은 여러 개의 서비스 영역으로 전환을 결정하는 단일(single)의 컨트롤 기능이 존재한다. 만약 하나의 서비스 영역에 장애가 발생하면 다른 영역으로 넘겨야 할지를 판단하는 것이 컨트롤 기능의 역할이다.

아마존은 단일 가용존(single availability zone)이 멀티 가용존(multiple availability zone)을 통제하는 콘트롤 패널(control panel)의 기능을 거꾸로 마비시켜, 고가용성 아키텍처의 기능이 상실되는 결과를 초래했다고 한다.

결국 고가용성 아키텍처라고 하는 것도 이것을 통제하는 컨트롤 기능을 마비시키는 사건에 대해서는 무력화될 수 밖에 없다는 것이다. 이 지점이 바로 고가용성 아키텍처의 실패 단일 접점(single point of failure)이다.

■클라우드 서비스에 대한 인식 변화

아마존의 이번 장애를 통해, 기업들은 그간 가지고 있던 클라우드 서비스의 환상에서 벗어나 현실을 보게 되었다. 최첨단 기술로 무장한 클라우드 서비스도 완벽할 수 없으며, 결국 클라우드 서비스를 활용하는 기업들은 이에 대한 대비를 스스로 해야 한다는 것을 깨닫게 됐다.

핵심 비즈니스를 지탱하는 중요 IT서비스를 내부에 둘 것인지 아니면 클라우드 서비스에 둘 것인지를 결정하고, 중요 IT서비스를 클라우드 서비스에 둘 경우 단일 벤더의 클라우드 서비스가 아니라 멀티 벤더의 클라우드 서비스로 구성할 것인지의 전략은 아마존과 같은 클라우드 서비스 제공 회사가 아니라, 서비스를 선택하는 기업들이 결정해야 한다는 점을 분명히 하게 됐다.

■아마존 장애의 고마움

아마존의 클라우드 서비스 장애는 클라우드 서비스와는 상관없이 모든 국내 IT조직들이 벤치마킹 해야 하는 사례라고 생각한다. 지금까지 언급한 시사점은 국내 IT조직들이 대부분 안고 있는 문제들이기 때문이다.

전통적인 IT조직들은 내부에서 발생한 장애에는 호들갑을 떨지만 외부에서 발생한 장애에 대해서는 관망하는 자세를 취하는 경우가 많다.

IT수준이 높고 개선을 위해 부단하게 노력하는 IT조직들은 외부의 장애조차도 내부의 장애로 치환해 피해를 가정해보고 여기에서 많은 개선점을 얻고 있다.

장애가 발생한 아마존에게 “미안하지만 참 고맙다”라는 말을 꼭 전해주고 싶다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.