구독 자동 판매
구독 자동 판매는 워크로드를 배포해야 하는 애플리케이션 팀에 프로그래밍 방식으로 구독을 발급하기 위한 플랫폼 메커니즘을 제공합니다. 다음 다이어그램은 플랫폼 및 워크로드 수명 주기에서 구독 자동 판매 적합한 위치를 보여 줍니다.
구독 자동 판매는 구독 민주화 개념을 기반으로 하여 애플리케이션 랜딩 존에 적용합니다. 구독 민주화를 사용하면 리소스 그룹이 아닌 구독이 워크로드 관리 및 규모에 대한 기본 단위입니다. 자세한 내용은 다음을 참조하세요.
왜 구독 자동 판매?
구독 자동 판매는 Azure에서 워크로드를 배포해야 하는 조직에 몇 가지 이점을 제공합니다. 애플리케이션 랜딩 존에 대한 구독을 요청, 배포 및 제어하는 프로세스를 표준화하고 자동화합니다. 구독 자동 판매는 구독 만들기 프로세스를 간소화하고 조직의 거버넌스 아래에 배치하므로 앱 팀은 더 큰 신뢰와 효율성으로 워크로드를 배포하는 데 집중할 수 있습니다.
- 간소화된 프로세스: 구독 자동 판매는 애플리케이션 팀이 구독을 요청할 수 있는 공식 프런트 도어를 제공하여 자체 구독 프로세스를 탐색할 필요가 없습니다.
- 향상된 속도: 애플리케이션 팀은 애플리케이션 랜딩 존에 더 빠르게 액세스하고 워크로드를 더 빠르게 온보딩할 수 있습니다.
- 효율적인 거버넌스: 플랫폼 팀은 최소한의 오버헤드로 애플리케이션 랜딩 존에 거버넌스를 적용할 수 있습니다.
구독 자동 판매 구현하는 방법
구독 자동 판매는 세 개의 팀을 포함합니다. CCoE(Cloud Center of Excellence)는 비즈니스 논리와 승인 프로세스를 설정합니다. 준비가 되면 애플리케이션 팀은 구독 요청을 합니다. 플랫폼 팀은 애플리케이션 팀에 구독을 전달하기 전에 요청을 사용하여 구독을 만들고 구성합니다. 애플리케이션 팀은 예산을 업데이트하고 워크로드를 배포하며 작업을 설정합니다. 다음 지침에서는 구독 자동 판매 프로세스의 각 단계에 대한 자세한 내용을 제공합니다. 자세한 내용은 구독 자동 판매기 구현 지침을 참조 하세요.
플랫폼 팀은 애플리케이션 팀에 많은 옵션 및 구독 유형을 추가할 수 있습니다. 이러한 형식은 플랫폼 엔지니어링 원칙 및 관행과 관련이 있기 때문에 제품 라인이라고 합니다. 요구 사항에 가장 적합한 옵션을 선택하는 방법에 대한 자세한 내용은 Common 구독 자동 판매 제품 라인을 참조하세요.
비즈니스 논리 및 승인 프로세스 설정
구독 자동 판매 모델을 구현하려면 필수 구독 정보를 수집하는 승인 프로세스를 설정해야 합니다. CCoE(Cloud Center of Excellence)는 승인 프로세스를 프로그래밍하고 수집할 정보에 대한 비즈니스 규칙을 설정해야 합니다.
프로세스를 자동화합니다. 더 빠른 프로비전 및 향상된 규정 준수를 위해 구독 요청 캡처 및 승인 프로세스를 자동화해야 합니다.
기존 도구와 통합합니다. 구독 자동 판매 승인 프로세스를 기존 ITSM(IT 서비스 관리) 도구에 통합해야 합니다. 통합은 승인 프로세스를 간소화하고, 수동 작업을 줄이며, 오류를 줄이면서 효율성을 향상시킬 수 있습니다. 또한 시간이 지남에 따라 유지 관리를 더 쉽게 하고 감사에 대한 규정 준수 보고를 지원합니다.
배포 파이프라인에 연결합니다. 승인 프로세스의 비즈니스 논리를 플랫폼 팀이 관리하는 구독 배포 파이프라인에 연결하는 것이 가장 좋습니다. Azure Pipelines 또는 GitHub Actions 워크플로는 구독 배포 파이프라인에 대한 일반적인 솔루션입니다.
섭취 시 요구 사항을 수집합니다. 비즈니스 논리는 애플리케이션 팀이 구독을 요청하고 구독 요구 사항을 제공할 수 있도록 허용해야 합니다. 이러한 요구 사항에는 예상 예산, 구독 소유자, 네트워킹 기대치 및 비즈니스 중요도 및 기밀성 분류가 포함되어야 합니다. 프로세스를 시작할 때 이 정보를 수집하면 배포 매개 변수 및 관련자 승인 요구 사항을 알 수 있습니다. 또한 섭취 프로세스는 플랫폼 팀에게 관리 그룹 계층 구조에 워크로드를 배치할 수 있는 충분한 정보를 제공해야 합니다.
승인 프로세스가 시작되면 애플리케이션 팀이 구독 요청을 시작할 수 있습니다.
구독 요청 만들기
구독 자동 판매는 애플리케이션 팀이 구독을 요청하는 표준 프로세스를 제공합니다. 구독 자동 판매 가용성을 사교화하고 구독 요청을 쉽게 수행할 수 있도록 하는 것이 중요합니다. 애플리케이션 팀이 구독 요청을 제출한 후 플랫폼 팀은 프로세스를 제어하는 것으로 가정합니다. 플랫폼 팀은 구독을 만들고 애플리케이션 팀에 구독을 제공할 때까지 제어권을 유지 관리합니다.
네트워킹 구성
구독 자동화는 필요한 네트워킹 구성 요소를 설정해야 하며 각 애플리케이션 팀의 요구 사항을 충족할 수 있을 만큼 유연해야 합니다. 일반적인 지침으로 단일 라우팅 도메인에서 겹치는 IP 주소를 사용하지 마세요. 크기 요구 사항이 변경되면 가동 중지 시간 없이 가상 네트워크의 주소 공간을 추가하거나 삭제할 수 있습니다. 자세한 내용은 다음을 참조하세요.
IPAM(IP 주소 관리) 도구를 사용합니다. IP 주소 할당을 간소화하려면 IPAM 시스템을 사용하여 자동 판매 프로세스에 통합해야 합니다. 자세한 내용 및 IPAM 지침은 IPAM(IP 주소 관리) 도구를 참조하세요.
앱 팀의 자율성을 부여합니다. 구독에서 서브넷 및 일부 가상 네트워크를 만들 수 있는 권한을 애플리케이션 팀에 부여해야 합니다. 플랫폼 팀은 항상 중앙 허브에 피어링하는 가상 네트워크를 만들어야 합니다.
네트워킹 거버넌스를 적용합니다. 플랫폼 팀은 (1) 관리 그룹 계층 구조에 할당된 Azure 정책 또는 (2) Azure Virtual Network Manager 및 보안 관리자 규칙을 통해 가상 네트워크 거버넌스를 적용해야 합니다. 자세한 내용은 정책 기반 거버넌스 및 위험 수준이 높은 포트를 차단하는 방법을 참조하세요.
구독 배치 확인
플랫폼 팀은 네트워킹 및 거버넌스 요구 사항을 사용하여 관리 그룹 계층 구조에 구독을 배치해야 합니다. 또한 구독을 만들기 전에 구독 할당량 제한을 검토해야 합니다. 자세한 내용은 요구 사항을 충족하도록 Azure 랜딩 존 아키텍처 조정을 참조 하세요.
올바른 관리 그룹을 식별합니다. 관리 그룹은 구독 및 워크로드 배포를 구성하고 관리하는 데 도움이 됩니다. 각 워크로드의 분류 및 요구 사항에 필요한 정책을 적용하는 관리 그룹을 찾거나 만듭니다.
유연한 자동화를 빌드합니다. 자동화는 (1) 여러 구독을 배포하고 (2) 구독 서비스 제한에 맞게 조정할 수 있을 만큼 유연해야 합니다.
여러 구독: 일부 워크로드에는 여러 구독이 필요합니다. 예를 들어 일부 워크로드에는 구독으로 구분된 여러 인스턴스가 있습니다. 또는 고객당 전용 리소스를 사용하는 SaaS 아키텍처는 종종 수십 개의 구독을 사용합니다.
구독 서비스 제한: 수천 개의 구독이 있는 엔터프라이즈에는 제한을 피하기 위해 이전 구독에 배포하거나 구독의 워크로드를 공동 배치할 수 있는 자동화가 있어야 합니다. 자세한 내용은 Azure 랜딩 존 FAQ를 참조 하세요.
프로비전 후 Azure Portal을 사용하여 할당량 증가를 수동으로 요청할 수 있습니다. 사용 가능한 API를 사용하여 이 프로세스를 자동화하는 것이 더 쉽습니다. 그러나 할당량 요청이 실패할 수 있으므로 오류를 처리하는 스크립트를 실행해야 합니다. 자세한 내용은 Microsoft.Capacity, Microsoft.Quota 및 Microsoft.Support를 참조하세요.
구독 만들기 및 구성
이제 요청된 구독을 만들고 구성할 수 있습니다. 목표는 반복 가능하고 일관된 프로세스를 만드는 것입니다. 가능한 한 많은 구독 만들기 및 구성 프로세스를 자동화합니다.
IaC(Infrastructure as Code)를 사용합니다. 구독 자동 판매 일반적인 전략은 IaC를 사용하여 프로그래밍 방식으로 구독을 만들고 구성하는 것입니다. Azure 구독을 프로그래밍 방식으로 만들려면 상업적 계약이 필요하지만 상용 계약 없이 구독 구성의 모든 측면을 자동화할 수 있습니다. 자세한 내용은 다음을 참조하세요.
Bicep 및 Terraform 모듈을 구독 자동 판매 상용 계약의 등록과 관계없이 구독 자동 판매 모델을 채택하는 데 도움이 되는 예제가 있습니다. GitHub 작업 또는 Azure Pipelines를 사용하여 자동화를 오케스트레이션해야 합니다.
비용 관리에 태그를 사용합니다. Microsoft Cost Management에서 비용 관리 및 보고 목적으로 각 구독에 대한 태그의 일관된 할당을 자동화해야 합니다. 상용 계약으로 청구 보고서를 받지만 Cost Management는 더 큰 기능을 제공합니다. 예를 들어 특정 태그를 사용하여 구독에 대한 보고서를 만들 수 있습니다. 자세한 내용은 비용 및 사용량 데이터에서 태그를 사용하고 태그 상속을 사용하여 비용을 그룹화하고 비용을 할당하는 방법을 참조하세요.
프로덕션 및 비프로덕션 구독을 사용합니다. 새 구독에 대한 요청에서 워크로드가 프로덕션용인지 DevTest인지 지정해야 합니다. DevTest 환경에서는 리소스 요금이 낮아지지만 다른 용어가 있습니다. DevTest 제품은 MPA에 사용할 수 없습니다. 자세한 내용은 다음을 참조하세요.
ID 및 RBAC(역할 기반 액세스 제어)를 설정합니다. Azure 구독 내에서 리소스에 대한 액세스를 관리하는 것은 안전하고 규정을 준수하는 환경을 유지하는 데 중요합니다. 액세스를 제어하려면 ID 및 RBAC를 설정해야 합니다. 이 설정에는 구독 소유자를 지정하고, 액세스를 관리할 Microsoft Entra 그룹을 만들고, 워크로드를 배포하는 자동화 계정을 설정하는 작업이 포함됩니다.
구독 소유자를 지정합니다. 구독 자동 판매 자동화는 만들 때 구독 소유자를 지정해야 합니다. 구독 요청은 이 정보를 수집할 때 캡처해야 합니다. 구독 소유자는 선택한 구독 디렉터리의 사용자 또는 서비스 주체만 될 수 있습니다. 게스트 디렉터리 사용자는 선택할 수 없습니다. 서비스 주체를 선택하는 경우 해당 앱 ID를 입력합니다.
Microsoft Entra 그룹을 만듭니다. 구독 소유자 외에도 자동 판매 프로세스에서 Microsoft Entra 그룹 구조를 사용하여 구독에 대한 액세스를 관리해야 합니다. 상승된(예: 쓰기) 액세스의 경우 그룹에 PIM을 사용하는 것이 좋습니다. 이 만들기 프로세스를 자동화하는 것은 구독 소유자 수를 제한하고 필요한 최소 액세스 수준을 사용하는 것과 같은 모범 사례를 위반해서는 안 됩니다.
워크로드 ID를 설정합니다. 워크로드 배포에 사용되는 워크로드 ID(서비스 원칙)에는 구독 범위에서 상승된 권한이 있는 경우가 많습니다. 구독 요청 프로세스는 워크로드 ID 요구 사항을 수집해야 합니다. 자동 판매 프로세스는 이러한 ID를 만들고 적절한 구독 액세스를 할당해야 합니다. 워크로드 ID는 PIM을 사용할 수 없으며 리소스에 대한 상시 액세스를 수신한다는 점에 유의해야 합니다. 비밀을 관리할 필요가 없도록 관리 ID를 사용하는 것이 좋습니다. 자세한 내용은 ID 디자인 영역을 참조 하세요.
애플리케이션 팀에 전달합니다. 플랫폼 팀이 구독을 만든 후 애플리케이션 팀에 구독을 전달해야 합니다.
구독 예산 업데이트
플랫폼 및 워크로드 팀은 구독의 재무 상태에 대한 책임을 공유합니다. 배포는 구독 요청의 정보를 기반으로 구독 예산을 만들어야 합니다. 애플리케이션은 구독을 받을 때 요구 사항에 맞게 예산을 업데이트해야 합니다. 예산은 현재 및 예측 사용량에 대한 지출을 감사하는 데 유용하지만 어려운 제한은 아닙니다. 워크로드가 예산 임계값을 초과할 경우 구독 소유자에게 알리기 위해 예산 경고를 만들어야 합니다. API Management와 같은 공유 서비스의 경우 Azure 비용 할당 규칙을 사용하여 소비하는 구독 간에 비용을 재배포하는 것이 좋습니다.
워크로드 배포 및 운영
애플리케이션 팀은 워크로드에 필요한 리소스를 만들고 작업을 관리할 수 있는 자율성을 가져야 합니다. 플랫폼 팀은 구독 거버넌스를 담당합니다. 워크로드의 거버넌스 요구 사항이 변경됨에 따라 플랫폼 팀은 워크로드 요구 사항을 가장 잘 충족하는 관리 그룹으로 구독을 이동해야 합니다. Bicep 또는 Terraform을 사용하여 이동을 자동화할 수 있습니다. 자세한 내용은 다음을 참조하세요.
다음 단계
애플리케이션 팀에 자동 판매할 수 있는 구독 또는 제품 라인을 검토합니다. 다양한 시나리오를 충족할 수 있도록 훌륭한 시작점을 설정합니다.