2011.08.09

기고 | 진단 데이터 기반으로 클라우드 SLA 수립하기

Gregory Machler | CSO
애플리케이션을 프라이빗/퍼블릭 클라우드에 성공적으로 이식하려면 어디에서부터 시작해야 할까?

CSO와 CIO들이라면 기업의 가장 중요한 웹 제품을 이해하는 것과 관련해 왜 '진단'(diagnostic)을 강조하는지 의아해할 수 있겠다. 원래 진단이란 서비스 공급자의 클라우드로 성공적으로 이식할 애플리케이션을 선정하고 그 방법을 파악하는데 목적을 두고 있었기 때문이다.

보통 이런 진단을 통해 애플리케이션이 어떤 클라우드 IaaS 제품(스토리지, 네트워크, 가상화 장치)이 필요한지 판단한다. 또 PaaS 계층에서 플랫폼 요소(서버/운영 시스템, 웹 서버)를 다룬다. 마지막으로 SaaS 소프트웨어 애플리케이션에 중점을 둔다.

그리고 정확하게 분석을 하고 나면, 기업의 상위 10대 애플리케이션 전부를 퍼블릭/프라이빗 클라우드와 연결한다. SaaS 계층에서 실행되는 소프트웨어에 영향을 미치지 않는 한 (여러 버전의 가상화 소프트웨어, 또는 이후 출시된 운영시스템을) 간단하게 이식할 수 있다.

10개 애플리케이션 모두를 대상으로 애플리케이션을 만들 수 있고, 또 기반 제품의 각기 다른 부분에 위치한 하나 이상의 애플리케이션을 통합할 수 있다. 그렇다면 무엇을 테스트 해야 성공을 보장받을 수 있을까?

필자는 서비스 제공자들이 잠재적 클라우드 고객에게 보여줄 수 있는 가장 중요하면서도 어려운 작업이 재난 긴급 복구라고 주장하곤 한다. 따라서 재난 긴급 복구 계획 테스팅에 아주 높은 우선 순위를 부여해야 한다.

또 재난 긴급 복구를 목적으로 수집한 정보는 주요 웹 애플리케이션을 클라우드 서비스 제공자에게 보내는데 필요한 정보들이다. 즉 각 애플리케이션에 대한 분석을 통해 서비스 제공자에게 이들을 클라우드로 이전해 테스팅하는 방법을 보여줄 수 있다.

이는 클라우드 서비스 제공자가 설정한 (모든 10개 애플리케이션에 필요한) 기본 애플리케이션과 이들 애플리케이션의 성공적인 긴급 복구에 필요한 추가 기능성을 테스트한다.  

더 중요한 부분이 있다. 진단은 기업과 클라우드 서비스 제공자 사이의 SLA (Service Level Agreement) 수립에 필요한 기능이 무엇인지 판단하는데 도움을 준다. 사실 분석가의 또 다른 최종 목표는 SLA를 정확하게 창출하는 것이다.

그렇다면 서비스 공급자로부터 비롯될 수 있는 다양한 고장을 고려하도록 SLA를 확실히 수립하려면 어떻게 해야 할까? 뭘 먼저 분석해야 할까?

각 지원 애플리케이션에 여전히 성능 매트릭스가 필요하다. 이 밖에도 적절한 성능 매트릭스를 준비하기 위해 답을 구해야 할 질문들이 있다. 참고로 다음은 대표적인 질문들이다. 반드시 모든 질문에 답을 구할 필요는 없다.

* 웹 브라우저 애플리케이션에 가장 잘 들어맞는 사용자 대응 유형은?

* 로드(20% 동시 사용자)하에서 웹 브라우저 애플리케이션의 응답 시간은?

* 각 클라우드 계층에 위치한 각 애플리케이션 컴포넌트의 실패를 복구하기까지 걸리는 시간은?

* 컴포넌트 실패가 특정 애플리케이션의 브라우저에 영향을 미치는지?

* 전체 데이터 센터에 재난이 닥쳤을 때 복구에 걸리는 시간은?

* 각 실패 별로 애플리케이션 비용은?

* 각 애플리케이션 별로 잠재적인 수익 손실이 있을까?

* 이런 애플리케이션의 실패와 관련된 브랜드 비용은?

* 애플리케이션 실패가 있을 경우 소송이 제기될 확률은?

마지막으로 애플리케이션 별로 정보들을 SLA에 반영해야 한다. SLA에서는 다양한 유형의 다운타임 에러 별로 기능 요건, 성능 매트릭스, 금전적 배상이 규정되어 있어야 한다.

서비스 제공자는 클라이트언트 아키텍처 모델과 제품을 고려해 동일한 제품과 소프트웨어로 이뤄진 동일한 아키텍처를 제공할 필요는 없다는 점을 명심해야 한다. 제공자는 유사한 기능과 대응 시간만을 충족하면 될 뿐이다.

또 SLA에 아키텍처 위험 영역을 명기해야 한다. 예를 들어 PaaS 계층의 데이터베이스 제품은 특정 한 개 벤더일 수 있다. 데이터베이스 벤더가 소프트웨어 출시에 약점을 보유하고 있다면 특정 데이터베이스를 사용하는 애플리케이션에 영향을 미칠 수 있다. 시스템 측면의 위험이다. 따라서 이런 부분들을 규정해야 하고 다운타임 비용을 계산해 기록해야 한다.

만약 공공에 기밀로 유지해야 하는 데이터를 보유하고 있는 애플리케이션이라면 브랜드 가치 손실에 따른 비용과 잠재적인 소송 관련 내용을 각 애플리케이션 별로 SLA에 포함해야 한다.

간단히 말해, 애플리케이션을 클라우드로 이전하려고 고려하고 있는 기업들은 중요한 웹 기반 애플리케이션 분석을 위해 진단이라는 방법을 활용할 수 있다. 제공기업이 동일한 아키텍처나 제품을 사용할 필요가 없지만 각 애플리케이션 별로 SLA를 준수해야 하기 때문이다. 진단과 관련한 질문 외에, 각 웹 애플리케이션 별로 성능 데이터를 수집해 SLA를 작성할 수 있도록 해야 한다. ciokr@idg.co.kr



2011.08.09

기고 | 진단 데이터 기반으로 클라우드 SLA 수립하기

Gregory Machler | CSO
애플리케이션을 프라이빗/퍼블릭 클라우드에 성공적으로 이식하려면 어디에서부터 시작해야 할까?

CSO와 CIO들이라면 기업의 가장 중요한 웹 제품을 이해하는 것과 관련해 왜 '진단'(diagnostic)을 강조하는지 의아해할 수 있겠다. 원래 진단이란 서비스 공급자의 클라우드로 성공적으로 이식할 애플리케이션을 선정하고 그 방법을 파악하는데 목적을 두고 있었기 때문이다.

보통 이런 진단을 통해 애플리케이션이 어떤 클라우드 IaaS 제품(스토리지, 네트워크, 가상화 장치)이 필요한지 판단한다. 또 PaaS 계층에서 플랫폼 요소(서버/운영 시스템, 웹 서버)를 다룬다. 마지막으로 SaaS 소프트웨어 애플리케이션에 중점을 둔다.

그리고 정확하게 분석을 하고 나면, 기업의 상위 10대 애플리케이션 전부를 퍼블릭/프라이빗 클라우드와 연결한다. SaaS 계층에서 실행되는 소프트웨어에 영향을 미치지 않는 한 (여러 버전의 가상화 소프트웨어, 또는 이후 출시된 운영시스템을) 간단하게 이식할 수 있다.

10개 애플리케이션 모두를 대상으로 애플리케이션을 만들 수 있고, 또 기반 제품의 각기 다른 부분에 위치한 하나 이상의 애플리케이션을 통합할 수 있다. 그렇다면 무엇을 테스트 해야 성공을 보장받을 수 있을까?

필자는 서비스 제공자들이 잠재적 클라우드 고객에게 보여줄 수 있는 가장 중요하면서도 어려운 작업이 재난 긴급 복구라고 주장하곤 한다. 따라서 재난 긴급 복구 계획 테스팅에 아주 높은 우선 순위를 부여해야 한다.

또 재난 긴급 복구를 목적으로 수집한 정보는 주요 웹 애플리케이션을 클라우드 서비스 제공자에게 보내는데 필요한 정보들이다. 즉 각 애플리케이션에 대한 분석을 통해 서비스 제공자에게 이들을 클라우드로 이전해 테스팅하는 방법을 보여줄 수 있다.

이는 클라우드 서비스 제공자가 설정한 (모든 10개 애플리케이션에 필요한) 기본 애플리케이션과 이들 애플리케이션의 성공적인 긴급 복구에 필요한 추가 기능성을 테스트한다.  

더 중요한 부분이 있다. 진단은 기업과 클라우드 서비스 제공자 사이의 SLA (Service Level Agreement) 수립에 필요한 기능이 무엇인지 판단하는데 도움을 준다. 사실 분석가의 또 다른 최종 목표는 SLA를 정확하게 창출하는 것이다.

그렇다면 서비스 공급자로부터 비롯될 수 있는 다양한 고장을 고려하도록 SLA를 확실히 수립하려면 어떻게 해야 할까? 뭘 먼저 분석해야 할까?

각 지원 애플리케이션에 여전히 성능 매트릭스가 필요하다. 이 밖에도 적절한 성능 매트릭스를 준비하기 위해 답을 구해야 할 질문들이 있다. 참고로 다음은 대표적인 질문들이다. 반드시 모든 질문에 답을 구할 필요는 없다.

* 웹 브라우저 애플리케이션에 가장 잘 들어맞는 사용자 대응 유형은?

* 로드(20% 동시 사용자)하에서 웹 브라우저 애플리케이션의 응답 시간은?

* 각 클라우드 계층에 위치한 각 애플리케이션 컴포넌트의 실패를 복구하기까지 걸리는 시간은?

* 컴포넌트 실패가 특정 애플리케이션의 브라우저에 영향을 미치는지?

* 전체 데이터 센터에 재난이 닥쳤을 때 복구에 걸리는 시간은?

* 각 실패 별로 애플리케이션 비용은?

* 각 애플리케이션 별로 잠재적인 수익 손실이 있을까?

* 이런 애플리케이션의 실패와 관련된 브랜드 비용은?

* 애플리케이션 실패가 있을 경우 소송이 제기될 확률은?

마지막으로 애플리케이션 별로 정보들을 SLA에 반영해야 한다. SLA에서는 다양한 유형의 다운타임 에러 별로 기능 요건, 성능 매트릭스, 금전적 배상이 규정되어 있어야 한다.

서비스 제공자는 클라이트언트 아키텍처 모델과 제품을 고려해 동일한 제품과 소프트웨어로 이뤄진 동일한 아키텍처를 제공할 필요는 없다는 점을 명심해야 한다. 제공자는 유사한 기능과 대응 시간만을 충족하면 될 뿐이다.

또 SLA에 아키텍처 위험 영역을 명기해야 한다. 예를 들어 PaaS 계층의 데이터베이스 제품은 특정 한 개 벤더일 수 있다. 데이터베이스 벤더가 소프트웨어 출시에 약점을 보유하고 있다면 특정 데이터베이스를 사용하는 애플리케이션에 영향을 미칠 수 있다. 시스템 측면의 위험이다. 따라서 이런 부분들을 규정해야 하고 다운타임 비용을 계산해 기록해야 한다.

만약 공공에 기밀로 유지해야 하는 데이터를 보유하고 있는 애플리케이션이라면 브랜드 가치 손실에 따른 비용과 잠재적인 소송 관련 내용을 각 애플리케이션 별로 SLA에 포함해야 한다.

간단히 말해, 애플리케이션을 클라우드로 이전하려고 고려하고 있는 기업들은 중요한 웹 기반 애플리케이션 분석을 위해 진단이라는 방법을 활용할 수 있다. 제공기업이 동일한 아키텍처나 제품을 사용할 필요가 없지만 각 애플리케이션 별로 SLA를 준수해야 하기 때문이다. 진단과 관련한 질문 외에, 각 웹 애플리케이션 별로 성능 데이터를 수집해 SLA를 작성할 수 있도록 해야 한다. ciokr@idg.co.kr

X