행간의 의미를 간파하라! 클라우드 SLA의 함정

2014년 11월 19일 텍사스에 있는 한 회사의 IT부서는 직원들로부터 마이크로소프트 오피스 365 클라우드 기반 이메일 시스템을 이용할 수 없다는 보고를 받았다.

사용자들이 전화기와 아웃룩에서 이메일을 쓸 수 없는 상태였다. 시간이 지나면서 일부 사용자의 이메일이 정상 상태로 돌아왔지만, 여전히 이메일을 사용할 수 없는 사람들도 있었다. 또 미국 내 직원들의 문제가 해결되자, 해외 직원들이 유사한 문제가 발생했음을 알려오기 시작했다. 일부 직원들은 24시간 동안 이메일을 사용하지 못했다.

서비스 중단 사고 이후, IT책임자들은 SLA(Service Level Agreement)를 위반했다면서 앞다퉈 마이크로소프트에 계약상의 권리를 주장했다. SLA에 따르면, 매달 99.9%의 시간 동안 오피스 및 다른 마이크로소프트 온라인 서비스를 사용할 수 있어야 한다. 이에 미치지 못할 경우, 25%의 크레딧을 고객에게 제공해야 한다. 그러나 마이크로소프트의 답변은 IT책임자들을 당황하게 만들었다. 웹을 통해 서비스를 이용할 수 있었기 때문에, 기술적으로 서비스가 중단된 것이 아니며, 따라서 SLA 위반이 아니라는 주장이었다.

마이크로소프트와의 관계를 감안해 익명을 요구한 한 IT부서 간부는 “웹 서비스라는 옵션을 사용할 의사가 있는 사람, 그럴 수 있는 사람, 이를 알고 있는 사람은 극소수에 불과하다”고 지적했다. 앞서 언급한 이 회사는 서비스 중단 사태 이후 직원들을 대상으로 아웃룩 서비스가 중단됐을 때 웹 이메일을 사용하는 방법을 교육했다.

이 사례에 대한 논평 요구에 마이크로소프트는 “항상 서비스를 제공하려 노력하고 있으며, SLA는 이에 대한 금전적 보증 수단이다. 마이크로소프트 온라인 서비스 제공 시간이 특정 달에 95% 미만으로 떨어질 경우, 고객에게 해당 기간의 요금을 크레딧으로 환불한다”는 보도자료를 보냈다.

앞서 소개한 사례는 클라우드 SLA의 약관을 철저히 이해할 필요가 있음을 보여준다. 엔터프라이즈 서비스 계약은 아주 복잡하다. 이에 마이크로소프트 오피스 365(SaaS 서비스), 마이크로소프트 애저(IaaS와 PaaS)의 SLA를 검토할 때 유심히 살펴봐야 할 10가지를 소개한다. 여기서 소개하는 팁 가운데 상당수는 AWS 등 다른 클라우드 플랫폼에도 적용된다.

1. 계약서와 모든 관련 문서를 정독한다.
당연하게 들리겠지만, 계약서를 읽지 않는 사람들도 있다. 최종 사용자 약관(End User License Agreements)를 대충 흝어보는데 그친다. 피카 커뮤니케이션(Pica Communications)에서 마이크로소프트 라이선싱 문제를 컨설팅하는 폴 드그루트는 “파워포인트 내용만 살펴보고, 덜컥 계약서에 서명하는 사람들이 많다”고 지적했다. 계약서에 이해가 되지 않는 조항이 있다면 도움을 요청하라. SLA를 이해하기 위해서는 읽어야 한다.

그렇다하더라도 계약서는 혼동되기 마련이다. 드그루트는 때론 관련 문서에 관련 정보가 수록되어 있다고 설명했다. SLA 관련 조항은 문서의 한 장으로 요약돼 있을 수 있다. 그러나 계약은 다른 서류에서 규정된 조건과 조항에 적용을 받는다. 따라서 관련 자료를 포함해 전체 계약서를 읽어야 한다.

2. SLA 위반은 즉시 보고한다.
서비스가 중단됐을 때 고객에게 자동으로 크레딧을 제공하는 공급업체가 있는 반면 그렇지 않은 업체도 있다. 따라서 고객은 SLA 조항을 위반하는 상황이 발생했다고 판단할 때, 이를 즉시 통보해야 한다. 드그루트의 고객들 중에는 서비스가 며칠 동안 중단됐는데도 이를 통보하지 않고, 자동으로 크레딧이 반영될 것이라고 확신하는 사람들이 있었다. 그러나 서비스 중단 사고를 기록해 통보해야 다운타임(서비스 중단시간)에 직면했음을 증명할 수 있다. 다시 말해, 문제가 발생하면 이를 기록해 즉시 공급자에게 통보하고, SLA 위반으로 권리를 청구해야 한다.

마이크로소프트는 고객이 사고가 발생한 달을 기준으로 다음 달 말까지 고객 지원 센터에 SLA 위반 클레임을 제출해줄 것을 요구하고 있다. (예를 들어, 2월 중순에 사고가 발생했다면 3월 말까지 통보해야 한다.) 이 클레임에는 ‘자세한 사고 내용’, ‘사고 시간’, ‘영향을 받은 장소와 사용자의 수’, ‘고객의 복구 대책에 관한 내용’이 포함되어야 한다.

3. ‘서비스 가동시간 99.9%=연간 최대 최대 8시간 서비스 중단 가능’을 의미한다.
마이크로소프트의 많은 서비스가 99.9%의 가동시간(Uptime)을 보증한다. 나쁘지 않다. 그러나 99.9%는 연간 8시간 45분의 서비스 중단시간이 허용된다는 의미다. 즉 8시간 45분의 서비스 중단은 SLA 위반이 아니다. 그러나 사용자 입장에서 하루에 8시간 동안 서비스를 사용할 수 없는 상태가 되면 어떨까? 여기 링크된 가동시간 계산기는 SLA 가동시간 보증 조항을 기준으로 특정 공급자의 서비스 중단시간을 계산해 준다.

4. 서비스마다 SLA가 다를 수 있다.
서비스마다 SLA 가동시간 보증 내용이 다를 수 있다. 예를 들어, 마이크로소프트 애저 VM의 경우 가동시간 보증 시간은 99.95%다(Availability Sets 2개 이상 도입). 반면 SQL 데이터베이스의 가동시간 보증 시간은 99.9%이다. 대다수 마이크로소프트 온라인 SaaS 제품은 99.9%의 가동시간을 보증한다. 99.9%는 매달 43분의 서비스 중단이 허용된다는 의미다. 이는 SLA 위반이 아니다.

마이크로소프트 전문 블로거인 트로이 헌트가 지적했듯, 여러 서비스가 순차적으로 중단돼 업무에 지장을 받았더라도, 각 서비스에서 보증한 서비스 중단시간을 별개로 계산해야 한다. 예를 들어, 애저 VM, SQL 데이터베이스, 애저 스토리지에 기반을 둔 시스템이 있다고 가정하자. 특정 달의 첫 날, 애저 VM이 21분간 멈추면서 업무가 중단됐다. 다음 날에는 애저 SQL이 42분간 중단되면서 애플리케이션을 사용할 수 없었다. 그렇지만 둘 모두 SLA 위반이 아니다. 이와 관련해 블로거인 브렌트 스티네만은 여러 서비스의 SLA를 종합적으로 계산하는 방법을 소개하기도 했다.

5. VM의 경우 여러 인스턴스에 배치해야 SLA가 효력을 발휘할 수 있다.
클라우드 컴퓨팅에서 명심해야 할 ‘문구’ 중 하나는 문제 발생에 대비해야 한다는 것이다. 이런 까닭에 마이크로소프트와 AWS 등 고객이 이런 문제 발생에 대비할 수 있는 시스템을 갖춰야 SLA 조건을 충족하는 것으로 규정하는 클라우드 서비스들이 있다. 예를 들어, AWS는 여러 가용지대(Availability Zones : AWS 클라우드와는 별개의 데이터센터)에 VM을 배치하고, VM 사본 모두를 유지하도록 요구한다. 그래야만 SLA가 효력을 발휘한다. 마이크로소프트는 가용지대 대신 가용세트(Availability Sets)라는 표현을 사용하고 있지만, 결국은 같은 의미다. 고객은 이런 SLA 조건에 부합하는 시스템을 구현하려면 주의를 기울여야 한다.

6. ‘무정지’ VM으로 바꾸면서 서비스 중단이 초래될 수 있는데, 이는 SLA 위반이 아니다.
시스템을 무정지형 시스템으로 설계하거나, 다른 VM이나 가용세트에서 대체 작동 하도록 만들면서 재부팅 등 문제가 발생할 수 있다. 새 VM들로 이전할 수 없어 시스템이 중단된 경우, 이는 공급업체의 잘못이 아니며, 따라서 SLA 위반으로 간주되지 않는다. AWS 고객의 경우 넷플릭스(Netflix)의 심미안 아미 케이어스 몽키(Simian Army Chaos Monkey)와 케이어스 고릴라(Chaos Gorilla)를 이용해 시스템의 중단에 대한 허용 한계를 테스트할 수 있다.

7. 정말 서비스가 중단된 것일까? 서비스 업체의 잘못일까?
앞서 소개한 텍사스 소재 회사의 IT부서는 마이크로소프트의 잘못으로 시스템이 중단됐다고 판단했다. 그리고 이는 사실이었다. 그러나 웹을 통해 서비스를 이용할 수 있었기 때문에 서비스가 중단된 것은 아니었으며, 따라서 SLA 위반으로 간주되지 않았다. 앱을 사용할 수 없을 때, 이것이 정말 IT업체의 잘못으로 인한 것일까? 어떤 방식으로도 서비스를 사용할 수 없는 상태일까? 업체의 잘못이 아닌 경우에도 이와 비슷한 클라우드 서비스 중단 사고가 발생한다.

마이크로소프트 SLA에 따르면, 마이크로소프트의 통제 아래 있는 상황에서 서비스가 중단된 경우에만 SLA 위반이 적용된다. 서비스가 중단됐을 경우, IT업체가 아닌 사용자의 잘못이 원인인지 확인해야 한다. 클라우드에 연결되는 네트워크를 예로 들 수 있다. 고객은 서비스 중단이 IT업체의 잘못 때문이며, 정말로 서비스가 중단됐음을 입증해야 SLA 위반에 따른 보상을 받을 수 있다. 마이크로소프트와 AWS가 중단된 서비스를 통보하는 장소인 서비스 무결성(Service Health) 대시보드는 공급업체의 잘못으로 인한 문제인지 판단하는데 도움을 주는 도구다.

8. 서비스 조건이 바뀔 수 있다.
클라우드가 급속도로 변화하는 것이니 만큼 공급업체의 서비스 내용도 바뀔 수 있다. 그리고 서비스 내용과 함께 SLA도 바뀐다. 일반적으로 SLA는 서비스 공급자가 고객에게 서비스나 SLA의 변경을 통보해야 하는지, 고객이 서비스 중단에 대비해야 하는지에 관한 내용을 규정하고 있다. 그러나 고객에게 통보할 지 여부는 공급자 및 서비스에 따라 차이가 있다. 갑작스런 서비스 변경으로 업무에 영향이 초래될 경우, 공급자가 이런 변경을 통보해야 하는지 점검해야 한다.

컨설팅 회사인 디렉션 온 마이크로소프트(Directions on Microsoft)의 조사 담당 부사장 도널드 레탈랙은 “마이크로소프트는 핵심 제품군에 ‘큰 변경’이 있을 경우 이를 고객에게 통보한다”고 말했다. ‘큰 변경(Disruptive Change)’이란 무엇일까? 마이크로소프트는 “고객이나 관리자가 온라인 서비스가 정상적인 운영 상태보다 크게 품질이 저하되는 것을 피하기 위해 조치를 취해야 하는 변경”이라고 정의하고 있다. 마이크로소프트의 다이내믹스 CRM(Dynamics CRM) 플랫폼을 예로 들면, 큰 변경이 있기 6개월 전에 이를 고객에게 통보해야 한다. 다른 변경 사항은 고객에게 통보할 필요가 없다.

9. 예정된 서비스 중단은 SLA 위반이 아니다.
서비스 공급자가 일부러 클라우드 서비스를 중지시키는 경우도 있다. 예를 들어, 버라이즌은 올해 초 약 48시간 동안 계획 아래 서비스를 중지시켰다. 이런 계획에 따른 서비스 중단은 SLA 위반이 아니다. 고객은 공급자에게 계획하고 있는 서비스 중단 계획을 통보하도록 요청할 수 있다.

10. ‘프리뷰’나 베타 서비스에는 SLA가 적용되지 않을 수 있다.
많은 공급자들이 프리뷰 제품이나 무료 서비스를 제공하고 있다. 이런 무료 또는 프리뷰 서비스는 SLA 적용 대상이 아니다. 이런 서비스를 핵심 업무 기능에 적용하기 전에 서비스 이용 조건과 이에 따른 위험을 이해해야 한다.

dl-ciokorea@foundryco.com