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