Azure는 리소스를 구성하는 다양한 옵션을 제공합니다. 다중 테넌트 솔루션에는 리소스 구성 전략을 계획할 때 고려해야 할 특정 절충점이 있습니다. 이 문서에서는 Azure 리소스 구성의 두 가지 핵심 요소인 테넌트 격리 및 여러 리소스에 대한 스케일 아웃을 검토합니다. 또한 Azure의 리소스 제한 및 할당량을 사용하는 방법과 이러한 제한을 초과하여 솔루션의 크기를 조정하는 방법에 대해서도 설명합니다.
주요 고려 사항 및 요구 사항
테넌트 격리 요구 사항
Azure에서 다중 테넌트 솔루션을 배포하는 경우 리소스를 각 테넌트에 전용으로 사용할지 아니면 리소스를 여러 테넌트 간에 공유할지를 결정해야 합니다. 이 시리즈의 다중 테넌트 접근 방식 및 서비스별 지침 섹션 전체에서 다양한 리소스 범주에 대한 옵션과 절충점에 대해 설명합니다. 일반적으로 다양한 테넌트 격리 옵션이 있습니다. 격리 모델을 결정하는 방법에 대한 자세한 지침은 다중 테넌트 솔루션에 대해 고려해야 하는 테넌트 모델을 검토하세요.
확장
리소스 그룹 및 구독을 포함하여 대부분의 Azure 리소스에는 크기 조정 기능에 영향을 줄 수 있는 제한이 적용됩니다. 계획된 테넌트 수 또는 계획된 시스템 부하를 충족하려면 스케일 아웃 또는 bin 압축을 고려해야 할 수 있습니다.
많은 수의 테넌트 또는 높은 부하로 증가하지 않을 것이라고 확신하는 경우 스케일 아웃 계획을 과도하게 엔지니어링하지 않습니다. 그러나 솔루션이 확장되도록 계획하는 경우 스케일 아웃 계획을 신중하게 고려합니다. 이 문서의 지침에 따라 규모에 맞게 설계해야 합니다.
자동화된 배포 프로세스가 있고 리소스 간에 크기를 조정해야 하는 경우 여러 리소스 인스턴스에서 테넌트를 배포하고 할당하는 방법을 결정합니다. 예를 들어 특정 리소스에 할당할 수 있는 테넌트 수에 도달하고 있음을 어떻게 감지할 수 있나요? 필요할 때 새 리소스를 적시에 배포할 계획인가요? 아니면 필요할 때 사용할 준비가 되도록 리소스 풀을 미리 배포하시겠나요?
팁
디자인 및 개발의 초기 단계에서는 자동화된 스케일 아웃 프로세스를 구현하도록 선택하지 않을 수 있습니다. 확장함에 따라 크기를 조정하는 데 필요한 프로세스를 고려하고 명확하게 문서화해야 합니다.
또한 크기 조정 기능을 제한할 수 있는 코드 및 구성을 가정하지 않아야 합니다. 예를 들어 여러 스토리지 계정으로 스케일 아웃해야 할 수 있습니다. 애플리케이션 계층에서 모든 테넌트에 대한 단일 스토리지 계정에만 연결한다고 가정하지 않는지 확인합니다.
고려해야 할 접근 방식 및 패턴
테넌트 격리
Azure 리소스는 계층 구조를 통해 배포되고 관리됩니다. 대부분의 리소스는 구독에 포함된 리소스 그룹에 배포됩니다. 관리 그룹은 구독을 모두 논리적으로 그룹화합니다. 이러한 모든 계층 계층은 Microsoft Entra 테넌트에 연결됩니다.
각 테넌트에 대한 리소스를 배포하는 방법을 결정하는 경우 계층 구조의 다른 수준에서 격리할 수 있습니다. 각 옵션은 특정 유형의 다중 테넌트 솔루션에 유효하며, 이점과 절충점이 제공됩니다. 또한 서로 다른 격리 모델을 솔루션의 여러 구성 요소에 사용하여 접근 방식을 결합하는 것이 일반적입니다.
공유 리소스 내의 격리
Azure 리소스를 여러 테넌트 간에 공유하고 모든 워크로드를 단일 인스턴스에서 실행하도록 선택할 수 있습니다. 중요한 특정 고려 사항 또는 옵션을 이해하려면 사용하는 Azure 서비스에 대한 서비스별 지침을 검토하세요.
리소스의 단일 인스턴스를 실행하는 경우 크기를 조정할 때 도달할 수 있는 서비스 제한, 구독 제한 또는 할당량을 고려해야 합니다. 예를 들어 AKS(Azure Kubernetes Service) 클러스터에서 지원하는 최대 노드 수가 있고, 스토리지 계정에서 지원하는 초당 트랜잭션 수에 대한 상한이 있습니다. 이러한 제한에 도달하면 크기를 여러 공유 리소스로 조정하는 방법을 고려합니다.
또한 애플리케이션 코드에서 다중 테넌트를 완전히 인식하고 특정 테넌트의 데이터에 대한 액세스를 제한하도록 해야 합니다.
공유 리소스 접근 방식을 보여 주기 위해 Contoso에서 웹 애플리케이션, 데이터베이스 및 스토리지 계정을 포함하는 다중 테넌트 SaaS 애플리케이션을 빌드하고 있다고 가정합니다. 공유 리소스를 배포하도록 결정하고 이러한 리소스를 사용하여 모든 고객에게 서비스를 제공할 수 있습니다. 다음 다이어그램에서는 모든 고객이 단일 리소스 세트를 공유합니다.
리소스 그룹의 개별 리소스
각 테넌트에 대한 전용 리소스를 배포할 수도 있습니다. 단일 테넌트에 대한 솔루션의 전체 복사본을 배포할 수 있습니다. 또는 일부 구성 요소를 테넌트 간에 공유하고 특정 테넌트 전용의 다른 구성 요소를 배포할 수 있습니다.
리소스 그룹을 사용하여 동일한 수명 주기를 통해 리소스를 관리하는 것이 좋습니다. 일부 다중 테넌트 시스템에서는 여러 테넌트에 대한 리소스를 단일 리소스 그룹 또는 리소스 그룹 세트에 배포하는 것이 좋습니다.
배포 파이프라인에서 테넌트별 리소스 배포를 시작하는지 아니면 애플리케이션에서 시작하는지를 포함하여 이러한 리소스를 배포하고 관리하는 방법을 고려해야 합니다. 특정 리소스가 특정 테넌트와 관련되는지를 명확하게 식별하는 방법도 결정해야 합니다. 명확한 명명 규칙 전략, 리소스 태그 또는 테넌트 카탈로그 데이터베이스를 사용하는 것이 좋습니다.
여러 테넌트와 개별 테넌트에 대해 배포하는 리소스 간에 공유하는 리소스에 대해 별도의 리소스 그룹을 사용하는 것이 좋습니다. 그러나 일부 리소스의 경우 Azure는 리소스 그룹에 배포할 수 있는 단일 종류의 리소스 수를 제한합니다. 이 제한은 확장함에 따라 여러 리소스 그룹에서 크기를 조정해야 할 수도 있음을 의미합니다.
Contoso에 Adventure Works, Fabrikam 및 Tailwind의 세 고객이 있다고 가정합니다. 세 고객 간에 웹 애플리케이션 및 스토리지 계정을 공유한 다음, 각 테넌트에 대해 개별 데이터베이스를 배포하도록 선택할 수 있습니다. 다음 다이어그램에서는 각 고객에게 공유 리소스가 포함된 리소스 그룹과 데이터베이스가 포함된 리소스 그룹이 할당됩니다.
구독의 개별 리소스 그룹
각 테넌트에 대한 리소스 세트를 배포하는 경우 전용 테넌트별 리소스 그룹을 사용하는 것이 좋습니다. 예를 들어 배포 스탬프 패턴을 따르는 경우 각 스탬프는 자체 리소스 그룹에 배포해야 합니다. 여러 테넌트별 리소스 그룹을 공유 Azure 구독에 배포하도록 고려할 수 있습니다. 이렇게 하면 정책 및 액세스 제어 규칙을 쉽게 구성할 수 있습니다.
각 테넌트에 대한 리소스 그룹 세트를 만들고 모든 공유 리소스에 대한 공유 리소스 그룹도 만들도록 선택할 수 있습니다.
테넌트별 리소스 그룹을 공유 구독에 배포하는 경우 각 구독의 최대 리소스 그룹 수와 배포하는 리소스에 적용되는 다른 구독 수준 제한을 알고 있어야 합니다. 이러한 제한에 도달하면 여러 구독에서 크기를 조정해야 할 수 있습니다.
이 예에서 Contoso는 각 고객에 대한 스탬프를 배포하고 이러한 스탬프를 단일 구독 내의 전용 리소스 그룹에 배치하도록 선택할 수 있습니다. 다음 다이어그램에서는 각 고객에 대해 세 개의 리소스 그룹을 포함하는 구독이 만들어집니다.
별도의 구독
테넌트별 구독을 배포하면 테넌트별 리소스를 완전히 격리할 수 있습니다. 또한 대부분의 할당량 및 제한이 구독 내에서 적용되므로 테넌트별로 별도의 구독을 사용하면 각 테넌트에서 해당 할당량을 완전히 사용할 수 있습니다. 일부 Azure 청구 계정 유형의 경우 구독을 프로그래밍 방식으로 만들 수 있습니다. 구독 간 컴퓨팅에 Azure 예약 및 Azure 절감 플랜을 사용할 수도 있습니다.
만들 수 있는 구독 수를 알고 있어야 합니다. 기업계약이 있는 경우와 같이 최대 구독 수는 Microsoft 또는 Microsoft 파트너와의 상업적 관계에 따라 다를 수 있습니다.
그러나 많은 수의 구독에서 작업하는 경우 할당량 증가를 요청하는 것이 더 어려울 수 있습니다. 할당량 API는 일부 리소스 종류에 대한 프로그래밍 인터페이스를 제공합니다. 그러나 많은 리소스 종류의 경우 지원 사례를 시작하여 할당량 증가를 요청해야 합니다. 많은 구독을 사용하는 경우 Azure 지원 계약 및 지원 사례를 사용하는 것이 어려울 수도 있습니다.
액세스 제어 규칙 및 정책을 쉽게 관리할 수 있도록 테넌트별 구독을 관리 그룹 계층 구조로 그룹화하는 것이 좋습니다.
예를 들어 Contoso에서 다음 다이어그램과 같이 세 고객 각각에 대해 별도의 Azure 구독을 만들도록 결정했다고 가정합니다. 각 구독에는 해당 고객에 대한 전체 리소스 세트를 포함하는 리소스 그룹이 포함됩니다.
각 구독에는 해당 고객에 대한 전체 리소스 세트를 포함하는 리소스 그룹이 포함됩니다.
관리 그룹을 사용하여 구독 관리를 간소화합니다. 프로덕션을 관리 그룹 이름에 포함하면 프로덕션 테넌트와 비 프로덕션 또는 테스트 테넌트를 명확하게 구분할 수 있습니다. 비 프로덕션 테넌트에는 다른 Azure 액세스 제어 규칙 및 정책이 적용됩니다.
모든 구독은 단일 Microsoft Entra 테넌트에 연결됩니다. 단일 Microsoft Entra 테넌트를 사용하면 사용자 및 서비스 주체를 포함한 Contoso 팀의 ID를 전체 Azure 자산에서 사용할 수 있습니다.
별도의 Microsoft Entra 테넌트에서 별도의 구독
각 테넌트에 대해 개별 Microsoft Entra 테넌트도 수동으로 만들거나 고객의 Microsoft Entra 테넌트 내에서 구독에 리소스를 배포할 수도 있습니다. 그러나 여러 Microsoft Entra 테넌트와 함께 작업하면 인증하고, 역할 할당을 관리하고, 전역 정책을 적용하고, 다른 많은 관리 작업을 수행하기가 더 어려워집니다.
Warning
대부분의 다중 테넌트 솔루션에 대해 여러 Microsoft Entra 테넌트를 만들지 않는 것이 좋습니다. Microsoft Entra 테넌트에서 작업하면 복잡성이 더해지고 리소스의 크기를 조정하고 관리하는 기능이 줄어듭니다. 일반적으로 이 접근 방식은 고객을 대신하여 Azure 환경을 운영하는 MSP(관리되는 서비스 공급자)에서만 사용됩니다.
단일 Microsoft Entra 테넌트는 여러 개별 구독 및 Azure 리소스에서 사용할 수 있습니다. 여러 Microsoft Entra 테넌 트를 배포하기 전에 목적을 달성할 수 있는 다른 방법이 있는지 여부를 고려합니다.
여러 Microsoft Entra 테넌트에 연결된 구독에서 Azure 리소스를 관리해야 하는 경우 Azure Lighthouse를 사용하여 Microsoft Entra 테넌트 전체에서 리소스를 관리하는 것이 좋습니다.
예를 들어 Contoso는 다음 다이어그램과 같이 개별 Microsoft Entra 테넌트를 만들고 각 고객에 대해 별도의 Azure 구독을 만들 수 있습니다.
Microsoft Entra 테넌트는 구독 및 필요한 리소스를 포함하는 Contoso의 각 테넌트에 대해 구성됩니다. Azure Lighthouse는 각 Microsoft Entra 테넌트에 연결됩니다.
bin 압축
리소스 격리 모델에 관계없이 솔루션이 여러 리소스에 걸쳐 스케일 아웃하는 시기와 방법을 고려해야 합니다. 시스템 부하가 증가하거나 테넌트 수가 증가함에 따라 리소스의 크기를 조정해야 할 수 있습니다. 요구 사항에 맞는 최적의 리소스 수를 배포하려면 bin 압축을 고려합니다.
팁
많은 솔루션에서 리소스 크기를 개별적으로 조정하는 대신 전체 리소스 세트의 크기를 조정하는 것이 더 쉽습니다. 배포 스탬프 패턴을 따르는 것이 좋습니다.
리소스 한계
Azure 리소스에는 솔루션 계획에서 고려해야 하는 제한 및 할당량이 있습니다. 예를 들어 리소스는 최대 동시 요청 수 또는 테넌트별 구성 설정을 지원할 수 있습니다.
각 리소스를 구성하고 사용하는 방법도 해당 리소스의 확장성에 영향을 줍니다. 예를 들어 특정 양의 컴퓨팅 리소스가 제공되면 애플리케이션에서 정의된 초당 트랜잭션 수에 성공적으로 응답할 수 있습니다. 이 시점 이후에도 스케일 아웃해야 할 수 있습니다. 성능 테스트는 리소스에서 더 이상 요구 사항을 충족하지 않는 지점을 식별하는 데 도움이 됩니다.
참고
크기를 여러 리소스로 조정하는 원칙은 여러 인스턴스를 지원하는 서비스를 사용하는 경우에도 적용됩니다.
예를 들어 Azure App Service는 계획의 인스턴스 수 스케일 아웃을 지원하지만 단일 계획의 크기를 조정할 수 있는 범위에는 제한이 있습니다. 대규모 다중 테넌트 앱에서는 이러한 제한을 초과할 수 있으며 확장에 맞게 추가 App Service 리소스를 배포해야 합니다.
일부 리소스를 테넌트 간에 공유하는 경우 요구 사항에 따라 구성되면 먼저 리소스에서 지원하는 테넌트 수를 결정해야 합니다. 그런 다음, 총 테넌트 수를 제공하는 데 필요한 만큼의 리소스를 배포합니다.
예를 들어 다중 테넌트 SaaS 솔루션의 일부로 Azure Application Gateway를 배포한다고 가정합니다. 애플리케이션 디자인을 검토하고, 부하 상태에서 애플리케이션 게이트웨이의 성능을 테스트하고, 해당 구성을 검토합니다. 그런 다음, 단일 애플리케이션 게이트웨이 리소스를 100명의 고객 간에 공유할 수 있다고 결정합니다. 조직의 확장 계획에 따라 첫 해에 150명의 고객을 온보딩한다고 예상되므로 예상 부하를 처리할 여러 애플리케이션 게이트웨이를 배포하도록 계획해야 합니다.
이전 다이어그램에는 두 개의 애플리케이션 게이트웨이가 있습니다. 첫 번째 게이트웨이는1~100명의 고객 전용이고, 두 번째 게이트웨이는 101~200명의 고객 전용입니다.
리소스 그룹 및 구독 제한
공유 리소스를 사용하는지 아니면 전용 리소스를 사용하는지에 관계없이 제한을 고려해야 합니다. Azure는 리소스 그룹 및 Azure 구독에 배포할 수 있는 리소스의 수를 제한합니다. 이러한 제한에 도달하면 여러 리소스 그룹 또는 구독에서 크기를 조정하도록 계획해야 합니다.
예를 들어 각 고객에 대해 전용 애플리케이션 게이트웨이를 공유 리소스 그룹에 배포한다고 가정합니다. 일부 리소스의 경우 Azure는 동일한 종류의 리소스를 최대 800개까지 단일 리소스 그룹에 배포하도록 지원합니다. 따라서 이 제한에 도달하면 새 애플리케이션 게이트웨이를 다른 리소스 그룹에 배포해야 합니다. 다음 다이어그램에는 두 개의 리소스 그룹이 있습니다. 각 리소스 그룹에는 800개의 애플리케이션 게이트웨이가 포함되어 있습니다.
리소스 그룹 및 구독에서 테넌트 bin 압축
리소스, 리소스 그룹 및 구독에서 bin 압축 개념을 적용할 수도 있습니다. 예를 들어 테넌트 수가 적은 경우 단일 리소스를 배포하고 모든 테넌트 간에 공유할 수 있습니다. 다음 다이어그램에서는 단일 리소스로의 bin 압축을 보여 줍니다.
확장함에 따라 단일 리소스에 대한 용량 제한에 도달하고 여러(R) 리소스로 스케일 아웃할 수 있습니다. 다음 다이어그램에서는 여러 리소스에 대한 bin 압축을 보여 줍니다.
시간이 지남에 따라 단일 리소스 그룹의 리소스 수 제한에 도달한 다음, 여러(R) 리소스를 여러(G) 리소스 그룹에 배포할 수 있습니다. 다음 다이어그램에서는 여러 리소스 그룹의 여러 리소스에 대한 bin 압축을 보여 줍니다.
그리고 규모가 더 커짐에 따라 각각 여러(R) 리소스가 있는 여러(G) 리소스 그룹을 포함하는 여러(S) 구독에 배포할 수 있습니다. 다음 다이어그램에서는 여러 리소스 그룹 및 구독의 여러 리소스에 대한 bin 압축을 보여 줍니다.
스케일 아웃 전략을 계획하면 크기를 매우 많은 수의 테넌트로 조정하고 높은 수준의 부하를 유지할 수 있습니다.
태그
리소스 태그를 사용하면 비용을 관리하고 추적하는 데 유용할 수 있는 사용자 지정 메타데이터를 Azure 리소스에 추가할 수 있습니다. 자세한 내용은 리소스 태그를 사용하여 비용 할당을 참조하세요.
피해야 할 안티패턴
- 크기 조정을 계획하지 않습니다. 배포할 리소스의 제한 및 부하 또는 테넌트 수가 증가함에 따라 중요해질 수 있는 제한을 명확히 이해해야 합니다. 크기 조정에 따라 추가 리소스를 배포하는 방법을 계획하고 이 계획을 테스트합니다.
- 빈 압축을 계획하지 않습니다. 즉시 확장할 필요가 없는 경우에도 시간이 지남에 따라 여러 리소스, 리소스 그룹 및 구독에서 Azure 리소스의 크기를 조정하도록 계획합니다. 나중에 크기를 여러 리소스로 조정해야 할 수 있는 경우 애플리케이션 코드에서 단일 리소스가 있는 것처럼 가정하지 않습니다.
- 많은 개별 리소스의 크기를 조정합니다. 복잡한 리소스 토폴로지를 사용하는 경우 개별 구성 요소의 크기를 하나씩 조정하기가 어려울 수 있습니다. 배포 스탬프 패턴에 따라 솔루션의 크기를 하나의 단위로 조정하는 것이 더 간단한 경우가 많습니다.
- 필요하지 않은 경우 각 테넌트에 대해 격리된 리소스를 배포합니다. 많은 솔루션에서 여러 테넌트에 대해 공유 리소스를 배포하는 것이 더 비용 효율적이고 효율적입니다.
- 별도의 Microsoft Entra 테넌트 사용 일반적으로 여러 Microsoft Entra 테넌트는 프로비전할 수 없습니다. Microsoft Entra 테넌트에서 리소스를 관리하는 것은 복잡합니다. 단일 Microsoft Entra 테넌트에 연결된 구독 간에 크기를 조정하는 것이 더 간단합니다.
- 크기를 조정할 필요가 없는 경우 과도하게 설계합니다. 일부 솔루션에서는 특정 크기 조정 수준을 초과하여 확장할 수 없음을 확실하게 알고 있습니다. 이러한 시나리오에서는 복잡한 크기 조정 논리를 빌드할 필요가 없습니다. 그러나 조직에서 확장하려는 경우 크기를 조정할 준비가 되어 있어야 합니다(잠재적으로 예고 없이).
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- John Downs | 수석 고객 엔지니어, FastTrack for Azure
기타 기여자:
- Jason Beck | 선임 고객 엔지니어, FastTrack for Azure
- Bohdan Cherchyk | 수석 고객 엔지니어, FastTrack for Azure
- Laura Nicolas | 선임 고객 엔지니어, FastTrack for Azure
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
- Joshua Waddell | 선임 고객 엔지니어, FastTrack for Azure
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.
다음 단계
비용 관리 및 할당 접근 방식을 검토합니다.