Azure 랜딩 존에 대한 테스트 접근 방식
참고 항목
이 문서는 Microsoft Azure에만 적용되고 Microsoft 365 또는 Microsoft Dynamics 365와 같은 다른 Microsoft Cloud 제품에는 적용되지 않습니다.
일부 조직에서는 Azure Policy 정의 및 할당, RBAC(역할 기반 액세스 제어) 사용자 지정 역할 및 할당 등에 대한 Azure 랜딩 존 플랫폼 배포를 테스트하려고 할 수 있습니다. ARM 템플릿(Azure Resource Manager 템플릿), AzOps, Terraform, Bicep을 사용하거나 Azure Portal을 통해 수동으로 자동화를 통해 테스트를 완료할 수 있습니다. 이 지침은 Azure 랜딩 존 플랫폼 배포에서 변경 내용 및 해당 영향을 테스트하는 데 사용할 수 있는 접근 방식을 제공합니다.
이 문서는 PlatformOps 및 Central 기능 팀 및 작업과 관련이 있는 플랫폼 자동화 및 DevOps 중요한 디자인 영역 지침과 함께 사용할 수도 있습니다.
이 지침은 프로덕션 환경 관리 그룹 계층 구조의 변경 내용을 제어하는 강력한 변경 관리 프로세스가 있는 조직에 가장 적합합니다. 카나리아 관리 그룹 계층 구조는 프로덕션 환경에 배포하기 전에 배포를 작성하고 테스트하는 데 독립적으로 사용할 수 있습니다.
참고 항목
카나리아라는 용어는 개발 환경 또는 테스트 환경과의 혼동을 방지하는 데 사용됩니다. 이 이름은 설명 용도로만 사용됩니다. 카나리아 Azure 랜딩 존 환경에 적합한 이름을 정의할 수 있습니다.
마찬가지로 이 지침 전체에서 사용되는 프로덕션 환경이라는 용어는 워크로드에 대한 Azure 구독 및 리소스를 포함하고 있는 조직에서 운영하는 관리 그룹 계층 구조를 의미합니다.
플랫폼 정의
Important
이 지침은 랜딩 존, 워크로드, 애플리케이션 또는 서비스라고 알려진 애플리케이션 또는 서비스 소유자가 사용할 개발 환경 또는 테스트 환경을 위한 것이 아닙니다. 이러한 것들은 프로덕션 환경 관리 그룹 계층 구조 및 관련 거버넌스(RBAC 및 Azure Policy) 내에서 배치되고 처리됩니다.
이 지침은 플랫폼 수준 테스트 및 Azure 랜딩 존 컨텍스트의 변경에만 해당합니다.
엔터프라이즈 규모는 랜딩 존을 대규모로 만들고 운영할 수 있도록 필요한 Azure 플랫폼 구성 요소를 설계하고 배포하는 데 도움이 됩니다.
이 문서와 테스트 방법의 범위에 포함되는 플랫폼 리소스는 다음과 같습니다.
| 제품 또는 서비스 | 리소스 공급자 및 유형 |
|---|---|
| 관리 그룹 | Microsoft.Management/managementGroups |
| 관리 그룹 구독 연결 | Microsoft.Management/managementGroups/subscriptions |
| 정책 정의 | Microsoft.Authorization/policyDefinitions |
| 정책 이니셔티브 정의 또는 정책 세트 정의 | Microsoft.Authorization/policySetDefinitions |
| 정책 할당 | Microsoft.Authorization/policyAssignments |
| RBAC 역할 정의 | Microsoft.Authorization/roleDefinitions |
| RBAC 역할 할당 | Microsoft.Authorization/roleAssignments |
| Abunələr | Microsoft.Subscription/aliases |
예제 시나리오 및 결과
이 시나리오의 사례로 정책 기반 거버넌스 디자인 원칙에 따라 모든 랜딩 존의 리소스 및 설정을 제어하기 위해 새 Azure Policy의 영향과 결과를 테스트하려는 조직을 예로 들겠습니다. 이 조직은 변경이 미칠 수 있는 영향을 우려하여 이러한 변경을 프로덕션 환경에 직접 적용하지 않으려 합니다.
카나리아 환경을 사용하여 이 플랫폼 변경을 테스트하면 조직에서 Azure Policy 변경의 영향과 결과를 구현하고 검토할 수 있습니다. 이 프로세스를 통해 프로덕션 환경에 Azure Policy를 구현하기 전에 조직의 요구 사항을 충족할 수 있습니다.
비슷한 시나리오는 Azure RBAC 역할 할당 및 Microsoft Entra 그룹 멤버 자격 변경일 수 있습니다. 프로덕션 환경에서 변경하기 전에 일종의 테스트가 필요할 수 있습니다.
Important
이는 대부분의 고객에게 일반적인 배포 방법 또는 패턴이 아닙니다. Azure 랜딩 존 배포에는 필수가 아닙니다.
그림 1: 카나리아 관리 그룹 계층 구조
다이어그램에서 알 수 있듯이 전체 Azure 랜딩 존 프로덕션 환경 관리 그룹 계층 구조는 아래 Tenant Root Group중복됩니다. canary 이름은 관리 그룹 표시 이름 및 ID에 추가됩니다. ID는 단일 Microsoft Entra 테넌트 내에서 고유해야 합니다.
참고 항목
카나리아 환경 관리 그룹 표시 이름이 프로덕션 환경 관리 그룹 표시 이름과 같을 수 있습니다. 이 경우 사용자에게 혼란을 줄 수 있습니다. 따라서 표시 이름뿐 아니라 ID에도 "canary"라는 이름을 추가하는 것이 좋습니다.
그 후 카나리아 환경 관리 그룹 계층 구조는 다음 리소스 종류의 테스트를 간소화하는 데 사용됩니다.
- 관리 그룹
- 구독 배치
- Rbac
- 역할(기본 제공 및 사용자 지정)
- Assignments
- Azure Policy
- 정의(기본 제공 및 사용자 지정)
- 세트 정의라고도 하는 이니셔티브
- Assignments
전체 카나리아 환경 관리 그룹 계층 구조를 배포하지 않으려는 경우 어떻게 해야 할까요?
전체 카나리아 환경 관리 그룹 계층 구조를 배포하지 않으려면 다이어그램에 표시된 것처럼 샌드박스 구독을 사용하여 프로덕션 환경 계층 구조 내에서 플랫폼 리소스를 테스트할 수 있습니다.
그림 2: 샌드박스를 강조하는 Enterprise 규모 관리 그룹 계층 구조
이 시나리오에서 Azure Policy 및 RBAC를 테스트하려면 테스트를 완료하려는 ID(예: 사용자 계정, 서비스 주체 또는 관리되는 서비스 ID)에 할당된 소유자 RBAC 역할이 있는 단일 Azure 구독이 필요합니다. 이 구성을 사용하면 샌드박스 구독 범위 내에서만 Azure Policy 정의 및 할당을 작성, 할당 및 수정할 수 있습니다.
이 샌드박스 접근 방식은 구독 내에서 RBAC 테스트에도 사용할 수 있습니다. 특정 사용 사례에 대한 권한을 부여하기 위해 새로운 사용자 지정 RBAC 역할을 개발하는 경우를 예로 들 수 있습니다. 이 테스트는 모두 샌드박스 구독에서 수행할 수 있으며 계층 구조의 더 높은 곳에서 역할을 만들고 할당하기 전에 테스트할 수 있습니다.
이 방법의 이점은 샌드박스 구독을 필요한 시간 동안 사용한 후 환경에서 삭제할 수 있다는 것입니다.
그러나 이 방법을 사용하면 관리 그룹 계층 구조에서 RBAC 및 Azure 정책의 상속을 테스트할 수 없습니다.
단일 Microsoft Entra 테넌트 사용
단일 Microsoft Entra 테넌트를 사용하는 경우 고려해야 할 고려 사항은 다음과 같습니다.
- Microsoft Entra 테넌트에 대한 엔터프라이즈 규모 디자인 권장 사항을 따릅니다.
- 클라우드 채택 프레임워크 Azure 모범 사례에 따라 단일 디렉터리 및 ID 지침을 표준화하면 대부분의 경우 단일 Microsoft Entra 테넌트가 모범 사례입니다.
- 단일 Microsoft Entra 테넌트에서 동일한 사용자가 동일한 Microsoft Entra 테넌트 내의 관련 관리 그룹 계층 구조에 할당된 프로덕션 환경 및 카나리아 Azure 랜딩 존 환경 모두에 서로 다른 Microsoft Entra 그룹을 사용할 수 있습니다.
- 여러 Microsoft Entra 테넌트에서 여러 ID로 인해 Microsoft Entra ID 라이선스 비용이 증가하거나 중복되었습니다.
- 이 점은 특히 Microsoft Entra ID P1 또는 P2 기능을 사용하는 고객과 관련이 있습니다.
- 사용자와 그룹이 두 Microsoft Entra 테넌트 간에 동일하지 않을 가능성이 높기 때문에 RBAC 변경은 카나리아 환경과 프로덕션 환경 모두에서 더 복잡해질 것입니다.
- 또한 사용자 및 그룹 ID는 전역적으로 고유하기 때문에 Microsoft Entra 테넌트에서 동일하지 않습니다.
- 여러 Microsoft Entra 테넌트 관리로 인한 복잡성 및 관리 오버헤드를 줄입니다.
- 테스트를 수행하기 위해 액세스를 유지하고 별도의 테넌트에 로그인해야 하는 권한 있는 사용자가 실수로 카나리아 환경 대신 프로덕션 환경을 변경하거나 그 반대로 변경할 수 있습니다.
- 구성 드리프트 및 배포 오류 가능성을 줄입니다.
- 추가 보안 및 비상 또는 긴급 액세스 프로세스를 만들 필요가 없습니다.
- Azure 랜딩 존 배포에 대한 변경 내용을 구현하는 데 필요한 시간과 마찰을 줄입니다.
구현 지침
다음은 프로덕션 환경 관리 그룹 계층 구조와 함께 Azure 랜딩 존에 대한 카나리아 관리 그룹 계층 구조를 구현하고 사용하는 방법에 대한 지침입니다.
Warning
포털을 사용하여 현재 Azure 랜딩 존 환경을 배포하고 관리하는 경우 프로덕션 환경과 카나리아 환경이 자주 동기화되지 않아 복제본(replica) 같은 계층 구조 및 프로덕션 환경을 제공하지 않기 때문에 카나리아 접근 방식을 효율적으로 채택하고 사용하기 어려울 수 있습니다.
이 시나리오에 있는 경우 위에 나열된 대로 Azure 랜딩 존에 대한 코드로서의 인프라 배포 접근 방식으로 이동하는 것이 좋습니다. 또는 카나리아와 프로덕션 간의 구성 드리프트의 잠재적 위험을 인식하고 주의를 기울여야 합니다.
- 관련 프로덕션 환경 또는 카나리아 환경 관리 그룹 계층 구조에 대한 권한이 부여된 별도의 Microsoft ENTRA SPN(서비스 주체) 또는 MSI(관리 서비스 ID)를 사용합니다.
- 이 지침은 PoLP(최소 권한 원칙)를 따릅니다.
- Git 리포지토리, 분기 또는 리포지토리 내에서 별도의 폴더를 사용하여 프로덕션 환경 및 카나리아 환경 Azure 랜딩 존 배포에 대한 코드로서의 인프라를 보유합니다.
- 배포되는 계층 구조에 따라 관련 Microsoft Entra SPN(서비스 주체) 또는 MSI(관리 서비스 ID)를 CI/CD 파이프라인의 일부로 사용합니다.
- 프로덕션 환경에서 하듯이 카나리아 환경에 대한 git 분기 정책 또는 보안을 구현합니다.
- 승인자 수를 줄이고 카나리아 환경의 페일 패스트(Fail-fast)를 검사하는 것이 좋습니다.
- 환경 변수를 사용하여 배포될 계층 구조를 변경하는 동일한 Azure Pipelines 또는 GitHub 작업을 사용합니다. 또 다른 옵션은 파이프라인을 복제하고 하드 코딩된 설정을 수정하여 배포될 계층 구조를 정의하는 것입니다.
- Azure Pipelines DevOps 템플릿 또는 GitHub Actions 워크플로 템플릿을 사용하면 DRY(반복 금지) 원칙을 준수하는 데 도움이 됩니다.
- 필요한 경우 카나리아 관리 그룹 계층 구조 주변으로 이동할 수 있는 별도의 EA 부서 및 계정 아래에 카나리아 구독 세트를 만듭니다.
- 리소스 세트를 항상 카나리아 환경 구독에 배포하면 도움이 될 수 있습니다.
- 카나리아 환경에서 변경의 유효성을 검사할 수 있는 리소스 세트를 만드는 ARM 템플릿, Bicep 또는 Terraform과 같은 Infrastructure-as-Code 템플릿을 사용하면 도움이 될 수 있습니다.
- 카나리아 환경 구독을 포함한 모든 Azure 구독에 대한 모든 Azure 활동 로그를 Azure 랜딩 존 디자인 권장 사항에 따라 프로덕션 환경 Azure Log Analytics 작업 영역으로 보냅니다.
팁
프로덕션 환경에 Azure 랜딩 존이 이미 배포되어 있고 이제 카나리아 환경을 추가하려는 경우 프로덕션 환경 계층 구조의 현재 배포를 복제하고 리소스 이름을 수정하여 카나리아 명명 체계를 접두사로 지정하는 것이 좋습니다.
이는 카나리아 환경을 사용하도록 설정하기 위해 배포하는 내용이 처음부터 프로덕션과 동기화되도록 하기 위한 것입니다. Git 리포지토리와 함께 코드로서의 인프라 도구를 사용할 때 이 작업을 쉽게 수행할 수 있습니다.
다음 단계
랜딩 존 샌드박스 환경을 구현하는 방법을 알아봅니다.