태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

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 플랫폼에서 지원할 수 없는 미들웨어나 3rd 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 는 서로 배타적이거나 이질적인 관계가 아닙니다. 비즈니스의

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

합니다.

 

신고
저작권
Creative Commons License
Posted by 마호메이


티스토리 툴바