행간의 의미를 간파하라! 클라우드 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) 대시보드는 공급업체의 잘못으로 인한 문제인지 판단하는데 도움을 주는 도구다.