Cloud Computing - Day 01

Senior Consultant 한성배 입니다.

 

처음 Cloud 관련 칼럼을 쓰려고 할 때 많이 망설였습니다.

이미 Cloud 에 관련해서는 업계의 화두라고 이야기 되는 만큼 많은 자료가 쇄도하고 있는

상태이고, MS 의 Azure, Amazon 의 AWS 등 관련 정보도 다 읽지도 못할 정도로 많은

정보가 Posting 된 현실이기 때문입니다.

 

하지만, 그 많은 자료 중에서 막상 Cloud 가 무엇일까 라고 생각하게 된다면,

또한 적절한 자료를 찾기에 쉽지 않은 것도 현실인 듯싶습니다.

 

저는 우선 MS 의 PaaS Platform 인 Azure Cloud 를 위주로 이야기를 풀어 나갈까 합니다만,

Azure 도 많은 변화가 있을 예정입니다.

 

Azure 의 변화와 관련해서는 이후 차분히 포스팅을 해 나갈 예정입니다.

 

또한 본격적으로 기술 적인 내용을 다루게 될 초 중반 이전 단계에서는 Cloud 에 대한

일반적인 이해를 돕기 위한 내용과 왜 Cloud 를 도입하는가 등에 대한 소개 관점에서

풀어나갈까 합니다.

 

전체 강좌는 몇 회로 끝날지 모르겠습니다.

그만큼 다루고 싶은 내용도 많고 주제도 많은 만큼, 부지런히 정리하고, 번역해서 올리도록

하겠습니다.

 

첫 시간에는 Cloud 에 대한 소개와, 왜 Cloud 를 도입하는가 등에 대한 이야기부터 풀어

나갈까 합니다.

 

가. What is Cloud Service ?

 

Cloud 라고 하면, 흔히 Daum Cloud , 네이버 N 드라이브 등을 연상하게 됩니다. 실지로

On-Site 에서 만나 뵙는 고객 분들도 그런 질문을 많이 던지시기도 합니다. 혹은, P2P 파일 공유

같은 것으로 인지하시는 분들도 많은 현실입니다.

 

그렇다면 Cloud 의 사전적인 정의부터 보고 넘어가도록 하겠습니다.

출처는 위키백과입니다.

 

“ 클라우드 컴퓨팅(cloud computing)은 인터넷 기반(cloud)의 컴퓨팅(computing) 기술을 의미한다.

인터넷 상의 유틸리티 데이터 서버에 프로그램을 두고 그때 그때 컴퓨터나 휴대폰 등에 불러와서

사용하는 웹에 기반한 소프트웨어 서비스이다. “

일반적으로…

l  클라우드 컴퓨팅은 IT 관련된 기능들이 서비스 형태로 제공되는 컴퓨팅 스타일이다.

l  사용자들은 지원하는 기술 인프라스트럭처에 대한 전문 지식이 없어도 또는 제어할 줄

몰라도 인터넷으로부터 서비스를 이용할 수 있다.

l  IEEE 에서는 "정보가 인터넷 상의 서버에 영구적으로 저장되고 데스크탑이나 테이블

컴퓨터, 노트북, 벽걸이 컴퓨터, 휴대용 기기 등과 같은 클라이언트에는 일시적으로

보관되는 패러다임이다." 라고 말한다.

l  일반적인 클라우드 컴퓨팅에서 소프트웨어와 데이터는 서버에 저장된다.

l  클라우드 컴퓨팅은 웹 2.0, SaaS(software as a service)와 같이 최근 잘 알려진

기술 경향들과 연관성을 가지는 일반화된 개념이다.

l  이들 개념들의 공통점은 사용자들의 컴퓨팅 요구를 만족시키기 위해 인터넷을

이용한다는 사실이다.

 

와 같은 내용으로 서술하고 있습니다.

 

IEEE 에서의 정의와 같이 위의 그림을 보면 수 많은 정보가 다양한 형태로 인터넷 상의 서버에

영구적으로 저장되고, 데스크 탑이나 테이블 컴퓨터 , 노트북 , 벽걸이 컴퓨터 , 휴대용 기기

등과 같은 클라이언트에는 일시적으로 보관되어지는 형태를 볼 수 있습니다.

 

즉, 정보의 형태가 특정 형태 (파일 or 문서 등) 로 한정되어지지 않는 다는 것을 의미합니다.

 

Cloud 는 용도에 따라 사용하는 Cloud 의 형태가 달라지지 않을 까라고 생각합니다만,

Global Business 를 하고 있지 않은 상황이 하더라도, Public Cloud 를 고려한다면,

Globalization 이 가능한 Cloud Provider 를 고려하는 방향으로 하는 것이 나아 보입니다.

 

하지만, Cloud Service 를 제공하는 IDC 의 국제 보안 인증이나,

각종 규약 등의 차원에서 고려해볼 문제입니다.

 

이 부분은 후에 좀더 깊은 내용을 다루면서 보다 자세히 언급할까 합니다.

 

나. Why Cloud ?

 

다음은 On-Premises 에서 운영 중인 서버에서 나타나는 Workload Patterns 에 대한 부분입니다.

 

On-Premises 환경은 기업 사내 환경 또는 IDC 에 서버를 두고 운영하는 환경을 통틀어서,

Cloud 에 올라가 있지 않는 환경으로 이해하시면 될 거 같습니다.

 

================================================================

 

이 패턴은 일정 시간 load 가 발생하다가 일정 시간은 load 가 아예 없다가 하는 형태를

반복하는 패턴입니다. Load 가 언제 발생할지 예측할 수 있다고 해도, 항상 최대 load 만큼의

서버 자원을 확보하여 운영하거나, 혹은 매번 서버 자원을 교체하는 번거로운 작업을

수행해야 할 수 있습니다.

 

이 패턴은 사용량이 점진적으로 증가하는 패턴을 나타냅니다. 이 경우는 비교적 무난하게

서버를 증설 하여 대응할 수 있겠지만, 어느 시점에 어느 정도의 서버를 증설해서

Bandwidth 를 확보해야 할지 명확히 알기는 어려운 문제입니다.

 

 

이 패턴은 load 가 일정 시간만 증가하는 일종의 이벤트 행사와 같은 형태입니다. 어느 시점에

Load 가 증가할지 모르므로 항상 maximum size 로 서버 자원을 확보해둬야 하는 문제가

있습니다. 그만큼 Max 시점이 아닌 경우에는 서버의 자원이 낭비된다는 것을 의미합니다.

 

 

이 경우는 load 가 증가/감소를 반복하는 패턴입니다. 어느 시점에 증가하고, 어느 시점에

감소할지 명확히 알 수 있다면 적절하게 서버를 증설/철수가 가능할거라 예상이 되지만,

실지로는 시점을 명확히 알 수도 없고, 매번 서버를 증설/철수 한다는 것도 쉬운 문제가 아닙니다.

 

================================================================

 

Cloud Service 는 이러한 Workload Pattern 에 최적화 되어 있습니다.

Workload 가 발생할 때, 유연하게 증설되어 load 를 처리하고, load 가 감소하면,

리소스를 줄여서 리소스의 낭비를 막고, 비용을 절검하는 효과를 가져올 수 있습니다.

 

이러한 것을 cloud 의 elastic 한 환경이라고 하며, 기술 구현적인 관점에서는 Cloud 환경이

Auto Scaling 을 지원해야 가능한 문제입니다.

 

*. 왜 클라우드를 사용하는 가?

 

왜 클라우드를 사용하는 가라고 하는 추가적인 이점을 살펴보면 다음과 같은 점들을

언급해 볼 수 있습니다.

 

1. 버전 업그레이드에 따라 re-deploy 할 필요가 없다.

+ 서비스가 전 세계적이거나, 혹은 특정 지역에 종속적이라고 할지라도 많은 서버를

보유하고 있다면, 버전 업그레이드에 따른 re-deploy 도 상당한 작업이 될 것입니다.

하지만, Cloud 는 이러한 배포 문제에 있어서 클라우드 환경에서는 매우 빠르게 배포가

가능하며, 버전 관리 또한 수월한 편입니다.

 

2. 소프트웨어 유통 비용이 없다.

+ 소프트웨어를 생산하였다 하더라도, 유통을 위해서는 많은 절차와 판매 루트의 확보 등 유통 루트를 개척하는 일이 매우 어려운 일입니다. 하지만, 클라우드의 경우 전 세계를 대상으로

배포가 가능하므로, 이러한 유통 루트를 확보하고 유지하기 위한 비용이 들어가지 않습니다.

 

3. Reseller , 총판 등의 중간 Broker 가 없어 Margin 을 높일 수 있다.

+ 기존의 소프트웨어 제품들을 판매하거나 할 때는, Reseller 나 총판 등 거쳐야 하므로,

중간 유통 비용이 많이 소모되었다면, 클라우드 환경에서는 클라우드 프로바이더와

솔루션 프로바이더가 직접 거래를 하게되고, 소비자는 클라우드 환경에서 직접 받게 되므로

이러한 유통 과정을 줄일 수 있어서, 마진의 폭을 높일 수 있게 됩니다.

 

4. 고객과 Cloud Service Vender 간의 관계가 Rock-in 된다.

+ 비슷한 이야기입니다만, 중간 과정이 없으므로 고객과 솔루션 프로바이더의 관계가 직접적으로

Rock-in 이 됩니다.

 

5. 서비스 별 Pricing 을 다양화 할 수 있다.

+ 이 부분은 쉽게 이해하기에는 기존에 Box 타입으로 솔루션을 납품하던 벤더가 PaaS 기반의

클라우드에 서비스를 올려서 가입형 서비스로 전환 시켜 SaaS 형태로 서비스를 함으로써,

Case By Case 의 비용 구조를 월단위,년단위, 혹은 특정 계약 단위 등으로 다양한 과금 모델을

만들 수 있게 됩니다.

 

6. 초기 개발의 Risk 를 줄일 수 있다.

+ 서비스를 Deploy 해보고, 반응이 안 좋을 경우 서비스를 내리는 것도 신속하게 적용이

가능합니다. 우스개 소리로 안 되는 사업은 빨리 접을 수 있습니다. ^^

 

7. 원가 Risk 를 줄일 수 있다.

+ 사용량 만큼만 과금이 되는 구조이므로, 원가 Risk 를 줄일 수 있습니다.

 

8. Azure 에 올라가는 순간 3개의 복사본이 생기므로 가용성이 자동적으로 보장된다.

+ 이 부분은 SQL Azure 에 대한 이야기입니다. 향후에도 언급하겠지만, SQL Azure 의 경우는

배포할 경우, 시스템적으로는 Main Instance 하나만 바라보고 있지만, 내부적으로는 총 3개의

Instance 가 Active 되어 있어서, Main Instance 가 Crush 가 발생했을 경우, 다음 Instance 로

자동으로 연결이 됩니다. 동시에 새로운 Instance 가 하나 더 Active 됩니다.

아주 운이 안 좋게 3개가 동시에 죽는 천재지변과 같은 사태가 발생하지 않는 이상은

높은 수준의 가용성이 확보가 됩니다.

 

9. HA 구축 비용이 없다.

+ 고 가용성을 보장하기 위한 구축 비용을 이야기하는 부분입니다만, 일반적으로 시스템의

고 가용성을 보장하기 위해서는 인프라 구축에 매우 많은 비용이 소모됩니다. 이중화 처리 ,

백업 처리 , 보안 처리 등등 이러한 많은 초기 투자 비용을 줄일 수 있다는 점은 매우

큰 이점이 아닐까 합니다.

10. 구독 모델이기 때문에 매출이 계속 누적되어 시간이 지날수록 매출이 증가합니다.

+ 위에 부분에 나온 내용과 다소 중복인 듯 싶습니다만, 단일 제품을 납품하는 구조가 아니라

가입 형 서비스로의 구축이 가능하기 때문에, 초기 매출이 높지는 않지만, 시간이 지날수록

매출이 증가하는 구조를 가져가게 됩니다.

 

*. Cloud Solution Business 를 위한 요구 사항

 

클라우드 솔루션이 장점을 가지고 있다고 해도, 클라우드로 전환하기 위해서 고려해야 하는

사항들이 분명이 존재할 것입니다. 여기서는 몇 가지 사항에 대해서 우선 언급해 볼까 합니다.

 

1. 솔루션 마이그레이션

+ 기존의 솔루션을 클라우드 플랫폼 구조에 맞게 수정해야 하는 문제가 발생합니다.

때에 따라서는 아키텍처 구조부터 변경을 해야 하는 경우도 발생 할 수가 있는 데,

플랫폼에 종속적인 아키텍처 구조를 가져야 하는 솔루션이나 실시간성이 매우 중요한 솔루션의

경우는 클라우드로의 이관이 불가능 할 수도 있습니다.

 

2. 비즈니스 모델 추가

+ 앞 단에 나왔던 바와 같이 구독형 모델을 추가할 수가 있습니다.

 

3. 월 과금 시스템 구축

+ 클라우드 제공자는 월 과금 시스템을 일반적으로 사용하고 있습니다. 그에 따라서, 솔루션

제공자는 클라이언트에게 월 과금 시스템을 운영하시거나 혹은 클라우드의 월 과금 비용을

클라이언트가 알아서 결제하게 하는 시스템을 채택할 수도 있습니다.

 

4. Overhead 발생 – 매월 과금,입금 확인,서류 처리 등

+ 월 과금 시스템에 기반해서 처리를 하다보면, 기존의 단일 솔루션 납품 구조와는 다른

매월 과금 처리에 대한 Overhead 가 발생할 수도 있습니다.

 

다. 클라우드 서비스 모델

 

 

*. Cloud 서비스 모델을 이해하기 좋은 그림은 위와 같습니다.

노란색 부분은 직접 설정하는 부분이라고 이해하시면 됩니다.

 

1. Packaged Software

+ 클라우드에 들어 있지 않는 솔루션입니다. IDC 에 있건, 회사 내부에서 서비스하건 모두

마찬가지라고 보시면 될 거 같습니다. 일반적으로 네트워크 설정부터, 저장 장치 설정 ,

서버 설정 , 가상화 지원 , O/S 설정 , 미들웨어 , 런타임 설정 , 어플리케이션에서 사용하는

데이터 구조 및 관리에 대한 설정 , 서비스 하는 어플리케이션 설정 등을 모두 직접 관리해야

하며, 보안 , 백업 , 패치 , 업데이트 등등 모두 직접 수행해야 하는 모델입니다.

세세하게 직접 다 컨트롤이 가능하며, 인프라에 종속적인 솔루션이나 실시간성이 중요한 솔루션

구조에 적합하다고 볼 수 있습니다.

기존의 대 부분의 솔루션이 이 구조에 해당됩니다.

 

2. Infrastructure (as a Service) = IaaS

+ AWS 가 대표 주자라고 할 수 있을 거 같습니다. 가상화 단계까지는 클라우드 제공자가

제공하며, 솔루션 개발사는 O/S 단부터의 관리를 수행하게 됩니다. 기존의 솔루션을 거의

그대로 포팅이 가능한 클라우드이며, 몇몇 PaaS 플랫폼에서 지원할 수 없는 미들웨어나 3^rd Party

솔루션 등을 사용할 수 있습니다. 국내의 클라우드 제공사는 IaaS 의 초기 모델 수준이라고

보시면 될 거 같습니다. IaaS 모델도 클라우드 플랫폼이므로 어느 정도 Elastic 한 특성을

가지고 있습니다.

 

3. Platform (as a Service) = PaaS

+ 클라우드 플랫폼에서는 제일 상위의 개념이라고 할 수 있을 거 같습니다. MS 의 Azure 와

Force.com (세일즈포스닷컴의 Salesforces – SaaS 와 다른 서비스 입니다.) 가 PaaS 의 대표적이라

할 수 있을 거 같습니다. PaaS 는 개발자와 개발사에게 인프라나 OS , 플랫폼 관리 등의 부담을

거의 대 부분 경감시킵니다만, 모든 부담을 없애지는 않습니다.

 

4. Software (as a Service) = SaaS

+ 어플리케이션의 소비 관점에서 제공되는 IT 의 서비스 방식을 의미합니다. 쉽게 생각하면,

웹 메일 기업용 서비스나 ERP 서비스 등과 비슷하다고 볼 수 있습니다. 다만, ASP 서비스와

SaaS 서비스는 차이점을 가지고 있습니다. 해외의 경우 세일즈포스닷컴의 CRM 과 같은 서비스가

PaaS 기반위에서 구축되어 서비스 되는 SaaS 서비스라고 볼 수 있을 거 같습니다.

 

99. 그렇다면…

+ On-Premises , IaaS , PaaS 는 서로 배타적이거나 이질적인 관계가 아닙니다. 비즈니스의

요구 사항에 맞게 필요에 따라 적절한 플랫폼을 선택하여 제공하는 것이 가장 최적이 아닐까

합니다.