배포 스탬프 패턴

배포 스탬프 패턴에는 여러 워크로드나 테넌트를 호스트하고 작동하는 다른 유형의 리소스 그룹을 프로비전, 관리 및 모니터링하는 작업이 포함됩니다. 각 개별 복사본을 스탬프라고 부르며 간혹 서비스 단위, 배율 단위 또는 셀이라고도 합니다. 다중 테넌트 환경에서 모든 스탬프 또는 배율 단위는 미리 정의된 수의 테넌트를 제공할 수 있습니다. 솔루션을 거의 선형으로 확장하고 점점 더 많은 테넌트를 제공하도록 스탬프 여러 개를 배포할 수 있습니다. 이 방법은 솔루션의 확장성을 향상시키고 여러 지역에 인스턴스를 배포하며 고객 데이터를 분리할 수 있습니다.

컨텍스트 및 문제점

클라우드에서 애플리케이션을 호스팅할 때 애플리케이션의 성능과 안정성을 고려하는 것이 중요합니다. 솔루션의 단일 인스턴스를 호스트하는 경우 다음과 같은 제한 사항이 적용될 수 있습니다.

• 규모 제한. 애플리케이션의 단일 인스턴스를 배포하면 크기 조정이 자연스럽게 제한될 수 있습니다. 예를 들어 인바운드 연결 수, 호스트 이름, TCP 소켓 또는 기타 리소스 수에 제한이 있는 서비스를 사용할 수 있습니다.
• 비선형 크기 조정 또는 비용. 솔루션 구성 요소 중 일부는 요청 수나 데이터 양에 따라 선형으로 확장되지 않을 수 있습니다. 대신 임계값이 충족되면 갑작스럽게 성능이 저하되거나 비용이 증가할 수 있습니다. 예를 들어 데이터베이스를 사용하여 용량을 더 추가하는 데 드는 한계 비용(스케일 업)이 크게 증가하고 스케일 아웃이 더욱 경제적인 전략임을 발견할 수 있습니다.
• 고객 분리. 특정 고객의 데이터를 다른 고객의 데이터와 격리해야 할 수 있습니다. 마찬가지로, 다른 고객보다 서비스에 더 많은 시스템 리소스가 필요한 고객이 있을 수 있으며 다른 인프라 세트에 그룹화하는 것이 좋습니다.
• 단일 및 다중 테넌트 인스턴스 처리 솔루션의 고유한 독립 인스턴스가 필요한 대규모 고객이 있을 수 있습니다. 다중 테넌트 배포를 공유할 수 있는 소규모 고객 풀이 있을 수도 있습니다.
• 복잡한 배포 요구 사항. 제어된 방식으로 서비스에 업데이트를 배포하고 다른 시간에 다른 일부 고객 기반에 배포해야 할 수 있습니다.
• 업데이트 빈도. 시스템을 자주 업데이트하는 것을 용인하는 고객이 있을 수 있지만, 다른 고객은 위험을 싫어하고 요청을 제공하는 시스템을 드물게 업데이트하기를 원할 수 있습니다. 이러한 고객을 격리된 환경에 배포하는 것이 합리적일 수 있습니다.
• 지리적 또는 지정학적 제한. 대기 시간을 줄이거나 데이터 주권 요구 사항을 준수하려면 일부 고객을 특정 지역에 배포할 수 있습니다.

이러한 제한 사항은 종종 다중 테넌트로 설계된 SaaS(Software as a Service)를 빌드하는 ISV(독립 소프트웨어 공급업체)에 적용됩니다. 그러나 다른 시나리오에도 동일한 제한 사항이 적용될 수 있습니다.

솔루션

이러한 문제를 방지하려면 리소스를 배율 단위로 그룹화하고 스탬프 복사본 여러 개를 프로비전하는 것이 좋습니다. 각 배율 단위에서 테넌트 하위 집합을 호스트하고 제공합니다. 스탬프는 서로 독립적으로 작동하며 독립적으로 배포 및 업데이트할 수 있습니다. 단일 지리적 지역에는 단일 스탬프가 포함되거나 지역 내에서 수평 스케일 아웃을 허용하는 스탬프가 여러 개 포함될 수 있습니다. 스탬프에는 고객 하위 집합이 포함되어 있습니다.

배포 스탬프는 솔루션에서 IaaS(Infrastructure as a Service)나 PaaS(Platform as a Service) 구성 요소를 사용하는지 또는 둘을 혼합하여 사용하는지 여부를 적용할 수 있습니다. 일반적으로 IaaS 워크로드에서는 확장하는 데 더 많은 개입이 필요하므로 이 패턴은 IaaS가 많은 워크로드에서 스케일 아웃을 허용하는 데 유용할 수 있습니다.

스탬프를 사용하여 배포 링을 구현할 수 있습니다. 다른 고객이 다른 빈도로 서비스 업데이트를 받으려는 경우 서로 다른 스탬프로 그룹화할 수 있으며 각 스탬프에는 서로 다른 케이던스에 업데이트가 배포될 수 있습니다.

스탬프는 서로 독립적으로 실행되므로 데이터는 암시적으로 분할됩니다. 또한 단일 스탬프는 스탬프 내에서 확장성과 탄력성을 내부적으로 허용하도록 추가 분할을 사용할 수 있습니다.

App Service, Azure Stack 및 Azure Storage를 포함하여 많은 Azure 서비스에서 배포 스탬프 패턴을 내부적으로 사용합니다.

배포 스탬프는 지오드와 관련이 있지만 완전히 다릅니다. 배포 스탬프 아키텍처에서 시스템의 여러 독립 인스턴스가 배포되고 일부 고객 및 사용자가 포함됩니다. 지오드의 모든 인스턴스에서 모든 사용자의 요청을 처리할 수 있지만 이 아키텍처의 디자인 및 빌드가 더욱 복잡한 경우가 많습니다. 하나의 솔루션 내에서 두 패턴을 혼합하는 것도 고려할 수 있습니다. 이 문서의 뒷부분에서 설명하는 트래픽 라우팅 접근 방식은 이러한 하이브리드 시나리오의 예입니다.

배포

동일한 구성 요소의 동일한 복사본을 배포하는 데 관련된 복잡성으로 인해 이 패턴을 구현할 때 성공하려면 좋은 DevOps 사례가 중요합니다. Bicep, JSON ARM 템플릿(Azure Resource Manager 템플릿), Terraform 및 스크립트를 사용하는 등 인프라를 코드로 설명하는 것이 좋습니다. 이 방식을 사용하면 각 스탬프의 배포가 예측 가능하고 반복 가능하게 할 수 있습니다. 또한 스탬프 간의 구성에서 우발적인 불일치와 같은 인간 오류 가능성을 줄입니다.

업데이트를 모든 스탬프에 병렬로 자동 배포할 수 있습니다. 이 경우 Bicep 또는 Resource Manager 템플릿과 같은 기술을 고려하여 인프라와 애플리케이션의 배포를 조정할 수 있습니다. 또는 먼저 일부 스탬프에 업데이트를 점진적으로 배포한 다음, 다른 스탬프에 점진적으로 배포하도록 결정할 수 있습니다. Azure Pipelines 또는 GitHub Actions와 같은 릴리스 관리 도구를 사용하여 각 스탬프에 대한 배포를 오케스트레이션하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.

• Azure Pipelines와 Bicep 통합
• JSON ARM 템플릿을 Azure Pipelines와 통합

배포에 대한 Azure 구독과 리소스 그룹의 토폴로지를 신중하게 고려합니다.

• 일반적으로 구독에는 단일 솔루션에 대한 모든 리소스가 포함되므로 일반적으로 모든 스탬프에 단일 구독을 사용하는 것이 좋습니다. 그러나 일부 Azure 서비스는 구독 전체 할당량을 부과하므로 이 패턴을 사용하여 높은 수준의 스케일 아웃을 허용하는 경우 여러 구독에 스탬프를 배포하는 것을 고려해야 할 수도 있습니다.
• 리소스 그룹은 일반적으로 동일한 수명 주기로 구성 요소를 배포하는 데 사용됩니다. 모든 스탬프에 업데이트를 한 번에 배포하려는 경우 단일 리소스 그룹을 사용하여 모든 스탬프의 모든 구성 요소를 포함하고 리소스 명명 규칙과 태그를 사용하여 각 스탬프에 속하는 구성 요소를 식별하는 것이 좋습니다. 또는 각 스탬프에 독립적으로 업데이트를 배포하려는 경우 각 스탬프를 자체 리소스 그룹에 배포하는 것이 좋습니다.

용량 계획

부하 및 성능 테스트를 사용하여 지정된 스탬프가 수용할 수 있는 대략적인 부하를 결정합니다. 부하 메트릭은 단일 스탬프가 수용할 수 있는 고객/테넌트 수 또는 스탬프 내의 구성 요소가 내보내는 서비스의 메트릭을 기반으로 할 수 있습니다. 지정된 스탬프가 용량에 근접하는 시기를 측정할 수 있는 충분한 계측이 있고 수요에 대응하기 위해 새 스탬프를 신속하게 배포할 수 있는지 확인합니다.

트래픽 라우팅

각 스탬프가 독립적으로 처리되는 경우 배포 스탬프 패턴이 우수하게 작동합니다. 예를 들어 Contoso에서 여러 스탬프에 동일한 API 애플리케이션을 배포하는 경우 DNS를 사용하여 트래픽을 관련 스탬프로 라우팅하는 것이 좋을 수 있습니다.

• unit1.aus.myapi.contoso.com은 트래픽을 호주 지역 내 스탬프 unit1로 라우팅합니다.
• unit2.aus.myapi.contoso.com은 트래픽을 호주 지역 내 스탬프 unit2로 라우팅합니다.
• unit1.eu.myapi.contoso.com은 트래픽을 유럽 지역 내 스탬프 unit1로 라우팅합니다.

그런 다음, 클라이언트가 올바른 스탬프에 연결되어야 합니다.

모든 트래픽의 단일 수신 지점이 필요한 경우 트래픽 라우팅 서비스를 사용하여 지정된 요청, 고객 또는 테넌트의 스탬프를 확인할 수 있습니다. 트래픽 라우팅 서비스는 클라이언트를 스탬프 관련 URL로 보내거나(예: HTTP 302 응답 상태 코드 사용) 클라이언트를 인식하지 않고 역방향 프록시 역할을 하고 트래픽을 관련 스탬프로 전달합니다.

중앙 집중식 트래픽 라우팅 서비스는 특히 솔루션이 여러 지역에서 실행되는 경우 디자인하는 데 복잡한 구성 요소일 수 있습니다. 트래픽 라우팅 서비스를 여러 지역(스탬프가 배포되는 모든 지역 포함)에 배포한 다음, 데이터 저장소(테넌트를 스탬프에 매핑)가 동기화되도록 하는 것이 좋습니다. 트래픽 라우팅 구성 요소 자체는 지오데 패턴의 인스턴스일 수 있습니다.

예를 들어 Azure API Management가 트래픽 라우팅 서비스 역할에서 작동하도록 배포될 수 있습니다. 테넌트와 스탬프 간의 매핑을 저장하는 Azure Cosmos DB 컬렉션에서 데이터를 조회하여 요청에 적합한 스탬프를 확인할 수 있습니다. 그런 다음, API Management는 백 엔드 URL을 동적으로 관련 스탬프의 API 서비스로 설정할 수 있습니다.

요청의 지리적 배포와 트래픽 라우팅 서비스의 지역 중복성을 사용하려면 API Management를 여러 지역에 배포하거나 Azure Front Door를 사용하여 트래픽을 가장 가까운 인스턴스로 보낼 수 있습니다. Front Door는 백 엔드 풀로 구성될 수 있으므로 요청을 사용 가능한 가장 가까운 API Management 인스턴스로 보낼 수 있습니다. 애플리케이션이 HTTP/S를 통해 노출되지 않는 경우 지역 간 Azure Load Balancer를 사용하여 지역별 Azure Load Balancer 에 들어오는 호출을 배포할 수 있습니다. Azure Cosmos DB의 전역 배포 기능을 사용하여 각 지역에서 매핑 정보를 업데이트된 상태로 유지할 수 있습니다.

트래픽 라우팅 서비스가 솔루션에 포함된 경우 게이트웨이 역할을 하므로 토큰 유효성 검사, 제한 및 권한 부여와 같은 다른 서비스에 게이트웨이 오프로드를 수행할 수 있는지 여부를 고려합니다.

트래픽 라우팅 아키텍처 예제

전역 트래픽 라우팅에 Azure Front Door, Azure API Management 및 Azure Cosmos DB를 사용하는 다음 예제 트래픽 라우팅 아키텍처와 일련의 지역별 스탬프를 고려합니다.

사용자가 일반적으로 뉴욕에 상주한다고 가정해 보겠습니다. 해당 데이터는 미국 동부 지역의 스탬프 3에 저장됩니다.

사용자가 캘리포니아로 이동한 다음, 시스템에 액세스하는 경우 미국 서부 2 지역을 통해 연결이 라우팅될 수 있습니다. 요청할 때 지리적으로 가장 가까운 위치이기 때문입니다. 그러나 요청은 궁극적으로 스탬프 3에서 처리되어야 합니다. 데이터가 저장되는 위치이기 때문입니다. 트래픽 라우팅 시스템은 요청이 올바른 스탬프로 라우팅되게 합니다.

문제 및 고려 사항

이 패턴을 구현할 방법을 결정할 때 다음 사항을 고려해야 합니다.

• 배포 프로세스. 여러 스탬프를 배포할 때는 자동화되고 완전히 반복 가능한 배포 프로세스를 사용하는 것이 좋습니다. Bicep, JSON ARM 템플릿 또는 Terraform 모듈을 사용하여 스탬프를 선언적으로 정의하고 정의를 일관성 있게 유지하는 것이 좋습니다.
• 교차 스탬프 작업. 솔루션이 여러 스탬프에 독립적으로 배포되면 "모든 스탬프에 얼마나 많은 고객이 있습니까?"와 같은 질문에 대한 대답이 더욱 복잡해질 수 있습니다. 각 스탬프와 집계된 결과에 대해 쿼리를 실행해야 할 수 있습니다. 또는 모든 스탬프가 통합 보고에 사용되는 중앙 집중식 데이터 웨어하우스에 데이터를 게시하는 것이 좋습니다.
• 스케일 아웃 정책 결정. 스탬프에는 한정된 용량이 있으며 스탬프에 배포할 수 있는 테넌트 수와 같은 프록시 메트릭을 사용하여 스탬프를 정의할 수 있습니다. 각 스탬프에 대해 사용 가능한 용량과 사용된 용량을 모니터링하고 새 테넌트가 해당 테넌트에 전달될 수 있도록 추가 스탬프를 사전에 배포하는 것이 중요합니다.
• 최소 스탬프 수. 배포 스탬프 패턴을 사용하는 경우 솔루션의 스탬프를 두 개 이상 배포하는 것이 좋습니다. 스탬프를 하나만 배포하는 경우 스케일 아웃할 때 적용되지 않는 코드 또는 구성에 실수로 가정을 하드 코딩하기 쉽습니다.
• 비용 배포 스탬프 패턴에는 인프라 구성 요소 복사본 여러 개를 배포하는 작업이 포함되며 이로 인해 솔루션 운영 비용이 크게 증가할 수 있습니다.
• 스탬프 간 이동. 각 스탬프는 독립적으로 배포되고 작동하므로 스탬프 간에 테넌트 이동이 어려울 수 있습니다. 애플리케이션에는 지정된 고객에 대한 정보를 다른 스탬프로 전송한 다음, 원래 스탬프에서 테넌트 정보를 제거하는 사용자 지정 논리가 필요합니다. 이 프로세스에는 스탬프 간 통신을 위한 백플레인이 필요할 수 있으므로 전체 솔루션의 복잡성이 더욱 증가합니다.
• 트래픽 라우팅. 이 문서의 앞부분에서 설명한 대로 지정된 요청에 대한 올바른 스탬프로 트래픽을 라우팅하려면 테넌트를 스탬프로 확인하는 추가 구성 요소가 필요할 수 있습니다. 이 구성 요소를 고가용성으로 설정해야 할 수 있습니다.
• 공유 구성 요소. 스탬프 간에 공유할 수 있는 일부 구성 요소가 있을 수 있습니다. 예를 들어 모든 테넌트에 대한 공유 단일 페이지 앱이 있는 경우 해당 앱을 한 지역에 배포하고 Azure CDN을 사용하여 전역적으로 복제하는 것이 좋습니다.

이 패턴을 사용해야 하는 경우

다음과 같은 경우에 이 패턴이 유용합니다.

• 확장성에 대한 자연스러운 제한. 예를 들어 일부 구성 요소가 고객이나 요청을 특정 수 이상으로 확장할 수 없거나 확장해서는 안 되는 경우 스탬프를 사용하여 스케일 아웃하는 것이 좋습니다.
• 특정 테넌트를 다른 테넌트에서 분리해야 하는 요구 사항. 보안 문제로 인해 다른 고객과 함께 다중 테넌트 스탬프에 배포할 수 없는 고객이 있는 경우 자체 격리된 스탬프에 배포할 수 있습니다.
• 동시에 솔루션의 다른 버전에 일부 테넌트가 있어야 함
• 각 테넌트의 데이터와 트래픽을 특정 지역으로 보내야 하는 다중 지역 애플리케이션
• 가동 중단 시 복원력을 달성하려는 희망. 스탬프는 서로 독립적이므로 중단이 단일 스탬프에 영향을 주는 경우 다른 스탬프에 배포된 테넌트는 영향을 받지 않아야 합니다. 이러한 격리는 인시던트나 중단의 '영향력'을 포함하는 데 도움이 됩니다.

다음과 같은 경우에는 이 패턴이 적합하지 않습니다.

• 높은 수준까지 확장할 필요가 없는 간단한 솔루션
• 애플리케이션 레이어 크기를 늘리거나 데이터베이스와 스토리지 계층에 대한 예약된 용량을 늘리는 등 단일 인스턴스 내에서 간편하게 스케일 아웃하거나 스케일 업할 수 있는 시스템
• 배포된 모든 인스턴스에서 데이터를 복제해야 하는 솔루션. 이 시나리오의 지오드 패턴을 고려합니다.
• 일부 구성 요소만 확장해야 하지만 다른 구성 요소를 확장할 필요가 없는 솔루션. 예를 들어 모든 솔루션 구성 요소의 새 복사본을 배포하는 대신 데이터 저장소를 분할하여 솔루션을 확장할 수 있는지 여부를 고려합니다.
• 프런트 엔드 JavaScript 애플리케이션과 같은 정적 콘텐츠로만 구성된 솔루션. 스토리지 계정에 이러한 콘텐츠를 저장하고 Azure CDN을 사용하는 것이 좋습니다.

워크로드 디자인

설계자는 워크로드 디자인에서 배포 스탬프 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:

디자인 결정과 마찬가지로 이 패턴을 통해 도입 가능한 다른 핵심 요소의 목표에 관한 절충을 고려합니다.

지원 기술

• 코드 제공 인프라. 예를 들면 Bicep, Resource Manager 템플릿, Azure CLI, Terraform, PowerShell, Bash입니다.
• 트래픽을 특정 스탬프나 트래픽 라우팅 서비스로 라우팅할 수 있는 Azure Front Door

예제

다음 예제에서는 앱 서비스와 각 스탬프의 SQL Database를 사용하여 간단한 PaaS 솔루션의 스탬프 여러 개를 배포합니다. 예를 들어 스탬프를 템플릿에 배포된 서비스를 지원하는 모든 지역에서 구성할 수 있지만 이 템플릿은 미국 서부 2 지역 내 스탬프 두 개와 서유럽 지역의 추가 스탬프를 배포합니다. 스탬프 내에서 앱 서비스는 자체 공용 DNS 호스트 이름을 수신하며 다른 모든 스탬프와 독립적으로 연결을 받을 수 있습니다.

아래 링크를 클릭하여 솔루션을 배포합니다.

트래픽 라우팅 방식 예제

다음 예제에서는 가상 API 애플리케이션의 배포 스탬프 세트와 함께 사용할 수 있는 트래픽 라우팅 솔루션 구현을 배포합니다. 들어오는 요청의 지리적 배포를 허용하도록 Front Door는 소비 계층의 API Management 인스턴스 여러 개와 함께 배포됩니다. 각 API Management 인스턴스는 요청 URL에서 테넌트 ID를 읽은 다음, 지역 분산된 Azure Cosmos DB 데이터 저장소에서 관련 요청 스탬프를 조회합니다. 그런 다음, 요청이 관련 백 엔드 스탬프로 전달됩니다.

아래 링크를 클릭하여 솔루션을 배포합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• John Downs | 주 프로그램 관리자

기타 기여자:

• Daniel Larsen | 수석 고객 엔지니어, FastTrack for Azure
• Angel Lopez | 선임 소프트웨어 엔지니어, Azure 패턴 및 사례
• Paolo Salvatori | 수석 고객 엔지니어, FastTrack for Azure
• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

관련 참고 자료

• 분할을 간단한 또 다른 방법으로 사용하여 데이터 계층을 스케일 아웃할 수 있습니다. 스탬프는 암시적으로 데이터를 분할하지만 분할에는 배포 스탬프가 필요하지 않습니다. 자세한 내용은 분할 패턴을 참조하세요.
• 트래픽 라우팅 서비스를 배포하는 경우 이 구성 요소를 최대한 사용할 수 있도록 게이트웨이 라우팅과 게이트웨이 오프로드 패턴을 함께 사용할 수 있습니다.