배포 스탬프 패턴은 여러 워크로드 또는 테넌트를 호스트하고 작동하기 위해 리소스 그룹을 프로비전, 관리 및 모니터링합니다. 각 개별 복사본을 스탬프 또는 서비스 단위, 배율 단위 또는 셀이라고도 합니다. 다중 테넌트 환경에서 각 스탬프는 미리 정의된 수의 테넌트를 제공합니다. 여러 스탬프를 배포하여 솔루션을 거의 선형적으로 확장하고 점점 더 많은 테넌트를 제공합니다. 이 방법을 사용하면 솔루션의 확장성을 향상시키고, 여러 지역에 인스턴스를 배포하고, 고객 데이터를 구분할 수 있습니다.
Note
자세한 내용은 Azure의 다중 테넌트 솔루션 설계를 참조하세요.
컨텍스트 및 문제점
클라우드에서 애플리케이션을 호스트할 때 애플리케이션의 성능과 안정성을 고려합니다. 솔루션의 단일 인스턴스를 호스트하는 경우 다음 제한 사항이 적용될 수 있습니다.
크기 조정 제한: 애플리케이션의 단일 인스턴스가 자연 크기 조정 제한에 도달할 수 있습니다. 예를 들어 사용하는 서비스는 인바운드 연결, 호스트 이름, TCP(Transmission Control Protocol) 소켓 또는 기타 리소스의 수를 제한할 수 있습니다.
비선형 크기 조정 또는 비용: 솔루션의 구성 요소 중 일부는 요청 수 또는 데이터 양으로 선형적으로 확장되지 않을 수 있습니다. 대신 임계값을 충족하면 성능이 저하되거나 비용이 급증할 수 있습니다. 예를 들어 데이터베이스에 더 많은 용량을 추가하거나 확장하면 비용이 엄청나게 비싸지고 규모 확장이 비용 효율적이라는 것을 알 수 있습니다.
고객 분리: 한 고객의 데이터를 다른 고객의 데이터에서 격리해야 할 수 있습니다. 다른 사용자보다 더 많은 시스템 리소스를 사용하는 고객이 있을 수도 있습니다. 다양한 인프라 집합에서 그룹화할 수 있습니다.
단일 테넌트 및 다중 테넌트 인스턴스: 일부 대규모 고객은 솔루션의 자체 독립 인스턴스가 필요할 수 있습니다. 소규모 고객은 다중 테넌트 배포를 공유할 수 있습니다.
복잡한 배포 요구 사항: 제어된 방식으로 서비스에 업데이트를 배포하고 다른 시간에 고객 기반의 여러 하위 집합에 배포해야 할 수 있습니다.
업데이트 빈도: 일부 고객은 빈번한 업데이트를 용인하는 반면 위험 회피 고객은 요청을 제공하는 시스템에 대한 드문 업데이트를 원합니다. 이러한 고객을 격리된 환경에 배포할 수 있습니다.
지리적 또는 지정학적 제한 사항: 짧은 대기 시간을 달성하거나 데이터 주권 요구 사항을 준수하기 위해 일부 고객을 특정 지역에 배포할 수 있습니다.
이러한 제한 사항은 일반적으로 다중 테넌트로 디자인되는 SaaS(Software as a Service)를 빌드하는 소프트웨어 개발 회사에 적용되는 경우가 많습니다. 다른 시나리오에도 동일한 제한 사항이 적용될 수 있습니다.
솔루션
이러한 문제를 방지하려면 리소스를 배율 단위 로 그룹화하고 스탬프의 여러 복사본을 프로비전하는 것이 좋습니다. 각 스케일 유닛은 테넌트의 하위 집합을 호스트하고 제공합니다. 스탬프는 서로 독립적으로 실행되며 독립적으로 배포하고 업데이트할 수 있습니다. 단일 지리적 지역에는 지역 내에서 수평으로 확장되는 하나의 스탬프 또는 여러 스탬프가 포함될 수 있습니다. 각 스탬프는 고객의 하위 집합을 제공합니다.
배포 스탬프는 솔루션이 IaaS(Infrastructure as a Service) 또는 PaaS(Platform as a Service) 구성 요소를 사용하는지 또는 둘 다의 조합으로 사용하는지 여부를 적용할 수 있습니다. IaaS 워크로드는 일반적으로 크기를 조정하기 위해 더 많은 개입이 필요하므로 이 패턴은 IaaS가 많은 워크로드를 스케일 아웃하는 데 도움이 될 수 있습니다.
스탬프를 사용하여 배포 링을 구현할 수 있습니다. 다른 고객이 다른 빈도로 서비스 업데이트를 원하는 경우 다른 스탬프에 그룹화하고 각 스탬프에 업데이트를 다른 주기로 배포합니다.
스탬프는 독립적으로 실행되므로 데이터를 암시적으로 분할 합니다. 또한 단일 스탬프는 내부적으로 더 많은 분할을 사용하여 크기를 조정하고 탄력적으로 유지할 수 있습니다.
동일한 구성 요소의 동일한 복사본을 배포하는 것은 복잡하므로 좋은 DevOps 사례가 중요합니다. 각 스탬프의 배포를 예측 가능하고 반복할 수 있도록 인프라를 코드로 설명합니다.
배포 스탬프는 지리적 위치와 관련이 있지만 서로 다릅니다. 배포 스탬프 아키텍처에서 시스템의 각 독립 인스턴스는 고객 및 사용자의 하위 집합을 제공합니다. 지오데 아키텍처에서 모든 인스턴스는 모든 사용자의 요청을 처리할 수 있지만 이 방법은 일반적으로 디자인 및 빌드에 더 복잡합니다. 하나의 솔루션 내에서 두 패턴을 결합할 수도 있습니다. 이 문서의 뒷부분에서 설명하는 트래픽 라우팅 접근 방식은 이러한 하이브리드 시나리오의 예입니다.
문제 및 고려 사항
이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.
배포 프로세스: 여러 스탬프를 배포하는 경우 배포 프로세스를 자동화하고 완전히 반복합니다. Bicep 또는 Terraform 모듈을 사용하여 스탬프를 선언적으로 정의하고 정의를 일관되게 유지합니다.
크로스 스탬프 작업: 여러 스탬프에 솔루션을 독립적으로 배포할 때, 모든 스탬프에서 고객 수를 파악하기가 어려울 수 있습니다. 각 스탬프를 쿼리하고 결과를 집계해야 할 수 있습니다. 또는 모든 스탬프가 통합 보고를 위해 중앙 집중식 데이터 웨어하우스에 데이터를 게시하게 할 수 있습니다.
스케일 아웃 정책: 스탬프에는 스탬프에 배포할 수 있는 테넌트 수와 같은 프록시 메트릭을 사용하여 정의할 수 있는 한정된 용량이 있습니다. 각 스탬프에 대해 사용 가능하고 사용된 용량을 모니터링하고, 더 많은 스탬프를 사전에 배포하여 새 테넌트에 전달합니다.
최소 스탬프 수: 배포 스탬프 패턴을 사용하는 경우 솔루션의 스탬프를 두 개 이상 배포합니다. 단일 스탬프만 배포하는 경우 스케일 아웃할 때 적용되지 않는 코드 또는 구성에 쉽게 하드 코드 가정을 적용할 수 있습니다.
비용: 배포 스탬프 패턴은 인프라 구성 요소의 여러 복사본을 배포하므로 솔루션 운영 비용이 크게 증가합니다.
스탬프 간 이동: 각 스탬프는 독립적으로 실행되므로 스탬프 간에 테넌트 이동이 어려울 수 있습니다. 애플리케이션에는 고객의 정보를 다른 스탬프로 전송한 다음 원래 스탬프에서 테넌트의 정보를 제거하는 사용자 지정 논리가 필요합니다. 이 프로세스를 수행하려면 백플레인에서 스탬프 간에 통신해야 하므로 솔루션의 복잡성이 더욱 높아질 수 있습니다.
트래픽 라우팅: 이 문서의 앞에서 설명한 대로, 특정 요청을 적절한 스탬프로 라우팅하기 위해서는 테넌트를 스탬프로 매핑하는 추가 구성 요소가 필요할 수 있습니다. 이 구성 요소는 고가용성이어야 할 수도 있습니다.
스탬프 간 관찰 가능성: 스탬프 수가 증가함에 따라 전반적인 상태를 파악하고 인시던트 수를 신속하게 감지하기가 더 어려워집니다. Azure Monitor 사용하여 모든 스탬프에서 메트릭, 로그, 추적 및 경고를 수집하고 상호 연결합니다. 이 데이터를 사용하여 비정상 스탬프를 식별하고 문제를 진단합니다.
지역별 오류 영향: 스탬프는 독립적으로 실행되지만 지역 간에 본질적으로 중복되지는 않습니다. 하나 이상의 스탬프를 호스트하는 지역을 사용할 수 없게 되면 해당 지역이 복구되거나 테넌트를 다른 지역의 스탬프로 마이그레이션할 때까지 해당 스탬프의 테넌트에 대한 액세스 권한이 손실됩니다. 이 시나리오를 계획하려면 복구 절차를 문서화하고, 테넌트 기대치를 설정하고, 중요한 테넌트에 지역 중복 스탬프 배치가 필요한지 여부를 고려합니다.
공유 구성 요소: 스탬프 간에 공유할 수 있는 구성 요소가 있을 수 있습니다. 예를 들어 모든 테넌트에 대한 공유 단일 페이지 앱이 있는 경우 한 지역에 배포하고 Azure Front Door 에지 캐싱을 사용하여 전역적으로 복제합니다.
거버넌스 및 구성 드리프트: 스탬프 수가 증가함에 따라 보안 정책, RBAC(역할 기반 액세스 제어) 할당, 네트워크 제어, 관찰 가능성 설정 및 서비스 구성을 일관성 있게 유지하기가 더 어려워집니다. Azure Policy 사용하여 거버넌스를 코드 처리하고 일관성 없는 동작 및 규정 준수 격차를 방지하기 위해 드리프트에 대한 각 스탬프의 유효성을 지속적으로 검사합니다.
이 패턴을 사용하는 경우
다음 경우에 이 패턴을 사용합니다.
솔루션에는 확장성에 대한 자연스러운 제한이 있습니다. 예를 들어 일부 구성 요소가 특정 수의 고객 또는 요청을 초과하여 확장할 수 없거나 확장되지 않아야 하는 경우 스탬프를 사용하여 규모를 확장합니다.
특정 테넌트는 다른 테넌트에서 분리해야 합니다. 보안 문제로 인해 일부 고객을 다중 테넌트 스탬프에 배포할 수 없는 경우 자체 격리된 스탬프에 배포합니다.
솔루션의 여러 버전에서 일부 테넌트도 동시에 호스트해야 합니다.
각 테넌트의 데이터 및 트래픽을 특정 지역으로 전송해야 하는 다중 리전 애플리케이션을 빌드합니다.
가동 중단 시 복원력을 달성하려고 합니다. 스탬프는 독립적으로 실행되므로 중단이 단일 스탬프에 영향을 주는 경우 다른 스탬프의 테넌트는 영향을 받지 않습니다. 이 격리는 인시던트 또는 중단의 폭발 반경을 제한합니다.
이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.
솔루션은 간단하며 높은 수준까지 확장할 필요가 없습니다.
애플리케이션 계층의 크기를 늘리거나 데이터베이스 및 스토리지 계층에 대한 예약된 용량을 늘리는 등 단일 인스턴스 내에서 시스템을 확장하거나 확장할 수 있습니다.
배포된 모든 인스턴스에서 데이터를 복제해야 합니다. 이 시나리오의 지오데 패턴을 고려합니다.
일부 구성 요소의 크기만 조정하면 되며 다른 구성 요소의 크기는 조정하지 않아도 됩니다. 예를 들어 모든 솔루션 구성 요소의 새 복사본 을 배포하는 대신 데이터 저장소를 분할 하여 솔루션 크기를 조정할 수 있는지 여부를 고려합니다.
솔루션은 프런트 엔드 JavaScript 애플리케이션과 같은 정적 콘텐츠로만 구성됩니다. 콘텐츠 배달 네트워크에서 이 콘텐츠를 배달합니다.
워크로드 디자인
워크로드 디자인에서 배포 스탬프 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소 다루는 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.
| 핵심 요소 | 이 패턴으로 핵심 목표를 지원하는 방법 |
|---|---|
| 안정성 설계 결정을 통해 워크로드가 오작동에 대한 복원력을 높일 수 있으며 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 할 수 있습니다. | 스탬프는 독립적으로 작동하므로 한 스탬프의 오류는 격리되고 다른 스탬프의 테넌트에 영향을 주지 않습니다. 지역에 여러 스탬프를 배포하면 중복성 및 복구 계획의 기반이 되며, 이로 인해 지역 가동 중단의 반경이 줄어듭니다. - RE:05 중복성 - RE:07 자기 보존 |
| 운영 우수성은 표준화된 프로세스와 팀 응집력을 통해 워크로드 품질을 제공하는 데 도움이 됩니다. | 이 패턴은 변경할 수 없는 인프라 목표, 고급 배포 모델을 지원하며 안전한 배포 사례를 용이하게 할 수 있습니다. - OE:05 코드로서의 인프라 - OE:11 안전한 배포 사례 |
| 성능 효율성은 크기 조정, 데이터 및 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족 하는 데 도움이 됩니다. | 이 패턴은 워크로드에서 정의된 배율 단위에 맞춰지는 경우가 많습니다. 단일 배율 단위가 제공하는 것보다 용량이 더 필요한 경우 스케일 아웃하기 위해 다른 스탬프를 배포합니다. - PE:05 크기 조정 및 분할 |
이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.
Example
다음 예제 아키텍처는 Azure Front Door, Azure API Management 및 Azure Cosmos DB 사용하여 트래픽을 전역적으로 일련의 지역별 스탬프로 라우팅합니다.
사용자가 뉴욕에 있다고 가정해 보겠습니다. 스탬프 3은 미국 동부 지역에 데이터를 저장합니다.
사용자가 캘리포니아로 이동하여 시스템에 액세스하는 경우 요청 시 해당 지역이 가장 가깝기 때문에 시스템은 미국 서부 2 지역을 통해 연결을 라우팅합니다. 그러나 스탬프 3은 데이터를 저장하기 때문에 궁극적으로 요청을 처리해야 합니다. 트래픽 라우팅 시스템은 요청을 올바른 스탬프로 라우팅합니다.
Deployment
Bicep 또는 Terraform 사용하여 인프라를 코드로 설명합니다. 이 방법을 사용하면 각 스탬프의 배포를 예측 가능하고 반복할 수 있습니다. 또한 스탬프 간의 구성에서 우발적인 불일치와 같은 인간 오류 가능성을 줄입니다.
업데이트를 모든 스탬프에 자동으로 병렬로 배포할 수 있습니다. Bicep 같은 기술은 인프라 및 애플리케이션의 배포를 조정할 수 있습니다. 또는 먼저 일부 스탬프에 대한 업데이트를 점진적으로 롤아웃한 다음 다른 스탬프에 점진적으로 배포하도록 결정할 수 있습니다. Azure Pipelines 또는 GitHub Actions와 같은 릴리스 관리 도구를 사용하여 각 스탬프에 대한 배포를 오케스트레이션하는 것이 좋습니다.
배포에 대한 Azure 구독과 리소스 그룹의 토폴로지를 신중하게 고려합니다.
일반적으로 구독에는 단일 솔루션에 대한 모든 리소스가 포함되어 있으므로 모든 스탬프에 단일 구독을 사용하는 것이 좋습니다. 그러나 개 Azure 서비스는 구독 전체 할당량을 적용합니다. 이 패턴을 사용하여 높은 수준의 스케일 아웃을 허용하는 경우 여러 구독에 스탬프를 배포해야 할 수 있습니다.
리소스 그룹에는 일반적으로 동일한 수명 주기를 공유하는 구성 요소가 포함됩니다. 모든 스탬프에 업데이트를 동시에 배포하려는 경우 모든 스탬프에 대한 모든 구성 요소가 포함된 단일 리소스 그룹을 사용할 수 있습니다. 리소스 명명 규칙 및 태그를 사용하여 각 스탬프에 속하는 구성 요소를 식별합니다. 또는 각 스탬프에 대한 업데이트를 독립적으로 배포하려는 경우 각 스탬프를 자체 리소스 그룹에 배포할 수 있습니다.
용량 계획
부하 및 성능 테스트를 사용하여 지정된 스탬프가 수용할 수 있는 대략적인 부하를 결정합니다. 로드 메트릭은 단일 스탬프가 수용할 수 있는 고객 또는 테넌트 수 또는 스탬프의 서비스가 내보내는 메트릭을 기반으로 할 수 있습니다. 용량에 접근할 때 측정할 수 있도록 각 스탬프를 계측하고 수요에 대응하기 위해 새 스탬프를 신속하게 배포할 수 있는지 확인합니다.
트래픽 라우팅
배포 스탬프 패턴은 각 스탬프를 독립적으로 처리할 때 잘 작동합니다. 예를 들어 Contoso가 여러 스탬프에 동일한 API 애플리케이션을 배포하는 경우 Contoso는 DNS(도메인 이름 시스템)를 사용하여 트래픽을 관련 스탬프로 라우팅할 수 있습니다.
-
unit1.aus.myapi.contoso.com은 트래픽을 호주 지역 내 스탬프unit1로 라우팅합니다. -
unit2.aus.myapi.contoso.com은 트래픽을 호주 지역 내 스탬프unit2로 라우팅합니다. -
unit1.eu.myapi.contoso.com은 트래픽을 유럽 지역 내 스탬프unit1로 라우팅합니다.
Azure 이러한 레코드를 Azure DNS 호스트하고 각 지역 및 스탬프에 대해 일관된 하위 도메인 규칙을 사용할 수 있습니다. 이 방법은 예측 가능한 라우팅 및 작업을 유지 관리합니다.
클라이언트는 올바른 스탬프에 연결할 책임이 있습니다.
솔루션에 모든 트래픽에 단일 수신 지점이 필요한 경우 트래픽 라우팅 서비스를 사용하여 지정된 요청, 고객 또는 테넌트에 대한 스탬프를 확인할 수 있습니다. 트래픽 라우팅 서비스는 클라이언트를 스탬프에 대한 관련 URL(예: HTTP 302 응답 상태 코드를 반환)으로 보내거나 역방향 프록시 역할을 하며 클라이언트가 인식하지 않고 트래픽을 관련 스탬프로 전달합니다.
중앙 집중식 트래픽 라우팅 서비스는 특히 솔루션이 여러 지역에서 실행되는 경우 디자인하는 데 복잡한 구성 요소일 수 있습니다. 스탬프를 호스트하는 모든 지역을 포함하여 여러 지역에 트래픽 라우팅 서비스를 배포하고 테넌트를 스탬프에 매핑하는 데이터 저장소를 동기화하는 것이 좋습니다. 트래픽 라우팅 구성 요소 자체는 Geode 패턴의 인스턴스일 수 있습니다.
예를 들어 API Management 를 배포하여 트래픽 라우팅 서비스 역할을 할 수 있습니다. API Management는 테넌트와 스탬프 간의 매핑을 저장하는 Azure Cosmos DB 컬렉션에서 데이터를 조회하여 요청에 대한 적절한 스탬프를 결정합니다. 그런 다음 API Management는 백 엔드 URL을 관련 스탬프의 API 서비스 로 동적으로 설정합니다 .
요청을 지리적으로 분산하고 트래픽 라우팅 서비스에 대한 지역 중복성을 제공하려면 여러 지역에 API Management를 배포하고Azure Front Door 사용하여 가장 가까운 API Management 게이트웨이로 트래픽을 전달합니다. 이 토폴로지에서 Azure Front Door는 오리진 그룹, 상태 검사, 및 적절한 라우팅 방법을 사용하여 비정상 API Management 지역 게이트웨이에서 요청을 라우팅합니다. 그런 다음, API Management는 필요에 따라 스탬프 엔드포인트 간의 장애 조치(failover) 규칙을 포함하여 테넌트-스탬프 매핑 및 백 엔드 구성(또는 백 엔드 풀)을 사용하여 적절한 스탬프로 라우팅합니다. 애플리케이션이 HTTP 또는 HTTPS를 통해 노출되지 않는 경우 cross 지역 Azure 부하 분산 장치를 사용하여 들어오는 호출을 지역 Azure 부하 분산 장치에 배포할 수 있습니다. Azure Cosmos DB
솔루션에 트래픽 라우팅 서비스가 포함된 경우 게이트웨이 역할을 하고 토큰 유효성 검사, 제한 및 권한 부여와 같은 다른 서비스에 대해 게이트웨이 오프로드를 수행할 수 있는지 여부를 고려합니다.
다음 단계
기여자
Microsoft는 이 문서를 유지 관리합니다. 이 문서를 작성한 기여자는 다음과 같습니다.
대표 저자:
- John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
기타 기여자:
- 페데리코 아람바리 | 선임 소프트웨어 개발자, Clarius 컨설팅
- 다니엘 라슨 | 수석 고객 엔지니어, Azure용 FastTrack
- Angel Lopez | 선임 소프트웨어 엔지니어, Azure 패턴 및 사례
- Paolo Salvatori | 수석 고객 엔지니어, FastTrack for Azure
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.
관련 리소스
- 분할을 다른 간단한 방법으로 사용하여 데이터 계층을 확장할 수 있습니다. 스탬프는 데이터를 암시적으로 분할하지만 분할에는 배포 스탬프가 필요하지 않습니다. 자세한 내용은 분할 패턴참조하세요.
- 솔루션이 트래픽 라우팅 서비스를 배포하는 경우 게이트웨이 라우팅 및 게이트웨이 오프로드 패턴을 결합하여 이 구성 요소를 최대한 활용할 수 있습니다.