Microsoft Dynamics CRM 4.0 배포
Aaron Elder
한눈에 보기:
- CRM 시스템의 소프트웨어 구성 요소
- 개발 수명 주기
- CRM 솔루션의 요소
- 단일 시스템 상의 다중 고객 지원 소개
목차
솔루션 개발 수명 주기
CRM 솔루션의 요소
단일 시스템 상의 다중 고객 지원 소개
설계 고려 사항
핵심 내용
CRM을 단순히 영업 및 마케팅 관리 도구로 생각하는 것은 큰 착각입니다. 사실 Microsoft Dynamics CRM(고객 관계 관리)은 실제 개체와 관련한 정보와 프로세스를 관리 및 추적하는 응용 프로그램의 개발에 사용되는 플랫폼입니다. 이러한 개체는 고객일 수도 있지만 사실상 관리가 필요한 모든 엔터티(및 관련 작업)가 개체가 될 수 있습니다.
다른 모든 대규모 사용자 지정 솔루션과 마찬가지로 배포와 관련하여 알아야 할 몇 가지 기본적인 사항이 있습니다. 이 기사에서는 Microsoft Dynamics CRM 배포와 관련한 몇 가지 기본 개념에 대해 설명하겠습니다. 전체 제품 수명 주기 배포에 이러한 개념이 어떻게 이용되는지도 살펴봅니다. 또한 여러 개의 배포를 단일 솔루션 릴리스로 관리하는 방법과 단일 시스템 상의 다중 고객 지원을 전체 솔루션 수명 주기에서 올바르게 사용하는 방법도 다룹니다.
칼럼의 본 내용을 시작하기에 앞서 Microsoft Dynamics CRM "솔루션"은 모든 사용자 지정 항목, 확장 항목, 사용자 지정 코딩, 스키마 변경 항목 등을 통칭하는 표현임을 밝혀 둡니다. 한마디로 솔루션은 특정 항목이 아니라 모든 변경 내용을 아우르는 개념입니다.
사실상 Microsoft Dynamics CRM 솔루션은 표준 ASP.NET 2.0 및 Microsoft .NET Framework 3.5 데이터 기반 웹 응용 프로그램입니다. 이 3계층 시스템에는 다음 세 가지 주요 구성 요소가 포함됩니다.
데이터 계층 SQL Server 2005 또는 SQL Server 2008 데이터베이스. SQL Server 2008을 사용하려면 기술 자료 문서 "Microsoft Dynamics CRM 4.0을 Microsoft SQL Server 2008과 함께 실행할 수 있도록 지원"에서 설명하는 핫픽스가 필요합니다.
중간 계층 Microsoft 인터넷 정보 서비스(IIS) 6.0 이상 웹 프런트 엔드, SQL Server Reporting Services(SRS) 2005 또는 SRS 2008, ASP.NET 3.5, 사용자 지정 Windows 서비스
클라이언트 계층 Microsoft Internet Explorer 6.0 이상 클라이언트, ASP.NET 2.0 이상, Microsoft Office Outlook 2003 또는 Office 2007 클라이언트(오프라인 액세스 옵션 포함), SDK 소비자 및 타사 모바일 클라이언트와 같은 기타 클라이언트
Microsoft Dynamics CRM은 Microsoft Exchange Server 2003 이상, Active Directory 등의 다양한 외부 시스템도 사용합니다.
솔루션 개발 수명 주기
Microsoft Dynamics CRM 솔루션은 사용자 지정 응용 프로그램 개발 프로젝트와 마찬가지로 그림 1에 나와 있는 프로세스와 유사한 수명 주기로 개발됩니다.
그림 1 응용 프로그램 개발 수명 주기
전체 프로세스는 개발, 테스트 및 프로덕션 시스템을 구성하는 몇 가지 환경에 의해 지원됩니다. 물론 다면적 엔터프라이즈 응용 프로그램 환경에서는 이러한 구성이 매우 복잡해질 수 있습니다. 예를 들어 시스템 환경을 미러링하려는 경우 그림 2와 같은 구성이 될 수 있습니다.
그림 2 개발, 테스트 및 프로덕션 환경 미러링
이 모델은 SRS와 CRM이 같은 컴퓨터에 설치되어 있고 부하 분산 등의 기능은 고려하지 않는다는 전제 하에 도메인 3개, 도메인 컨트롤러 3대, 메일 서버 3대, 웹 서버 3대, 데이터베이스 서버 3대로 구성됩니다. 여기에 Microsoft Office SharePoint Services(MOSS)와 같은 몇 가지 외부 서비스 및 중복성을 추가할 경우 그림 3과 같은 복잡한 체계가 만들어질 수 있습니다.
그림 3 복잡성 증가
비용과 복잡성으로 인해 시스템 환경 격리의 필요성과 비용 절감 및 관리 효율성 제고의 필요성 사이에서 절충점을 찾아야 할 것입니다. 이러한 이유로 조직에서는 가상화나 Microsoft Dynamics CRM에서 기본 제공되는 단일 시스템 상의 다중 고객 지원 기능 같은 다양한 기술을 도입하여 이러한 문제를 해결하려 합니다.
CRM 프로젝트의 수명 주기를 지원하는 일련의 환경을 설계할 때는 설계자가 중요하게 생각하는 원칙에 따라 몇 가지 설계 방식 중 하나를 선택하게 됩니다. 한편에는 완전한 복제를 사용하는 완벽하게 격리된 환경을 지향하는 설계자가 있습니다. 이들은 프로덕션 환경 외부에서 정상 작동하는지 확인하려면 프로덕션 환경과 100% 일치하는 테스트 환경이 필요하다고 믿습니다. 테스터와 IT 담당자가 프로덕션 환경의 정상 작동을 확신하기 위해서는 모든 서버, 모든 항목, 모든 설정까지 동일해야 하고 개발 및 프로덕션 환경으로부터 완전하게 격리되어야 한다는 논리입니다.
이와 대조적으로, 격리 여부는 크게 문제되지 않는다고 생각하는 설계자도 있습니다. 이들은 가능한 한 프로덕션 환경에서 직접 개발하고 테스트하려 합니다. 중복성을 시간과 비용의 낭비로 보고, 프로덕션 환경에서 바로 구현하는 편이 배포하기가 쉽다고 믿습니다.
이러한 양 극단에 치우치지 않고 Microsoft Dynamics CRM 기반 솔루션의 경우 복잡성, 비용, 격리, 관리 효율성이 적절히 균형 잡힌 혼합 모델의 개발이 가능하다는 것을 인식해야 합니다.
CRM 솔루션의 요소
Microsoft Dynamics CRM 솔루션의 구성 요소는 크게 4가지 범주로 나눌 수 있으며 그중 일부만 포함하거나 아니면 네 가지 모두를 포함한 솔루션을 개발할 수 있습니다.
사용자 지정 항목 사용자 지정 항목에는 폼/표/스키마/메타데이터의 변경 항목, 보안 역할, 워크플로, 시스템 설정 및 템플릿이 포함됩니다. Microsoft Dynamics CRM 사용자 지정 항목은 하나 이상(일반적으로 1 - 2개)의 압축된 XML 파일로 제공됩니다. 사용자 지정 항목은 Outlook 또는 웹 클라이언트의 "설정 | 사용자 지정" 영역에서 CRM 배포로 가져온 다음 "게시"하여 활성화합니다. 이러한 모든 과정은 Microsoft Dynamics CRM SDK에 대해 작성된 코드로 자동화할 수 있습니다.
확장 항목 확장에는 사용자 지정 항목과 별도로 배포해야 하는 플러그 인 등의 사용자 지정 코드와 보고서가 포함됩니다. 플러그 인 등록 정보는 XML 파일로 저장되며 명령줄이나 Microsoft에서 제공하는 Windows Form 응용 프로그램을 통해 배포할 수 있습니다. 또한 Microsoft Dynamics CRM SDK에 대해 작성된 코드를 통해 배포 프로세스를 자동화할 수도 있습니다.
사용자 지정 코드 솔루션의 일부로 개발된 모든 항목을 말하며 외부 웹 서비스, 사용자 지정 웹 응용 프로그램 구성 요소 등이 포함될 수 있습니다. 사용자 지정 코드 배포와 관련한 규칙 및 실행 방법은 다른 사용자 지정 웹 응용 프로그램과 다르지 않습니다.
데이터 환경이 작동할 수 있도록 해당 환경으로 가져와야 하는 정보를 말합니다. 제품 코드 목록 같은 도메인 데이터나 사용자가 여기에 포함될 수 있습니다. 솔루션에 필요한 데이터는 스크립트 코드 또는 CRM의 대량 가져오기 기능을 사용하거나, BizTalk 또는 기타 ETL(추출, 변환, 로드) 도구를 사용하는 일종의 외부 프로세스를 통해 Microsoft Dynamics CRM 인스턴스에 배포할 수 있습니다. 사용자를 비롯한 일부 데이터는 수동으로 작성하거나 Microsoft Dynamics CRM SDK 호출을 통해 작성해야 합니다.
필자는 CRM 솔루션 배포를 사용자 지정 응용 프로그램 개발 배포와 동일하게 생각합니다. 즉, 개발 및 테스트 시에는 각각의 새로운 솔루션 빌드를 새로운 기본 시스템에서 설치하고 프로세스는 되도록이면 반복 가능한 스크립트로 작성합니다.
단일 시스템 상의 다중 고객 지원 소개
다음으로 이러한 구성 요소를 배포하게 될 환경을 살펴보도록 하겠습니다. Microsoft Dynamics CRM 4.0 Enterprise Edition에서 단일 시스템 상의 다중 고객 지원 기능이 지원된다는 내용을 읽어 본 적이 있을 겁니다. 이 기능은 단일 배포 내에서 여러 Microsoft Dynamics CRM 인스턴스로 분할할 수 있도록 지원합니다. 다시 말해 완전히 분리된 여러 조직이 각각 자체적인 보고서, 워크플로, 사용자 지정 항목 및 스키마를, 동일한 실제 서버와 데이터베이스 인스턴스 및 IIS 웹 사이트를 사용하는 동일한 하드웨어 집합에서 실행할 수 있습니다.
언뜻 보면 이 기능은 모든 관리 용이성, 격리, 비용 문제를 해결해 주는 만병통치약처럼 보입니다. 그림 4에서는 이 솔루션을 시각적으로 보여 줍니다.
그림 4 단일 시스템 상의 다중 고객 지원 솔루션
각 조직이 공유 SQL Server에서 고유한 실제 데이터베이스 또는 인스턴스(사용자 지정 항목, 워크플로, 사용자, 역할 및 설정 포함)를 가지며 SQL Reporting Services 폴더도 각각 고유하게 구성되기 때문에 논리적인 구성으로 보입니다.
분리된 조직이 서로 다른 팀 또는 부서 솔루션의 일부인 경우에는 이 모델이 매우 적합합니다. 단일 시스템 상의 다중 고객 지원은 바로 이러한 용도로 설계된 기능입니다. 각 조직(또는 고객)별로 고유한 데이터베이스가 사용되기는 하지만 OU(조직 구성 단위)와 Active Directory 그룹은 모든 조직에서 공유되고 플랫폼 서비스와 프런트 엔드 응용 프로그램도 공유하게 됩니다. 따라서 동일한 비동기 서비스와 IIS 웹 사이트가 조직 간에 공유됩니다. 프런트 엔드 서버는 URL에 따라 호스트할 조직을 결정하는 URL 공급자를 통해 이러한 여러 조직을 "호스트"할 수 있습니다.
crmserver/ContosoDevOrg/loader.aspx와 crmserver/ContosoTestOrg/loader.aspx라는 URL을 예로 들어 보겠습니다. CRM 서버는 루트 디렉터리를 검색하여 지원할 조직의 이름을 확인합니다. crmserver/loader.aspx의 경우와 같이 루트 조직 이름이 검색되지 않으면 서버는 기본적으로 배포 시스템에 생성된 첫 번째 조직이나 호출하는 사용자에게 액세스 권한이 있는 조직을 호스트합니다.
두 조직에서 동일한 웹 사이트를 사용하기 때문에 솔루션에 사용자 지정 코드가 포함되어 있으면 해당 코드도 두 조직에서 공유하게 됩니다(예: crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx와 crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx).
두 코드는 디스크에서 동일한 실제 파일(예: C:\inetpub\wwwroot\isv\mycustomdialog.aspx)을 가리킵니다. 그런데 사용자 지정 확장 항목은 개발, 테스트 및 프로덕션 환경에서 각기 다를 수 있어 심각한 문제가 발생할 수 있습니다. 예를 들어 응용 프로그램의 빌드 11을 개발하는 동시에 빌드 9에 대한 UAT(사용자 승인 테스트)를 진행하고 있다고 가정해 보십시오. 이 경우 단일 시스템 상의 다중 고객 지원을 사용하여 시스템 환경의 문제를 해결하려 하면 이 두 빌드를 격리하는 데 어려움을 겪게 됩니다. 이러한 상황에서는 그림 5와 같은 솔루션으로 문제 해결을 시도하게 되기 쉽습니다.
그림 5 서로 별개인 여러 IIS 서버로 사용자 지정 솔루션 코드 분리 시도
네트워크 부하 분산 주소를 더 이상 사용하지 않는다면 이 모델에서는 사용자가 다음과 같은 URL에 연결될 수 있습니다.
개발 192.168.1.100/ContosoDevOrg/loader.aspx
테스트 192.168.1.105/ContosoTestOrg/loader.aspx
프로덕션 192.168.1.110/Contoso/loader.aspx
이 모델에서는 디스크에 서로 다른 세 가지 코드베이스가 저장되어 각각 서로 다른 조직을 호스트하는 3개의 프런트 엔드 서버를 구성할 수 있습니다. 사용자가 실수로 잘못된 서버의 잘못된 조직에 연결하지 않는 한 문제는 없습니다.
그러나 아쉽게도 모든 프런트 엔드 서버가 동일한 배포의 일부로 간주되므로 처음에는 잘 나타나지 않지만 점차적으로 세부적인 문제가 발생하기 시작합니다. 게다가 솔루션에 비동기 플러그 인이나 워크플로가 사용되는 경우 사용자가 액세스할 서버를 제어할 수는 있지만 어느 비동기 서비스가 어느 조직의 이벤트와 요청을 처리할지를 제어할 수 없기 때문에 문제가 더 심각해집니다.
배포의 모든 비동기 서비스는 라운드 로빈 방식으로 작동하고, 따라서 배포 서버의 비동기 서비스가 워크플로, 시스템 작업 또는 테스트 서버에서 보낸 요청에 대한 비동기 플러그 인 응답을 처리할 수 있기 때문에 격리 요구 사항이 충족되지 않습니다. 뿐만 아니라 이 비동기 프로세스에 의해 실행되는 사용자 지정 코드가 서버의 디스크에 배포해야 하는 파일(예: 구성 파일, GAC(전역 어셈블리 캐시)의 파일)을 사용한다면 버전 충돌도 발생하게 됩니다.
대개 이러한 문제는 디스크에 배포해야 하는 사용자 지정 코드를 작성하거나, 사용자 지정 코드가 특정 서버에서만 사용 가능한 리소스를 사용할 경우에만 발생합니다. 사용자 지정 항목(스키마, 폼, 뷰 등), 워크플로 및 보고서만 사용하는 단순한 솔루션은 그림 4의 방식을 사용해도 문제가 없습니다.
단일 시스템 상의 다중 고객 지원의 용도는 무엇이며, 어떤 경우에 이 기능이 제품 수명 주기 환경의 솔루션으로 적합할까요? 단일 시스템 상의 다중 고객 지원은 프로덕션 환경에서 여러 개별 고객을 호스트하는 데 따른 하드웨어 문제를 해결하려는 목적으로 설계되었고 그 성과도 뛰어납니다. 이전에는 Microsoft Dynamics CRM 3.0에서 각 배포 또는 고객별로 전용 SQL Server 또는 SQL Server 인스턴스와 프런트 엔드 서버를 구축해야 했습니다.
이는 배포별 설정이 레지스트리와 디스크에 저장되는 등의 여러 가지 이유 때문이었습니다. 그러나 이제 이러한 모든 구성이 데이터베이스로 옮겨졌기 때문에 단일 응용 프로그램 서버에서 여러 조직을 처리할 수 있습니다. 단일 시스템 상의 다중 고객 지원은 Microsoft Dynamics CRM Online을 비롯한 CRM의 호스트된 버전에 유용합니다.
설계 고려 사항
몇 가지 잠재적인 문제점을 살펴보았으니 이제 배포를 설계할 때 고려해야 할 사항을 알아보도록 하겠습니다. 물론 고려할 사항은 상황에 따라 다릅니다. Microsoft Dynamics CRM 4.0 가상 컴퓨터 데모("CRM 리소스" 보충 기사의 URL 참조)에서 보듯이 전체 CRM 환경(도메인 컨트롤러, SQL 서버 및 웹 서버 포함)을 단일 컴퓨터에서 실행해도 문제가 없습니다. 단일 컴퓨터 가상 이미지를 배포 환경에 사용하는 경우는 매우 흔합니다. 그러나 테스트 시에는 프로덕션 환경의 주요 문제를 확인해야 하기 때문에 테스트 환경의 구조는 프로덕션 환경을 미러링하는 것이 좋지만 용량의 경우에는 그렇지 않습니다. 그림 6에 이러한 환경의 예가 나와 있습니다.
그림 6 프로덕션 구조를 미러링한 테스트 환경 구조
이 경우 가상화를 활용하여 인프라의 실제 하드웨어를 최소화하고 테스트할 핵심 시나리오만 가상화하여 가상화 리소스도 최소화할 수 있습니다. 개발자가 솔루션을 배포할 환경을 잘 파악하고 있으며 주의를 기울일 것이라는 확신이 있으면 단일 서버 이미지(개인용 데스크톱에 자체 가상 컴퓨터가 있는 경우 복수의 이미지)에서 개발을 진행하도록 할 수 있습니다. 개발자가 주의를 기울여야 하는 문제가 바로 테스트 환경에서 확인할 문제이며, 다음과 같습니다.
구성 가능한 설정 구현 예를 들어 서버가 localhost 또는 특정 포트에 당연히 응답할 것으로 가정해서는 안 됩니다.
복수 서버임을 인지 프록시 사용자나 위임을 위한 신뢰 관계를 설정하지 않고도 문제없이 작동할 것으로 가정해서는 안 됩니다.
부하 분산 고려 세션 상태와 캐싱에 주의를 기울여야 합니다. Microsoft Dynamics CRM은 완전히 상태 비저장 방식으로 설계되었으며 라운드 로빈 부하 분산 장치와 문제없이 작동합니다.
단일 시스템 상의 다중 고객 지원 고려 단일 컴퓨터에서 여러 고객을 호스트하는 경우 동일한 프로세스 공간을 공유하게 됩니다. 따라서 캐시와 같은 요소에 조직 이름을 키로 사용하여 특정 조직의 사용자가 실수로 다른 조직의 데이터를 사용하지 않도록 해야 합니다. 또한 서버로 연결되거나 서버를 다시 호출하는 클라이언트 쪽 코드가 있으면 호출 시 URL에 조직 이름이 유지되도록 해야 합니다. 그렇지 않으면 기본 조직 또는 원치 않는 조직에 연결될 수 있습니다.
CRM 리소스
Microsoft Dynamics CRM 4.0 구현 가이드
비즈니스 응용 프로그램 개발 플랫폼으로서의 Microsoft Dynamics CRM 4.0
Microsoft Dynamics CRM 4.0 가상 컴퓨터
Microsoft Dynamics CRM 4.0 최적화 및 유지 관리
핵심 내용
격리의 중요성 솔루션을 설계할 때는 가장 적합한 방법(그림 4, 5 또는 6)이 무엇인지와 사용자 지정 코드가 실행될 수 있는 시기 및 위치를 고려해야 합니다. 또한 솔루션에 사용되는 확장 유형으로 인해 이러한 사항이 문제가 될 수 있는 가능성도 살펴야 합니다.
가상화 가상화는 프로덕션 환경의 주요 테스트 시나리오를 미러링한 환경을 구축할 때 복잡성을 줄이는 데 도움이 됩니다. 가상화 설정과 관련해서 몇 가지 지침을 소개하자면, 우선 CRM과 SQL Server를 서로 다른 서버에 설치해야 합니다. 이렇게 하면 위임을 위한 신뢰 관계와 기타 관련 문제를 확인하기가 용이합니다. 둘째로, 세션, 캐싱 및 서버 간 문제를 쉽게 파악하려면 CRM 서버의 부하를 분산해야 합니다. 마지막으로, 연결 문제를 파악하기 쉽도록 도메인 컨트롤러와 전자 메일을 서로 다른 서버에 구성해야 합니다.
각 빌드마다 환경을 새로 설정일반적인 규칙으로, 서버를 "기본" 상태로 복원할 수 있도록 가상 환경이나 Microsoft Dynamics CRM 데이터베이스(Data 및 Config) 중 하나의 백업을 생성하는 것이 좋습니다. 그런 다음 매번 사용자 지정 코드, 사용자 지정 항목, 플러그 인, 도메인 데이터를 포함한 새 배포를 새로운 환경에 전체 설치합니다.
중복/성능 테스트를 별도로 수행할 수 있음 규모가 매우 큰 조직이 아니라면 장애 조치(failover)와 성능 테스트를 실제로 구축된 환경이 아니라 격리된 시뮬레이션 환경에서 수행하는 것이 보통입니다. 따라서 이러한 시나리오를 테스트하기 위해 테스트 환경을 구축할 필요가 없습니다. 또는 프로덕션 환경이나 별도의 일회성 환경에서 테스트할 수도 있습니다.
정리하면 Microsoft Dynamics CRM은 올바르게 구성 및 배포하기만 하면 소규모 팀에서 전사적 솔루션에 이르는 모든 규모의 조직을 처리할 수 있는 확장 가능한 엔터프라이즈급 시스템입니다. 적합한 제품 수명 주기 환경을 선택할 때는 다양한 요소를 고려해야 합니다.
일반적으로 단일 시스템 상의 다중 고객 지원은 복잡한 솔루션의 제품 수명 주기 개발 문제를 해결하는 데 이상적인 방법이 아니므로 그 기능을 완전히 이해한 후에 사용하는 것이 좋습니다. 기본적인 사용자 지정만 필요로 하거나, 올바르게 코딩 및 격리되어 디스크 리소스 또는 서버별 액세스를 사용하지 않는 사용자 지정 확장을 사용하는 간단한 솔루션의 경우 그림 4에 나와 있는 모델을 따르면 됩니다.
보다 완벽한 격리, 서버별 리소스 또는 액세스(서버 간에 VLAN을 통해서만 외부 서비스에 액세스할 수 있는 경우) 등이 필요한 솔루션의 경우에는 그림 6의 모델을 따르는 것이 좋습니다. 또한 혼합으로 인해 복잡성만 더하는 그림 5의 방법은 피하는 것이 좋습니다.
궁극적으로 Microsoft Dynamics CRM은 수천 가지 구성으로 배포할 수 있으며 적합한 구성은 솔루션의 요구 사항에 따라 다릅니다. 단일 시스템 상의 다중 고객 지원, 단일 서버 배포 환경, 가상 테스트 환경을 잘 이해하고 중요한 테스트 시나리오를 파악할 수 있다면 문제없이 작동하면서 경제적인 제품 수명 주기 배포를 설계할 수 있습니다.
Aaron Elder(Microsoft Dynamics CRM MVP)는 기술 컨설팅 및 인터렉티브 마케팅 업체인 Ascentium에서 근무하고 있습니다. 문의 사항이 있으면 저자의 블로그 ascentium.com/blog/crm을 방문하시기 바랍니다.