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

현재의 IT 주요 트렌드가 무엇일까요? SOA(Service Oriented Architecture), Web2.0, SaaS(Software as a Service), RIA(Rich Internet Application), 그리고 클라우드 컴퓨팅 (Cloud Computing) 이라고 생각합니다.

한마디로 간단히 정의하면
SOA는 "Reuse & Agility, 재사용과 민첩합"을 목적으로 나온 개념입니다.
Web2.0은 "Network Effect, 네트웍 효과, 소셜 네트웍" 으로 설명할 수 있을 것 같구요,
SaaS는 "Flexbile Pricing & Delivery, 유연한 가격 정책과 서비스의 새로운 Delivery 방식" 이구요,
RIA는 "Experience, 사용자 경험"이 주요 개념입니다.
그렇다면, Cloud Computing은 "Service Utility, 즉 유틸리티, 수도 및 전기와 같은 컴퓨팅"이라고 설명할 수 있을 것입니다.

위와 같은 다른 용어로 시장에서는 설명을 하고 나름대로의 정의를 내리기는 하지만, 사실 SOA, SaaS, Web2.0, RIA, Cloud Computing은 어떻게 보면 다르지 않습니다. 모두 현재까지 나와있는 표준들, 다양한 기술들을 이용하여 조금씩 다른 방식으로 사용하고 있다라고 이야기할 수 있습니다.

마이크로소프트는 이러한 5가지 개념을 소프트웨어 플러스 서비스 라고 하는 Umbrella로 설명하고 있습니다. 어떤 개념을 사용하더라도 결국에는 소프트웨어, 서비스가 공존하는 환경이 펼쳐진다는 것이죠.

SQL Server Data Services에 대해서는 앞의 글에 간략히 설명을 드렸기에 개요는 더이상 말하지 않겠습니다. 오늘은 SSDS에 대해 조금 더 자세히 설명해 보겠습니다.

SSDS의 이해

Authority, Container, Entity의 체계로 데이터를 저장, 관리합니다.

1. 데이터 모델
    - 특정한 스키마를 필요로 하지 않고, 유연한 데이터 모델을 지원합니다. 엔티티가 최소의 단위 입니다. 엔티티는 프로퍼티를 통해 실제 데이터 값을 가지고 있습니다. 모든 엔티티는 서비스 메타데이타 프로퍼티와 사용자 지정 프로퍼티를 함께 가지고 있습니다. 고정형 엔티티는 없습니다. 서비스 형태로 사용되어져야 하는 특성 상 엔티티와 엔티티간에의 속성은 독립적으로 서로 영향을 미치지 않습니다. 특정 프로퍼티의 값의 데이터 유형은 엔티티 별로 서로 달라집니다. 프로퍼티의 표준화 및 엔티티간의 프로퍼티 유형은 어플리케이션 개발자에 의해 결정되기 때문입니다. 프로퍼티의 데이터 타입의 종류는 스트링, 바이너리, Boolean, Number, 날짜 등입니다.

2. 데이터 조작
    - Authority, 컨테이너, 엔티티에 생성/수정/삭제 등의 데이터 조작이 가능합니다. SSDS는 웹 사이트 인터페이스를 통해 SSDS의 계정 및 authority의 생성 및 삭제 기능을 지원합니다.  
  . 컨테이너의 생성 및 삭제 조작 가능 (수정 기능은 제공되지 않습니다)
  . 엔티티의 생성, 대체 및 삭제 가능
  . 직렬화 포맷의 단일 컨테이너의 검색/조회 가능
  . 직렬화 포맷의 단일 엔티티 검색/조회 가능

3. Query 언어
    - SSDS는 텍스트기반의 쿼리 언어를 지원하는데, C#을 이용한 LINQ 패턴도 가능합니다. 쿼리 언어는 간단한 필터링 시나리오가 가능하도록 해주는데, 단일 authority나 컨테이너를  아래와 같은 규칙에 의해 조회 가능합니다.
    . 특정 조건을 만족하는 컨테이너 값을 가져오기 위해 authority를 조회할 수 있음
      (이 경우 쿼리의 범위는 쿼리가 적용되는 단일 authority로 한정됨)
    . 특정 조건을 만족하는 엔티티 값을 가져오기 위해 컨테이너를 조회 할 수 있음
      (이 경우 쿼리의 범위는 쿼리가 적용되는 단일 컨테이너로 한정됨)
쿼리는 Boolean(AND, OR, NOT) 및 비교 연산자(<, >, <=, >=, !=, ==)를 사용할 수 있음.
모든 비교는 특정 형태로 이루어 져야 하는데, "프로퍼티 OP(연산자) 상수/파라미터"의 형태여야 함. 예를들면, SELECT e FROM e IN 엔티티 WHERE e["도시"] == "서울";

4. 리소스 기반의 쿼리
    - SSDS는 리소스 기반의 쿼리를 지원하는데, 리소스 쿼리는 엔티티, 컨테이너 등의 경로를 경유하여 값을 가져오는 것을 의미합니다. 예를들면, 다음의 REST URI는 특정 컨테이너를 의미하죠.
ChildrensBooksContainer1 beneath the authority:
mydomain.ssds.microsoft.com

만약 http://mydomain.ssds.microsoft.com/ChildrensBooksContainer1 이라는 URI를 입력했다면 해당 컨테이너에 들어있는 모든 엔티티값이 리턴값으로 돌아올 것입니다.

또, 한단계 더 나아가서 http://http://mydomain.ssds.microsoft.com/ChildrensBooksContainer1/SomeBook 이라는 REST URI 를 입력한다면 해당 컨테이너에서 일치하는 SomeBook, 즉 특정 엔티티가 리턴값으로 돌아오게 되는 거죠.

5. 보안
    - 보안은 계정, authority, 컨테이너 레벨에 적용됩니다. 계정은 Windows Live ID를 통해 보호되고, 각 authority는 "Secret Key"를 통해 read/write 접근 권한을 부여하며, 컨테이너 역시 "Secret Key"를 통해 read/write 권한을 부여합니다. 선택적으로 컨테이너는 외부에 읽기 권한을 부여하는 것이 가능합니다.

6. API
    - SSDS 서비스의 런타임은 웹서비스를 통해 이용 가능한데, 가장 중요한 방식은 RESTful 서비스 입니다. Authrity, 컨테이너, 엔티티는 모두 URI 주소를 통해 접근 가능합니다. 또한, SOAP 기반의 endpoint도 지원되는데, SOAP endpoint는 authority 까지만 지원됩니다.
현재까지는 XML이 주로 사용되는 문서 포맷인데, 이후에 AtomPub 등의 다양한 프로토콜이 추가 지원될 것으로 예정되어 있습니다. Visual C#, Visual Basic 등을 통해 LINQ Qurty 역시 사용 가능합니다.

서비스 배포(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의 블로그에서 가져왔습니다."