서비스 배포(Service Delivery)는 네트워킹, 보안, 모니터링, 운영체제, 비즈니스 프로세스 및 시스템 자동화 등의 기술적인 영역을 지식 및 베스트 프랙티스와 결합하는 광범위한 작업 입니다. 딱 보기에도 만만치 않은 작업 같이 보이시죠? 통신 업체는 이미 서비스 배포에 대한 다양햔 경험을 가지고 있고, 이 산업의 특징은 다음의 약어로 설명 될 것 같습니다. FCAPS(Fault, Configuration, Accounting, Performance, Security Management)
소프트웨어, 솔루션을 개발하는 ISV가 호스팅 운영 환경에 대한 경험이 없고, 관심이 없는 것은 당연한 일이지요. 이런 업체가 SaaS 시장으로 진입하는데 있어 가장 큰 장애요인이 바로 이 운영 입니다.
그런데 재밌는 사실은 시장 상황이 서비스 친화적으로 변하면서 이런 업체들이 자체적으로 호스팅 솔루션을 개발하곤 한다는 것이지요. 그런데 과연 이것이 그들의 서비스를 얼마나 차별화해줄까요? 개발 비용 및 시간이 상당히 많이 들 것임이 분명하지요. 이런 업체들을 위해 SaaS 호스팅, 즉 운영을 대행해줄 업체가 있다면 아주 환상적인 찰떡 궁합이 될 거라고 생각합니다. .jpg)
그림1. 간단한 호스팅 플랫폼
위의 그림에서 보면 ISV가 빌링, 미터링, 로깅 등을 모두 직접 처리하고 있습니다. 그렇지만, 이런 모듈은 호스팅 업체가 전문성이 있죠. 그림2를 한 번 살펴보도록 하겠습니다. SaaS 배포 플랫폼 (SDP, SaaS Delivery Platform)을 통해 서비스 컴포넌트들이 일반화되면 가능하다는 것이죠. SDP에서 제공되는 인터페이스를 통해 어플리케이션이 인프라 서비스와 서로 의사소통을 할 수 있게 되는 것입니다. SDP가 운영체제가 제공하는 역할과 같이 일반화 되면 소프트웨어 업체들은 핵심 어플리케이션 개발에 전념할 수 있게 되고 결국 시장 진입이 한결 쉬워지는 겁니다. .jpg)
그림2. SDP가 구현된 후의 아키텍처
SDP는 인프라 서비스 이외에도 소프트웨어 업체가 사용할 수 있는 관리, 모니터링, 어플리케이션 설정등의 다양한 기능이 포함될 수 있습니다. 게다가 서비스 사용 패턴, 빌링 트랜잭션 및 결제 관련된 다양한 상황등의 고차원 비즈니스 정보를 대쉬보드, 컨트롤 패널 형태로 제공할 수 도 있습니다. 소프트웨어 벤더가 마켓 전략을 수립하는데 필요한 BI(Business Intelligence)로 활용이 가능한 것이죠.
SDP는 SaaS 형태로 사업을 하려는 고객을 모두 모아서 매출 규모를 극대화 할 수 있는 새로운 모델 입니다. 왜냐면 현재 호스팅 업체의 경우 상면(공간), 전원부족 등의 제약으로 인해 무작정 서버수를 늘리는 것은 한계가 있기 때문입니다. 현재의 자원을 어떻게 최대로 활용할 필요가 있고, SDP가 바로 그 대안이 될 수 있다는 거죠. 이를 위해서는 자동화 및 SDP를 어떻게 공유할 것인지에 대해 고민할 필요가 있습니다. SDP는 여러 고객이 함께 사용해야 하기 때문에 한 번 개발해 놓으면 지속적인 매출이 여러 고객으로부터 확보되는 장점을 가지고 있습니다.
그렇다면
SaaS 호스팅 업체가 ISV 업체를 끌어들일 수 있는 서비스가 무엇일까요?
SaaS 호스팅 업체가 개발 및 제공해야 하는 기술적인 차별성은 무엇일까요?
SaaS 호스팅을 통해 소프트웨어 서비스의 디자인과 구현 방법은 어떻게 달라질까요?
소프트웨어 개발과 배포 사이의 갭을 어떻게 SaaS 호스팅 업체가 메꿔줄 수 있을까요?
ISV가 원하는 것을 최적화
시장의 어플리케이션 개발 플랫폼에 주목하여 인기 있는 운영체제 플랫폼, 어플리케이션 플랫폼, 데이터 베이스를 선택할 수 있도록 제공한다면 소프트웨어 사업자가 어플리케이션을 서비스 배포 인프라에 통합하는데 소요되는 시간을 단축시킬 수 있을 겁니다. .jpg)
그림3. WCF 기반의 소프트웨어 서비스를 위해 빌링 모듈을 제공
빌링 모듈을 WCF 기반으로 제공하면 소프트웨어 개발 업체는 서비스 형태로 이용이 가능하게 된다는 거죠. 웹서비스 요청을 받아서, 빌링 인터셉터가 빌링 이벤트를 발생시키면 빌링 시스템이 요청을 받아서 미터링 데이터베이스에 값을 저장하는 형태로 이루어집니다.
또한, 소프트업체가 일반적으로 필요로 하는 솔루션을 조사한 후 호스팅 환경의 어플리케이션이 필요로 하는 모델을 설정해 놓을 수 있습니다. 이러한 모듈 (즉, WCF 빌링 인터셉터), 템플릿, 가이드 제공을 통해 어플리케이션이 호스팅 환경에서 효과적으로 동작하고, 통합될 수 있도록 아키텍처를 사전에 검토하여 만들 수 있게 되는 거지요. 그림4 참조. .jpg)
그림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은 특정한 요구가 없는 경우이며 추가적인 요구가 있을 때 비용이 더 비싸지는 것을 보실 수 있습니다. .jpg)
호스팅 업체의 빌링 사이클에 맞추어 빌링을 진행할 경우는 비용을 적게 내면 되겠지만, 만약 별도의 주기를 가지고 빌링을 진행해야 한다면 더 많은 비용을 지불해야 할 것입니다.
SaaS 호스팅 연속성
어플리케이션 업체가 SaaS 호스팅을 사용하는 것은 좋은 일임에 틀림없지만, 서비스를 다른 회사가 운영할 때 완전히 분명한 역할을 나누는 것은 정말 어려운 일입니다. ISV가 호스팅을 직접 할 것인지, 일부는 직접하고 SaaS 호스팅 업체를 일부 활용하는 하이브리드 형태로 할 것인지, 아니면 완전히 일임할 것인지는 다양한 요소에 의해 결정될 수 있을 겁니다. 왜냐면 추가적인 비용을 내겠다고 하더라도 SaaS 호스팅 업체가 표준 호스팅 환경 이외에는 제공하지 않겠다고 할 수 있기 때문이죠. 이런 경우는 직접 해야 하는 것이죠.
어플리케이션 플랫폼의 요구사항 이외에도 법적인 규제 및 비즈니스 컴플라이언스 요인 때문에라도 직접 호스팅 해야할 때가 있을 수 있을 겁니다. 예를들면 데이터센터의 기계간의 통신에 IPSec을 반드시 사용해야 한다거나 데이터베이스의 암호화를 위해 4096-비트 암호화 키를 사용해야 한다는 등의 규제가 있고 이런 스펙을 제공하는 호스팅 업체가 없다면 직접 할 수 밖에 없겠죠.
하지만 일반적인 경우에는 표준 방식을 사용할 수 있을 것이고, 빌링시스템, 모니터링, 프로비저닝 등의 시스템을 그대로 활용할 수 있다면 대단히 큰 연구 개발 비용을 절감할 수 있게 될 것입니다. .jpg)
그림6. SaaS 호스팅 연속성
주문과 빌링의 예를 들어볼까요. ISV가 자기 채널을 통해 취득된 고객의 주문을 관리하기로 결정했지만, 결국 처리는 SaaS 호스팅 업체의 채널을 통해 주문을 처리했다고 생각해보죠. 왜 이렇게 할까요? SaaS 호스팅 업체의 비즈니스 정책은 누구를 통해 취득되었든 간에 주문처리 서비스에 의해 처리되어야 하고 매출도 공유해야 하는 것이었기 때문이죠. 대신 SaaS 호스팅 업체가 빌링시스템 사용료를 벌크 형태로 통합 처리하는 경우 비용을 절감할 수 있는 이점이 있습니다. 대부분의 호스팅 업체는 이미 정부 정책에 맞는 빌링 솔루션을 보유하고 있기 때문에 별도로 고민할 필요가 없는 겁니다.
SaaS 호스팅 알아보기
저의 전문 분야 SaaS 호스팅 입니다. ^^
SDP의 아키텍처를 조금 더 자세히 살펴보겠습니다..gif)
그림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의 제일 큰 목적은 소프트웨어 벤더가 어플리케이션 서비스를 운영하고 관리하는데 필요한 사용자 아이덴티티, 소프트웨어 서비스의 사용과 관계된 다양한 비즈니스 활동을 지원하는 것이죠. 크게 나누어 보면 위에 언급한 아이덴티이와 접근관리 등으로 나누어 볼 수 있습니다. 아래 그림 참조.jpg)
그림8. SDP가 할 수 있는 일들에 대한 High Level 아키텍처
SDP가 할 수 있는 일은 인프라에 관계된 컴포넌트 외에도 산업계 및 운영 프로세스와 연계된 아주 정제되고 특화된 플랫폼 서비스 모듈이 포함되어야 합니다. 그림에서 보듯 모든 액티비티와 프로세스는 다 연계되어 있습니다. 프로비저닝 모듈의 경우 주문 관리 모듈에 의해 시작되는 것을 보실 수 있고 겨룩에는 아이덴티티 관리, CRM, SLA 모니터링 모듈과 연계되어 다양한 셋업 및 설정 단계를 거치게 됩니다. SDP의 설계는 위와 같이 연계된 모든 작업을 고려하여 실시되어야 합니다.
또한 중요하게 고려해야 하는 아키텍처 고려 요소가 바로 멀티태넌시 입니다. 1차로, SDP의 아이덴티티 관리 모듈에서 SaaS 호스팅 업체는 SDP에 입주한 소프트웨어 업체의 아이덴티티를 관리할 수 있어야 합니다. 왜냐면, SaaS 호스팅 업체는 여러 소프트웨어 업체의 고객들을 호스팅하기 때문에 멀티태넌시의 여부에 따라 각 소프트웨어 업체들의 입주 고객들에 차별화된 아이덴티티 및 억세스 정책을 적용할 수 있기 때문입니다. 2차로, 각 소프트웨어 입주 고객들은 소프트웨어 서비스를 사용하는 고객에게 별도의 아이덴티티 및 억세스 정책을 적용할 수 있어야 합니다. 즉 멀티레벨 멀티 태넌시 컨셉을 가지고 있어야 한다는 말이지요. 그림 참조.gif)
그림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의 어플리케이션이 보안 프록시 컴포넌트를 구현하는 예를 설명하고 있습니다. .jpg)
그림10. 싱글 사인 온 (SSO) 시나리오
세번째, SSO 시나리오는 엔터프라이즈의 사용자가 지금 사용하는 계정 정보를 가지고 호스팅 어플리케이션에 로그인 하도록 하는 방식입니다. 다양한 방식으로 구현할 수 있지만, 어떤 것은 너무 확장성이 떨어지고 오류 가능성이 많기도 합니다. 디렉토리 동기화 등의 방식이 고려될 수 있긴 하지만 확장성이 떨어지고 비효율 적이라고 생각됩니다. 새로운 방식은 표준 기반의 아이덴티티 (즉, Active Directory Federation Service) 등을 통해 아이덴티티 시스템 간의 정책에 트러스트를 형성하고, 서로 느슨하게 연결되도록 하여 확장성을 보장하는 방식을 사용할 수 있습니다. 즉, SaaS 호스팅 업체와 엔터프라이즈 간에 엔터프라이즈 SSO를 위한 트러스트 관계를 맺는 것이죠. 하지만, 엔터프라이즈 고객은 이 방식을 크게 선호할 거라고 보여지지는 않습니다.
주문 및 프로비저닝 (Ordering & Provisioning)
주문과 프로비저닝은 밀접하게 연계되어 있습니다.
소프트웨어 벤더 On-board
소프트웨어 벤더와 호스팅 업체 간에는 Qualification 프로세스를 거치게 되는데 기술, 비즈니스와 연계된 꼭 알아야 하는 정보 및 추정하는 내용을 서로 공유하여 프로비저닝을 진행하는 것이 발생할 수 있는 위험요소를 사전에 최소화 할 수 있습니다.
. 어플리케이션의 속성 및 기능
. 어플리케이션이 구동 가능한 운영 체제와 어플리케이션 플랫폼
. 어플리케이션 아키텍처에 대한 이해 및 보유 여부
. 어플리케이션에서 사용하는 엔티티와 데이터 모델, 데이터베이스의 필요 사항
. 네트워킹 관련 필요 사항
. 방화벽 이슈를 일으킬 우려가 있는 현재 사용중인 프로토콜
. 어플리케이션 프로토타입이 배포 되었는지? 배포 문서가 만들어 졌는지? 배포에 도움이 될 만한 문서 여부?
. 관리와 트러블슈팅에 있어 어플리케이션의 관리 포인트
. 고려가 필요한 법적인, 규제와 연계된 컴플라이언스 이슈가 있는지?
. 원하는 성능 메트릭 및 어느 정도의 사용자가 사용할 것으로 추정되는지?.jpg)
그림11. 소프트웨어 벤더의 On Boarding 프로세스
하나의 워크플로우 안에 어플리케이션과 플랫폼 컴포넌트를 인프라 플랫폼 프로비저닝 컴포넌트가 설치 및 설정 할 수 있도록 소프트웨어 이미지, 호스팅 인프라의 설명 및 설정 정보와 SDP의 기능 등이 모두 포함되어 있습니다. SDP의 기능 중에서 어플리케이션 및 운영 지원 (아이덴티티 관리, 모니터링) 등도 필요에 따라 포함됩니다.
바로 위의 워크플로우는 어플리케이션 배포를 위한 것이고, 또 다른 워크플로우는 소프트웨어 서비스를 실제 사용하는 사용자가 리뷰, 구독 및 접근 하는데 있어 필요한 프로덕트 카탈로그 및 주문 관리 서비스에 대해 설명합니다.
On-boarding 어플리케이션 사용자
사용자가 어플리케이션을 사용하도록 준비하는 단계는 사용자가 프로덕트 카탈로그에서 서비스를 선택하여 주문을 시작하는 순간 시작됩니다. 어플리케이션에 따라 다르긴 하지만, 구매 신청, 고객의 조직, 주소, 연락처 및 빌링 정보가 필요하게 되죠. 보다 더 복잡한 어플리케이션의 경우 주문 프로세스가 고객 혼자 힘으로 끝나지 않을 수 있습니다. 고객 영업 대표가 인계 받아서 사용자 대신 정보가 등록되는 경우도 있을 수 있겠죠.
새로운 주문이 주문 관리 어플리케이션을 통해 들어오면 새로운 주문 관리 워크플로우 인스턴스가 SDP안의 프로비저닝 액티비티를 일으키게 됩니다. 대부분의 작업들이 바로 준비되지 않는 경우가 많기 때문에 주문 관리 워크플로우는 대기 상태에 있게 되고 해당 주문에 대한 주문 추적 번호가 발급됩니다.
그림12는 주문 관리와 어플리케이션 사용자의 주문 완료 프로세스에 대해 설명합니다. .jpg)
그림12. 주문관리 및 주문 완료 프로세스
주문에 대한 상세 정보가 프로비저닝 파이프라인에 보내집니다. 비즈니스 연관된 정보, 즉 고객의 조직, 빌링 정보, 서비스 개시 등에 대한 정보가 고객 및 빌링 시스템에 입력 됩니다. 또 다른 파이프라인에서는 어플리케이션 프로비저닝 요청이 큐에 입력이 됩니다. 어플리케이션 프로비저닝 시스템이 해당 요청을 받게 되면 설정하고 업데이트해야 할 어플리케이션 컴포넌트를 알아낸 다음 프로비저닝 로직에 따라 실행을 하게 됩니다. 어플리케이션 프로비저닝 로직이 복잡할 때 소프트웨어 업체는 SDP 프로비저닝 시스템이 호출하여 작업할 수 있는 자동 스크립트 또는 코드를 구현하는 것이 좋습니다. 하이브리드 시나리오 역시 가능한데, SaaS 호스팅 업체가 웹서버에 가상 디렉토리를 생성하거나 LDAP 디렉토리를 새로 만들고 사용자 계정을 아이덴티티 시스템에 등록하는 스크립트를 만들 수도 있겠죠. 동시에 소프트웨어 업체는 새로운 고객의 엔트리와 사용자가 설정 가능한 인터페이스, 브랜드, 칼라 스킴, 워크플로우, 비즈니스 룰, 엔티티데이터 모델 등 어플리케이션 메타데이터 정보를 업데이트 할 수 있는 프로비저닝 인터페이스를 제공할 수도 있을 겁니다.
가입자의 프로비저닝 작업은 SDP에서 핵심적인 요소이기도 하고, 완전히 자동화가 이루어지기 정말 어려운 분야이기도 한데, 프로비저닝 워크플로우가 성공적으로 진행되기 어려운 경우에 대한 예외 프로세스를 고려해야 합니다. 중복된 이름이 LDAP 디렉토리에 존재하여 해당 OU(Organization Unit)을 만들지 못하는 경우 등이 생긴다는 것이고, 이럴때는 지금까지 해왔던 모든 작업에 대한 undo 및 롤백 등으로 이전 상태로 되돌려야 하고, 지원인력이 트러블슈팅하거나 향후에 수정할 수 있도록 로깅이 반드시 남아야 합니다 . 프로비저닝 시스템은 해당 단위 작업에 대해 이해하고 있어야 하고, 이전 상태로 되돌릴 수 있는 Undo 기능을 가지고 있어야 함을 의미합니다.
모든 작업이 성공적으로 완료된 후에도 해당 작업에 대해 로그가 남아 있어야 합니다.
미터링과 빌링
