[아키텍처 저널 번역] 19권 애플리케이션을 클라우드에 맵핑 #1/2

이번 번역물은 아키텍처 저널 19권에 실려있는 "애플리케이션을 클라우드에 매핑"이라는 아티클을 번역한 것으로 현재 클라우드 컴퓨팅에 관한 관심이 고조되고 여기 저기서 비지니스를 위해 어떻게 활용할 것인지를 고민하고 있는 시점에서 시기적절한 주제인 듯 하다. 내용을 간단히 요약하면 다음과 같다.
- 어떤 것들을 클라우드에 올릴 것인지, 혹은 새로 만드는 것을 클라우드에서 개발해야하는지 등에 대한 논의가 많은데, 이에 대한 가이드를 제공한다.
- 클라우드에 적합한 애플리케이션인지 아닌지를 판단하기 위해서 혹은 어떤 클라우드 사업자가 가장 적합한지를 판단하기 위해 고려해야 할 것들이 있다.
- 먼저, 고려 중인 애플리케이션의 특성을 부록에 나와 있는 속성들을 기준으로 드릴다운해가며 정리한다. 예를 들면, 데이터 관리 --> 접근 방식 --> 온라인/오프라인 혹은 둘다 --> 둘다인 경우에는 싱크도 고려, 오프라인만인 경우 클라우드 부적합 등
- 그 다음, 클라우드 서비스의 특성을 다섯 가지 특성, 즉, 클라우드 인프라, 클라우드 스토리지, 클라우드 플랫폼, 클라우드 애플리케이션, 핵심 클라우드 서비스로 구분하여 각각의 특성을 드릴 다운하여 정리한다. 각 사업자의 장단점도 함께 기술한다.
- 이러한 과정을 통해 클라우드에 적합한 애플리케이션인지, 그렇다면 가장 적합한 클라우드 사업자는 누구인지 등을 하나하나 체크해볼 수 있다.
오늘 올리는 부분은 여기까지이며, 다음에 이어서 올릴 부분은 티켓팅 시스템을 예로들어 클라우드 기반으로 구현할  때 고려 사항을 살펴보고, 구분의 기준이 되는 각종 속성들을 부록으로 제공하고 있다.

---------------------------------------------------
요약
전 세계적으로 경제적 압박이 커지면서 많은 기업들이 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 애플리케이션 등을 비롯한 모든 애플리케이션은 특정 목적을 충족하기 위해 설계된다. 애플리케이션의 기능을 구현하려면 일정한 특성들이 존재해야 한다. 예를 들어, 주문 관리 시스템의 경우에는, 애플리케이션의 트랜잭션 및 잠금 지원이 애플리케이션에 무엇보다 중요하다. 이는 클라우드 저장소가 이러한 목적의 데이터 저장소에는 적합하지 않을 수도 있다는 것을 의미한다. 특정 애플리케이션 혹은 대규모 애플리케이션의 하위 시스템이 갖는 주요 특성을 파악하는 것은 특정 애플리케이션이 클라우드에 적합한지 여부를 판단하는 데 있어 매우 중요한 과정이다.

그림 1. 애플리케이션의 특성 맵

그림 1은 모든 애플리케이션과 연관될 수 있는 여러 가지 주요 상위 특성(파란색 열)을 보여준다. 특정 애플리케이션에 존재할 수 있는 특성의 수를 기록할 필요는 없다. 해당 애플리케이션의 중요한 특성이 무엇인가만 판단하면 된다. 이렇게 하면 관리하기 쉬운 특성 목록을 작성하여 클라우드에 매핑할 수 있다. 예를 들어, 데이터 관리를 선택하면 상위 수준의 특성에 대해 보다 자세한 정보를 제공하는 부차적인 특성의 목록이 나타난다. 액세스를 선택하면 데이터 소스에 온라인 액세스, 오프라인 액세스, 온라인과 오프라인으로 모두 액세스하는 방식 중에서 원하는 것을 지정할 수 있다.
데이터 액세스 사례를 통해 이 특성이 클라우드 공급자를 통해 데이터 저장소를 이용할지 여부를 선택하는 데 있어 어떤 영향을 미치는지 확인해 볼 수 있다. 문제의 애플리케이션이 순수하게 온라인 데이터만 필요로 한다면, 클라우드 저장소가 탁월한 선택이 될 것이다. 반면, 오프라인 데이터만 필요하다면 이는 해당 애플리케이션이 클라우드에 적합하지 않다는 것을 알려주는 중요한 지표가 될 수 있다. 애플리케이션에 온라인 모델과 오프라인 모델이 모두 필요한지를 결정해야 한다면, 애플리케이션과 클라우드 간의 데이터 동기화를 위한 애플리케이션 개발 비용을 고려해야 한다.
최종 사용자를 위해 오프라인 및 온라인 액세스를 모두 지원하기로 선택하는 경우에는 프로젝트 비용이 추가로 늘어날 것이다. 하지만 만약 우수한 확장성과 같은 또 다른 특성이 파악된다면 이 영역에서 클라우드가 제공하는 이점이 오프라인 액세스환경 개발에 소요되는 비용을 쉽게 상쇄시킬 수 있을 것이다. (6페이지에 있는 부록 A, 애플리케이션 매핑 특성 참조)

그림 2. 애플리케이션 특성을 클라우드 특성에 매핑

클라우드 구성 요소
애플리케이션을 분해하고 주요 특성을 파악했다면 클라우드,( 특히 클라우드 서비스 공급자)에 대해서도 비슷한 작업을 시작할 수 있다. 클라우드 특성을 개괄적인 범주로 분리하면 매핑 프로세스를 간소화할 수 있다. 이 예에서 사용된 범주는 클라우드 인프라, 클라우드 저장소, 클라우드 플랫폼, 클라우드 애플리케이션, 그리고 핵심 클라우드 서비스이다.
그림 2와 같이 모든 애플리케이션 특성을 하나 이상의 범주로 구분된 클라우드 특성에 매핑할 수 있다.

클라우드 인프라
클라우드 인프라는 인프라, 또는 보다 일반적으로으로 말해 클라우드에 있는 가상 서버를 말한다. 인프라 솔루션은 대규모 프로세스나 애플리케이션을 지원하는 처리 능력이다. 대규모 애플리케이션의 예로는 Facebook이나 MySpace를 생각할 수 있고, 대규모 처리 능력의 경우는 항공기나 자동차 제조를 위해 엔지니어링 스트레스 테스트 시뮬레이션을 실행하는 고성능 인프라 클러스터를 생각해 보도록 하자.
클라우드 인프라의 주요 수단은 가상화이다. 보다 구체적으로 말하면, 대규모 데이터 센터에서 가상 서버를 실행함으로써 고가의 하드웨어를 구입 및 유지 관리해야 할 필요성을 해결하고 인프라 리소스를 공유함으로써 규모의 경제를 활용하는 것이다. 가상화 플랫폼은 일반적으로 전체 가상화 또는 부분 가상화 환경이다. (가상화에 대한 보다 자세한 설명은 7페이지의 부록 B를 참조)

클라우드 저장소
클라우드 저장소는 클라우드에 있는 모든 유형의 데이터 저장소를 말하는 것으로, 데이터베이스와 유사한 기능을 제공하는 서비스, 비정형 데이터 서비스(예: 디지털 미디어 파일 저장소), 데이터 동기화 서비스 또는 NAS(Network Attached Storage) 서비스를 포함한다. 데이터 서비스는 사용량 기준 결제 방식, 또는 이 경우 용량(GB) 기준 결제 방식으로 이용한다(저장 및 이동 데이터 모두 포함).
클라우드 저장소는 언제 어디에서든 방대한 데이터를 저장 및 검색할 수 있는 기능을 비롯해 다양한 장점을 제공한다. 데이터 저장소 서비스는 빠르고 저렴하며 거의 무한한 확장이 가능하다. 단, 아무리 우수한 서비스도 때로 장애가 발생하기 때문에 신뢰성이 문제가 될 수 있다. 트랜잭션 지원 역시 클라우드 기반 저장소 시스템이 안고 있는 문제 중 하나인데, 기업에서 저장 시스템을 널리 사용해야 하는 경우에는 반드시 해결해야 하는 중대사안이다.

클라우드 플랫폼
클라우드 플랫폼은 사실상 클라우에서 애플리케이션을 구축, 테스트, 구현, 실행 및 관리할 수 있는 능력이다. 클라우드 플랫폼은 이러한 작업에 대해 다양한 선택의 여지를 제공한다. 예를 들어, 온라인 전용, 오프라인 전용 또는 온라인/오프라인 결합 형태로 구축 작업을 수행할 수 있고 플랫폼에 따라 애플리케이션 테스트를 위한 도구를 지원하지 않거나 매우 우수한 도구를 지원할 수 있다.
일반적으로 클라우드 플랫폼은 웹 기반 애플리케이션 및 서비스를 위한 경제적이고 확장성이 우수한 호스팅/개발 환경이다. 지나치게 단순화하는 면이 있기는 하지만, 클라우드 플랫폼을 일반 웹 호스트보다 확장성과 가용성이 우수한, 보다 발전된 형태의 웹 호스팅으로 간주할 수 있다. 어떠한 기술이든 장단점이 있는데, 클라우드 플랫폼의 단점은 이동성이다. 특정 플랫폼에서 실행되도록 어떤 애플리케이션을 개발하는 즉시, 다른 클라우드 플랫폼으로 이동하거나 기존 호스팅 환경으로 다시 이동하는 것은이 사실상 불가능하다.

그림 3. 클라우드 저장소의 다섯 가지 클라우드 범주 및 특성

클라우드 애플리케이션
클라우드 애플리케이션은 클라우드 내에 부분적으로 또는 전체적으로 존재하며 클라우드 서비스를 이용하여 애플리케이션 내에서 핵심 기능을 구현한다. 클라우드 애플리케이션의 아키텍처는 전통적인 애플리케이션 모델과 상당히 다를 수 있으므로, 클라우드 애플리케이션을 구현하려면 애플리케이션 설계 사고 방식의 근본적인 전환이 필요할 수 있다.
클라우드 애플리케이션은 로컬에 애플리케이션을 설치 및 실행해야 하는 필요성을 해소시켜 주므로 소프트웨어 유지 관리, 구축, 관리 또는 지원에 필요한 비용을 절감할 수 있다. 이러한 유형의 애플리케이션은 SaaS(Software as a Service) 애플리케이션으로 간주된다.
이러한 애플리케이션의 대안은 S+S(Software plus Services) 모델로, 전통적인 애플리케이션 개발과 완벽한 SaaS 구현을 혼합한 것이다. S+S 애플리케이션은 일반적으로 외부에 호스팅된 서비스의 인터페이스로 고객의 PC에 설치된 리치 클라이언트 애플리케이션을 사용한다. 일반적으로, S+S 애플리케이션에는 오프라인 모드에서 애플리케이션과 상호 작용할 수 있는 기능과, 필요에 따라 중앙 서비스로 동기화할 수 있는 기능이 포함되어 있다.

핵심 클라우드 서비스
핵심 클라우드 서비스는 ID 관리, 서비스 간 통합, 매핑, 과금/결제 시스템, 검색, 메시징, 비즈니스 프로세스 관리, 워크플로 등 클라우드 기반 솔루션을 지원하는 서비스를 말한다. 핵심 클라우드 서비스는 개인이 직접 사용하거나 시스템 간 통합을 통해 간접적으로 사용할 수 있다.
많은 서비스가 BSS (Business Support System) 또는 OSS (Operational Support System)의 범주에 해당하는 상황에서 핵심 클라우드 서비스의 진화는 어쩌면 전자 통신 업계의 진화 과정을 모방하게 될 것이다.

BSS 서비스는 상호 작용을 관리하고 고객은 일반적으로 다음과 같은 작업을 처리한다.
- 주문 접수
- 청구서 처리 
- 수금

OSS 서비스는 서비스 자체를 관리하고 다음과 같은 사항을 처리한다.
- 서비스 모니터링
- 서비스 프로비저닝
- 서비스 구성

클라우드 서비스의 특성 맵
다섯 가지 클라우드 범주를 사용하면 범주별로 일련의 특성을 작성할 수 있다. 이러한 특성은 다음 두 가지 방식으로 이용할 수 있다.
- 애플리케이션의 특성을 클라우드 특성에 매핑하여 클라우드 서비스가 해당 애플리케이션에 적합한지 검사하고 어떤 유형의 서비스를 사용할지 파악한다.
- 애플리케이션을 호스팅할 수 있는 후보자로 여러 클라우드 서비스 공급자를 평가하고 선택한 공급자를 통해 어떤 유형의 서비스를 이용할 수 있는지 확인한 다음, 제공된 서비스의 구체적인 구현 특성을 파악한다.

그림 3은 다섯 가지 클라우드 범주와 클라우드 저장소 범주의 특성 목록을 보여준다. 각 클라우드 공급자는 조금씩 다른 방식으로 클라우드 서비스를 구현한다. 예를 들어, Microsoft와 같은 기업은 개발자가 특정 애플리케이션에 필요한 기능에 따라 선택할 수 있는 다양한 대체 저장소를 제공하고 있다.
의사 결정을 내릴 때에는 구현 비용을 감안해야 하기 때문에, 특정 클라우드 공급자의 서비스가 여러분의 요구 사항에 적합한지 판단할 경우, 애플리케이션 특성과 마찬가지로 클라우드 특성을 주의 깊게 고려해야 한다. (6페이지에 있는 부록 A, 클라우드 매핑 특성 샘플 참조)

클라우드 및 애플리케이션 오버레이
하나의 솔루션을 구현할 때 사용할 수 있는 클라우드 서비스와 애플리케이션을 완벽하게 이해했으니, 이제 최종적으로 어떤 아키텍처가 가능한지에 대한 결정을 내릴 수 있다. 클라우드가 전통적인 애플리케이션 아키텍처의 실용적이고 경제적인 대안이라는 판단이 든다면, 그 다음으로 할 일은 해당 애플리케이션에 가장 적합한 클라우드 공급자를 선택하는 것이다. 
자신의 요구 사항을 완벽하게 충족시킬 수 있는 단일 공급업체는 없다고 해도 틀린 말이 아닐 것이다. 반면, 여러 공급업체를 이용하면 애플리케이션이 필요한 모든 서비스를 이용할 수 있다.

그림 4. 여러 클라우드 서비스 및 공급업체를 이용하는 단일 애플리케이션

그림 4는 여러 클라우드 공급자가 제공하는 다양한 클라우드 서비스를 이용하는 애플리케이션을 보여준다. 상기 사례는 ASP.NET으로 구축되고 Azure 플랫폼 (클라우드 플랫폼)에서 실행되고 있는 애플리케이션을 나타낸다. 단, 이때의 애플리케이션에는 완벽하게 신뢰할 수 있는 (full trust) 구성 요소도 필요한데, 이는 구성 요소가 전체 가상 환경 (클라우드 인프라) 에서만 실행 가능하다는 것을 의미한다. 데이터는 Microsoft 클라우드(클라우드 저장소)에 저장되고 서비스 버스 및 Identity 같은 서비스 (핵심 클라우드 서비스)도 Azure를 통해 제공된다. 이 애플리케이션에 마지막으로 필요한 것은 과금/결제 서비스 (핵심 클라우드 서비스)인데, 이는 다른 클라우드 공급자를 통해 제공될 수 있다.
이러한 시나리오는 실현 가능하기는 하지만, 여러 공급자에 계정을 두고 다수의수많은 API를 사용하며 모든 서비스를 하나의 애플리케이션에 통합하는 데 따르는 비용이 비현실적일 수 있다. 현실적으로 가능한 솔루션은 애플리케이션에 필요한 서비스의 대다수를 제공하는 단일 공급업체를 찾고, 이를 기본 플랫폼으로 이용하여 혼합 솔루션을 구축하는 것이다.