구독 자동 판매 구현 지침

Azure

이 문서에서는 구독 자동 판매 자동화에 대한 구현 지침을 제공합니다. 구독 자동 판매는 애플리케이션 팀이 워크로드를 더 빠르게 배포할 수 있도록 구독을 요청, 배포 및 관리하는 프로세스를 표준화합니다.

그림 1. 예제 Azure 환경의 구독 자동 판매 구현입니다.

GitHub 아이콘 시작점으로 사용해야 하는 구독 자동 판매 Bicep 및 Terraform 모듈을 만들었습니다. 구현 요구 사항에 맞게 템플릿을 수정해야 합니다. 구독 자동 판매 프로세스에 대한 자세한 내용은 구독 자동 판매 개요를 참조하세요.

아키텍처

세 가지 기본 작업을 수행하려면 구독 자동 판매 자동화를 설계해야 합니다. 구독 자동 판매 자동화는 (1) 구독 요청 데이터를 수집하고, (2) 플랫폼 자동화를 시작하고, (3) 코드로서의 인프라를 사용하여 구독을 만들어야 합니다. 이러한 세 가지 작업을 수행하기 위해 구독 자동 판매 자동화를 구현하는 방법에는 여러 가지가 있습니다. 예제 구현(그림 2)은 Gitflow를 사용하는 한 가지 방법을 보여 줍니다. Gitflow 디자인은 많은 플랫폼 팀이 플랫폼을 관리하는 데 사용하는 선언적 접근 방식과 일치합니다.

그림 2. 구독 자동 판매 자동화의 구현 예제입니다.

예제 구현(그림 2) 에서 데이터 수집 도구 는 구독 요청 데이터를 수집합니다. 구독 요청이 승인을 받으면 플랫폼 자동화를 시작합니다. 플랫폼 자동화는 요청 파이프라인, 소스 제어 및 배포 파이프라인으로 구성됩니다. 요청 파이프라인은 데이터 수집 도구의 데이터를 사용하여 JSON 또는 YAML 구독 매개 변수 파일을 만듭니다. 또한 요청 파이프라인은 새 분기를 만들고, 구독 매개 변수 파일을 커밋하고, 소스 제어에서 끌어오기 요청을 엽니다. 새 분기는 소스 제어의 주 분기와 병합됩니다. 병합은 배포 파이프라인을 트리거하여 코드로서의 인프라 모듈을 사용하여 구독을 만듭니다.

배포는 거버넌스 요구 사항에 따라 올바른 관리 그룹에 구독을 배치해야 합니다(그림 1 참조). 이 배포는 비용 관리의 기초로 예비 구독 예산을 만듭니다. 워크로드의 요구 사항에 따라 배포는 빈 가상 네트워크를 만들고 지역 허브에 대한 피어링을 구성할 수 있습니다. 플랫폼 팀은 생성 및 구성 후에 애플리케이션 팀에 구독을 전달해야 합니다. 애플리케이션 팀은 구독 예산을 업데이트하고 워크로드 리소스를 만들어야 합니다.

데이터 수집

데이터 수집의 목표는 비즈니스 승인을 받고 JSON/YAML 구독 매개 변수 파일의 값을 정의하는 것입니다. 애플리케이션 팀이 구독 요청을 제출할 때 데이터 수집 도구를 사용하여 필요한 데이터를 수집해야 합니다. 데이터 수집 도구는 플랫폼 자동화를 시작하기 위해 구독 자동 판매 워크플로의 다른 시스템과 인터페이스해야 합니다.

데이터 수집 도구를 사용합니다. ITSM(IT 서비스 관리) 도구를 사용하여 데이터를 수집하거나 Microsoft PowerApps와 같은 코드가 낮은 도구 또는 코드 없는 도구를 사용하여 고객 포털을 빌드할 수 있습니다. 데이터 수집 도구는 구독 요청을 승인하거나 거부하는 비즈니스 논리를 제공해야 합니다.

필요한 데이터를 수집합니다. 배포를 자동화할 수 있도록 JSON/YAML 구독 매개 변수의 값을 정의하기에 충분한 데이터를 수집해야 합니다. 수집하는 특정 값은 요구 사항에 따라 달라집니다. 요청 권한 부여자, 비용 센터 및 네트워킹 요구 사항(인터넷 또는 온-프레미스 연결)을 캡처해야 합니다. 애플리케이션 팀에 예상 워크로드 구성 요소(애플리케이션 플랫폼, 데이터 요구 사항), 데이터 민감도 및 환경 수(개발, 테스트, 사전 프로덕션, 프로덕션)를 요청하는 것이 유용할 수 있습니다.

데이터의 유효성을 검사합니다. 데이터 수집 프로세스 중에 데이터의 유효성을 검사해야 합니다. 플랫폼 자동화 단계의 뒷부분에서 문제를 해결하기가 더 어렵습니다.

추적 가능한 요청을 만듭니다. 데이터 수집 도구는 새 구독에 대해 기록되고 추적 가능한 요청을 만들어야 합니다(예: ITSM 도구의 티켓). 요청에는 해당 구독의 요구 사항을 충족하는 데 필요한 모든 데이터가 포함되어야 합니다. 비즈니스 논리 및 권한 부여 추적을 요청에 바인딩해야 합니다.

다른 내부 시스템과의 인터페이스입니다. 필요한 경우 데이터 수집 도구는 조직의 다른 도구 또는 시스템과 상호 작용해야 합니다. 목표는 다른 시스템의 데이터로 요청을 보강하는 것입니다. 자동화를 실행하려면 ID, 재무, 보안 및 네트워킹 데이터가 필요할 수 있습니다. 예를 들어 자동화는 IPAM(IP 주소 관리) 도구와 인터페이스하여 올바른 IP 주소 공간을 예약할 수 있습니다.

트리거를 만듭니다. 구독 요청이 승인을 받으면 데이터 전송이 플랫폼 자동화를 트리거해야 합니다. 데이터 수집 도구에서 필요한 데이터를 사용하여 푸시 알림을 만드는 것이 가장 좋습니다. 프로세스를 시작하려면 Azure Functions 또는 Azure Logic Apps와 같은 미들웨어 계층이 필요할 수 있습니다.

플랫폼 자동화 시작

데이터 수집 도구의 알림 및 데이터는 플랫폼 자동화를 트리거해야 합니다. 플랫폼 자동화의 목표는 JSON/YAML 구독 매개 변수 파일을 만들고, 파일을 주 분기에 병합하고, 코드 기반 인프라 모듈과 함께 배포하여 구독을 만드는 것입니다. 플랫폼 팀은 플랫폼 자동화를 소유하고 유지 관리해야 합니다. 예제 구현의 플랫폼 자동화는 요청 파이프라인, 소스 제어 및 배포 파이프라인으로 구성됩니다(그림 2 참조).

JSON 또는 YAML 파일을 사용합니다. 정형 데이터 파일(JSON 또는 YAML)을 사용하여 구독을 만들 데이터를 저장해야 합니다. 파일의 구조를 문서화하고 향후 요구 사항을 지원하기 위해 확장할 수 있도록 해야 합니다. 예를 들어 다음 JSON 코드 조각은 GitHub의 Bicep 모듈 중 하나에 대한 구독 매개 변수 값을 정의합니다.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "subscriptionDisplayName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionAliasName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionBillingScope": {
      "value": "providers/Microsoft.Billing/billingAccounts/1234567/enrollmentAccounts/123456"
    },
    // Insert more parameters here
  }
}

전체 파일을 참조하세요. 자세한 예제는 Bicep 예제 및 Terraform 예제를 참조하세요.

구독 요청당 하나의 파일을 사용합니다. 구독은 구독 자동 판매 프로세스의 배포 단위이므로 각 구독 요청에는 하나의 전용 구독 매개 변수 파일이 있어야 합니다.

끌어오기 요청 시스템을 사용합니다. 구독 매개 변수 파일을 만드는 Gitflow 프로세스는 다음 단계를 자동화해야 합니다.

각 구독 요청에 대한 새 분기를 만듭니다.
수집된 데이터를 사용하여 분기의 새 구독에 대한 단일 YAML/JSON 구독 매개 변수 파일을 만듭니다.
분기에서 .로 끌어오기 요청을 만듭니다 main.
이 끌어오기 요청에 대한 상태 변경 및 참조로 데이터 수집 도구를 업데이트합니다.

예제 구현의 요청 파이프라인은 이러한 단계를 실행합니다(그림 2 참조). 워크플로가 복잡한 경우 Azure에서 호스트되는 코드 기반 솔루션을 사용할 수도 있습니다.

구독 매개 변수 파일의 유효성을 검사합니다. 끌어오기 요청은 요청 데이터의 유효성을 검사하는 Linting 프로세스를 트리거해야 합니다. 목표는 배포가 성공하도록 하는 것입니다. YAML/JSON 구독 매개 변수 파일의 유효성을 검사해야 합니다. IP 주소 범위를 계속 사용할 수 있는지 확인할 수도 있습니다. 또한 사람의 개입으로 수동 검토 게이트를 추가할 수도 있습니다. 최종 검토를 수행하고 구독 매개 변수 파일을 변경할 수 있습니다. 출력은 구독을 만들 모든 데이터가 포함된 JSON/YAML 구독 매개 변수 파일이어야 합니다.

배포 파이프라인을 트리거합니다. 끌어오기 요청이 분기에 병합 main 되면 병합은 배포 파이프라인을 트리거해야 합니다.

구독 만들기

구독 자동 판매 자동화의 마지막 작업은 새 구독을 만들고 구성하는 것입니다. 예제 구현에서는 배포 파이프라인을 사용하여 JSON/YAML 구독 매개 변수 파일을 사용하여 코드로서의 인프라 모듈을 배포합니다(그림 2 참조).

인프라를 코드로 사용합니다. 배포에서는 인프라를 코드로 사용하여 구독을 만들어야 합니다. 플랫폼 팀은 적절한 거버넌스를 보장하기 위해 이러한 템플릿을 만들고 유지 관리해야 합니다. 구독 자동 판매 Bicep 및 Terraform 모듈을 사용하고 구현 요구 사항에 맞게 수정해야 합니다.

배포 파이프라인을 사용합니다. 배포 파이프라인은 새 구독의 생성 및 구성을 오케스트레이션합니다. 파이프라인은 다음 작업을 실행해야 합니다.

작업 범주	파이프라인 작업
ID	• 구독 소유권을 나타내기 위해 Microsoft Entra 리소스를 만들거나 업데이트합니다. • 워크로드 팀 배포에 대한 권한 있는 워크로드 ID를 구성합니다.
거버넌스	• 관리 그룹 계층 구조에 배치합니다. • 구독 소유자를 할당합니다. • 구성된 보안 그룹에 대한 구독 수준 RBAC(역할 기반 액세스 제어)를 구성합니다. • 구독 수준 Azure Policy를 할당합니다. • 클라우드용 Microsoft Defender 등록을 구성합니다.
네트워킹	• 가상 네트워크를 배포합니다. • 플랫폼 리소스(지역 허브)에 대한 가상 네트워크 피어링을 구성합니다.
Budgets	• 수집된 데이터를 사용하여 구독 소유자를 위한 예산을 만듭니다.
보고	• IPAM과 같은 외부 시스템을 업데이트하여 IP 예약에 커밋합니다. • 최종 구독 이름 및 GUID(Globally Unique Identifier)로 데이터 수집 도구 요청을 업데이트합니다. • 구독이 준비되었음을 애플리케이션 팀에 알립니다.

프로그래밍 방식으로 구독을 만들려면 상업적 계약이 필요합니다. 상용 계약이 없는 경우 구독을 만드는 수동 프로세스를 도입해야 하지만 구독 구성의 다른 모든 측면을 자동화할 수 있습니다.

워크로드 ID를 설정합니다. 배포 파이프라인은 인터페이스하는 모든 시스템에서 이러한 작업을 수행할 수 있는 권한이 필요합니다. 관리 ID 또는 OIDC(OpenID Connect)를 사용하여 Azure에 인증해야 합니다.

배포 후

구독 자동 판매 자동화는 구독 만들기 및 구성으로 끝납니다. 플랫폼 팀은 만든 후 새 구독을 애플리케이션 팀에 전달해야 합니다. 애플리케이션 팀은 구독 예산을 업데이트하고, 워크로드 리소스를 만들고, 워크로드를 배포해야 합니다. 플랫폼 팀은 구독의 거버넌스를 제어하고 시간이 지남에 따라 구독 거버넌스에 대한 변경 내용을 관리합니다.

비용 관리를 적용합니다. 구독 예산은 비용 관리에 중요한 알림을 제공합니다. 배포는 구독 요청 데이터를 기반으로 예비 구독 예산을 만들어야 합니다. 애플리케이션 팀은 구독을 받습니다. 워크로드의 요구 사항을 충족하도록 예산을 업데이트해야 합니다. 자세한 내용은 다음을 참조하세요.

구독 거버넌스를 관리합니다. 워크로드의 거버넌스 요구 사항이 변경되면 구독을 업데이트해야 합니다. 예를 들어 구독을 다른 관리 그룹으로 이동해야 할 수 있습니다. 이러한 일상적인 작업 중 일부에 대한 자동화를 빌드해야 합니다. 자세한 내용은 다음을 참조하세요.

다음 단계

구독 자동 판매는 구독 만들기 프로세스를 간소화하고 표준화하여 조직의 거버넌스 아래에 배치합니다. 애플리케이션 팀이 애플리케이션 랜딩 존에 더 빠르게 액세스하고 워크로드를 더 빠르게 온보딩할 수 있도록 구독 자동 판매 자동화를 구현해야 합니다. 자세한 내용은 다음을 참조하세요.

다음을 통해 공유