 | |
|
난이도 : 중급 Amber Roy-Chowdhury, Senior Software Engineer, IBM
Germán Goldszmidt, Distinguished Engineer, IBM
Carl Osipov, Software Architect, IBM
2007 년 7 월 18 일 다중 소유(Multi-tenancy)는 공유된 공통의 호스팅 환경에서 여러 클라이언트들에게 서비스를 제공하는 기능입니다. 이 글에서 다중 소유의 개념과, software-as-a-service에 대한 네트워크 기반 접근 방식을 설명합니다.
머리말
이전 기술자료에서는 복합 비즈니스 서비스(CBS)의 개념을 설명하였고, 여기에 필요한 전개 환경의 핵심 요소들을 짚어보았다. 이번에는 공유된 공통의 호스팅 환경에서 여러 클라이언트들에게 서비스를 제공하는 기능인 다중 소유(multi-tenancy)에 대해 설명하겠다. 또한 software-as-a-service (SaaS)에 대한 네트워크 기반 접근 방식을 설명하고, SaaS 다중 소유를 활용하는 다양한 사용자 유형을 설명한다. SaaS 호스팅 환경에서 다중 소유를 지원하는 원리와 기술 구현에 대해 배울 것이다. WebSphere® Process Server와 Portal, 가상 포털, 포틀릿용 clone-and-configure 구현 패턴을 사용한 다중 소유 플랫폼을 구현에 대해 설명한다. 포틀릿 구현을 수정하여 포털 역할에 대한 확장된 프로파일 정보를 지원하는 예제도 제공한다. 이 글은 소프트웨어 서비스와 포틀릿 기반 사용자 인터페이스에 대한 디자인 변화에 초점을 맞출 것이다.
다중 소유
Software-as-a-service(SaaS) 모델(또는 software
on-demand)에서, 서비스(WSDL을 사용하여 기술된 서비스) 제공은 네트워크를 기반으로 이루어진다. 이러한 접근 방식은 설치 장치를 활용한 패키징 형태의 전통적인 전달 방식과는 반대되는 것이다. 전통적인 서비스 공급자는 대형 데이터 센터에 소프트웨어를 호스팅 하고, 인터넷을 사용하여 비즈니스 서비스를 전달한다. 이 글의 예제는 서비스 공급자가 독립적인 회사이고, 서비스 공급자가 큰 기업 내 한 부서라는 특정 상황에 초점을 맞춘다.
그림 1은 SaaS 예제를 묘사하고 있다. 여기에서, Bank Account Opening 서비스 공급자는 Account Opening 서비스 구현을 호스팅 하는 반면, 서비스 등록자(소유자)는 First Bank와 Second Canadian Bank 같은 은행이다. 이러한 은행들은 고유한 Account Opening 서비스 설정을 고객에게 제공하고 있다.
그림 1. SaaS 예제
뱅킹 SaaS 애플리케이션에서 역할에 대한 상세한 예제는 SOA 복합 비즈니스 서비스 구현하기, Part 1: 비즈니스 서비스를 수행할 SOA 복합 애플리케이션을 개발하기에 나와있다. Part 1에서는 공통의 공유 호스팅 환경에서 다중 비즈니스 서비스 등록자(소유자)를 다중 소유(multi-tenancy)로서 지원하는 기능에 대해 설명했다.
다중 소유에 대한 지원은 런타임 전반에 걸친 디자인 고려 사항이다. 런타임 환경의 토폴로지의 모든 레이어, 서비스 구현, 사용자 인터페이스를 신중하게 고려해야 한다. 다중 소유 플랫폼 구현에 대한 옵션은 하드웨어 기반에서 가상화로 스팩트럼을 확장한다. 각 등록자는 전용 하드웨어와 소프트웨어 세트에서 호스팅 될 수 있다. 이 토폴로지는 호스팅 환경에 사용되는 실제 하드웨어를 선택함으로써 다양한 옵션들을 통해서 사용자에게 최대한의 유연성을 제공하고 있다. 예를 들어, CPU 선택을 통해서 구체적인 성능을 선택할 수 있다. 또한 서버 하드웨어에 기반하여 신뢰성 레벨도 선택할 수 있다. 하지만, 이러한 토폴로지는 비용이 많이 들 수 있다. 공급자가 클라이언트를 위한 전용 서버를 관리해야 하기 때문이다. 공급자는 많은 고객들에 하드웨어를 공유함으로써 비용 절감을 실감한다. 예를 들어, 공급자는 고객 당 하나의 데이터베이스를 가진 서버에 다중 데이터베이스를 설치하여 비용을 줄일 수 있다. 공급자는 애플리케이션 서버의 인스턴스도 공유하여 비즈니스 서비스의 다중 인스턴스를 호스팅 한다.
개념상으로는, 다중 소유 플랫폼용 옵션 범위는 다음과 같이 나뉠 수 있다.
비공유 환경 조차도 잘 정의된 토폴로지, 공통의 하드웨어/소프트웨어 제품 정의, 통합 로드맵을 통해 효용을 누릴 수 있다. 서버 공유 카테고리는 매우 광범위하고, 다음과 같은 옵션들을 포함하고 있다.
- 지원 인프라스트럭처만 공유하는데, 이는 Tivoli® Provisioning Manager 같은 제품을 사용하여 제공된다.
- Tivoli Access Manager와 WebSeal 같은 제품을 사용하여 보안을 공유한다.
- DB2 같은 제품을 사용하여 데이터베이스 서비스를 공유한다.
- 애플리케이션, 프로세스, 포털 서버 같은 미들웨어를 공유한다.
이 글에서는 공유 애플리케이션에 대해 논할 것이다. 하드웨어와 소프트웨어를 포함한 전체 스택이 사용자들을 통해서 재사용 되는 환경이다. 소프트웨어는 개별 등록자를 위해 설정된다. (커스터마이징 옵션도 남겨둔다.)
다음 섹션에서는 다중 소유에 대한 지원이 어떻게 이루어지는지를 배울 것이다. 이 섹션에서는 복합 애플리케이션에 필요한 서비스의 세 가지 핵심 유형들에 초점을 맞추겠다.
그림 2. 복합 애플리케이션 서비스
엔터프라이즈 서비스
다음 제품들은 다중 소유 플랫폼에 사용되어 CBS용 인프라스트럭처를 구현한다.
- WebSphere Portal
- WebSphere Process Server
- WebSphere Service Registry and Repository
- DB2
- Tivoli 제품들(Directory Server 포함)
그림 3. 복합 비즈니스 서비스 아키텍처
그림 3의 런타임 환경에서 프리젠테이션과 비즈니스 서비스에 필요한 기능이 실행되지만, 일부 작동은 서비스 공급자측의 관리자가 직접 수행하여 등록자들에게 이러한 기능을 노출 및 설정해야 한다. 새로운 등록자(소유자)를 플랫폼에 추가하려면, 공급자 측의 관리자는 다음을 수행해야 한다.
- LDAP 디렉토리 서버(Tivoli Directory Server)에 전용 영역을 만들어야 한다. 이 영역은 WebSphere Portal의 구조 디렉토리를 사용하여 설정되어야 한다.
- 등록자 계정 아이디가 등록자에게 할당되어야 한다. 이 아이디는 WebSphere Portal의 가상 포털 기능과 함께 사용되고 등록자의 웹 채널 목적지 같은 고유한 URL의 일부가 된다.
- 테마와 스킨이 각 은행 마다 구현되어 등록자의 가상 포털의 레이아웃과 룩앤필을 정의하고, 개별 포틀릿들을 정의해야 한다. 테마와 스킨은 다중 소유 플랫폼을 구동하는 WebSphere Portal에 설치되어야 한다.
프리젠테이션 서비스
다중 소유 호스팅 플랫폼의 프리젠테이션 서비스는 사용자에게 인증 전용 엔트리 포인트를 제공해야 한다. 이 플랫폼은 등록자와 엔드 유저 모두에게 보안성을 보장해야 하고, 모든 플랫폼 사용자들의 정보를 보호해야 한다. 다중 소유 플랫폼의 프리젠테이션 서비스에서는 다음과 같은 기능을 사용할 수 있어야 한다.
- 채널 목적지(Channel destination)는 등록자의 엔드 유저에게 플랫폼에 대한 엔트리 포인트를 제공한다. 예를 들어, 웹 채널의 경우, 고유 URL은 채널 목적지로서의 역할을 할 수 있지만, IVR 채널의 경우, toll-free 넘버가 사용될 수 있다.
- 등록자 고립(Subscriber isolation)으로 등록자들의 사용자가 비즈니스 서비스와 플랫폼의 다른 등록자의 정보에 액세스 할 수 없도록 한다. 예를 들어, 뱅킹 서비스 공급자인 SaasBank가 두 개의 뱅킹 서비스 등록자(First Bank NA와 Second Canadian Bank)를 갖고 있는 상황을 생각해 보자. 이 예제에서, First Bank NA의 고객이 웹 사이트에 로그인 하면, 고객은 First Bank NA에 대한 사용자 인증을 받아야 한다. Second Canadian Bank나 SaasBank 인증이 아니다.
- 브랜딩(Branding)은 엔드 유저가 채널 목적지에 액세스 하거나 채널 인증을 받을 때, 엔드 유저에게는 해당 등록자만의 룩앤필이 제공된다. 예를 들어, First Bank NA 고객이 로그인 하면, 사용자 인터페이스는 그 은행 고유의 것이 되어야 하고, 엔드 유저에 의해 수정된 룩앤필 설정(레이아웃 또는 사용자 스킨)은 First Bank NA에 속해야 한다.
지금까지, 이 섹션에서는 다중 소유 애플리케이션의 사용자 측면(User-Facin)은 무시한 채 인프라스트럭처 기능에만 초점을 맞췄다. WebSphere Portal 같은 포털 기반 환경에서 다중 소유 애플리케이션을 위해 구현된 포틀릿들은 다음 섹션에서 설명할 고려 사항들에 기반하여 디자인 및 개발되어야 한다.
등록자 공급자가 개별 등록자들간 포틀릿들을 공유하기 때문에, 각 포틀릿은 각 등록자들을 위해 설정이 가능해야 한다. 높은 재사용 수준을 유지하려면, 포틀릿에서의 설정 가능성은 등록자 아이디 또는 등록자의 서비스 엔드포인트 같은 이름-값 쌍 설정부터 엔드 유저로 렌더링 되어야 하는 폼 필드나 액션 버튼을 가리키는 설정이 되어 있는 등록자 스팩의 룩앤필까지 등록자 스팩의 설정을 지원해야 한다. 등록자 레벨에서 설정 가능성을 실현하는 것 외에도, 개별 등록자가 서비스 공급자의 지원을 받지 않고 설정을 수행할 수 있어야 한다.
이전 단락에서 설명한 설정 고려 사항들을 처리하기 위해, 다중 소유 애플리케이션에 포틀릿의 구현과 전개에 대해 "clone-and-configure" 접근 방식을 채택할 수 있다. WebSphere Portal에서는 서버에 전개된 개별 포틀릿들이 복제될 수 있다. 포틀릿 코드를 포함하고 있는 각각의 WAR 파일의 경우, 클론 또는 포틀릿 카피는 다른 설정 옵션으로 만들어 질 수 있다. 다른 등록자에 다른 설정을 지원하기 위해, 서비스 공급 관리자는 각 등록자를 위해 포틀릿을 복제하고 포틀릿 클론에만 등록자가 액세스 할 수 있는 방식으로 포털 권한 설정을 할당한다. 또한, 서비스 공급 관리자는 추가 권한을 등록 관리자에게 할당하여 등록 관리자들이 복제된 포틀릿을 설정할 수 있는 권한을 부여한다.
예를 들어, 뱅킹 다중 소유 애플리케이션의 정황 속에서, Funds Transfer 서비스라고 하는 사용자 서비스를 처리하는 포틀릿을 생각해 보자. 가상의 SaasBank의 서비스 공급자는 Funds Transfer 포틀릿을 Second Canadian Bank로 노출한다면, 포틀릿 전개에 사용되는 clone-and-configure 방식은 다음과 같다.
- Administrative 콘솔에서 WebSphere Portal Portlet Management 그룹을 연다.
- Manage Portlets 기능을 사용하여 Funds Transfer 포틀릿의 복제 카피를 찾아 생성한다.
- Administrative 콘솔에서 Resource Permissions를 사용하여 Funds Transfer 포틀릿의 클론을 찾는다.
- Second Canadian Bank용 등록 관리자를 복제된 Funds Transfer 포틀릿의 관리자로서 추가한다.
Second Canadian Bank 등록 관리자의 관점에서, Funds Transfer 포틀릿이 그 은행에 사용되면(복제된 포틀릿은 적절한 권한을 생성 및 할당했다.)등록 관리자는 다음 단계를 수행한다.
- Administrative console > Portlet Management > Manage Portlets를 사용하여 Funds Transfer 포틀릿을 찾는다.
- Funds Transfer 포틀릿용 설정을 열고, Second Canadian 은행 용 등록자 계정 아이디를 지정한다.
- 서비스 엔드포인트 같은 Funds Transfer 포틀릿의 다른 설정 부분을 검토 및 수정한다.
비즈니스 서비스
그림 2에서 보았듯이, 다중 소유 애플리케이션의 비즈니스 서비스들은 프리젠테이션 레이어에 의해서 다른 등록자에서 기인한 요청들을 받아서 처리해야 한다. 더욱이, 비즈니스 서비스의 디자인 및 구현은 서비스들이 등록자와 사용자들에 맞춰 재사용 및 개인화 되도록 해야 한다.
이전 섹션에서 언급했듯이, 다중 소유 플랫폼의 각 등록자는 고유한, 플랫폼 중심의 등록자 아이디로 구분된다. 사용자 인터페이스 레이어에서, 등록자 스팩의 포틀릿 설정은 아이디를 관리하고 등록자의 엔드 유저와 관련된 아이디를 유지해야 한다. 프리젠테이션 레이어에 있는 엔드 유저에 의해 생성된 서비스 요청들은 비즈니스 로직 레이어에서 핸들되는데, 여기에서 아이디는 비즈니스 서비스에 대한 설정 매개변수로서 취급된다.
프리젠테이션 레이어에서 비즈니스 레이어로 등록자 아이디를 전달하면 비즈니스 서비스 구현에 두 가지 영향을 준다. 첫 번째는, WSDL 인터페이스 디자인, 특히 서비스로 흘러가는 데이터용 메시지 스키마 디자인에는 매개변수들 중 하나로서 등록자 아이디가 포함되어야 한다. 예를 들어, 아래 코드에서, 등록자 아이디는 대출 처리 비즈니스 프로세스 샘플에 사용된 processLoan 메시지의 일부로서 bankID를 호출된 변수로서 구현된다.
Listing 1. 코드 리스팅
<!--
<wsdl:types>
<schema elementFormDefault="qualified"
targetNamespace="http://process91958946.www.example.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:impl="http://process91958946.www.example.com"
xmlns:intf="http://process91958946.www.example.com"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<element name="processLoan">
<complexType>
<sequence>
<element name="bankId" nillable="false" type="xsd:string"/>
<element name="loanAmount" nillable="true" type="xsd:decimal"/>
<element name="customerId" nillable="true" type="xsd:string"/>
<element name="ssn" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="processLoanResponse">
<complexType>
<sequence/>
</complexType>
</element>
</schema>
</wsdl:types>
|
두 번째는, 비즈니스 레이어의 서비스 구현이 등록자 아이디를 사용하여 서비스 등록자와 개별 엔드 유저에게 다양성을 제공해야 한다. WebSphere Process Server (WPS)를 사용하여 구현된 다중 소유 플랫폼은 서비스 구현에 가변성을 추가하기 위해 많은 옵션들을 제공한다. 예를 들어, WebSphere Business Modeler를 사용하여 구현된 비즈니스 프로세스는 WPS 에서 실행되기에 알맞은 BPEL 비즈니스 규칙으로 변환되는 가변 포인트를 나타내기 위해 추가될 될 수 있다. 비즈니스 규칙은 WebSphere Business Modeler 없이, WebSphere Integration Developer를 사용하여 BPEL 워크플로우에서 직접 지정될 수 있다. 예를 들어, 다양한 등록자용 대출 승인 프로세스에서의 규칙 중에는, First Bank NA의 경우는 신용 평점 720 이상이면 자동 승인이지만, Second Canadian Bank의 신청자의 경우는 평점이 750 이상이어야 한다.
결론
CBS용 다중 소유 플랫폼의 핵심적인 아키텍처 개념을 설명했다. 다중 소유 플랫폼에서의 역할들은 서비스 공급자, 서비스 등록자, 다중 소유 애플리케이션의 엔드 유저들 간 관계를 나타내는 뱅킹 애플리케이션 예제를 통해 설명했다. 애플리케이션 아키텍처는 핵심 서비스 유형인 인프라스트럭처, 프리젠테이션, 비즈니스로 구성된다. 이 글에서는 인프라스트럭처 서비스의 기본 런타임 아키텍처, 프리젠테이션 서비스와 관련한 문제, clone-and-configure 패턴, 비즈니스 서비스 구현 시 다중 소유 애플리케이션 디자인의 영향에 대해 설명했다.
참고자료 교육
토론
필자소개 | 
| | Amber Roy-Chowdhury는 IBM Research Triangle Park, NC의 소프트웨어 엔지니어이다. WebSphere Portal 아키텍처와 개발을 담당하고 있다. 현재 Property Broker로 알려진 WebSphere Portal용 통신 중개 프레임웍의 아키텍트 및 기술 리더로 활동하고 있다. 이전에는 WebSphere Application Server와 Encina Transaction Processing Monitor 제품 개발 업무를 담당했다. 일리노이대학교 어버너 샘페인 캠퍼스에서 박사 학위를 받았다. |
| 
| | Germán Goldszmidt박사는 IBM Software Group의 수석 엔지니어로서, SOA 비즈니스 서비스를 제공, 커스터마이징, 전개하는 통합 플랫폼 아키텍처를 연구하고 있다. IBM T.J. Watson Research Center의 연구원이었으며, Océano, eUtility, Network Dispatcher 등 여러 기술들의 디자인 및 구현을 담당했다. |
| 
| | Carl Osipov는 IBM Software Group의 Strategy and Technology 부서의 소프트웨어 아키텍트이다. 분산 컴퓨팅, 스피치 애플리케이션 개발, 전산 중립적인 언어를 전문으로 하고 있다. 서비스 지향 아키텍처 관련하여 저술 및 강연 활동을 하고 있다. 현재 복합 비즈니스 서비스의 재사용 기술 디자인에 주력하고 있다. |
기사에 대한 평가
| |
