아키텍트2009. 12. 8. 11:33

서비스를 개발하기 위해 WCF, WF를 사용해보신 경험이 있을 겁니다. 실제 환경에서 WCF와 WF를 사용할 때의 과제 중 하나는 서버 환경에서 서비스와 워크플로를 호스트하는 위치를 결정하는 것이죠. WCF를 위해 Windows Server 2008의 IIS와 WAS(Windows Process Activation Service)를 선택하는 경우가 일반적 입니다.

현재 IIS와 WAS를 조합하면 들어오는 메시지에 응답하여 프로세스 활성화, 프로세스 모니터링 및 상태관리, 프로세스 재활용, CLR AppDomain 통합, 기본 제공 보안, 그리고 IIS 관리자와 Windows Powershell cmdlet을 통해 사용할 수 있는 몇 가지 기본적인 관리 기능을 포함하여 다양한 핵심 기능이 제공됩니다.

IIS와 WAS의 조합으로 WCF 응용 프로그램 호스팅을 위한 기반이 마련되었지만 서비스 관리 영역에서는 부족한 점이 있습니다. IIS/WAS 조합은 서비스 추적, 모니터링, 실행중인 서비스 인스턴스 진단과 같은 WCF 전용 서비스 관리 기능을 전혀 제공하지 않습니다. 호스팅되는 서비스의 상태를 쿼리할 수 없기 때문입니다. 또한, 여러 서버팜에서 장기간 실행되는 워크플로를 지원하려면 기본적으로 상태 저장 모델이 요구되기 때문에 서버환경에서 WF 응용 프로그램을 호스팅하기는 까다롭습니다. .NET Framework 3.0에서는 WF 서버 호스트를 제공하지 않았기 때문에 개발자가 직접 작성해야 했죠. 그러나 .NET Framework 3.5부터는 WorkflowServiceHost 클래스가 도입되면서 기본적으로 WF 워크플로를 WCF 서비스로 호스트할 수 있게 되었고, IIS/WAS 내에서 WF 워크플로를 호스트 하는 것 또한 가능해졌습니다.

WorkflowServiceHost가 도움은 되긴 하지만, 전체 여러 웹 서버 팜에서 상태 저장 워크플로를 관리하기 위한 도구 자원이나 런타임에 실행 중인 워크플로 인스턴스를 모니터링 및 관리하기 위한 도구가 없었습니다. 대부분의 개발자는 BizTalk Server와 서비스 및 워크플로 관리 기능 면에서 비슷하면서도 간소화 된 환경을 원합니다. 즉, WCF와 WF 응용 프로그램을 위해 특별히 디자인된 단순한 모델이 적절하고 필요한 것입니다.

마이크로소프트는 WCF 및 WF 응용 프로그램을 위한 유용한 호스팅 및 관리 기능을 제공하는 코드명 “Dublin” 이라는  Windows Server 확장 집합을 준비하고 있습니다. “Dublin”은 기본적으로 IIS/WAS에 기반을 두는 서비스 관리 확장의 집합으로 Windows Server의 일부로 제공됩니다. “Dublin” 확장을 사용하면 서비스와 워크플로는 여전히 IIS/WAS에서 호스팅 되지만 현재 IIS/WAS에 없는 추가적인 WCF와 WF 전용 관리 기능과 도구를 응용 프로그램에서 사용할 수 있습니다. 향후 버전의 Windows Server에는 다양한 “Dublin” 확장이 Windows Server 응용 프로그램 서버 역할의 일부로 제공될 계획입니다. 일부에서 Windows Application Server라고 부르는 사람들도 있습니다.

“Dublin” 확장에서는 안정적이고 견고한 서비스와 장기 실행 워크플로를 위한 관리지원이 포함되어 있습니다. “Dublin”을 사용하면 응용 프로그램을 팜의 여러 개별적인 서버에 배포할 수 있으며 세부적인 서비스 관리 작업에 필요한 도구도 제공됩니다. 그림1의 아키텍처를 살펴보도록 하겠습니다. 

그림1. “Dublin” 아키텍처

“Dublin”에서는 서비스 지속성과 모니터링을 위한 기반이 되는 몇 가지 런타임 데이터베이스를 제공합니다. .NET Framework에서 제공하는 런타임 구성 요소와 서비스 계층이 있으며 이 계층은 이러한 데이터베이스에 기반을 둡니다. “Dublin”에서는 이러한 런타임을 더욱 확장하여 통합된 호스팅, 지속성, 모니터링 및 메시징 기능을 제공합니다. 이 계층과 기본 런타임 데이터베이스를 합친 것을 “Dublin” 이라고 합니다.

아키텍처의 최상위 두 개 계층은 “Dublin”을 사용할 수 있도록 만들어 주는 것입니다. Windows Powershell cmdlet을 통해 다양한 기능을 스크립팅 할 수 있도록 해주는 관리 API 계층이 있습니다. 그 위에 IIS 관리자 환경이 있고, 실질적으로 Windows Powershell cmdlet 에 기반을 두고 있기에 대부분의 IIS 관리자가 편안하게 느낄 수 있습니다. IIS 관리자에서 할 수 있는 모든 일은 cmdlet으로도 할 수 있습니다. 앞에서 언급한 호스팅 및 관리 작업을 수행하기 위해 다양한 UI 확장을 IIS 관리자에 추가했습니다. 그 중에서도 응용 프로그램 배포 및 구성, 응용 프로그램 관리, 그리고 응용 프로그램 모니터링을 위한 확장이 있습니다. 이러한 확장은 실행, 일시 중단, 지속된 워크플로 인스턴스 등의 항목을 보여주는 시스템 런타임 대시보드도 제공합니다.

참고문헌: MSDN, .NET Framework 4.0과 "Dublin"의 WCF 및 WF 서비스

Posted by 조이트리
아키텍트2009. 12. 7. 18:48

Windows Server AppFabric은 확장성, 가용성 및 고성능 애플리케이션을 개발하는데 필요한 분산 메모리 캐싱 플랫폼을 제공합니다. 오늘은 Velocity에 대해서 정리해보려고 합니다.

캐시를 통하면 애플리케이션이 불필요하게 데이터 소스 (Database 등)에 연결하여 데이터를 가져올 필요가 없기 때문에 급격하게 성능이 향상 됩니다. 분산 캐싱은 캐시 클러스터를 통해 수요가 증가하더라도 복잡한 로브밸런싱을 구성하지 않고도 안정적인 성능을 제공 받게 됩니다. 확장성은 서버를 추가하기만 하면 얻을 수 있게 되는 간단한 개념으로 바뀝니다. 고가용성은 해당 데이터를 Velocity가 복사할 수 있도록 설정하면, 해당 클러스터로 연결된 모든 서버간에 고가용성을 얻게 되는 거죠. Velocity는 원격 네트웍에 있는 서버 간에도 설정될 수 있습니다.

이전 글에서, 현재까지 구성되는 클라우드 컴퓨팅은 인프라 클라우드, 즉 서버 운영에 대한 부분에 집중되어 있다고 말씀 드렸습니다. 하지만, 애플리케이션에 대한 확장성, 분산 캐싱, Fail-over 등이 이루어져야 진정한 의미의 클라우드 컴퓨팅 플랫폼이라고 할 수 있습니다. 인프라 Fabric, 즉 인프라 클라우드는 마이크로소프트의 Dynamic Data Center toolkit으로 구성하고, 애플리케이션 Fabric은 Windows Server AppFabric으로 구성하면 진정한 의미의 분산 클라우드 운영체제를 구성할 수 있게 될 것 같습니다. 자, 그럼 AppFabric의 Velocity에 대해 좀 더 자세히 알아보도록 하겠습니다. Velocity는 현재는 CTP(Community Technology Preview) 버전이고, CTP4가 최신 입니다.

Velocity를 어떻게 활용할 것인지에 대한 일반적인 시나리오를 몇 개 설정해봤습니다.
(Grid Dynamics가 벤치마크를 실시했습니다.)

1. 블로그 엔진 애플리케이션, 분산 캐싱
2. 전자상거래 웹사이트, 세션 상태 제공자 (Session State Provider)

Velocity 시나리오 (1)

블로그 엔진은 데이터를 많이 사용하는 웹 애플리케이션의 좋은 예제라고 할 수 있습니다. 친구 리스트 및 feeds, 게시글에 대한 아이템을 가져오기 위해 복잡한 데이터베이스 쿼리를 사용하게 됩니다. 또한, 같은 정보가 사이트 내의 여러 페이지에 보여지는 경우가 많죠. 결국 같은 정보를 여러 번 반복해서 가져오게 되는 거죠. 분산 캐싱을 이용하면 성능 향상을 볼 수 있는 이유 입니다.

 
그림1. 블로그 엔진 애플리케이션 아키텍처

두 개의 버전으로 테스트가 이루어졌습니다. 첫 번째, 데이터베이스만 사용. 두 번째, 데이터베이스에서 조회된 내용을 캐시에 저장함.

1) Throughput


그림2. Throughtput (Without Velocity, With Velocity)

그림3. Latency (Without Velocity, With Velocity)

2) 확장성

그림4. Scalability (Without Velocity, With Velocity)

작은 데이터 셋 때 이 정도의 결과값이었고, 큰 데이터 셋을 대상으로 했을 때 더 좋은 결과가 나왔습니다.

3. 고가용성

그림5. HA(High Availability)를 켰을 때와 껐을 때의 결과 값

큰 차이가 나지 않는다. 다만, HA를 켜지 않은 상황에서 2배 정도의 메모리를 더 사용하는 것으로 나타남

4) Failover


 
 그림6. 애플리케이션의 throughput - Failover 테스트                   

At 05:00에 Node1 제거
At 10:00에 Node2 제거
At 20:00에 Node1 삽입
At 30:00에 Node2 삽입

오늘은 여기까지 정리하겠습니다. 내일은 2번째, Session State Provider에 대해 적어보겠습니다.

이 글은 Grid Network의 Velocity Benchmark White Paper를 기준으로 작성했습니다.

Posted by 조이트리