출처 : http://msdn.microsoft.com/ko-kr/aa699427.aspx
Mapping Applications to the Cloud
.jpg)
애플리케이션을 클라우드에 매핑
Darryl Chantry
요약:전 세계적으로 경제적 압박이 커지면서 많은 기업들이 IT 관련 TCO(총 소유 비용)를 절감하기 위한 대안으로 클라우드 컴퓨팅에 눈을 돌리기 시작했다. 클라우드 컴퓨팅 기술을 활용하는 방법을 모색할 때에는 비즈니스 특성상 클라우드 컴퓨팅을 고려할 수 있는지 등을 자문해 봄으로써 클라우드로 이동하기에 적합한 애플리케이션과 그렇지 않은 애플리케이션을 확인하는 과정을 거쳐야 한다.
이 글은 클라우드 컴퓨팅의 개념을 개괄적으로 설명하고, 자신의 애플리케이션 또는 비즈니스 모델이 클라우드로 이동하기에 적합한지 여부를 판단하기 위해 엔터프라이즈 애플리케이션을 클라우드 컴퓨팅 플랫폼에 매핑하는 방식에 대해 논의한다.
클라우드가 먼저인가, 클라우드 컴퓨팅이 먼저인가?
클라우드 컴퓨팅은 소규모 ISV(Independent Software Vendor), 실리콘 밸리 신생 기업, 비용 절감을 모색하는 대기업 등 전 세계 수많은 IT(정보 기술) 전문가들의 상상력에 불을 지폈피고 있다. 모든 IT 문제를 해결할 특효약을 개발하기 위해 클라우드에 주목하는 사람들이 점점 늘어나는 추세이다.
클라우드 컴퓨팅에 관한 대대적인 광고에서 한 가지 흥미로운 점은 무엇이 클라우드 컴퓨팅은 무엇인지, 그리고이고 그것이 아닌 것은클라우드 컴퓨팅이 아닌 것은 무엇인아닌지에 관한 명확한 정의가 부족결여되어 있하다는 것이다. 100명의 사람들에게 클라우드의 정의와 클라우드 컴퓨팅이 무엇이라고 생각하는지에 대해 묻는다면한 질문을 던진다면 아마도 150개의 다른 답변을 듣게 될 것이다. 두 번 대답하길 좋아하는 어떤 사람들은 두 번째 대답을을 하는데 첫 번째 대답에이 두 번째 대답과 모순되게 말하기도 한다.는 경우가 있다. 이러한 실정을 감안한다면 클라우드 컴퓨팅에 대한 전반적인 정의를 먼저 살펴보는 것이으로 이 글을 시작하는 것이 적절할 듯 싶다.
클라우드(또는원한다면 ‘인터넷’이라고 하자)가 등장한 지 25년 정도 되었으니 의심의할 여지 없이 클라우드가 클라우드 컴퓨팅보다 먼저가 아닐까닌가? 혹자는 인터넷에 최초로 설치된 서버는 사실상 데이터와 애플리케이션을 전역에서으로 공유 및 실행하기 위해서, 즉 여러 곳에 전역적으로 여러 곳에 배치구축된 클라우드 컴퓨팅 리소스에 거의 무한에 가까운한 확장성을 제공하기 위해 설치된 저장 장치였다고 주장할 수도 있을 것이다. 이를 주로 데이터, 애플리케이션 및 컴퓨팅 성능에 거의 무한한 확장성을 제공하기 위해 존재하는 오늘날의 클라우드 컴퓨팅 이니셔티브와 비교해 보면 그 차이점을 쉽게 알 수 있지 않을까?다. 아니 사실 차이점이 있기나 할까?그렇다면, 이 둘 사이에 차이점이 정말로 존재하는 걸까?
차이점은 오늘날에는 신기술을 사용하여 오래된 개념을 새롭게 해석하기 위해 신기술을 사용하고 있다는고 있다는 것이다. 클라우드 컴퓨팅은 이러한 사고를 기반으로 유틸리티 기반의 사용량 기준 결제 (pay-for-what-you-use) 방식을 통해 예산에 구애 받지 않고 이용할 수 있는, 혁명보다는 진화에 가까운 기술이다.
유틸리티 컴퓨팅
유틸리티 컴퓨팅은 전기나 물을 사용하는 것과 같이 사용한 만큼만 비용을 지불하는 미터제 서비스로 컴퓨팅 리소스(인프라, 저장소, 핵심 서비스)를 사용하는 것을 말한다. 유틸리티는 하드웨어, 서버, 애플리케이션 플랫폼을 구입, 운영, 유지 관리하고 과금 또는 보안 서비스와 같은 핵심 서비스를 개발해야 하는 필요성을 해소시킬 수 있다. 다음 시나리오를 참고하도록 하자.
Facebook 또는 MySpace를 위한 구성 요소를 제공하려는 웹 기반 ISV는 다음과 같은 딜레마에 빠지고 만다. 이들이 개발하는 구성 요소는 수천 명이 채택하거나,할 수도 있고 어떤 식으로든형태로든 받아들여지기 위해 고군분투하게 될할 수도 있을 것이다. 대부분의 ISV는 자본금이 부족하기 때문에 애플리케이션 개발 비용과 소프트웨어 지원을 위한 인프라 제공 비용을 지출함에 있어사이에서 적절한 균형을 유지해야 한다.
이러한 비용 조정 조치는 플랫폼 지원은 우수하지만 성능이 좋지 않은 애플리케이션을 낳을 수도 있고 또는 성능은 우수하지만 미흡한 플랫폼 지원으로 거의 액세스가접근이 불가능한 애플리케이션을 낳을 수도 있다. 어떤둘 중 어떤 시나리오도 성공하기는 힘들다. 힘든데, 바로 이런 경우에 유틸리티 기반의 클라우드 플랫폼이 도움이 된다. 클라우드 유틸리티 플랫폼은 ISV의 애플리케이션에 대한 수요를 충족시키기 위해할 수 있도록 손쉽게 확장할 수 있는 경제적인 대안 솔루션을 제공함으로써 가능하고 사실상 보유하고 있는한 모든 리소스를 우수한 애플리케이션을 구축하는 데 사용할 수 있도록 지원한다.할 수 있게 해 주는 경제적인 대안 솔루션을 제공한다.
클라우드 서비스는 기본적으로 유틸리티 솔루션으로 제공되기 때문에므로, 제품에 장애가 발생하는 경우 ISV는 서비스를 차단하고 해당 소프트웨어와 관련된 모든 비용 지출을 중단하면 된다.
또한, 유틸리티 모델을 통해 기업은 추가 인프라 리소스를 제공하여 최대 부하를 관리함으로써 사설 데이터 센터 운영 비용의 일부를 상쇄할 수 있는데, 이를 일컬어 클라우드 버스팅(cloud bursting)이라고도 한다.
전통적으로 최대 부하를 처리하기 위해 기업들은 주로 최대 부하를 감당할 수 있는 처리 능력을 갖추도록 데이터 센터를 설계하였다. 이는 곧 최대 부하에 이르지 않는 대부분의 시간 동안 데이터 센터가 저조한 활용도를 보인다는 것을 의미한이다. 클라우드 버스팅을 이용하는 기업은 각자의 환경에서 일상적인 모든 워크로드를 처리할 수 있는 사양으로 데이터 센터를 구축한 후 클라우드 공급자를 통해 추가 리소스를 제공하여 최대 부하를 감당할 수 있다.
유틸리티 컴퓨팅은 대규모 데이터 센터를 통해 사용자에게 거의 무한한 저장소 용량 또는 컴퓨팅 성능을 제공할 수 있도록 하는 일정 형태의 가상화 플랫폼과 연관되는 경우가 많다. 클라우드 컴퓨팅의 진화는 현재 기본적인 인프라를 넘어 서비스를 포함하는 개념으로 유틸리티 컴퓨팅의 정의를 확대하고 있다.
모든 애플리케이션을 클라우드로 이동할 것인가?
모든 애플리케이션을 클라우드에서 운영할 것인가? 기존 애플리케이션을 모두 클라우드로 이동시켜야할 할 것인가? 모든 신규 애플리케이션을 클라우드에서 개발할 것인가? 클라우드란 도대체 무엇인가? 클이는 클라우드 서비스 사용을 고려하기 시작할 때하면 생겨나는 이런 의문들이다.이 생긴다.
클라우드 플랫폼으로 이동하고 클라우드 플래폼에서 개발하거나 클라우드 인프라에 호스팅하기에 적합한 애플리케이션이 있는가 하면, 클라우드를 사용하기에 부적합한 애플리케이션도 있다. 전술한 모든 질문에는 “상황에 따라 다르다”라는, 아키텍처에 관한 기본 해답이 통할 수 있을 것이다. 실제로 모든 애플리케이션의 일부 또는 전체가 클라우드에 있을 수 있다. 한 가지 주의해야 할 점을 들자면, 클라우드로 이동하고자 하는 애플리케이션의 특성 및 (가능한 경우) 기능의 장단점이다.
다음은 페이지에서는 특정 애플리케이션을 클라우드에서 운영하는 것이 실용적인가에 대한 결정을 내리는 데 도움이 되도록 애플리케이션과 클라우드를 기본적인 속성들로 분해하기 위한 몇 가지 방안을 논의한다.
애플리케이션을 클라우드에 매핑
주문 관리 시스템, 항공 예약 시스템, CRM 애플리케이션 등을 비롯한 모든 애플리케이션은 특정 목적을 위해충족하기 위해 설계된다. 애플리케이션의 기능을 구현하려면 일정한 특성들이 존재해야 한다. 예를 들어, 주문 관리 시스템의 경우에는, 애플리케이션의 트랜잭션 및 잠금 지원이 애플리케이션에 무엇보다 중요하다. 이는 클라우드 저장소가 이러한 목적의 데이터 저장소에는 적합하지 않을 수도 있다는 것을 의미한다. 하나의특정 애플리케이션 혹은 대규모대규모 애플리케이션의 하위 시스템이 갖는 주요 특성을 파악하는 것은 특정 애플리케이션이 클라우드에 적합한지 여부를 판단하는 데 있어 매우 중요한 과정이다.
.jpg "애플리케이션의 특성 맵")
Figure 1. 애플리케이션의 특성 맵
그림 1은 모든 애플리케이션과 연관될 수 있는 여러 가지 주요 상위 특성(파란색 열)을 보여준다. 특정 애플리케이션에 존재할 수 있는 특성의 수를 기록할 필요는 없다. 해당 애플리케이션의 중요한 특성을이 무엇인가만 판단하기만 하면 된다. 이렇게 하면 관리하기 쉬운 특성 목록을 작성하여 클라우드에 매핑할 수 있다. 예를 들어, 데이터 관리를 선택하면 상위 수준의 특성에 대해 보다 자세한 정보를 제공하는 부차적인 특성의 목록이 나타난다. 액세스를접근을 선택하면 데이터 소스에 온라인 액세스접근, 오프라인 액세스접근, 온라인과 오프라인으로 모두 액세스접근 하는 방식 중에서 원하는 것을 지정할 수 있다.
데이터 액세스접근 사례를 통해 이 특성이 클라우드 공급자를 통해 데이터 저장소를 이용할지 여부를 선택하는 데 있어 어떤 영향을 미치는지 확인해 볼 수 있다. 문제의 애플리케이션이 순수하게 온라인 데이터만 필요로 한다면, 클라우드 저장소가 탁월한 선택이 될 것이다. 반면, 오프라인 데이터만 필요하다면 이는 해당 애플리케이션이 클라우드에 적합하지 않다는 것을 알려주는 중요한 지표가 될 수 있다. 애플리케이션에 온라인 모델과 오프라인 모델이 모두 필요한지를 결정해야 한다면, 애플리케이션과 클라우드 간의 데이터 동기화를 위한 애플리케이션 개발 비용을 고려해야 한다.
최종 사용자를 위해 오프라인 및 온라인 액세스를접근을 모두 지원하기로 선택하면는 경우에는 프로젝트 비용이 추가로 늘어날 것이다. 하지만 만약 우수한 확장성과 같은 또 다른 특성이 파악된다면되면 이 영역에서 클라우드가 제공하는 이점이 오프라인 액세스환경 개발에 소요되는 비용을 쉽게 상쇄시킬할 수 있을 것이다. (부록 A, 애플리케이션 매핑 특성 참조)
클라우드 구성 요소
애플리케이션을 분해하고 주요 특성을 파악했다면 클라우드,( 특히 클라우드 서비스 공급자)에 대해서도 비슷한 작업을 시작할 수 있다. 클라우드 특성을 개괄적인 범주로 분리하면 매핑 프로세스를 간소화할 수 있다. 이 예에서 사용된 범주는 클라우드 인프라, 클라우드 저장소, 클라우드 플랫폼, 클라우드 애플리케이션, 그리고 핵심 클라우드 서비스이다.
그림 2와 같이 모든 애플리케이션 특성을 하나 이상의 범주로 구분된 클라우드 특성에 매핑할 수 있다.
.jpg "애플리케이션 특성을 클라우드 특성에 매핑")
Figure 2. 애플리케이션 특성을 클라우드 특성에 매핑
클라우드 인프라
클라우드 인프라는 인프라, 또는 보다 일반적으로으로 말해 클라우드에 있는 가상 서버를 말한다. 인프라 솔루션은 대규모 프로세스나 애플리케이션을 지원하는 처리 능력이다. 대규모 애플리케이션의 예로는대규모 Facebook이나 MySpace를 생각할 수 있고, 대규모 처리 능력의 경우는 항공기나 자동차 제조를 위해 엔지니어링 스트레스 테스트 시뮬레이션을 실행하는 고성능 인프라 클러스터를 생각해 보도록 하자.
클라우드 인프라의 주요 수단은 가상화이다. 보다 구체적으로 말하면, 대규모 데이터 센터에서 가상 서버를 실행함으로써 고가의 하드웨어를 구입 및 유지 관리해야 할 필요성을 해결하고 인프라 리소스를 공유함으로써 규모의 경제를 활용하는 것이다. 가상화 플랫폼은 일반적으로 전체 가상화 또는 부분 가상화 환경이다. (가상화에 대한 보다 자세한 설명은 부록 B를 참조)
클라우드 저장소
클라우드 저장소는 클라우드에 있는 모든 유형의 데이터 저장소를 말하는 것으로, 데이터베이스와 유사한 기능을 제공하는 서비스, 비정형 데이터 서비스(예: 디지털 미디어 파일 저장소), 데이터 동기화 서비스 또는 NAS(Network Attached Storage) 서비스를 포함한다. 데이터 서비스는 사용량 기준 결제 방식, 또는 이 경우 용량(GB) 기준 결제 방식으로 이용한다(저장 및 이동 데이터 모두 포함).
클라우드 저장소는 언제 어디에서든 방대한 데이터를 저장 및 검색할 수 있는 기능을 비롯해 다양한 장점을 제공한다. 데이터 저장소 서비스는 빠르고 저렴하며 거의 무한한 확장이 가능하다. 단, 아무리 우수한 서비스도 때로 장애가 발생하기 때문에 신뢰성이 문제가 될 수 있다. 트랜잭션 지원 역시 클라우드 기반 저장소 시스템이 안고 있는 문제 중 하나인데, 기업에서 저장 시스템을 널리 사용해야 하는 경우에는 반드시 해결해야 하는 중대사안이다.
클라우드 플랫폼
클라우드 플랫폼은 사실상 클라우드에서 애플리케이션을 구축, 테스트, 구현, 실행 및 관리할 수 있는 능력이다. 클라우드 플랫폼은 이러한 작업에 대해 다양한 선택의 여지를 제공한다. 예를 들어, 온라인 전용, 오프라인 전용 또는 온라인/오프라인 결합 형태로 구축 작업을 수행할 수 있고 플랫폼에 따라 애플리케이션 테스트를 위한 도구를 지원하지 않거나 매우 우수한 도구를 지원할 수 있다.
일반적으로 클라우드 플랫폼은 웹 기반 애플리케이션 및 서비스를 위한 경제적이고 확장성이 우수한 호스팅/개발 환경이다. 지나치게 단순화하는 면이 있기는 하있지만, 클라우드 플랫폼을 일반 웹 호스트보다 확장성과 가용성이 우수한, 보다 발전된 형태의 웹 호스팅으로 간주할 수 있다. 어떠한 기술이든 장단점이 있는데, 클라우드 플랫폼의 단점은 이동성이다. 특정 플랫폼에서 실행되도록 어떤 애플리케이션을 개발하는 즉시, 다른 클라우드 플랫폼으로 이동하거나 기존 호스팅 환경으로 다시 이동하는 것은이 사실상 불가능하다.
클라우드 애플리케이션
클라우드 애플리케이션애플리케이션은 클라우드 내에 부분적으로 또는 전체적으로 존재하며 클라우드 서비스를 이용하여 애플리케이션 내에서 핵심 기능을 구현한다. 클라우드 애플리케이션의 아키텍처는 전통적인 애플리케이션 모델과 상당히 다를 수 있으므로, 클라우드 애플리케이션을 구현하려면 애플리케이션 설계 사고 방식의 근본적인 전환이 필요할 수 있다.
이러한 애플리케이션의 대안은 S+S(Software plus Services) 모델로, 전통적인 애플리케이션 개발과 완벽한 SaaS 구현을 혼합한 것이다. S+S 애플리케이션은 일반적으로 외부에 호스팅된 서비스의 인터페이스로 고객의 PC에 설치된 리치 클라이언트 애플리케이션을 사용한다.
클라우드 애플리케이션은 로컬에 애플리케이션을 설치 및 실행해야 하는 필요성을 해소시켜 주므로 소프트웨어 유지 관리, 구축, 관리 또는 지원에 필요한 비용을 절감할 수 있다. 이러한 유형의 애플리케이션은 SaaS(Software as a Service) 애플리케이션으로 간주된다.
일반적으로, S+S 애플리케이션에는 오프라인 모드에서 애플리케이션과 상호 작용할 수 있는 기능과, 필요에 따라 중앙 서비스로 동기화할 수 있는 기능이 포함되어 있다.
핵심 클라우드 서비스
핵심 클라우드 서비스는ID 관리, 서비스 간 통합, 매핑, 과금/결제 시스템, 검색, 메시징, 비즈니스 프로세스 관리, 워크플로 등 클라우드 기반 솔루션을 지원하는 서비스를 말한다. 핵심 클라우드 서비스는 개인이 직접 사용하거나 시스템 간 통합을 통해 간접적으로 사용할 수 있 가능하다.
많은 서비스가 BSS (Business Support System) 또는 OSS (Operational Support System)의 범주에 해당하는 상황에서 핵심 클라우드 서비스의 진화는 어쩌면 전자 통신 업계의 진화 과정을를 모방하게 될 것이다.
BSS 서비스는 상호 작용을 관리하고 고객은 일반적으로 다음과 같은 작업을 처리한다.
- 주문 접수
- 청구서 처리
- 수금.
OSS 서비스는 서비스 자체를 관리하고 다음과 같은 사항을 처리한다.
- 서비스 모니터링
- 서비스 프로비저닝
- 서비스 구성.
클라우드 서비스의 특성 맵
다섯 가지 클라우드 범주를 사용하면 범주별로 일련의 특성을 작성할 수 있다. 이러한 특성은 다음 두 가지 방식으로 이용할 수 있다.
- 애플리케이션의 특성을 클라우드 특성에 매핑하여 클라우드 서비스가 해당 애플리케이션에 적합한지 검사하고 어떤 유형의 서비스를 사용할지 파악한다.
- 애플리케이션을 호스팅할 수 있는 후보자로 여러 클라우드 서비스 공급자를 평가하고 선택한 공급자를 통해 어떤 유형의 서비스를 이용할 수 있는지 확인한 다음, 제공된 서비스의 구체적인 구현 특성을 파악한다.
.jpg "클라우드 저장소의 다섯 가지 클라우드 범주 및 특성")
Figure 3. 클라우드 저장소의 다섯 가지 클라우드 범주 및 특성
그림 3은 다섯 가지 클라우드 범주와 클라우드 저장소 범주의 특성 목록을 보여준다. 각 클라우드 공급자는 조금씩 다른 방식으로 클라우드 서비스를 구현한다. 예를 들어, Microsoft와 같은 기업은 개발자가 특정 애플리케이션에 필요한 기능에 따라 선택할 수 있는 다양한 대체 저장소를 제공하고 있다.
의사 결정을 내릴 때에는 구현 비용을 감안해야 하기 때문에, 특정 클라우드 공급자의 서비스가 여러분의 요구 사항에 적합한지 판단할 경우, 애플리케이션 특성과 마찬가지로 클라우드 특성을 주의 깊게 고려해야 한다. (부록 A, 클라우드 매핑 특성 샘플 참조)
클라우드 및 애플리케이션 오버레이
하나의 솔루션을 구현할 때 사용할 수 있는 클라우드 서비스와 애플리케이션을 완벽하게 이해했으니, 이제 최종적으로 어떤 아키텍처가 가능한지에 대한 결정을 내릴 수 있다. 클라우드가 전통적인 애플리케이션 아키텍처의 실용적이고 경제적인 대안이라는 판단이 든다면, 그 다음으로 할 일은 해당 애플리케이션에 가장 적합한 클라우드 공급자를 선택하는 것이다.
자신의 요구 사항을 완벽하게완벽하게 충족시킬 수 있는 단일 공급업체는 없다고 해도 틀린 말이 아닐 것이다. 반면하지 못할 가능성이 크지만, 여러 공급업체를 이용하면 애플리케이션에이 필요한 모든 서비스를 이용할 수 있다.
.jpg "여러 클라우드 서비스 및 공급업체를 이용하는 단일 애플리케이션")
Figure 4. 여러 클라우드 서비스 및 공급업체를 이용하는 단일 애플리케이션
그림 4는 여러 클라우드 공급자가 제공하는 다양한 클라우드 서비스를 이용하는 애플리케이션을 보여준다. 상기 사례는 ASP.NET으로 구축되고 Azure 플랫폼 (클라우드 플랫폼)에서 실행되고 있는 애플리케이션을 나타낸다. 단, 이때의 애플리케이션에는 완벽하게 신뢰할 수 있는 (full trust) 구성 요소도 필요한데, 이는 구성 요소가 전체 가상 환경 (클라우드 인프라) 에서만 실행 가능하다는 것을 의미한다. 데이터는 Microsoft 클라우드(클라우드 저장소)에 저장되고 서비스 버스 및 Identity 같은 서비스 (핵심 클라우드 서비스)도 Azure를 통해 제공된다. 이 애플리케이션에 마지막으로 필요한 것은 과금/결제 서비스 (핵심 클라우드 서비스)인데, 이는 다른 클라우드 공급자를 통해 제공될 수 있다.
이러한 시나리오는 실현 가능하기는 하지만, 여러 공급자에 계정을 두고 다수의수많은 API를 사용하며 모든 서비스를 하나의 애플리케이션에 통합하는 데 따르는른 비용은이 비현실적일 수 있다. 현실적으로 가능한 솔루션은 애플리케이션에 필요한 서비스의 대다수를 제공하는 단일 공급업체를 찾고, 이를 기본 플랫폼으로 이용하여 혼합 솔루션을 구축하는 것이다.
하나의 클라우드로 모든 애플리케이션 지원
하나의 클라우드가 존재하는가, 다수의 클라우드가 존재하는가? 이이는 필자가 지금까지 미 수도 없이 많이 들어온 논쟁이다. 이 논쟁의 일면에는 퍼블릭 클라우드와 다른 프라이빗 클라우드가 존재한다. 사적으로 구현한 클라우드 기술을 클라우드라고 할 수 있는가, 아니면 다른 것으로 봐야 할까? 모든 퍼블릭 클라우드는 동일한 기능을 제공하는가? 프라이빗 클라우드와 퍼블릭 클라우드를 혼합하여 함께 사용하는 애플리케이션이나 시스템의 경우는는 어떠한가? 어그리고 이들은 어디에 해당적절한하는가?
이러한 논쟁은 무의미하다는 것이 필자의 솔직한 의견이다. 어떤 이론에 동의하든 원하는 결과는원하는 결과는 같다. 효즉, 실제로 작동하는 가능한 가장 비용 효과적인 시스템을 구축하는 것이다.이고 가장 경제적인 시스템을 구축하는 것이다. 이전 섹션에서는 결정을 내리는 데 도움이 되는 방안을 논의했다면 지금부터는 클라우드에 존재하거나 혼합 클라우드 솔루션의 일부로 존재할 수 있는 애플리케이션에 대해 간략하게 살펴볼 것이다.
클라우드에서 솔루션 아키텍처 설계 하기
이 섹션에서는 클라우드 서비스를 사용하여 구현할 수 있는 솔루션에 대한 세 가지 애플리케이션 시나리오를 설명한다. 다음 시나리오는 클라우드 서비스를 사용할 수 있는 포괄적인 솔루션 목록이 아니며, 실현 가능한 애플리케이션을 몇 가지 제시한 것에 불과하다.
티켓팅 시스템
클라우드 인프라의 장점에 대해 논의할 때, 콘서트 티켓팅 시스템이 클라우드 시나리오에 적합하다는 것에 대해서는 대체로 의견 일치를 보인다(그림 5). 외견상으로표면적으로는 이런 유형의 애플리케이션이 적합해 보인다. 티켓팅 시스템은 짧은 기간에 많은 수요를 감당해야 하는 경우가 많다 (사람들은 곧 매진될 콘서트 또는 스포츠 경기의 티켓을 사기 위해 몰려든다). 이 기간이 지나면 작업량이 적거나 중간 정도인 수준의 기간이 길게 이어진다.
.jpg "티켓팅 시스템에 클라우드 인프라 이용")
Figure 5. 티켓팅 시스템에 클라우드 인프라 이용
티켓팅 애플리케이션은 수요가 많은 기간 동안에, 즉 컴퓨팅 리소스 요구량이 아주 많은 시기에는 과부하되는 경우가 많다. 이러한 시기를 감당하기 위해서는 가상 시스템의 인스턴스를 실행할 수 있는 기능이 효과적이다. 단, 이러한 솔루션의 아키텍처 설계시에 다음과 같은 몇 가지 이슈를 반드시 고려해야 한다.
- 티켓팅 시스템은 데이터 사용량과 트랜잭션이 아주 많다. 특정어떤 주어진 이벤트의에 특정 좌석을 예약하거나하고 결제를 하기 위해서 트랜잭션이 필요할 수 있다.
- 많은 고객이 해당 티켓팅 회사에 계정이 있거나 계정 생성을 원할 수 있으므로, 개인 식별 정보를 수집해야 한다.
- 신용 카드 결제 확인에는은 많은 시간이 걸릴소요될 수 있으며, 이는므로 티켓팅 프로세스에서 나타나는 병목 현상의 원인이 될 수 있다.
- 일부 가상 서버 플랫폼은 상태를 저장할 수 없다. 이는 서버 이미지가 종료되면 해당 이미지 내에 저장된 데이터에 대한 모든 변경 내용이나 추가 내용이 손실된다는 것을 의미한이다.
- 기존 티켓팅 회사들은 이미 인프라 및 데이터 관리에 상당한 규모의 투자를 하였다.
- 선택하는 클라우드 서비스에 따라, 상태를 저장할 수 없는 가상 클라우드 서버 이미지의 경우, 정보를 이벤트마다 다시 생성해야 하는데, 이렇게 되면 각각의 새로운 인스턴스에 맞는 환경을 준비하기 위해 상당량의 작업을 수행해야 한다.
이러한 점들을 염두에 두면 클라우드 서비스를 이용하여 최대 부하 시간에 기존 시스템에 대한 수요를 줄일 수 있는 여러 가지 방법이 있다존재한다.
- 내부 시스템을 완벽하게 이중화. 가장 많은 양의 작업이 필요하다. 이는 애플리케이션을 사용할 준비가 되면 새로운 인스턴스가 만들어질 때마다 기존 시스템과 동기화해야 하기 때문이다. 시스템을 계속 켜둔 상태로 두면 (용량이 줄어든 상태라 할지라도) 서비스 플랫폼 사용 비용 때문에 많은 비용이 들 수 있다.
- 내부 시스템과 클라우드 시스템 간의 워크로드를 실시간으로 분리. 두 개의 환경에서 좌석 선택과 티켓 구입 과정을 분리하는 것이다. 예를 들어, 내부 티켓팅 시스템에서 트랜잭션이 시작되어 고객이 계정에 로그인하고 참석하고자 하는 이벤트를 선택하고 좌석을 정하게 되면, 최종 결제 처리를 위해 클라우드 서비스로 넘어가는 것이다. 즉, 단순히 마지막 처리 단계를 완료하는 가상 클라우드 서버를 구축하는 것이기 때문에 주 시스템과 동기화할 필요가 없고, 효과적인 상태 비저장 처리 엔진 역할을 할 수 있다. 최소한의 데이터만 클라우드 서비스에 전송하면 되고 신용카드 정보는 일회용으로 외부 시스템에 수집한 후 삭제할 수 있다.
- 일괄 처리를 통해 내부 시스템 간의 워크로드 분리.앞서 말한 처리 방식과 비슷하지만, 이 방식은 참조 정보를 포함한 모든 개인 정보를 내부 시스템에 수집한다는 점에서 차이가 있다. 그런 다음, 이러한 정보는 프로세스 대기열에 있다가 클라우드 서비스로 일괄 전송되어 처리된다. 즉, 결제가 실패하면 티켓 구입을 시도하는 사람과 연락하는 보조 프로세스를 구현해야 한다.
상기의 솔루션은 사용량이 많은 기간 동안 티켓팅 시스템이 클라우드 서비스와 회사 내부 시스템 간에 처리 작업을 어떤 방식으로 분리할 수 있는지를 보여주는 사례이다.
포토/비디오 처리
이 예는 다수의 서비스(인프라, 저장소, 대기)를 결합하여 하나의 데이터 처리 솔루션을 제공하는 방법을 보여준다(그림 6). 이 시나리오에는 디지털 미디어 파일을 렌더링하거나 포맷을 변경하기 위해 클라우드 서비스를 이용하는 포토 처리점들이 처리 체인점이 있다.
.jpg "사진/비디오 처리에 클라우드 인프라 이용")
Figure 6. 사진/비디오 처리에 클라우드 인프라 이용
이 포토 체인은 미국 전역에 수많은 매장을 두고 있으며, 대규모 이미지 및 비디오 처리를 중앙 집중화하여 시스템의 두 가지 측면, 즉 각 저장소매장의 하드웨어 수와 하드웨어 유지 보수 및 지원 작업의 복잡성을 줄이고자 한다.
고객이 다른 포맷으로 변환해야 하는 비디오와 함께를 들고 매장을 찾아오면방문하면, 먼저 해당 비디오 파일을이 먼저 저장소 서비스로 업로드시킨다. 그러면된 후 ‘파일이 저장소 플랫폼에 있으며고 다른 포맷으로 변환해야 한다’는 메시지가 대기열 서비스에 배치된다. 컴퓨터 인스턴스를 실행하는 애플리케이션 컨트롤러가 대기열에서 이 메시지를 받은 후, 가상 시스템의 기존 인스턴스를 사용하거나 새로운 인스턴스를 만들어 비디오의 포맷 변경을 처리한다. 이 프로세스가 완료되는 즉시, 컨트롤러는 프로젝트가 완료되었음을 매장에 알리기 위해 대기열에 메시지를 배치한다.
상기 시나리오는 온라인 환경으로 쉽게 바꿀 수 있기 때문에, 고객은 실제 매장을 방문할 필요 없이 파일을 업로드하여 처리할 수 있다.
웹 사이트 최대 로드 처리
마지막으로 트래픽이 불규칙하게 매우 많아져서 이러한 최대 로드를 지원할 수 있는 호스팅 인프라를 구축하는 것이기가 현실적으로 불가능한 웹 사이트의 예를 들어보도록 하겠다(그림 7). 긴급 뉴스속보가 있는 뉴스 사이트, 새로운 게임을 발표하는 게임 사이트, 새로운 블록버스터블록버스터의 예고편을 보여주는 영화 사이트가 여기에 해당된다.
.jpg "최대 로드 지원을 위해 클라우드 인프라 사용")
Figure 7. 최대 로드 지원을 위해 클라우드 인프라 사용
이 시나리오에 대한 솔루션은 회사 웹 사이트의 완벽한 복사본을 생성하는 것이다. 즉, 웹 사이트의 일부가 클라우드 서비스 인프라 서비스에서 많은 트랙픽을 처리하는 것이다. 사이트의 복사본은 로드 밸런싱된 일련의 서버 또는 클러스터로 구성 가능한 수많은 웹 서버에서 실행되는 정적 인스턴스가 될 것이다. 원본 웹 사이트에 필요한 변경 작업을 수행한 다음 이를 클라우드 서버에 동기화할 수 있다. 이렇게 하면 지연이 발생하겠지만, 웹 서버와 웹 사이트를 유지 관리하는 데 드는 수고를 크게 줄이고 내부 호스팅 웹 사이트와 외부 호스팅 웹 사이트 간 상태를 유지 관리하는 문제를 해소할 수 있다.
클라우드 서비스를 사용할 수 있는 시나리오가 더 많이 있으므로 상기 시나리오를 위한 솔루션을 설계하는 방법도 많이 있다. 여기서는, 새롭게 등장하고 있는 서비스의 활용 사례와 몇 가지 대안을 조명하는 것으로 마무리하고자 한다.
결론
클라우드 및 클라우드 기술이 지닌 매력 때문에 많은 개발자, ISV, 신생 기업 및 대기업은 클라우드 서비스를 면밀히 검토하고 도입의 적합성 여부를 진단하고 있다. TCO 비용 절감과 더불어 저장소 및 인프라의 무제한 확장 가능성을 무시하기 어렵다. 클라우드의 가능성은 확실히 검토할 만한 것이지만, 클라우드 서비스 도입은 신중하게 다루고 아울러 모든 애플리케이션이 클라우드에 적합한 것은 아니라는 사실을 명심해야 한다. 많은 애플리케이션이 클라우드에서 운영될 것이다. 하지만, 클라우드에 일부 솔루션을 호스팅하는 데 드는 부대 비용으로 인해 일부 프로젝트의 경우, 잘 정립된 전통적인 아키텍처 및 기술에 비해 훨씬 더 많은 개발 및 운영 비용이 들 수도 있다.
Appendix A
.jpg)
.jpg)
부록 B
클라우드 인프라 플랫폼 및 가상화 유형
클라우드 컴퓨팅 플랫폼의 핵심 지원 기술 중 하나는 가상화, 즉 컴퓨팅 리소스를 추상화할 수 있는 기술이다. 오늘날 클라우드 인프라 플랫폼은 크게 전체완벽히 가상화된 환경 아니면 또는 부분 반가상화된 (paravirtualized) 환경으 이 두 가지 형태로 구축된다.
방금 언급한 두 가지 이외에도 변형된 형태의 가상화 기술이 더 많지만, 이 글의 목적상 현재 존재하고 클라우드 인프라 솔루션에 원활하게 통합 가능한 몇 가지 가상화 방식만 논의하도록 하겠다.
에뮬레이션
이 유형의 가상화에서는 가상 환경이 수정되지 않은 게스트 OS (운영 체제)가 필요로 하는 하드웨어 아키텍처를 에뮬레이트한다. 에뮬레이트된 하드웨어를 접하게 되는 일반적인 경우 중 하나는 모바일 장치를 사용하는 경우이다. 애플리케이션 개발자는 에뮬레이트된 환경을 통해, 예를 들어 스마트폰이나 PDA에서 실행되도록 설계된 애플리케이션을 테스트할 것이다(그림 8 참조).
.jpg "에뮬레이트된 가상화 환경")
Figure 8. 에뮬레이트된 가상화 환경
장점: 기본 하드웨어와 완전히 다른 하드웨어 환경을 시뮬레이션션한다. 데스크톱에 에뮬레이트되는 스마트폰 등의 모바일 장치를 예로 들 수 있다.
단점: 성능 수준이 낮고 리소스 사용량이 많다.
전체 가상화
전체 가상화에서는 가상화 환경 내에 수정되지 않은 완전한 게스트 OS의 이미지가 생성되고 실행된다. 전체 가상화와 에뮬레이션의 차이점은 모든 가상화 게스트가 동일한 하드웨어 아키텍처에서 실행된다는 것이다. 모든 게스트가 동일한 하드웨어를 지원하므로 게스트가 하드웨어에서 많은 명령을 직접 실행하여 성능을 향상시킬 수 있다(그림 9참조).
.jpg "전체 가상화 환경")
Figure 9. 전체 가상화 환경
장점: 여러 공급업체가 제공하는 여러 버전의 OS(예: Microsoft Windows Server 2003, Windows Server 2008, Linux, and UNIX)를 실행할 수 있다.
단점: 가상화 이미지는 전체 OS를 설치하는 것이므로 파일 용량이 매우 커질 수 있다. 전체 가상화 환경에서는 (특히 일반 하드웨어에) 심각한 성능 문제가 발생하고 입출력 작업이 많은 애플리케이션이 부정적인 영향을 받을 수 있다.
반가상화 (Para-Virtualization)
반가상화에서는 하이퍼바이저가 물리적 하드웨어의 수정 복사본을 내보낸다. 내보낸 계층은 서버 하드웨어와 아키텍처가 동일하다. 하지만 게스트 OS가 네이티브에 가까운 속도로(near-native speeds) 작동하게 하려면 이 계층에 특정 수정 작업을 수행해야 한다. 이처럼 수정된 호출을 활용하려면 게스트 OS를 약간 수정해야 한다. 예를 들어, 물리적 하드웨어에서 기대하는 것과 동일한 수준의 기능을 제공하는 하이퍼콜(hypercall)을 이용하기 위해 게스트 OS를 수정할 수 있다. 단, 하이퍼콜을 이용할 경우 가상화 환경에서 실행될 때에 게스트의 효율성이 크게 향상된다(그림 10 참조).
.jpg "반가상화 환경")
Figure 10. 반가상화 환경
장점: 가볍고 속도가 빠르다. 이미지 크기가 크게 줄어들고 성능이 네이티브에 가까운 속도로 향상될 수 있다. 일반적으로 전체 가상화를 지원하지 않는 아키텍처를 가상화할 수 있게 해 준다.
단점: 게스트 OS가 네이티브 기능에 대해 하이퍼콜을 지원하려면 게스트 OS를 수정해야 한다.
OS 레벨 가상화
OS 가상화에서는 가상 시스템이 없고 전적으로 단일 OS 내에서 가상화가 이루어진다. 게스트 시스템은 기본 OS의 공통된 기능과 드라이버를 공유하며, 완전히 분리된 컴퓨터와 모양과 느낌이 유사하다. 각 게스트 인스턴스는 자체적인 파일 시스템, IP 주소 및 서버 구성을 가지며 완전히 다른 애플리케이션을 실행한다(그림 11 참조).
.jpg "OS 가상화 환경")
Figure 11. OS 가상화 환경
장점: 가볍고 속도가 빠르며고 효율적이다.며 대량의 가상 인스턴스를 지원할 수 있다.
단점: 인스턴스 격리 및 데이터 관련 보안이 중대한 문제이다. 가상 인스턴스는 반드시 동일한 OS를 지원해야 한다.
애플리케이션 가상화
기타 다른 유형의 가상화와 마찬가지로 애플리케이션 가상화를 위해서는 가상화 계층이 존재해야 한다. 가상화 계층은 가상화 애플리케이션이 기본 파일 시스템으로 보내는 모든 호출을 가로채어 가상 위치로 리디렉션한다. 애플리케이션은 물리적 플랫폼으로부터 완전히 분리되어 가상화 계층하고만 상호 작용한다. 이렇게 되면 상호 호환되지 않는 애플리케이션을 병렬로 실행할 수 있다. 예를 들어, Microsoft Internet Information Services 4.0, 5.0 및 6.0을 모두 병렬로 실행할 수 있다. 또한, 설계 시점에서 염두에 두지 않은 OS에서도 애플리케이션을 원활하게 실행할 수 있도록 지원함으로써 애플리케이션의 이동성을 향상시켜 준다(그림 12 참조).
.jpg "애플리케이션 가상화 환경")
Figure 12. 애플리케이션 가상화 환경
장점: 애플리케이션의 이동성을 향상시켜 서로 다른 운영 환경에서도 실행할 수 있게 해 준다. 호환되지 않는 애플리케이션의 병렬 실행을 지원하고, 주문형 애플리케이션 스트리밍을 통해 애플리케이션 구축 속도를 향상시켜 준다.
단점: 가상 시스템 지원에 따른 부담으로 런타임 및 네이티브 환경 모두에서 애플리케이션의 실행 속도가 더 늦어질 수 있다. 모든 소프트웨어를 가상화할 수 있는 것은 아니므로 완벽한 솔루션이 되지 못한다.
글쓴이저자 소개
Darryl Chantry는 Microsoft Platform Architecture 팀의 수석 아키텍트이다. 엔터프라이즈 아키텍트, 솔루션 아키텍트, 인프라 아키텍트로 근무한 경험을 바탕으로 폭넓은 기술력을 보유하고 있다. Darryl은 뉴질랜드 오클랜드에서 나고태어나 자랐으며 2002년에 Microsoft의 New Zealand Developer & Platform Evangelism 팀에 합류했다. 럭비를 매우 좋아하며 인류학, 역사 및 사용자 경험에 특별한 관심을 가지고 있다. Darryl 부부는 현재 보어보엘 개 한 마리와, 버마산미즈 고양이 두 마리와 함께 워싱턴 레드몬드에서 살고 있다.
본 주제와 유사한 추가 정보
- Azure Services Platform 소개 (a David Chappell article)
- 비즈니스를 위한 Azure
- 기업 개발자를 위한 Azure
- ISVs(Independent Software Vendors)를 위한 Azure
'Windows AZURE' 카테고리의 다른 글
| Windows AZURE 툴 설치 (0) | 2010.11.03 |
|---|
