2011.11.10

기고 | 클라우드와 SLA에 대한 불편한 진실

Bernard Golden | CIO
필자는 앞으로 다가올 한 클라우드 컴퓨팅 컨퍼런스의 프로그램들을 살펴보다 계약서와 서비스수준협약(SLA)에 중점을 둔 몇몇 세션들에 주목을 했다. 누구라도 세션에 대한 설명을 읽다 보면 주의를 기울여 SLA를 공들여 만드는 것이야 말로 클라우드 컴퓨팅을 성공적으로 활용할 수 있는 토대가 된다는 결론을 내릴 수 있다.

세션은 다음과 같은 클라우드 컴퓨팅 관련 주제와 관련해 참석자들을 어떻게 도울 수 있는지 상세히 설명하고 있었다.

-가동시간, 가용성, 성능에 대한 정의
-SLA 협상 기법
-SLA에 포함시켜야 할 내용: 가상화 기기의 가용성, 응답 시간, 네트워크 지연 등
-SLA 위반 시 패널티 조율


SLA를 주제로 다룬 많은 토론들을 경청했듯 이들 세션에 대한 설명을 보고 있자니, 피할 수 없는 진실 하나가 떠올랐다. SLA 자체가 가용성을 높여주지는 않는다는 사실이다. SLA는 사고가 발생하고 나서 법적 공방을 위한 근거 자료로 쓰인다는 데 목적을 둘 뿐이다.

하지만 이런 점을 지적하는 세션들은 없었다. 세션 설명서는 SLA를 영리하게 협상하면 애플리케이션이 중단되는 사태를 막을 수 있는 것처럼 설명하고 있다. 이는 진실과는 다소 거리가 있다.

모든 기반은 어떤 식으로든 중단되는 사태가 닥칠 수 있다는 것이 진실이다. 서비스 제공자의 역량을 주의 깊게 평가하면 더 나은 제공자를 선택하는데 도움이 된다. 또 더 비싼 요금을 지불하면 빠른 응답이나 소통을 기대할 수 있다. 하지만 서비스 중단 사태에서도 벗어날 수 없다. SLA 약정을 만드는데 얼마나 시간을 투자하느냐와는 상관없이 100%의 가동시간을 확보할 수는 없다.

그렇다면 사람들이 SLA를 중시하는 이유는 무엇일까?

일정 수준의 통제력을 확보할 수 있다는 점을 가장 먼저 이유로 들 수 있다. 사무실에 앉아서 특별한 대우를 요구하고, 계약서 내용을 가지고 씨름하면서, 특정 조항을 다른 조항으로 변경하면서 사람들은 자신이 상황을 통제하고 있다고 느낀다. 이렇게 하면 안심이 된다. 그러나 서비스 제공자의 계약을 기본적으로 바꿀 수 있다는 생각은 애당초 버리는 게 좋다.

필자는 한 변호사의 SLA 프레젠테이션에서 이런 사실을 알게 됐다. 그는 90분 동안 계약서의 상세한 항목들을 설명하고 난 후 "물론, 여러분은 표준 계약서를 크게 바꿀 수 없습니다. 기본적으로 제공자의 책임을 줄이도록 만들어졌기 때문입니다. 여러분이 논의해야 할 부분은 어느 정도의 서비스를 확보하느냐 하는 것입니다"라고 결론을 맺었다.

사람들은 또 SLA가 서비스 중단 이후의 실랑이에 일종의 근거를 제공해주기 때문에 이를 중시한다. 처음에 공을 많이 들이면 나중에 더 큰 보상을 받을 수 있다. 그러나 명심해야 할 부분이 있다. 얼마나 실랑이를 많이 벌이든, 중단으로 인한 사업상의 손실을 완벽하게 보장 받을 수는 없다는 것이다.

다시 한 번 강조하자면, SLA의 패널티의 금액은 서비스 이용료로 한정돼 있다. 서비스 중단으로 인해 사용자가 안게 되는 손해가 아니라는 뜻이다. 또 서비스 비용 자체가 서비스 중단으로 인해 손해금액의 극히 일부에 불과한 경우가 많다.

여기 대형 아웃소싱 업체에서 근무한 적이 있는 사람이 들려준 사례가 하나 있다. 이 회사의 고객사 중 대형 소매 기업이 이었었는데 이 고객사의 웹사이트가 블랙 프라이데이 동안 중단된 적이 있었다. 애플리케이션이 6시간 동안 사용 불능 상태에 빠지면서 5,000만 달러에 달하는 손실을 입었다. 당시 아웃소싱 업체가 고객사에 제공한 보상은 얼마냐면, 고작 300달러였다. 6시간 동안 서비스를 제공하며 받는 금액만큼만 보상하기 때문이다.

이 이야기가 시사하는 바는 무엇인가? 이런 관점에서 SLA에 논의하라는 것이다. 애플리케이션을 사용 못하게 되더라도 전체 손해금액만큼을 보상 받을 수 는 없다.

SLA를 두고 실랑이를 벌이느라 너무 많은 에너지를 투자하는데 따른 최악의 상황은 더 중요한 사항을 간과할 수 있다는 것이다. 다름 아닌 가동시간을 확보하는 방법이다. 이는 빙산에 충돌해 침몰한 타이타닉호에 타고 있는 것과 같다. 조타실에 앉아 항해 위치와 조건을 이야기하느라 많은 시간을 투자했지만 결국 조그만 빙산을 예측하지는 못했다.

따라서 가장 중요한 사안은 애플리케이션 중단 사태를 어떻게 바라보고 가동시간을 어떻게 개선하느냐는 것이다.

볼테르의 유명한 명언을 염두에 두는 것이 좋다. "너무 잘하려고 하면 오히려 일을 그르친다"는 명언이다. 이는 '완벽함'은 '좋음'의 적이라는 뜻으로도 풀이할 수 있다. 클라우드 컴퓨팅에 적용해보면, "데이터센터의 가동시간이 수용할 수 있는 수준에 크게 미치지 못할 때, 99.999%의 가동시간을 보장 받을 수 없다는 이유로 클라우드 도입을 꺼리지 말라"는 이야기다.

클라우드 컴퓨팅을 도입해 가동시간을 크게 개선할 수 있다면 그렇게 해야 한다. 또 누군가 자신의 독자적인 컴퓨팅 환경의 가동시간에 대한 실제 통계가 없다면, 이는 클라우드 제공 업체로의 이전이 바른 방향이라는 것을 말해주는 신호기도 하다. 완벽하지 않을 수 있다. 그러나 자신의 가동시간을 추적조차 못하는 환경보다는 낫다. 필자의 말을 믿기 바란다. 아주 많은 IT 부서들이 자신의 가동시간 성능에 대해 확언하지 못한다.

다음은 애플리케이션 가동시간을 개선할 수 있는 몇 가지 방법들이다:

1. IT자원 중단에 대비할 애플리케이션을 설계하라. 아마도 애플리케이션 가동시간을 개선할 수 있는 가장 좋은 방법은 개별 자원이 실패하더라도(예, 서버 고장), 지속적으로 성능을 유지할 수 있도록 설계하는 것이다. 애플리케이션 서버를 이중화하면 서버 중단으로 가상화 기기가 중단되는 경우에도 애플리케이션이 계속 실행되도록 할 수 있다. 유사하게 데이터베이스 서버를 복제해 확보하면, 서버 하나가 중단되더라도 애플리케이션이 중단되는 것을 막을 수 있다. 실패한 애플리케이션을 대체하기 위해 새 인스턴스를 시작하는 애플리케이션 관리 프레임워크를 사용하면 중단 상황에서도 이중화 토폴로지가 유지되도록 할 수 있다.

2. 인프라 중단에 대비할 토폴로지를 설계하라. 영리한 설계를 통해 특정 애플리케이션 하드웨어 요소가 고장 났을 때의 애플리케이션 가용성을 보호할 수는 있다. 하지만 애플리케이션 환경이 실패했을 때는 소용이 없다. 애플리케이션이 실행되는 전체 데이터센터가 중단되었다면, 이중화 애플리케이션 설계를 사용하는 것은 효과가 없다. 이 경우 해결책은 애플리케이션을 지리적으로 분산해 도입하는 것이다. 제공자의 대규모 서비스 중단으로 애플리케이션의 일부가 사용 불능 상태에 빠지더라도, 애플리케이션을 지속적으로 운영할 수 있도록 하기 위해서다. 이를 위해서는 한층 복잡한 애플리케이션 설계가 필요하다. 하지만 다운타임으로부터의 보호 수준을 높일 수 있다.

3. 아웃소싱 업체의 중단 사태에 대비하라. 클라우드 제공자의 전체 인프라가 멈출 수 있다. 이렇게 될 확률이 아주 낮기는 하지만 가능성이 전혀 없지는 않다. 예를 들어 서비스 제공자의 전체 네트워크 인프라가 붕괴될 수 있고, 클라우드 제공자가 불시에 서비스를 중단할 수도 있다. 믿기지 않을지 모르겠다. 하지만 두 상황 모두 과거 온라인 서비스에서 실제 일어났던 일이다. 이에 대비한 해결책은 여러 업체를 기반으로 애플리케이션을 확대 설계하는 것이다. 많은 IT업체들은 이렇게 하는 것이 아주 어렵다고 주장하곤 한다. 클라우드 서비스 제공자의 다양성으로 인해 기능성을 달리해 이를 포함시킬 수 있는 애플리케이션을 설계하는 것이 아주 어렵기 때문이다. 그럼에도 불구하고 충분한 계획과 사려 깊은 설계가 바탕이 된다면 이런 애플리케이션 설계를 구현해 도입할 수 있다.

이와 관련 한가지 분명한 사실은, 가동시간의 확실성 수준을 높일수록 기술적인 복잡성도 까다로워진다는 것이다. 이는 더 많이 투자해야 한다는 의미기도 하다.

특정 애플리케이션에 이 정도의 투자가 필요한지 결정할 때는 위험요소도 함께 평가해야 한다. 사업 노출, 투자, 기술 운영에 있어 복잡성 사이의 상쇄효과를 평가해야 하라는 뜻이다. 이는 쉬운 일도 아닐뿐더러 해법도 간단하지 않다. 하지만 SLA를 놓고 실랑이를 벌이다 무익한 상황이 되는 것보다는 수용 가능한 더 나은 결과를 기대할 수 있을 것이다.

*Bernard Golden은 가상화, 클라우드 컴퓨팅 및 관련 이슈를 전문적으로 다루는 컨설팅 기업 하이퍼스트라투스(HyperStratus) CEO다. ciokr@idg.co.kr
2011.11.10

기고 | 클라우드와 SLA에 대한 불편한 진실

Bernard Golden | CIO
필자는 앞으로 다가올 한 클라우드 컴퓨팅 컨퍼런스의 프로그램들을 살펴보다 계약서와 서비스수준협약(SLA)에 중점을 둔 몇몇 세션들에 주목을 했다. 누구라도 세션에 대한 설명을 읽다 보면 주의를 기울여 SLA를 공들여 만드는 것이야 말로 클라우드 컴퓨팅을 성공적으로 활용할 수 있는 토대가 된다는 결론을 내릴 수 있다.

세션은 다음과 같은 클라우드 컴퓨팅 관련 주제와 관련해 참석자들을 어떻게 도울 수 있는지 상세히 설명하고 있었다.

-가동시간, 가용성, 성능에 대한 정의
-SLA 협상 기법
-SLA에 포함시켜야 할 내용: 가상화 기기의 가용성, 응답 시간, 네트워크 지연 등
-SLA 위반 시 패널티 조율


SLA를 주제로 다룬 많은 토론들을 경청했듯 이들 세션에 대한 설명을 보고 있자니, 피할 수 없는 진실 하나가 떠올랐다. SLA 자체가 가용성을 높여주지는 않는다는 사실이다. SLA는 사고가 발생하고 나서 법적 공방을 위한 근거 자료로 쓰인다는 데 목적을 둘 뿐이다.

하지만 이런 점을 지적하는 세션들은 없었다. 세션 설명서는 SLA를 영리하게 협상하면 애플리케이션이 중단되는 사태를 막을 수 있는 것처럼 설명하고 있다. 이는 진실과는 다소 거리가 있다.

모든 기반은 어떤 식으로든 중단되는 사태가 닥칠 수 있다는 것이 진실이다. 서비스 제공자의 역량을 주의 깊게 평가하면 더 나은 제공자를 선택하는데 도움이 된다. 또 더 비싼 요금을 지불하면 빠른 응답이나 소통을 기대할 수 있다. 하지만 서비스 중단 사태에서도 벗어날 수 없다. SLA 약정을 만드는데 얼마나 시간을 투자하느냐와는 상관없이 100%의 가동시간을 확보할 수는 없다.

그렇다면 사람들이 SLA를 중시하는 이유는 무엇일까?

일정 수준의 통제력을 확보할 수 있다는 점을 가장 먼저 이유로 들 수 있다. 사무실에 앉아서 특별한 대우를 요구하고, 계약서 내용을 가지고 씨름하면서, 특정 조항을 다른 조항으로 변경하면서 사람들은 자신이 상황을 통제하고 있다고 느낀다. 이렇게 하면 안심이 된다. 그러나 서비스 제공자의 계약을 기본적으로 바꿀 수 있다는 생각은 애당초 버리는 게 좋다.

필자는 한 변호사의 SLA 프레젠테이션에서 이런 사실을 알게 됐다. 그는 90분 동안 계약서의 상세한 항목들을 설명하고 난 후 "물론, 여러분은 표준 계약서를 크게 바꿀 수 없습니다. 기본적으로 제공자의 책임을 줄이도록 만들어졌기 때문입니다. 여러분이 논의해야 할 부분은 어느 정도의 서비스를 확보하느냐 하는 것입니다"라고 결론을 맺었다.

사람들은 또 SLA가 서비스 중단 이후의 실랑이에 일종의 근거를 제공해주기 때문에 이를 중시한다. 처음에 공을 많이 들이면 나중에 더 큰 보상을 받을 수 있다. 그러나 명심해야 할 부분이 있다. 얼마나 실랑이를 많이 벌이든, 중단으로 인한 사업상의 손실을 완벽하게 보장 받을 수는 없다는 것이다.

다시 한 번 강조하자면, SLA의 패널티의 금액은 서비스 이용료로 한정돼 있다. 서비스 중단으로 인해 사용자가 안게 되는 손해가 아니라는 뜻이다. 또 서비스 비용 자체가 서비스 중단으로 인해 손해금액의 극히 일부에 불과한 경우가 많다.

여기 대형 아웃소싱 업체에서 근무한 적이 있는 사람이 들려준 사례가 하나 있다. 이 회사의 고객사 중 대형 소매 기업이 이었었는데 이 고객사의 웹사이트가 블랙 프라이데이 동안 중단된 적이 있었다. 애플리케이션이 6시간 동안 사용 불능 상태에 빠지면서 5,000만 달러에 달하는 손실을 입었다. 당시 아웃소싱 업체가 고객사에 제공한 보상은 얼마냐면, 고작 300달러였다. 6시간 동안 서비스를 제공하며 받는 금액만큼만 보상하기 때문이다.

이 이야기가 시사하는 바는 무엇인가? 이런 관점에서 SLA에 논의하라는 것이다. 애플리케이션을 사용 못하게 되더라도 전체 손해금액만큼을 보상 받을 수 는 없다.

SLA를 두고 실랑이를 벌이느라 너무 많은 에너지를 투자하는데 따른 최악의 상황은 더 중요한 사항을 간과할 수 있다는 것이다. 다름 아닌 가동시간을 확보하는 방법이다. 이는 빙산에 충돌해 침몰한 타이타닉호에 타고 있는 것과 같다. 조타실에 앉아 항해 위치와 조건을 이야기하느라 많은 시간을 투자했지만 결국 조그만 빙산을 예측하지는 못했다.

따라서 가장 중요한 사안은 애플리케이션 중단 사태를 어떻게 바라보고 가동시간을 어떻게 개선하느냐는 것이다.

볼테르의 유명한 명언을 염두에 두는 것이 좋다. "너무 잘하려고 하면 오히려 일을 그르친다"는 명언이다. 이는 '완벽함'은 '좋음'의 적이라는 뜻으로도 풀이할 수 있다. 클라우드 컴퓨팅에 적용해보면, "데이터센터의 가동시간이 수용할 수 있는 수준에 크게 미치지 못할 때, 99.999%의 가동시간을 보장 받을 수 없다는 이유로 클라우드 도입을 꺼리지 말라"는 이야기다.

클라우드 컴퓨팅을 도입해 가동시간을 크게 개선할 수 있다면 그렇게 해야 한다. 또 누군가 자신의 독자적인 컴퓨팅 환경의 가동시간에 대한 실제 통계가 없다면, 이는 클라우드 제공 업체로의 이전이 바른 방향이라는 것을 말해주는 신호기도 하다. 완벽하지 않을 수 있다. 그러나 자신의 가동시간을 추적조차 못하는 환경보다는 낫다. 필자의 말을 믿기 바란다. 아주 많은 IT 부서들이 자신의 가동시간 성능에 대해 확언하지 못한다.

다음은 애플리케이션 가동시간을 개선할 수 있는 몇 가지 방법들이다:

1. IT자원 중단에 대비할 애플리케이션을 설계하라. 아마도 애플리케이션 가동시간을 개선할 수 있는 가장 좋은 방법은 개별 자원이 실패하더라도(예, 서버 고장), 지속적으로 성능을 유지할 수 있도록 설계하는 것이다. 애플리케이션 서버를 이중화하면 서버 중단으로 가상화 기기가 중단되는 경우에도 애플리케이션이 계속 실행되도록 할 수 있다. 유사하게 데이터베이스 서버를 복제해 확보하면, 서버 하나가 중단되더라도 애플리케이션이 중단되는 것을 막을 수 있다. 실패한 애플리케이션을 대체하기 위해 새 인스턴스를 시작하는 애플리케이션 관리 프레임워크를 사용하면 중단 상황에서도 이중화 토폴로지가 유지되도록 할 수 있다.

2. 인프라 중단에 대비할 토폴로지를 설계하라. 영리한 설계를 통해 특정 애플리케이션 하드웨어 요소가 고장 났을 때의 애플리케이션 가용성을 보호할 수는 있다. 하지만 애플리케이션 환경이 실패했을 때는 소용이 없다. 애플리케이션이 실행되는 전체 데이터센터가 중단되었다면, 이중화 애플리케이션 설계를 사용하는 것은 효과가 없다. 이 경우 해결책은 애플리케이션을 지리적으로 분산해 도입하는 것이다. 제공자의 대규모 서비스 중단으로 애플리케이션의 일부가 사용 불능 상태에 빠지더라도, 애플리케이션을 지속적으로 운영할 수 있도록 하기 위해서다. 이를 위해서는 한층 복잡한 애플리케이션 설계가 필요하다. 하지만 다운타임으로부터의 보호 수준을 높일 수 있다.

3. 아웃소싱 업체의 중단 사태에 대비하라. 클라우드 제공자의 전체 인프라가 멈출 수 있다. 이렇게 될 확률이 아주 낮기는 하지만 가능성이 전혀 없지는 않다. 예를 들어 서비스 제공자의 전체 네트워크 인프라가 붕괴될 수 있고, 클라우드 제공자가 불시에 서비스를 중단할 수도 있다. 믿기지 않을지 모르겠다. 하지만 두 상황 모두 과거 온라인 서비스에서 실제 일어났던 일이다. 이에 대비한 해결책은 여러 업체를 기반으로 애플리케이션을 확대 설계하는 것이다. 많은 IT업체들은 이렇게 하는 것이 아주 어렵다고 주장하곤 한다. 클라우드 서비스 제공자의 다양성으로 인해 기능성을 달리해 이를 포함시킬 수 있는 애플리케이션을 설계하는 것이 아주 어렵기 때문이다. 그럼에도 불구하고 충분한 계획과 사려 깊은 설계가 바탕이 된다면 이런 애플리케이션 설계를 구현해 도입할 수 있다.

이와 관련 한가지 분명한 사실은, 가동시간의 확실성 수준을 높일수록 기술적인 복잡성도 까다로워진다는 것이다. 이는 더 많이 투자해야 한다는 의미기도 하다.

특정 애플리케이션에 이 정도의 투자가 필요한지 결정할 때는 위험요소도 함께 평가해야 한다. 사업 노출, 투자, 기술 운영에 있어 복잡성 사이의 상쇄효과를 평가해야 하라는 뜻이다. 이는 쉬운 일도 아닐뿐더러 해법도 간단하지 않다. 하지만 SLA를 놓고 실랑이를 벌이다 무익한 상황이 되는 것보다는 수용 가능한 더 나은 결과를 기대할 수 있을 것이다.

*Bernard Golden은 가상화, 클라우드 컴퓨팅 및 관련 이슈를 전문적으로 다루는 컨설팅 기업 하이퍼스트라투스(HyperStratus) CEO다. ciokr@idg.co.kr