Azure 랜딩 존에서 애플리케이션 개발 환경 관리

아티클
12/13/2023

이 문서에서는 클라우드 플랫폼 팀이 가드레일을 구현하여 Azure 랜딩 존에서 애플리케이션 환경을 관리하는 방법을 설명합니다. 또한 다양한 애플리케이션 개발 환경을 프레임워크에 맞추는 방법도 설명합니다. 적절한 환경을 만드는 주요 측면은 적절한 관리 그룹에 구독을 배치하는 것입니다.

기본 설정

개발 팀은 신속하게 반복할 수 있는 기능이 필요하며, 클라우드 거버넌스 및 플랫폼 팀은 조직의 위험, 규정 준수 및 보안을 대규모로 관리해야 합니다. 정책 기반 거버넌스 및 구독 민주화라는 두 가지 주요 Azure 랜딩 존 디자인 원칙에 집중하여 애플리케이션 환경을 제대로 관리할 수 있습니다. 이러한 원칙은 기본 가드레일을 제공하고 애플리케이션 팀에 제어를 위임하는 방법을 설명합니다. 애플리케이션 팀은 Azure Well-Architected Framework 지침을 사용하여 워크로드를 디자인합니다. 자체 랜딩 존 리소스를 배포하고 관리하며, 플랫폼 팀은 Azure 정책을 할당하여 리소스를 제어합니다.

애플리케이션 팀이 기술 및 기능을 실험할 수 있도록 반 거버넌스 리소스에 샌드박스 리소스를 제공하는 것이 중요합니다.

애플리케이션 소유자가 구독 자동 판매 또는 다른 구독 만들기 프로세스를 사용하는 경우 여러 개발 환경에 대한 구독을 요청하는 방법을 알고 있어야 합니다.

이 문서에서는 관리 그룹, 정책 및 공유 플랫폼 아키텍처, 워크로드 또는 애플리케이션 랜딩 존을 포함한 Azure 랜딩 존에 대해 설명합니다.

참고 항목

이 문서의 지침은 워크로드 또는 애플리케이션 랜딩 존에만 적용됩니다. Azure 랜딩 존 플랫폼 자체에 대한 테스트 및 환경 분리는 카나리아 접근 방식을 설명하는 Azure 랜딩 존에 대한 테스트 방법을 참조하세요.

실제로는 단계적 환경의 수와 유형을 사용할 수 있습니다. 이 문서에서는 다음과 같은 단계적 환경을 참조합니다.

환경	설명	관리 그룹
Sandbox	프로토타입의 신속한 혁신에 사용되지만 프로덕션에 바인딩된 구성에는 사용되지 않는 환경	샌드박스 관리 그룹
개발	잠재적 릴리스 후보를 빌드하는 데 사용되는 환경	Corp 또는 Online과 같은 아키타입 관리 그룹
Test	단위 테스트, 사용자 승인 테스트 및 품질 보증 테스트를 포함하여 테스트를 수행하는 데 사용되는 환경	Corp 또는 Online과 같은 아키타입 관리 그룹
생산	고객에게 가치를 제공하는 데 사용되는 환경	Corp 또는 Online과 같은 아키타입 관리 그룹

자세한 내용은 애플리케이션 워크로드에 대한 개발, 테스트 및 프로덕션 환경을 처리하는 비디오와 Azure에서 사용해야 하는 구독 수를 참조하세요.

환경, 구독 및 관리 그룹

이 섹션의 필수 구성 요소는 리소스 조직 디자인 영역을 참조 하세요.

Azure 랜딩 존 사례를 채택할 때 구독을 올바르게 구성해야 합니다. 이상적으로 각 애플리케이션 환경에는 자체 구독이 있어야 합니다. 이 메서드는 환경을 격리된 상태로 유지하는 보안 및 정책 컨트롤을 제공합니다. 여기에는 한 환경에 대한 잠재적인 문제가 포함됩니다.

별도의 구독은 원형 수준에서 동일한 정책을 가집니다. 필요한 경우 애플리케이션 소유자는 구독별 정책을 할당하여 애플리케이션 및 환경별 동작을 적용할 수 있습니다.

일부 애플리케이션 아키텍처에서는 서비스가 환경 간에 공유되어야 합니다. 이 경우 여러 환경에 단일 구독을 사용할 수 있습니다. 워크로드 소유자는 클라우드 플랫폼 팀과 협력하여 여러 환경에 대한 단일 구독이 필요한지 확인하는 것이 좋습니다.

다음과 같은 경우 여러 애플리케이션 환경에 단일 구독을 사용합니다.

환경은 자체 구독에서 격리할 수 없습니다.
환경에는 네트워크 운영자와 같은 기능 역할에 동일한 팀이 할당됩니다.
환경은 동일한 정책을 사용할 수 있습니다.

애플리케이션 또는 서비스 워크로드가 단일 구독에 있어야 하고 각 환경에 적용되는 정책을 변경해야 하는 경우 다음을 수행할 수 있습니다.

랜딩 존 관리 그룹 아래에 새 아키타입 맞춤 관리 그룹을 만듭니다. 자세한 내용은 이 문서의 관리 그룹 계층 구조를 참조하세요.
개발 활동에 샌드박스 구독을 사용합니다. 샌드박스에는 덜 제한적인 정책 집합이 있습니다.
관리 그룹 수준 대신 구독 수준에서 적용되는 정책을 사용합니다. 정책 정의에 태그를 추가하여 정책을 필터링하고 올바른 환경에 적용할 수 있습니다. 특정 리소스 그룹에 정책을 할당하거나 제외할 수도 있습니다.

구독 만들기 프로세스 중에 정책을 구독 자동 판매 일부로 할당할 수 있습니다.

비용을 제어하는 데 도움이 되도록 구현하는 정책의 경우 필요한 경우 구독 수준에서 정책 정의를 적용합니다. 또는 랜딩 존 소유자가 비용을 담당하게 하여 진정한 자율성을 제공합니다. 자세한 내용은 플랫폼 자동화 및 DevOps를 참조 하세요.

Warning

관리 그룹 수준의 정책 및 컨트롤과 달리 구독에 대한 권한이 상승된 개인은 구독 기반 정책 및 태그를 변경할 수 있습니다. 적절한 역할을 가진 관리 관리자는 정책을 제외하거나, 정책을 수정하거나, 리소스에 대한 태그를 변경하여 이러한 컨트롤을 무시할 수 있습니다.

따라서 보안 중심 정책의 정의에 태그를 적용해서는 안 됩니다. 또한 다음 작업에 대해 항상 활성 상태인 권한을 할당하지 마세요.

Microsoft.Authorization/policyAssignments/*
Microsoft.Authorization/policyDefinitions/*
Microsoft.Authorization/policyExemptions/*
Microsoft.Authorization/policySetDefinitions/*

PIM(Privileged Identity Management)을 사용하여 이러한 작업을 제어할 수 있습니다.

관리 그룹 계층 구조

복잡한 관리 그룹 계층 구조를 방지합니다. 자주 수정하고, 비효율적으로 확장하고, 가치가 부족할 수 있습니다. 이러한 잠재적인 문제를 방지하기 위해 Azure 랜딩 존 관리 그룹은 워크로드 원형으로 정렬됩니다. 자세한 내용은 관리 그룹 및 구독 조직을 참조하세요.

아키타입 정렬은 관리 그룹이 특정 워크로드 아키타입에 대해서만 생성됨을 의미합니다. 예를 들어 개념 아키텍처 에서 랜딩 존 관리 그룹에는 Corp 및 온라인 자식 관리 그룹이 있습니다. 이러한 자식 관리 그룹은 보유하고 있는 워크로드에 대한 고유한 원형 패턴에 맞춥니다. 자식 관리 그룹은 내부 전용 및 공용 애플리케이션 및 서비스와 같은 하이브리드 연결(VPN/Azure ExpressRoute) 요구 사항에 중점을 줍니다.

샌드박스 환경을 제외하면 다양한 애플리케이션 환경에서 배포에 동일한 원형을 사용해야 합니다. 환경이 여러 구독으로 나뉘어 있더라도 관리 그룹 원형 및 요구 사항에 따라 동일한 단일 관리 그룹(corp 또는 online) 내에 유지됩니다.

개인 랩과 같은 구조화되지 않은 개발 또는 원형이 없는 워크로드에 샌드박스 구독을 사용할 수 있습니다. 애플리케이션 또는 서비스 워크로드 팀은 샌드박스 관리 그룹을 사용하여 다양한 Azure 서비스를 테스트하여 요구 사항에 가장 적합한 항목을 결정합니다. 서비스를 결정한 후 팀에 대한 랜딩 존(랜딩 존 관리 그룹 계층 구조의 올바른 워크로드 아키타입 정렬 관리 그룹에서)을 프로비전할 수 있습니다.

샌드박스 환경은 특정 애플리케이션에 사용할 수 있으며 워크로드 팀은 이를 실험에 사용할 수 있습니다.

자세한 내용은 다음을 참조하세요.

환경 기반 관리 그룹 과제

아키타입 내의 환경에 대한 관리 그룹은 관리 오버헤드를 추가하고 최소한의 가치를 제공할 수 있습니다.

랜딩 존 관리 그룹에는 회사 및 온라인 자식 관리 그룹 모두에 대한 가드레일을 적용하는 범용 정책이 있어야 합니다. Corp 및 Online에는 퍼블릭 및 프라이빗 워크로드와 관련된 회사 지침을 적용하는 고유한 정책이 있습니다.

많은 조직에서 SDLC(소프트웨어 개발 수명 주기) 환경을 위한 별도의 관리 그룹을 만들어 환경 정책 및 제어를 할당합니다. 실제로 이 방법은 워크로드 팀이 해결하는 것보다 더 많은 과제를 만듭니다. SDLC 환경에는 다른 정책이 없어야 하므로 별도의 관리 그룹은 권장하지 않습니다.

애플리케이션 소유자는 승격된 여러 SDLC 환경의 정책에 맞게 워크로드의 토폴로지 또는 리소스 구성을 변경할 수 있습니다. 이 방법을 사용하면 위험이 증가합니다. 각 환경과 관련된 규칙은 개발자 및 품질 보증 팀의 개발 환경이 저하될 수 있습니다. 애플리케이션에 한 환경에서 작동하는 하나의 가드레일 정책 집합이 있고 애플리케이션이 승격 주기의 뒷부분에 다른 정책 집합에 노출되는 경우에도 문제가 발생할 수 있습니다. 컨트롤이 변경되면 애플리케이션을 조정해야 할 수 있습니다.

이 추가 작업을 방지하려면 SDLC 환경에서 코드를 승격하는 동안 일관된 정책을 만듭니다. 각 환경에 대한 정책을 만들지 말고 샌드박스 환경을 제외한 모든 개발 환경에 일관된 집합을 제공해야 합니다.

예를 들어 조직에서 공용 네트워크의 수신을 방지하기 위해 특정 방화벽 규칙을 사용하여 스토리지 계정을 구성해야 하는 정책을 정의한다고 상상해 보십시오. 대신 스토리지 계정은 통신을 위해 Azure 랜딩 존 네트워크 내부의 프라이빗 엔드포인트를 사용합니다. 개발 환경에 이러한 정책이 없는 경우 워크로드를 테스트해도 공용 액세스를 허용하는 스토리지 계정의 잘못된 구성을 찾을 수 없습니다. 테스트 배포는 개발 환경에서 작동하며 반복됩니다. 솔루션이 스토리지 계정 정책이 있는 다른 환경으로 승격되면 적용된 정책으로 인해 배포가 실패합니다.

따라서 애플리케이션 개발 팀은 이미 상당한 노력을 투자한 후 배포 및 아키텍처를 재작업해야 합니다. 이 예제에서는 다양한 환경의 다양한 정책으로 문제가 발생할 수 있는 방법을 보여 줍니다.

참고 항목

다음 수식은 각 환경 또는 워크로드에 대한 별도의 관리 그룹이 제대로 확장되지 않는 이유를 보여 줍니다. N 워크로드 x Z 관리 그룹 = 총 관리 그룹입니다.

조직에 각각 개발, 테스트 및 프로덕션 환경에 관리 그룹과 자식 관리 그룹이 필요한 워크로드가 30개 있는 경우 조직은 다음을 수행합니다.

N = 워크로드/앱 수 = 30

Z = 워크로드 및 환경에 대한 관리 그룹 수(워크로드의 경우 1개 + 환경의 경우 3개) = 4

N(30) x Z(4) = 총 관리 그룹 120개

애플리케이션 소유자는 여러 환경에 다르게 적용하는 정책이 필요할 수 있습니다. 예를 들어 애플리케이션 소유자는 프로덕션 환경에 대한 백업 구성이 필요하지만 다른 환경에는 백업 구성이 필요하지 않을 수 있습니다.

일부 정책은 관리 그룹 수준에서 감사 정책으로 사용할 수 있습니다. 애플리케이션 팀은 컨트롤을 구현하는 방법을 결정합니다. 이 메서드는 배포를 방지하지는 않지만 인식을 만들고 애플리케이션 팀이 고유한 요구 사항을 관리할 수 있도록 합니다. 그런 다음, 보안 정책을 만들거나 이러한 요구 사항을 IaC(Infrastructure as code) 배포 모듈에 통합할 수 있습니다.

이 공유 책임 모델에서 플랫폼 팀은 사례를 감사하고 애플리케이션 팀은 구현을 관리합니다. 이 모델은 배포의 민첩성을 향상시킬 수 있습니다.

플랫폼 운영자는 각 애플리케이션 또는 서비스 워크로드 팀(랜딩 존 소유자)과 협력하여 요구 사항을 이해해야 합니다. 플랫폼 운영자는 애플리케이션 요구 사항 및 계획에 따라 구독을 제공할 수 있습니다. 또한 플랫폼 운영자는 애플리케이션 또는 서비스 워크로드 팀의 일반적인 요구 사항에 따라 구독 생성 프로세스 및 도구를 빌드할 수 있도록 다양한 유형의 워크로드에 대한 제품 라인을 지정하기로 결정할 수도 있습니다.

시나리오: VM(가상 머신) 기반 워크로드

Azure 랜딩 존의 초기 워크로드는 종종 Azure VM으로 구성됩니다. 이러한 워크로드를 Azure에 배포하거나 기존 데이터 센터에서 마이그레이션할 수 있습니다.

단일 구독에서 여러 환경에 VM을 배포하는 대신 다음을 수행할 수 있습니다.

각 애플리케이션 환경에 대한 구독을 설정하고 모두 동일한 아키타입 관리 그룹에 배치합니다.
적절한 구독에서 각 애플리케이션 환경에 대한 가상 네트워크를 배포합니다. 애플리케이션 환경의 크기에 따라 가상 네트워크 크기를 확인할 수 있습니다.
적절한 구독에 VM을 배포합니다. VM은 적절한 경우 각 환경에 대해 서로 다른 SKU 및 다양한 가용성 구성을 사용할 수 있습니다.

다양한 애플리케이션 환경 리소스는 다양한 액세스 제어로 보호됩니다. 따라서 애플리케이션 개발자가 배포 파이프라인을 설정할 때 각 파이프라인의 ID는 환경으로 제한될 수 있습니다. 이 구성은 우발적인 배포로부터 환경을 보호하는 데 도움이 됩니다.

시나리오: Azure 앱 Service

App Service를 사용하는 환경 구독이 있는 워크로드는 문제를 일으킬 수 있습니다. 애플리케이션 개발자의 경우 App Service 모범 사례는 배포 슬롯을 사용하여 웹앱에 대한 변경 및 업데이트를 관리하는 것입니다.

그러나 이 기능은 단일 구독 내에서만 사용할 수 있는 App Service 계획에 있는 앱에서만 사용할 수 있습니다. 플랫폼 운영자가 애플리케이션 소유자가 개발, 테스트 및 프로덕션 환경에 별도의 구독을 사용하도록 요구하는 경우 애플리케이션 배포 수명 주기를 관리하기가 더 어려울 수 있습니다.

이 예제에서 가장 좋은 옵션은 애플리케이션 또는 서비스 워크로드에 대한 단일 구독입니다. 애플리케이션 소유자는 보안 강화를 위해 리소스 그룹 수준에서 PIM과 함께 Azure RBAC(역할 기반 액세스 제어)를 사용할 수 있습니다.

다음을 통해 공유