우리는 Azure에서 몇 가지 역할을 수행합니다. 현재 이들 각각은 별도의 인스턴스에 배포되므로 개별적으로 확장 할 수 있습니다. (프로덕션에서는 이것이 우리가 원하는 것입니다.) 테스트는 낭비적인 것처럼 보이고 비용을 최소화하기 위해 모든 역할을 단일 인스턴스에 배포 할 수 있기를 원합니다.다른 구성으로 다른 인스턴스로 분할 된 역할을 사용하여 azure에 배포 하시겠습니까?
우리가 할 수 있을까요?
우리는 Azure에서 몇 가지 역할을 수행합니다. 현재 이들 각각은 별도의 인스턴스에 배포되므로 개별적으로 확장 할 수 있습니다. (프로덕션에서는 이것이 우리가 원하는 것입니다.) 테스트는 낭비적인 것처럼 보이고 비용을 최소화하기 위해 모든 역할을 단일 인스턴스에 배포 할 수 있기를 원합니다.다른 구성으로 다른 인스턴스로 분할 된 역할을 사용하여 azure에 배포 하시겠습니까?
우리가 할 수 있을까요?
역할은 본질적으로 일련의 Windows Azure VM 인스턴스에서 실행될 내용을 정의한 것입니다. 정의에 따라 자체 인스턴스가 있으므로 단일 인스턴스 집합을 대상으로 할 수 없습니다.
그렇다고해서 다른 역할의 코드를 하나의 단일 역할로 결합하는 데 방해가되는 것은 없습니다. OnStart()
및 Run()
이 필요한 모든 작업을 처리하고 시작 스크립트 항목을 결합해야합니다.
(당신이 이미 추측했다) : 비용 절감, 특히 낮은 볼륨에서 실행하는 경우 (전체 앱이 두 개의 인스턴스에서 실행될 수있는 반면, 역할별로 분할 된 더 많은 유휴 인스턴스보다).
잠재적 인 단점 : 단일 역할로 결합 된 모든 것이 이제 함께 확장됩니다. 이것은 당신에게 문제 일 수도 있고 아닐 수도 있습니다.
또한 크기 조정에 대해 생각해보십시오. Small에서 웹 사이트가 완벽하게 만족 스럽다고 가정 해 보겠습니다. 아직 XL (10GB RAM이 필요한 렌더러 일 수도 있습니다)이 필요한 백그라운드 작업이 있다고 가정 해 보겠습니다. SLA를 위해 항상 웹 사이트 인스턴스를 2 개 운영한다고 가정 해 보겠습니다. 이제 매우 낮은 볼륨에서도 앱은 2 개의 Small (웹) 및 1 개의 XL (백그라운드) 대신 2 개의 XL 인스턴스로 구성됩니다. 이제 유휴에 가까운 시스템은 별도의 역할보다 하나의 결합 된 역할만큼 비용이 많이들 수 있습니다. 이 내용은 사용자에게 적용되지 않을 수도 있습니다. 예를 들어 결합하는 것이 의미가 없을 수도 있습니다.
David의 멋진 설명에 덧붙여서 함께 추가하고 OnStart 또는 Run 무시를 통해 연결하는 방법은 다음과 같습니다. 하지만 정말로 제대로 테스트하고 있습니까? 구성 값 병합, 메모리 사용 관련 잠재적 문제, 동시성 등 프로덕션 환경에 배포 할 때 동일한 제품을 테스트하지 않을 것입니다.
더 나은 방법은 QA 환경에 매우 작은 인스턴스를 배포하는 것입니다. 중형 또는 대형 서버의 가격에 비해 약간의 비용이 들며 의미있는 테스트 플랫폼을 제공합니다.