디지털 Transformation, 데이터센터 & Cloud, 베트남

감히 제가 이런 말을 할 수 있는 위치에 있을까요? 아니죠. 큰일나죠.
마이크로소프트의 CEO 스티브 발머 회장님이 2010년 3월 4일, 워싱턴 대학교에서 한 강연에서 하신 말씀입니다.

”For the Cloud, we’re all in”, “Literally, I will tell you we’re betting our company on it”
좀 약하게 해석하면 “마이크로소프트의 모든 역량을 클라우드 컴퓨팅에 쏟아 붇겠다” 정도로 볼 수 있을 것 같아요.
하지만, 이것이 모든 개발을 클라우드 만에 국한하겠다는 의미는 아닙니다. 마이크로소프트의 소프트웨어 플러스 서비스 전략에서 볼 수 있듯이, 고객의 요구사항은 극단적인 한 방향으로만 가는 경우는 없습니다. 소프트웨어를 통해 직접 구축하고자 하는 고객, 서비스로 이용하고자 하는 고객, 서비스에서 다시 소프트웨어로 돌아가고자 하는 고객이 존재할 것이고 그 다리를 제공하는, 즉 고객의 선택에 따른 플랫폼을 제공하는 것이 마이크로소프트의 변하지 않는 중요한 전략이기 때문입니다.

클라우드 컴퓨팅 관련된 생각을 몇 가지로 정리했습니다.
스티브 발머 회장님의 강연 내용을 정리하면 이렇게 될 것 같아요.

첫째, 기회와 책임이 동시에 존재
- 컨텐츠를 생성과 동시에 공유할 수 있지만 프라이버시와 보안성에 대해서는 책임을 져야 한다는 의미

둘째, 클라우드 컴퓨팅과 같이 새로운 질서를 만들어 내는 기술은 한자리에 머물러 있지 않음
- 계속 변화하면서 진화하기 때문에 모습이 조금씩 바뀔 수 있다는 의미

셋째, 사회적, 그리고 직업적인 교류를 더 활발하게 함
- 다양한 디바이스를 통해 공통적인 데이터, 사용자 경험으로 더 많은 교류를 발생시킨다는 의미
- XBox Live를 통해 가상의 서로 다른 사용자가 동시에 같은 TV 프로그램을 시청하며 의견, 공감
- Gaming platform을 통해서 게임 이외의 TV, 대화 등으로 사회적인 친밀감을 형성하는 등의 기존의 벽이
   깨지는 계기가 됨

넷째, 클라우드는 더 똑똑한 디바이스를 필요로 함
- 사용자를 중심으로 사람, 장소, 컨텐츠, 커머스를 바로 접근할 수 있는 유형의, 즉 사용자 중심의 디바이스가
   제공되어야 함

다섯째, 클라우드의 기반은 서버이고, 서버가 진화하면서 클라우드가 진화하는 것임
- 결국 진화된 인프라 클라우드, 플랫폼 클라우드가 있어야 사용자가 경험하는 애플리케이션 클라우드가 발전할 수
   있는 것임

SPECIAL REPORT
위기 극복을 위한 IT 혁신
클라우드 컴퓨팅(Cloud Computing)

3부｜MS 클라우드 전략의 ‘코어’, 윈도우 애저│신현석 160

마이크로소프트의 소프트웨어 플러스 서비스 전략은 전통 소프트웨어 산업의 비즈니스 모델과 서비스 모델의 장점을 결합해 각 개인과 조직의 사업 특성에 딱 들어맞는 최적의 플랫폼을 조립식으로 구성하고 변형할 수 있도록 돕는 기술 전략과 제품 개발 방식을 의미합니다... 로 글을 시작했습니다.

클라우드 컴퓨팅 이란?
소프트웨어와 서비스, 소프트웨어 플러스 서비스
현실계는 소프트웨어 플러스로 이동 중, 클라우드 컴퓨팅의 위력
MS의 클라우드 컴퓨팅 플랫폼, 애저 서비스 플랫폼이란?
시나리오 및 리소스
의 목차를 가지고 있습니다.

글을 여기 다 올리는 것은 어려울 것 같네요. 잡지를 봐주시거나, 아니면 이후에 가능할 때 제가 올리도록 하겠습니다.

전체 글은 파일을 첨부합니다. 다운받아서 읽으시면 됩니다.

Cloud 기반 인프라의 등장

Cloud 기반 인프라가 새로운 핵심으로 등장하고 있습니다. 과연 Cloud 기반 인프라는 무엇일까요? 오늘 전통적인 방식의 인프라와 Cloud 기반 인프라를 접목한 새로운 모델을 제안해 보려고 합니다. 기업의 IT 인프라를 살펴보면 Cloud로 가면 좋을 것과 내부에서 운영하면 좋은 것을 구분할 수 있는데 두 가지 아키텍처상의 Trade Off을 살펴보는 것이 중요합니다. 구체적으로 들어가기 전에 한가지 예를 살펴보겠습니다.

서울에서 부산의 Hyatt 호텔까지 가는 방법

1.       승용차, 편리하지만 경제적으로 비효율적입니다.

2.       대중교통, 즉 기차, 비행기는 약간 불편하지만 가격이 저렴합니다.

그런데 왜 승용차를 이용하는 걸까요? 이유는 하고 싶은 대로 할 수 있기 때문입니다. (통제)

언제 출발 할지, 어디로 갈지(고속도로, 국도, 해안도로 등), 아파트 주차장에서 최종 목적지 Hyatt 호텔 주차장까지 직접 연결된다는 장점이 있죠. 기차의 경우는 정해진 시간표에 맞춰서 기차를 타야 하고, 정해진 경로, 즉 서울역에서 부산역까지 간 후 다시 대중교통을 이용해야 하며, 시끄러운 승객으로 인해 잠을 설칠 수도 있습니다. 장점은 가격이 싸고, 운전할 필요가 없다는 것이겠죠. (규모의 경제)

어떤 수단이 최선인가요? 이건 비용과 하고 싶은 대로 할 수 있는 것 어디에 우선순위를 둘 것이냐에 따라, 상황에 따라 다를 것 입니다. 약간의 비약 같지만, 기차를 클라우드라고 가정하도록 하겠습니다.

Lesson1. 클라우드는 직접 설치(On-Premise), 승용차에 비해 자유도가 떨어지지만, 규모의 경제를 얻을 수 있는 시스템입니다.

서울역에서 부산역까지 역과 역까지만 타고 갈 수 있다면 승용차에 비해 비용 효율적이겠지만 그렇게 매력적이지 않습니다. 원하는 목적지, Hyatt 호텔까지 가려면 버스, 택시, 오토바이, 자전거 등의 다른 운송수단이 필요합니다. 즉, 다양한 교통 수단이 혼합된 하이브리드 형태입니다. 높은 규모의 경제 (기차, 주요 도시간), 중간 정도의 규모의 경제로 (버스), 낮은 규모의 경제지만 최대의 유연성을 가진 택시, 오토바이, 자전거 등이 혼재되어 실 사회를 이루게 됩니다.

Lesson2. 하이브리드 형태를 통해 유연성과 신속성이 보장되면서 규모의 경제 또한 가능하게 됨

지금까지는 사람을 운송하는 이야기를 했지만, 화물에 대해 이야기를 해보면 효율적으로 짐을 싣고 내릴 수 있는 것이 굉장히 중요합니다. 특별한 장비, 및 프로세스가 사용되지 않는다면 싣고 내릴 때 엄청난 비용이 들 수 있습니다. 비용을 줄이는 방법이 바로 표준 컨테이너를 사용하는 방식이죠. 모든 화물을 컨테이너로 운반한다면 다양한 운송수단 간의 적재에 소요되는 비용을 최소화 할 수 있고 정제된 운송 네트웍을 사용할 수 있습니다.

Lesson3. 짐을 싣고 내리는 허브, 컨테이너화 기술을 통해 운송 시스템을 최적화하고, 정보 교환비용을 최소화 할 수 있음

이제 운송수단을 정보 시스템으로 바꾸어서 이야기를 진행해보도록 하겠습니다. 승용차는 On-Premise (직접 설치), 버스 및 택시는 호스팅 (운영 대행), 기차는 클라우드 및 SaaS로 이해를 하시면 됩니다.

앞의 3가지 Lesson을 통한 애플리케이션의 특징은 다음과 같습니다.

1.       전문화를 통한 최적화 (규모의 경제)

2.       유연성과 규모의 경제를 함께 이루는 하이브리드 전략

3.       데이터 교환을 쉽게 가능하도록 함

엔터프라이즈 적용 시나리오, Big Pharma (가상의 제약회사)

엔터프라이즈 기업에서 위와 같은 업무 특성에 맞는 최적화를 어떻게 적용하는지에 대한 글을 적어 보겠습니다.

엔터프라이즈기업의비즈니스동반자.doc

아이뉴스24가 주최한 넥스컴 2008에서 "소프트웨어 플러스 서비스 전략을 통한 SaaS, 클라우드컴퓨팅의 이해"에 대한 발표가 기사화 되었습니다. 아래 링크를 클릭하시면 보실 수 있습니다. 제가 전달하고자 했던 내용과 기사의 방향이 조금 다릅니다. 블로그를 통해 다시 정리해 보겠습니다.

"SaaS(Software as a Service) 개념은 기업의 IT 비용 절감의 가장 확실한 대안이다." 한국마이크로소프트는 14일 서울 논현동 건설회관에서 개최된 차세대 컴퓨팅 기술 세미나 '추계 넥스컴 2008' 행사를 통해 이같이 강조했다. SaaS란 소프트웨어를 제 3의 서비스 제공자 하드웨어에 설치하고, 인터넷을 통해 이를 이용할 수 있도록 하는 개념이다. 한국마이크로소프트는 자사 주요 제품을 서비스로 이용할 수 있도록 선택의 폭을 넓혔으며, 이를 통해 기업이 IT 비용을 줄여나가는데 앞장서고 있다고 설명했다. 한국마이크로소프트 신현석 부장은 "사용자는 적지 않은 금액의 소프트웨어 구매  비용을 지불하고, 구매 이후에도 주기적인 유지보수를위해 추가적인 비용을 지불한다"면서 "인터넷을 통해 소프트웨어를 서비스 형태로 '빌려쓰고' 사용한 만큼의 요금을 월이나 연간 단위로 지불하는 SaaS 방식은 기업의 이같은 고민을 해결해 준다"고 말했다.

서비스 배포(Service Delivery)는 네트워킹, 보안, 모니터링, 운영체제, 비즈니스 프로세스 및 시스템 자동화 등의 기술적인 영역을 지식 및 베스트 프랙티스와 결합하는 광범위한 작업 입니다. 딱 보기에도 만만치 않은 작업 같이 보이시죠? 통신 업체는 이미 서비스 배포에 대한 다양햔 경험을 가지고 있고, 이 산업의 특징은 다음의 약어로 설명 될 것 같습니다. FCAPS(Fault, Configuration, Accounting, Performance, Security Management)

소프트웨어, 솔루션을 개발하는 ISV가 호스팅 운영 환경에 대한 경험이 없고, 관심이 없는 것은 당연한 일이지요. 이런 업체가 SaaS 시장으로 진입하는데 있어 가장 큰 장애요인이 바로 이 운영 입니다.
그런데 재밌는 사실은 시장 상황이 서비스 친화적으로 변하면서 이런 업체들이 자체적으로 호스팅 솔루션을 개발하곤 한다는 것이지요. 그런데 과연 이것이 그들의 서비스를 얼마나 차별화해줄까요? 개발 비용 및 시간이 상당히 많이 들 것임이 분명하지요. 이런 업체들을 위해 SaaS 호스팅, 즉 운영을 대행해줄 업체가 있다면 아주 환상적인 찰떡 궁합이 될 거라고 생각합니다.
그림1. 간단한 호스팅 플랫폼

위의 그림에서 보면 ISV가 빌링, 미터링, 로깅 등을 모두 직접 처리하고 있습니다. 그렇지만, 이런 모듈은 호스팅 업체가 전문성이 있죠. 그림2를 한 번 살펴보도록 하겠습니다. SaaS 배포 플랫폼 (SDP, SaaS Delivery Platform)을 통해 서비스 컴포넌트들이 일반화되면 가능하다는 것이죠. SDP에서 제공되는 인터페이스를 통해 어플리케이션이 인프라 서비스와 서로 의사소통을 할 수 있게 되는 것입니다. SDP가 운영체제가 제공하는 역할과 같이 일반화 되면 소프트웨어 업체들은 핵심 어플리케이션 개발에 전념할 수 있게 되고 결국 시장 진입이 한결 쉬워지는 겁니다.


그림2. SDP가 구현된 후의 아키텍처

SDP는 인프라 서비스 이외에도 소프트웨어 업체가 사용할 수 있는 관리, 모니터링, 어플리케이션 설정등의 다양한 기능이 포함될 수 있습니다. 게다가 서비스 사용 패턴, 빌링 트랜잭션 및 결제 관련된 다양한 상황등의 고차원 비즈니스 정보를 대쉬보드, 컨트롤 패널 형태로 제공할 수 도 있습니다. 소프트웨어 벤더가 마켓 전략을 수립하는데 필요한 BI(Business Intelligence)로 활용이 가능한 것이죠.

SDP는 SaaS 형태로 사업을 하려는 고객을 모두 모아서 매출 규모를 극대화 할 수 있는 새로운 모델 입니다. 왜냐면 현재 호스팅 업체의 경우 상면(공간), 전원부족 등의 제약으로 인해 무작정 서버수를 늘리는 것은 한계가 있기 때문입니다. 현재의 자원을 어떻게 최대로 활용할 필요가 있고, SDP가 바로 그 대안이 될 수 있다는 거죠. 이를 위해서는 자동화 및 SDP를 어떻게 공유할 것인지에 대해 고민할 필요가 있습니다. SDP는 여러 고객이 함께 사용해야 하기 때문에 한 번 개발해 놓으면 지속적인 매출이 여러 고객으로부터 확보되는 장점을 가지고 있습니다.

그렇다면
SaaS 호스팅 업체가 ISV 업체를 끌어들일 수 있는 서비스가 무엇일까요?
SaaS 호스팅 업체가 개발 및 제공해야 하는 기술적인 차별성은 무엇일까요?
SaaS 호스팅을 통해 소프트웨어 서비스의 디자인과 구현 방법은 어떻게 달라질까요?
소프트웨어 개발과 배포 사이의 갭을 어떻게 SaaS 호스팅 업체가 메꿔줄 수 있을까요?

ISV가 원하는 것을 최적화

시장의 어플리케이션 개발 플랫폼에 주목하여 인기 있는 운영체제 플랫폼, 어플리케이션 플랫폼, 데이터 베이스를 선택할 수 있도록 제공한다면 소프트웨어 사업자가 어플리케이션을 서비스 배포 인프라에 통합하는데 소요되는 시간을 단축시킬 수 있을 겁니다.


그림3. WCF 기반의 소프트웨어 서비스를 위해 빌링 모듈을 제공

빌링 모듈을 WCF 기반으로 제공하면 소프트웨어 개발 업체는 서비스 형태로 이용이 가능하게 된다는 거죠. 웹서비스 요청을 받아서, 빌링 인터셉터가 빌링 이벤트를 발생시키면 빌링 시스템이 요청을 받아서 미터링 데이터베이스에 값을 저장하는 형태로 이루어집니다.
또한, 소프트업체가 일반적으로 필요로 하는 솔루션을 조사한 후 호스팅 환경의 어플리케이션이 필요로 하는 모델을 설정해 놓을 수 있습니다. 이러한 모듈 (즉, WCF 빌링 인터셉터), 템플릿, 가이드 제공을 통해 어플리케이션이 호스팅 환경에서 효과적으로 동작하고, 통합될 수 있도록 아키텍처를 사전에 검토하여 만들 수 있게 되는 거지요.  그림4 참조.

그림4. 호스팅 업체가 최적화 할 수 있는 일반적인 어플리케이션 모델

예를들면 아래와 같은 구현 가이드라인이 있을 수 있겠죠
1. 웹사이트, 웹서비스, 데이터베이스 등의 조합으로 만들어진 어플리케이션
2. SQL DB와 통신하는 WCF 서비스
3. 디렉토리 서비스를 사용하는 사용자 레포지터리와 통신하는 WCF
4. 모든 .NET 프레임웍의 어셈블리들은 어플리케이션이 모두 Private으로 설정 (Global Assembly Cache에 컴포넌트를 설치하지 않아야 함)
5. 모든 설정 정보는 .NET 프레임웍의 표준 파일 (web.config)에 저장되어야 함
6. 익셉션에 대한 로깅과 처리는 마이크로소프트 엔터프라이즈 라이브러리로 실행되어야 함
7. 데이터 억세스는 엔터프라이즈 라이브러리 데이터 억세스 어플리케이션 블록으로 실행되어야 함
8. 엔터프라이즈 라이브러리에는 표준 확장자만 허용됨
9. 엔터프라이즈 라이브러리의 바이너리가 SaaS 호스팅 업체에 의해 제공됨

이런 가이드를 적용함으로 소프트웨어 업체는 커스톰 관리 모듈을 직접 개발할 가능성을 줄이게 됩니다.
반면에 호스팅 환경에 통합하는데 필요한 플랫폼 툴을 호스팅 업체가 제공하고, 높은 운영 서비스 수준을 보장 받으면서 어플리케이션을 더 싸고, 빠르게 개발할 수 있게 되는 겁니다. 물론 이러한 것이 어플리케이션의 개발이 전체적인 운영 라이프사이클을 고려하지 않고 디자인 및 개발 되어야 한다는 것은 아닙니다. 반드시 "호스팅을 염두에 두고 개발되어야 합니다". (Design for Hosting) 이후에 Design for Hosting에 대해서는 더 자세히 다루겠습니다.

비용과 운영상의 컴플라이언스
SaaS 호스팅 업체를 사용하는 것이 많은 이점이 있지만 소프트웨어 업체들이 항상 제공되는 가이드를 따라서 개발해야만 하는 것은 아니고, 때로는 호스팅 환경이 특정 어플리케이션을 위해서만 구성되어야 할 때가 있습니다. 음악 이커머스 어플리케이션이 음악 트랙의 처음 20초 정도를 먼저 들려주어야 하고, 각 트랙이 아주 빠르게 로딩 되어야 할 필요가 있다고 해보죠. 이 어플리케이션은 대단히 빠른 디스크 및 네트웍 I/O가 제공되어야 한다고 할 때 SaaS 호스팅 업체의 일반적인 환경에서 제공되기 어렵겠죠. 또한, 내부에서 개발된 메인프레임과의 통합을 위해 MQ 시리즈 네트워킹 인프라가 필요할 수도 있겠죠. 어떤 경우든 소프트웨어 업체는 특화된 장치가 설치되기를 원하면 추가 비용을 부담해야 합니다.

원하는 내용이 크면 클수록 비용이 더 비싸지겠죠. 표준 환경에 대한 비용은 호스팅 업체가 이미 알고 있죠. 따라서 표준 환경을 원하면 비용이 제일 저렴할 겁니다. 어플리케이션이 표준 이외의 환경이 필요하다면 호스팅 업체가 더 많은 비용을 쓰게되겠죠. 아래 그림의 컴플라이언스 레벨 3은 특정한 요구가 없는 경우이며 추가적인 요구가 있을 때 비용이 더 비싸지는 것을 보실 수 있습니다.

호스팅 업체의 빌링 사이클에 맞추어 빌링을 진행할 경우는 비용을 적게 내면 되겠지만, 만약 별도의 주기를 가지고 빌링을 진행해야 한다면 더 많은 비용을 지불해야 할 것입니다.

SaaS 호스팅 연속성
어플리케이션 업체가 SaaS 호스팅을 사용하는 것은 좋은 일임에 틀림없지만, 서비스를 다른 회사가 운영할 때 완전히 분명한 역할을 나누는 것은 정말 어려운 일입니다. ISV가 호스팅을 직접 할 것인지, 일부는 직접하고 SaaS 호스팅 업체를 일부 활용하는 하이브리드 형태로 할 것인지, 아니면 완전히 일임할 것인지는 다양한 요소에 의해 결정될 수 있을 겁니다. 왜냐면 추가적인 비용을 내겠다고 하더라도 SaaS 호스팅 업체가 표준 호스팅 환경 이외에는 제공하지 않겠다고 할 수 있기 때문이죠. 이런 경우는 직접 해야 하는 것이죠.

어플리케이션 플랫폼의 요구사항 이외에도 법적인 규제 및 비즈니스 컴플라이언스 요인 때문에라도 직접 호스팅 해야할 때가 있을 수 있을 겁니다. 예를들면 데이터센터의 기계간의 통신에 IPSec을 반드시 사용해야 한다거나 데이터베이스의 암호화를 위해 4096-비트 암호화 키를 사용해야 한다는 등의 규제가 있고 이런 스펙을 제공하는 호스팅 업체가 없다면 직접 할 수 밖에 없겠죠.

하지만 일반적인 경우에는 표준 방식을 사용할 수 있을 것이고, 빌링시스템, 모니터링, 프로비저닝 등의 시스템을 그대로 활용할 수 있다면 대단히 큰 연구 개발 비용을 절감할 수 있게 될 것입니다.

그림6. SaaS 호스팅 연속성

주문과 빌링의 예를 들어볼까요. ISV가 자기 채널을 통해 취득된 고객의 주문을 관리하기로 결정했지만, 결국 처리는 SaaS 호스팅 업체의 채널을 통해 주문을 처리했다고 생각해보죠. 왜 이렇게 할까요? SaaS 호스팅 업체의 비즈니스 정책은 누구를 통해 취득되었든 간에 주문처리 서비스에 의해 처리되어야 하고 매출도 공유해야 하는 것이었기 때문이죠. 대신 SaaS 호스팅 업체가 빌링시스템 사용료를 벌크 형태로 통합 처리하는 경우 비용을 절감할 수 있는 이점이 있습니다. 대부분의 호스팅 업체는 이미 정부 정책에 맞는 빌링 솔루션을 보유하고 있기 때문에 별도로 고민할 필요가 없는 겁니다.

SaaS 호스팅 알아보기
저의 전문 분야 SaaS 호스팅 입니다. ^^
SDP의 아키텍처를 조금 더 자세히 살펴보겠습니다.

그림7. SDK를 통해 SDP 호스팅 환경에서 구동될 수 있도록 설계된 어플리케이션의 아키텍처

1) SDP를 통해 SaaS 어플리케이션의 라이프사이클 기간 동안 인프라, 운영 및 비즈니스 등을 지원함
2) SDP SDK의 추상화 계층을 통해 SaaS 어플리케이션과 SDP 런타임 사이에 이미 구축된 인터페이스를 통해
    커뮤니케이션이 이루어짐
3) SDP에 어플리케이션의 운영과 비즈니스 정책 적용을 위한 상태 및 이벤트 정보를 제공하는 SaaS 어플리
    케이션을 "Design for Hosting"으로 부르고, 바로 운영이 가능한 상태를 의미함

SaaS Delivery Platform (SDP)
. SDP가 할 수 있는 일들
. 아이덴티티와 접근 관리
. 주문 및 프로비저닝
. 미터링과 빌링
. 모니터링
. 기타 SDP 서비스들

자, 그럼 첫번째로 SDP가 할 수 있는 일을 살펴보겠습니다.
SDP의 제일 큰 목적은 소프트웨어 벤더가 어플리케이션 서비스를 운영하고 관리하는데 필요한 사용자 아이덴티티, 소프트웨어 서비스의 사용과 관계된 다양한 비즈니스 활동을 지원하는 것이죠. 크게 나누어 보면 위에 언급한 아이덴티이와 접근관리  등으로 나누어 볼 수 있습니다. 아래 그림 참조


그림8. SDP가 할 수 있는 일들에 대한 High Level 아키텍처

SDP가 할 수 있는 일은 인프라에 관계된 컴포넌트 외에도 산업계 및 운영 프로세스와 연계된 아주 정제되고 특화된 플랫폼 서비스 모듈이 포함되어야 합니다. 그림에서 보듯 모든 액티비티와 프로세스는 다 연계되어 있습니다. 프로비저닝 모듈의 경우 주문 관리 모듈에 의해 시작되는 것을 보실 수 있고 겨룩에는 아이덴티티 관리, CRM, SLA 모니터링 모듈과 연계되어 다양한 셋업 및 설정 단계를 거치게 됩니다. SDP의 설계는 위와 같이 연계된 모든 작업을 고려하여 실시되어야 합니다.

또한 중요하게 고려해야 하는 아키텍처 고려 요소가 바로 멀티태넌시 입니다. 1차로, SDP의 아이덴티티 관리 모듈에서 SaaS 호스팅 업체는 SDP에 입주한 소프트웨어 업체의 아이덴티티를 관리할 수 있어야 합니다. 왜냐면, SaaS 호스팅 업체는 여러 소프트웨어 업체의 고객들을 호스팅하기 때문에 멀티태넌시의 여부에 따라 각 소프트웨어 업체들의 입주 고객들에 차별화된 아이덴티티 및 억세스 정책을 적용할 수 있기 때문입니다. 2차로, 각 소프트웨어 입주 고객들은 소프트웨어 서비스를 사용하는 고객에게 별도의 아이덴티티 및 억세스 정책을 적용할 수 있어야 합니다. 즉 멀티레벨 멀티 태넌시 컨셉을 가지고 있어야 한다는 말이지요. 그림 참조
 
그림9. 멀티레벨 멀티태넌스 데이터 모델

조금 부연설명하면 Northwind는 SaaS 호스팅 업체이고 ISV A, ISV B는 소프트웨어 서비스 제공자로 가입을 했습니다. ISV A에 2개의 고객이 서비스 신청을 했는데 Application A, Application B를 각각 신청했다고 가정해보죠. 이 경우 관리 위임이 두 단계로 가능합니다. 소프트웨어 서비스 제공자와 어플리케이션 사용고객이 비로 Northwind에 의해 호스팅되고 있지만, SaaS 소프트웨어 서비스 제공자의 어드민, 또는 사용고객의 어드민에 의해 사용자 및 어플리케이션 Function 레벨에서 관리가 가능하다는 것이죠.

아이덴티티 및 억세스 관리
멀티레벨 멀티태넌트 아이덴티티 데이터 모델을 통해 각 하위 단계의 어드민에게 아이덴티티 및 억세스 정책에 대한 설정을 위임할 수 있게 됩니다. 각 고객들은 빌링 리포트를 생성하거나 데이터베이스 백업을 시작하는 등의 작업을 특정 몇 명에게만 권한을 부여할 수 있고, 각 사용자에게 알맞은 설정 및 기능을 선택하는 등의 작업을 가능하게 해야 합니다.

아이덴티티에 있어서 꼭 가능해야 하는 기능이 싱글 사인 온 (SSO) 입니다. 몇 가지 시나리오를 생각해보죠. 첫째, SDP에 호스팅된 어플리케이션 간에 SSO이 가능하도록 하는 것입니다. SaaS 호스팅 업체가 여러 소프트웨어 업체의 서비스를 번들링 하거나 리셀링 하는 일이 빈번할텐데 이런 번들링된 어플리케이션간에 SSO을 제공하는 것이 불필요한 로그인 작업을 없애고, 사용자의 편의성을 높일 것 입니다. 모든 어플리케이션 서비스를 사용하기 위해 사용자가 매번 로그인해야 한다고 생각해보면, 그런 서비스 이용 안하겠죠.

여러개의 호스팅 환경의 어플리케이션 간에 SSO이 가능하도록 하기 위해서 SaaS 호스팅 업체는 아이덴티티 제공자 역할도 해야 할 필요가 있습니다. 아이덴티티 제공자 역할을 위해 등록하고, 관리하고, 인증을 수행하기 위한 인프라가 필요하게 되죠. 아래 부분에서는 SSO을 어떻게 구현할 것인지에 대해 조금 더 자세히 적어 보겠습니다. 호스팅 환경의 어플리케이션을 억세스 하는데 사용자 아이덴티리를 인증하고 검증하는 것은 보안 측면에서는 당연히 그렇게 해야 하는 것이죠. 우선 아이덴티티 제공자로부터 아이덴티티에 대한 확인을 거쳐야 합니다. 계정이 유효하면, 아이덴티티 제공자는 보안 토큰을 발행하여 해당 사용자가 유효하다는 것을 확인시켜 줍니다. 어플리케이션이 체크하여 가입된 사람임을 확인한 후 보안 토큰의 유효성을 체크한 다음 사용자에게 권한을 부여합니다. 이후에 다른 어플리케이션을 사용하려고 한다면 사용자를 인증하기 위해 다시 입력 받을 필요가 없죠. 아이덴티티 제공자에 의해 동일한 보안 토큰이 발행되기 때문에 다른 어플리케이션 사용에 대한 권한을 그대로 유지하고 있고 결국 SSO이 이루어지는 것이죠. 시장에서 통용되는 SSO 패턴과 동일한 방식을 사용하는 겁니다.

위에서 설명한 SSO 방식은 호스팅 서비스 제공자가 발행한 보안 토큰을 사용하는 방식을 이야기 했지만 현실적으로 어플리케이션들이 서로 다른 유형의 보안 토큰을 사용할 수 있을 겁니다. 예를들면, 어떤 어플리케이션은 사용자 아이디와 비밀번호를 사용하고, 또 다른 어플리케이션은 HTTP 쿠키를 보안 토큰으로 쓸 수도 있겠죠.

시큐리티 토큰 교환 패턴은 만약 특정 어플리케이션이 서비스 제공자의 보안 토큰을 사용하도록 수정이 불가능할 때 사용을 고려할 수 있는 아키텍처 접근 방식 입니다. 패턴의 구현은 보안 토큰 교환 프록시 컴포넌트를 필요로 하고 서비스 제공자에 의해 발행된 표준 토큰을 미리 처리하도록 설치하는 방식을 취할 수 있습니다. 토큰 인증이 이루어진 후 프록시 컴포넌트가 어플리케이션이 요구하는 방식으로 또 다른 사용자의 계정값을 매핑하여 처리할 수 있습니다. 그림 10은 ISV A와 ISV B의 어플리케이션이 보안 프록시 컴포넌트를 구현하는 예를 설명하고 있습니다.

그림10. 싱글 사인 온 (SSO) 시나리오

세번째, SSO 시나리오는 엔터프라이즈의 사용자가 지금 사용하는 계정 정보를 가지고 호스팅 어플리케이션에 로그인 하도록 하는 방식입니다. 다양한 방식으로 구현할 수 있지만, 어떤 것은 너무 확장성이 떨어지고 오류 가능성이 많기도 합니다. 디렉토리 동기화 등의 방식이 고려될 수 있긴 하지만 확장성이 떨어지고 비효율 적이라고 생각됩니다. 새로운 방식은 표준 기반의 아이덴티티 (즉, Active Directory Federation Service) 등을 통해 아이덴티티 시스템 간의 정책에 트러스트를 형성하고, 서로 느슨하게 연결되도록 하여 확장성을 보장하는 방식을 사용할 수 있습니다. 즉, SaaS 호스팅 업체와 엔터프라이즈 간에 엔터프라이즈 SSO를 위한 트러스트 관계를 맺는 것이죠. 하지만, 엔터프라이즈 고객은 이 방식을 크게 선호할 거라고 보여지지는 않습니다.

주문 및 프로비저닝 (Ordering & Provisioning)
주문과 프로비저닝은 밀접하게 연계되어 있습니다.

소프트웨어 벤더 On-board
소프트웨어 벤더와 호스팅 업체 간에는 Qualification 프로세스를 거치게 되는데 기술, 비즈니스와 연계된 꼭 알아야 하는 정보 및 추정하는 내용을 서로 공유하여 프로비저닝을 진행하는 것이 발생할 수 있는 위험요소를 사전에 최소화 할 수 있습니다.
 . 어플리케이션의 속성 및 기능
 . 어플리케이션이 구동 가능한 운영 체제와 어플리케이션 플랫폼
 . 어플리케이션 아키텍처에 대한 이해 및 보유 여부
 . 어플리케이션에서 사용하는 엔티티와 데이터 모델, 데이터베이스의 필요 사항
 . 네트워킹 관련 필요 사항
 . 방화벽 이슈를 일으킬 우려가 있는 현재 사용중인 프로토콜
 . 어플리케이션 프로토타입이 배포 되었는지? 배포 문서가 만들어 졌는지? 배포에 도움이 될 만한 문서 여부?
 . 관리와 트러블슈팅에 있어 어플리케이션의 관리 포인트
 . 고려가 필요한 법적인, 규제와 연계된 컴플라이언스 이슈가 있는지?
 . 원하는 성능 메트릭 및 어느 정도의 사용자가 사용할 것으로 추정되는지?


그림11. 소프트웨어 벤더의 On Boarding 프로세스

하나의 워크플로우 안에 어플리케이션과 플랫폼 컴포넌트를 인프라 플랫폼 프로비저닝 컴포넌트가 설치 및 설정 할 수 있도록 소프트웨어 이미지, 호스팅 인프라의 설명 및 설정 정보와 SDP의 기능 등이 모두 포함되어 있습니다. SDP의 기능 중에서 어플리케이션 및 운영 지원 (아이덴티티 관리, 모니터링) 등도 필요에 따라 포함됩니다.
바로 위의 워크플로우는 어플리케이션 배포를 위한 것이고, 또 다른 워크플로우는 소프트웨어 서비스를 실제 사용하는 사용자가 리뷰, 구독 및 접근 하는데 있어 필요한 프로덕트 카탈로그 및 주문 관리 서비스에 대해 설명합니다.

On-boarding 어플리케이션 사용자
사용자가 어플리케이션을 사용하도록 준비하는 단계는 사용자가 프로덕트 카탈로그에서 서비스를 선택하여 주문을 시작하는 순간 시작됩니다. 어플리케이션에 따라 다르긴 하지만, 구매 신청, 고객의 조직, 주소, 연락처 및 빌링 정보가 필요하게 되죠. 보다 더 복잡한 어플리케이션의 경우 주문 프로세스가 고객 혼자 힘으로 끝나지 않을 수 있습니다. 고객 영업 대표가 인계 받아서 사용자 대신 정보가 등록되는 경우도 있을 수 있겠죠.

새로운 주문이 주문 관리 어플리케이션을 통해 들어오면 새로운 주문 관리 워크플로우 인스턴스가 SDP안의 프로비저닝 액티비티를 일으키게 됩니다. 대부분의 작업들이 바로 준비되지 않는 경우가 많기 때문에 주문 관리 워크플로우는 대기 상태에 있게 되고 해당 주문에 대한 주문 추적 번호가 발급됩니다.

그림12는 주문 관리와 어플리케이션 사용자의 주문 완료 프로세스에 대해 설명합니다.

그림12. 주문관리 및 주문 완료 프로세스

주문에 대한 상세 정보가 프로비저닝 파이프라인에 보내집니다. 비즈니스 연관된 정보, 즉 고객의 조직, 빌링 정보, 서비스 개시 등에 대한 정보가 고객 및 빌링 시스템에 입력 됩니다. 또 다른 파이프라인에서는 어플리케이션 프로비저닝 요청이 큐에 입력이 됩니다. 어플리케이션 프로비저닝 시스템이 해당 요청을 받게 되면 설정하고 업데이트해야 할 어플리케이션 컴포넌트를 알아낸 다음 프로비저닝 로직에 따라 실행을 하게 됩니다. 어플리케이션 프로비저닝 로직이 복잡할 때 소프트웨어 업체는 SDP 프로비저닝 시스템이 호출하여 작업할 수 있는 자동 스크립트 또는 코드를 구현하는 것이 좋습니다. 하이브리드 시나리오 역시 가능한데, SaaS 호스팅 업체가 웹서버에 가상 디렉토리를 생성하거나 LDAP 디렉토리를 새로 만들고 사용자 계정을 아이덴티티 시스템에 등록하는 스크립트를 만들 수도 있겠죠. 동시에 소프트웨어 업체는 새로운 고객의 엔트리와 사용자가 설정 가능한 인터페이스, 브랜드, 칼라 스킴, 워크플로우, 비즈니스 룰, 엔티티데이터 모델 등 어플리케이션 메타데이터 정보를 업데이트 할 수 있는 프로비저닝 인터페이스를 제공할 수도 있을 겁니다.

가입자의 프로비저닝 작업은 SDP에서 핵심적인 요소이기도 하고, 완전히 자동화가 이루어지기 정말 어려운 분야이기도 한데, 프로비저닝 워크플로우가 성공적으로 진행되기 어려운 경우에 대한 예외 프로세스를 고려해야 합니다. 중복된 이름이 LDAP 디렉토리에 존재하여 해당 OU(Organization Unit)을 만들지 못하는 경우 등이 생긴다는 것이고, 이럴때는 지금까지 해왔던 모든 작업에 대한 undo 및 롤백 등으로 이전 상태로 되돌려야 하고, 지원인력이 트러블슈팅하거나 향후에 수정할 수 있도록 로깅이 반드시 남아야 합니다 . 프로비저닝 시스템은 해당 단위 작업에 대해 이해하고 있어야 하고, 이전 상태로 되돌릴 수 있는 Undo 기능을 가지고 있어야 함을 의미합니다.
모든 작업이 성공적으로 완료된 후에도 해당 작업에 대해 로그가 남아 있어야 합니다.

미터링과 빌링

클라우드 컴퓨팅에 대한 글, 기사는 계속 쏟아져 나오고 있습니다. 사용하는 용어도 참 다양하지요. 클라우드컴퓨팅, 유틸리티컴퓨팅, PaaS(Platform as a Service) 등의 용어가 주로 나오지요.
"마이크로소프트의 Gianpaolo의 블로그에서 가져왔습니다."

그런데 "클라우드 컴퓨팅"이 사용될 때 아키텍처 측면에서는 어떤 변화가 있을까요?

1. "직접 해라" vs "서비스로 쓰자"
 - "직접 해라"의 경우는 컨트롤을 할 수 있지만, 반면에 규모의 경제 효과는 볼 수 없겠지요. 모든 비용을 혼자 지 불해야 합니다.
 - "서비스로 쓰자"의 경우는 규모의 경제는 확실히 얻을 수 있지만, 직접 제어할 수는 없는 거죠

즉, "제어"와 "규모의 경제" 사이의 Trade Off이 있다는 거죠



2. "누가 구축할거냐"와 "누구의 장비에서 운영할 거냐"
 - "누가 구축할거냐" (직접 개발하는 방식 vs 구입); 기능의 컨트롤에 영향을 미치는 거죠. 직접 구축한다면
    기능을 넣고 빼는 것을 맘대로 할 수 있지만, 서비스 제공자로 부터 소프트웨어를 획득하는 거라면 제공자가
    부여하는 것밖에 사용 못하겠지요.
 - "누구의 장비에서 운영할 거냐"; SLA의 컨트롤에 영향을 미칩니다. "On Premise" 방식으로 직접 설치하고
    운영한다면 SLA에 대한 모든 제어가 가능하겠지요. 물론 SLA에 대한 제어가 가능하다고해서 높은 SLA를
    제공한다거나, 클라우드 방식보다 더 잘한다는 보장은 없지만요. ^^ 결국 SLA에 대한 조절은 가능하다는
    것이고, 클라우드 방식을 사용한다면 SLA를 서비스 제공자가 주는대로 사용해야 겠지요.



3. 가능성 맵 (map of possibilities)
위의 2가지 요소가 왜 중요할까요? 이 두가지의 요소를 통해 엔터프라이즈가 IT 자산을 사용할 수 있는 가능성 맵을 만들어볼 수 있기 때문이지요.
엔터프라이즈는 위의 2가지 요소에 비추어 "기능의 컨트롤", "SLA 컨트롤"을 규모의 경제를 활용하면서 얻기를 원하고 있다는 거죠. 맵 상의 하나의 선택이 다른 것보다 더 좋다는 것을 의미하는 것은 아니고 비즈니스 상황 및 규제 등에 따라 다르게 선택될 수 있는 것입니다.

아래의 그림을 통해 IT 자산의 몇 가지 유형을 볼 수 있습니다. 맨 왼쪽 위에 보면 '직접 설치된 패키지 소프트웨어'를 볼 수 있는데 직접 설치하고, SLA에 대한 모든 제어가 가능하지만 기능에 대해서는 제한적으로 선택이 가능하고, 규모의 경제를 통해 아쉬움을 달래는 것이죠. 소프트웨어 벤더의 경우 수백, 수천의 고객에게 패키지를 판매함을 통해 직접 고객이 개발하는 것보다 더 저렴한 금액으로 소프트웨어를 공급하게 됩니다. 맨 아래의 왼쪽 영역이 "직접 개발하고 직접 운영하는 소프트웨어" 영역 인데, 뱅킹 시스템을 예로 들어보지요. 제어권 및 기능을 모두 가지고 있지만 규모의 경제는 실현 못하죠. 개발 및 운영에 대한 모든 비용을 혼자 감당합니다 오른쪽 맨 위 영역이 바로 'SaaS' 입니다. 규모의 경제 효과가 높지만 기능 및 SLA에 대해서는 한계가 존재하는 거죠. 중간의 칼럼 (호스팅과 클라우드 컴퓨팅)은 직접 구축 및 운영에 비해 SLA 제어에 대해서는 제어권이 약화되지만 규모의 경제 효과는 증가되는 것을 볼 수 있죠.


4. 가상의 시나리오
이 시나리오 에서는 몇 개의 IT 자산은 원하는 독자적인 시스템을 직접 구축 하고 몇 개는 시장에서 통용되는 되는 방식을 그대로 사용하는 것입니다. 다시 말하면, 차별화가 필요한 자산은 집중적인 투자를 하고 (의료 진단 소프트웨어 등), 아주 일반적인, 즉 차별화 되지 않는 자산 (CRM, 이메일 등)은 시장에서 구입하여 사용하는 것이죠. 게다가 IT 자산은 직접 운영하고 보유하여, IT 환경에 대한 SLA를 직접 통제하는 방식을 의미합니다.



이런 형태의 그림이 아주 일반적이지요. 하지만 대부분의 CIO 분들은 이런 형태가 이상적이지만, 너무 많은 예산이 차별화 되지 않는 솔루션에 사용된다고 이야기 합니다.
결국 바라는 모습은 이런 겁니다.


이메일과 CRM은 차별화 되기 쉽지 않고, 규모의 경제를 보장 받으면서 SLA와 기능에 대해 Trade Off하는 거죠. 직접 개발된 리거시 HR 시스템의 경우 기능면에서 규모의 경제를 보장 받는 형태로 전환되면서 SLA에 대한 보장 및 데이터 보안이 필요하다면 내부에서 운영되도록 할 수 있습니다. 의료 진단 소프트웨어의 경우는 차별화되어 경쟁력을 보유할 필요가 있으므로 기존 보다 2배 정도의 예산을 투자하여 뛰어나게 개발하는 겁니다. (다른 쪽에서 비용을 절감했기에 여기에 더 많은 예산을 쓸 수 있다는 거죠)

목적은 분명합니다. 컨트롤을 유지하면서 규모의 경제를 보장 받는 형태로 자산을 배치시키는 방향을 취하면 됩니다.

케즘을 넘어서 ...


말이 쉽지 사실 직접 행동하는 건 쉽지 않죠.
Geoffrey A. Moore의 책에서 나온 말을 인용해보죠. 소프트웨어를 넘어서 클라우드로는 "케즘을 넘어서..."와 비슷합니다. 이 케즘은 아키텍트가 마스터해서 넘겨야 하는 거죠. 아키텍처가 당면한 도전과제는 다양합니다.

첫째, 아이덴티티
둘째, 관리
셋째, 데이터 입니다.

아이덴티티의 경우 크로스 바운더리상의 인증과 권한, 싱글 사인 온, 아이덴티티 라이프 사이클 등이며 관리는 방화벽을 넘어서 SLA 모니터링과 소프트웨어 액션 트리거링 (Halting, Pausing, Throttling) 할 것인지에 대한 것과 데이터의 소유권, 데이터의 이전 및 리포팅과 프라이버시 등입니다.

클라우드 컴퓨팅에 대해서 모든 답을 다 가지고 있는 사람은 없을 것입니다. 여러가지 방향으로 좋은 아키텍트 및 해결책을 찾으려고 노력하고 있다는 것이 적절한 표현일 것입니다. 앞으로는 위에 언급한 3가지 도전과제에 대해 좀 더 상세히 다루어 보려고 합니다. 그리고, 마이크로소프트가 공개한 S+S 어플리케이션 LitwareHR2에 대한 아키텍처 및 코드에 대한 부분을 다음 글에 다루어 보도록 하겠습니다.

"마이크로소프트 Gianpaolo의 블로그에서 가져왔습니다."