728x90

🔍 개요

Azure OpenAI 서비스와 API Management를 함께 사용하면 프롬프트와 응답에 대한 상세한 로깅과 모니터링이 가능합니다.
2025년 5월 업데이트로 스트리밍 지원을 포함한 포괄적인 LLM 로깅 기능이 가능하게 되었습니다.

📖 참고: Azure API Management에서 Azure OpenAI에 대한 LLM 로깅 지원 - 5월 업데이트

가이드 범위 및 목표

본 가이드에서는 프롬프트와 응답에 대한 로깅에 초점을 맞춰 작성되었습니다.

API Management를 이용한 고급 정책 설정, 캐싱 전략, 멀티 리전 배포 등의 추가 기능은 추후 다뤄볼 예정입니다.

1. 아키텍처 구성

기본 아키텍처

2. 시나리오 전체 흐름

이 가이드에서 구현할 전체 과정을 미리 확인하여 체계적으로 작업을 진행하겠습니다.

작업 전 참고사항

 

각 단계는 순차적으로 진행되며, 이전 단계가 완료되어야 다음 단계로 진행할 수 있습니다. 예상 소요 시간은 약 45-60분입니다.

 

사전 준비사항

 

  • Azure 구독 및 소유자 권한
  • Azure CLI
  • Python 3.11+
구현 단계별 가이드
Copy
📋 1단계: Azure OpenAI 리소스 및 모델 배포 (10분)
   - OpenAI 서비스 생성
   - GPT 모델 배포 (예: gpt-4o-deployment)
 
📋 2단계: API Management 서비스 생성 (15분)
   - APIM 인스턴스 구성
   - Azure OpenAI API 템플릿으로 API 생성
 
📋 3단계: Managed Identity 권한 설정 확인 (5분)
   - 시스템 할당 관리 ID 확인
   - Azure OpenAI 리소스 IAM 역할 부여 확인
 
📋 4단계: LLM 로깅 활성화 (20분: Log Analytics 초기 테이블 생성 시간 필요)
   - 진단 설정으로 Log Analytics 연결
   - API별 LLM 로깅 활성화
 
📋 5단계: 연결 및 기능 테스트 (5분)
   - 테스트 기능으로 APIM ↔ OpenAI 연결 확인
   - Log Analytics에서 로그 생성 확인
 
📋 6단계: 외부 애플리케이션 테스트 (10분)
   - Python 클라이언트로 APIM 경유 호출
   - 토큰 사용량 및 로그 추적 분석
 
📋 7단계: 보안 정책 검증 (10분)
   - IP 제한 정책 구현 및 테스트
   - 차단 로그 분석 및 검증

3. Azure OpenAI 리소스 생성

리소스 생성

  • 리소스 그룹은 기존 리소스 그룹을 사용하거나 신규로 생성해도 무방합니다.
  • Azure OpenAI는 한국에서 가까운 "japaneast"로 생성
    최근 Korea Central도 지원되니 원하는 모델과 배포 유형의 지역 지원 여부를 확인하세요
Azure PortalAzure CLI
Copy
1. Azure Portal에서 '리소스 만들기' 선택
2. 'Azure OpenAI' 검색 후 선택
3. 기본 설정:
   - 구독: 본인의 구독 선택
   - 리소스 그룹: 새로 만들거나 기존 선택
   - 지역: East US, West Europe 등 OpenAI 지원 지역
   - 이름: 고유한 리소스 이름 (예: myopenai-resource)
   - 가격 책정 계층: Standard (S0)
4. '검토 + 만들기' → '만들기'

모델 배포

  • Azure OpenAI 리소스가 생성되면 사용할 모델을 배포해야 합니다.
Azure PortalAzure CLI
Copy
1. 생성된 Azure OpenAI 리소스로 이동
2. 상단에 'Go to Azure AI Foundry portal' 클릭
3. 왼쪽 블레이드 메뉴에서 '배포' - ' + 모델 배포' 클릭
4. 모델 설정:
   - 모델: gpt-4o
   - 모델 버전: 최신 버전 (예: 2024-11-20)
   - 배포 이름: gpt-4o-deployment (기억하기 쉬운 이름)
   - 배포 유형: 표준
5. '만들기' 클릭
배포 유형 선택 가이드
  • Standard: 일반적인 용도, 예측 가능한 워크로드
  • GlobalStandard: 글로벌 배포, 높은 가용성 필요시
  • ProvisionedManaged: 대용량 처리, 일정한 성능 보장 필요시

4. API Management 리소스 생성

리소스 생성

Azure PortalAzure CLI
Copy
1. Azure Portal에서 '리소스 만들기' 선택
2. 'API Management' 검색 후 선택
3. 기본 설정:
   - 구독: 본인의 구독 선택
   - 리소스 그룹: 새로 만들거나 기존 선택
   - 지역: Korea Central
   - 조직 이름: 회사명 입력
   - 관리자 이메일: 본인 이메일
   - 가격 책정 계층: Developer (개발/테스트용)
4. '검토 + 만들기' → '만들기'

⏱️ 배포 시간: 약 30분 소요
운영 환경 SKU 선택

Developer SKU는 개발/테스트 전용입니다. 운영 환경에서는 SLA가 보장되는 Basic 이상의 SKU를 사용하세요.

📖 SKU 상세 비교: Azure API Management v2 service tiers overview

5. Azure OpenAI와 API Management 연결

템플릿을 활용하여 Azure OpenAI API 생성

API Management에서 Azure OpenAI API를 생성하는 방식은 2가지가 있습니다:

  1. OpenAPI 사양 직접 가져오기: 복잡하고 수동 설정 필요
  2. Azure OpenAI 템플릿 사용: 자동 설정으로 구성이 간단

본 가이드에서는 구성이 비교적 간단한 템플릿 방식으로 진행합니다.

Portal에서 Azure OpenAI API 생성
Copy
1. API Management 인스턴스 → 'APIs' 메뉴 선택
2. '+ Add API' 클릭
3. **'Azure OpenAI'** 템플릿 선택 (Microsoft에서 제공하는 공식 템플릿)

1단계: API 템플릿 선택

2단계: OpenAI 인스턴스 및 설정 구성

3단계: 기본 설정 확인 후 생성

템플릿 사용의 장점

Azure OpenAI 템플릿을 사용하면 자동으로 Managed Identity 인증이 구성되고, 모든 필요한 엔드포인트와 파라미터가 정확하게 설정됩니다.

Managed Identity 권한 설정 및 IAM 확인

Azure OpenAI API 템플릿을 사용하면 자동으로 시스템 할당 관리 ID가 생성되고 권한이 설정됩니다. 이를 확인해보겠습니다.

1. API Management의 관리ID 활성화 상태 확인

2. Backend 권한 방식 확인

3. Azure OpenAI IAM 확인

Azure OpenAI 리소스 권한 확인
Copy
1. Azure OpenAI 리소스 → 'Access control (IAM)' 메뉴
2. 'Role assignments' 탭 확인
3. API Management의 Managed Identity가 다음 역할을 가지고 있는지 확인:
   - **Cognitive Services OpenAI User** 

권한 누락 시 수동 설정

만약 권한이 자동으로 설정되지 않았다면, Azure OpenAI 리소스에서 수동으로 API Management의 Managed Identity에 Cognitive Services OpenAI User 역할을 할당하세요.

인증 구조 이해

위에서 확인한 Managed Identity와 권한 설정은 APIM과 Azure OpenAI 간의 자동 인증을 위한 것입니다.
실제 클라이언트와의 통신 구조는 아래와 같습니다.

중앙 관리의 장점

클라이언트는 Azure OpenAI의 실제 API 키를 알 필요가 없고, APIM 구독키만 사용합니다.
모든 Azure OpenAI 접근은 APIM에서 중앙 관리되며, 키 로테이션, 사용량 모니터링, 정책 적용이 한 곳에서 처리됩니다.

6. LLM 로깅 활성화

진단 설정 구성

먼저 API Management 전체 레벨에서 진단 로그를 Log Analytics Workspace로 전송하도록 설정합니다.

진단 설정 구성
Copy
1. API Management 인스턴스 → '모니터링' → '진단 설정'
2. '+ 진단 설정 추가' 클릭
3. 설정 구성:
   - 진단 설정 이름: openai-logging
   - 로그 섹션에서 다음 선택:
     ☑️ Logs related to ApiManagement Gateway
     ☑️ Logs related to Websocket Connections  
     ☑️ **Logs related to generative AI gateway** (가장 중요!)
   - 대상 세부 정보:
     ☑️ Log Analytics 작업 영역에 보내기
     - 구독: 본인 구독
     - Log Analytics workspace: 새로 만들기 또는 기존 선택
     - Destination table: **리소스별** 선택
4. 'Save' 클릭

로그 생성 대기시간

진단 설정 완료 후 ApiManagementGatewayLlmLogs 테이블이 생성되고 로그가 적재되기까지 15-20분 정도 소요될 수 있습니다.

비용 관련 주의사항

Log Analytics Workspace는 데이터 수집량과 보존 기간에 따라 비용이 발생합니다.

  • Pay-as-you-go: GB당 $2.76 (변동 가능성 있음)
  • 기본 보존 기간: 30일 (추가 보존 시 별도 요금)
  • OpenAI 로그 특성: API 호출량이 많을 경우 상당한 로그 생성

권장 사항:

  • 테스트/개발 환경에서는 짧은 보존 기간 설정 (7일)
  • 프로덕션에서는 필수 로그만 수집 고려
  • 일일 사용량 제한 설정으로 예상치 못한 요금 발생 방지 (Log Analytics Workspace → '사용량 및 예상 비용' → '일일 상한')
  • 정확한 가격은 Azure 가격 계산기로 확인

API 설정에서 LLM 로그 활성화

먼저 생성한 Azure OpenAI API에서 LLM 로깅을 활성화해야 합니다.

API별 LLM 로깅 활성화
Copy
1. API Management → 'APIs' → 생성한 'Azure OpenAI Service' 선택
2. 'Settings' 탭 클릭
3. 'Diagnostics Logs' - 'Azure Monitor' 섹션에서:
   - Override global: ✅ 체크
   - Log LLM Message: ✅ 체크 (중요!)
4. 'Save' 클릭
 
⚠️ 주의사항:
진단 설정 직후에는 'Override global' 활성화 옵션이 보이지 않을 수 있습니다.
이 경우 약 10~15분 정도 기다린 후 페이지를 새로고침하여 다시 확인하세요.

LLM 로깅 추가 정보

새로운 기능: 2025년 5월 업데이트가 된 LLM 로깅 기능은 스트리밍 시나리오를 포함하여 최대 2MB까지의 프롬프트와 응답을 32KB 청크 단위로 로깅할 수 있습니다.

참고 문서: API 로깅 설정에 대한 더 자세한 내용은 Microsoft 공식 문서를 참고하세요
 API Management 모니터링 - API 로깅 설정 수정

7. 연결 테스트 및 로그 확인

APIM 기본 테스트

API Management Portal에서 제공하는 테스트 기능을 사용하여 Azure OpenAI와의 연결을 확인합니다.

테스트 진행
Copy
1. API Management → 'APIs' → 위에서 생성한 'Azure OpenAI Service' 선택
2. 'Test' 탭 클릭
3. 'Creates a completion for the chat message' 선택
4. 필수 파라미터 입력:
   - deployment-id: 배포한 모델명 (예: gpt-4o-deployment)
   - api-version: 2025-01-01-preview
5. Request body 예제:
   {
     "messages": [
       {"role": "user", "content": "안녕하세요, 테스트입니다."}
     ],
     "max_tokens": 100
   }
6. 'Send' 클릭

테스트 완료 화면

배포 모델명 확인 방법

만약 deployment-id와 api-version을 모를 경우 Azure OpenAI 배포모델 메뉴에서 확인하시면 됩니다.

Log Analytics 로그 확인

API Management 진단 로그를 저장한 Log Analytics에서 ApiManagementGatewayLlmLog 테이블 선택 후 실행

프롬프트/응답 메시지 확인

로그 확인 시 주의사항
  • 최초 로그가 나타나기까지 15-20분 소요
  • ApiManagementGatewayLlmLog 테이블이 없다면 더 기다리거나 진단 설정 재확인 필요
  • 로그가 보이지 않으면 API 설정에서 'LLM logging' 체크 상태 확인

일일 토큰 사용량 분석

프롬프트 로그 외에도 Kusto 쿼리를 통해 다양한 사용량 분석이 가능합니다. 아래는 일일 토큰 사용량을 집계하는 쿼리입니다.

일일 토큰 사용량 집계 쿼리
Copy
ApiManagementGatewayLlmLog
| where TimeGenerated >= ago(1d)
| where coalesce(SequenceNumber, 0) == 0
| where tolong(TotalTokens) > 0
| summarize
  TotalRequests   = count(),
  PromptTokensSum = sum(tolong(PromptTokens)),
  CompletionTokensSum = sum(tolong(CompletionTokens)),
  TotalTokensSum  = sum(tolong(TotalTokens)),
  AvgTokensPerReq = avg(tolong(TotalTokens))

8. 외부 애플리케이션 연동 테스트

Python 클라이언트 구성 및 실행

이제 외부 애플리케이션에서 APIM을 통해 Azure OpenAI를 호출하는 테스트를 진행합니다.

Python 클라이언트 코드
Copy
import requests
import json
import os

def call_azure_openai_via_apim():
  """
  API Management를 통해 Azure OpenAI를 호출하는 함수
  """
  
  # APIM 및 Azure OpenAI 설정
  apim_url = "https://your-apim-instance.azure-api.net/openai"  # APIM Gateway URL 경로
  deployment_name = "gpt-4o-deployment"                         # 실제 배포 모델명
  api_version = "2025-01-01-preview"                            # LLM 로깅 지원 버전
  subscription_key = "your-apim-subscription-key"               # APIM 구독 키
  
  # 완전한 API 엔드포인트 URL 구성
  url = f"{apim_url}/deployments/{deployment_name}/chat/completions?api-version={api_version}"
  
  # 요청 헤더 설정
  headers = {
      "Content-Type": "application/json",
      "api-key": subscription_key  # APIM에서 구성한 인증 헤더
  }
  
  # 요청 본문 데이터
  payload = {
      "messages": [
          {
              "role": "system",
              "content": "You are an AI assistant that helps people find information."
          },
          {
              "role": "user", 
              "content": "APIM을 거쳐 Azure OpenAI를 호출하는 구조를 간결하게 설명해 주세요."
          }
      ],
      "temperature": 0.7,      # 응답의 창의성 수준 (0.0-2.0)
      "top_p": 0.95,          # 어휘 다양성 제어 (0.0-1.0)
      "max_tokens": 800       # 응답 최대 길이 제한
  }
  
  try:
      # Azure OpenAI API 호출
      response = requests.post(url, headers=headers, json=payload, timeout=30)
      
      if response.status_code == 200:
          result = response.json()
          print("성공적으로 응답을 받았습니다.")
          print("응답 내용:")
          print(result['choices'][0]['message']['content'])
          
          # 토큰 사용량 정보 출력
          print("\n토큰 사용량:")
          usage = result.get('usage', {})
          print(f"  프롬프트 토큰: {usage.get('prompt_tokens', 'N/A')}")
          print(f"  완성 토큰: {usage.get('completion_tokens', 'N/A')}")
          print(f"  총 토큰: {usage.get('total_tokens', 'N/A')}")
          
          return result
          
      else:
          # HTTP 오류 상태 코드 처리
          print(f"HTTP 오류: {response.status_code}")
          print(f"오류 응답: {response.text}")
          return None
          
  except requests.exceptions.Timeout:
      print("요청 시간 초과 오류가 발생했습니다.")
      return None
  except requests.exceptions.RequestException as e:
      print(f"요청 중 오류가 발생했습니다: {e}")
      return None
  except json.JSONDecodeError:
      print("응답을 JSON으로 파싱하는 중 오류가 발생했습니다.")
      return None

# 메인 실행 부분
if __name__ == "__main__":
  print("APIM을 통한 Azure OpenAI 연결 테스트")
  print("=" * 60)
  
  # 기본 테스트
  print("\n기본 테스트:")
  result = call_azure_openai_via_apim()
  
  if result:
      print("\n테스트 완료! Log Analytics에서 로그를 확인하세요.")
  
  print("=" * 60)
APIM 설정 정보 확인

1. APIM Gateway URL 확인:

  • API Management → 'API' → 'Settings' → Base URL 복사

2. 구독키 확인:

  • API Management → '구독' → 'Built-in all-access subscription'
  • Primary key 또는 Secondary key 복사하여 코드에 사용

APIM Gateway URL 확인 화면

구독키 확인 화면

Python 스크립트 실행 결과 및 성공 응답

로그 확인

Python 애플리케이션 실행 후 Log Analytics에서 로그를 확인할 수 있습니다.

9. 보안 정책 테스트

Azure API Management는 위에서 다룬 로깅 기능 외에도 다양한 고급 기능을 제공합니다:

  • 보안 정책: IP 필터링, 인증/권한 부여, CORS 정책
  • 트래픽 관리: 속도 제한, 할당량 관리, 백엔드 라우팅
  • 데이터 변환: 요청/응답 수정, 헤더 조작, JSON-XML 변환
  • 캐싱: 응답 캐싱을 통한 성능 향상 및 비용 절감

본 섹션에서는 보안 정책 중 하나인 IP 필터링을 통해 Azure OpenAI 서비스 접근을 제한하는 방법을 실습해보겠습니다.

IP 제한 정책 구현

API Management에서 특정 IP 대역만 허용하는 보안 정책을 설정하고 테스트해보겠습니다.

IP 제한 정책 설정
Copy
1. API Management → 'APIs' → 'Azure OpenAI Service' 선택
2. 'Design' 탭 → 'Inbound processing' → '</> Code view' 클릭  
3. 정책 편집기에서 IP 필터 추가

IP 제한 정책
Copy
<policies>
  <inbound>
      <base />
      <!-- 허용 IP만 통과 -->
      <!-- 허용할 IP 대역 설정 -->
      <ip-filter action="allow">
          <address-range from="YOUR_OFFICE_IP_START" to="YOUR_OFFICE_IP_END" />
          <address-range from="YOUR_INTERNAL_NETWORK_START" to="YOUR_INTERNAL_NETWORK_END" />
          <!-- 예시: <address-range from="192.168.1.1" to="192.168.1.254" /> -->
          <!-- 예시: <address-range from="10.0.0.1" to="10.255.255.254" /> -->
      </ip-filter>
      <set-backend-service backend-id="YOUR_OPENAI_BACKEND_ID" />
  </inbound>

  <backend>
      <base />
  </backend>

  <outbound>
      <base />
  </outbound>

  <on-error>
      <base />
      <choose>
          <when condition="@(context.Response.StatusCode == 403)">
              <return-response>
                  <set-status code="403" reason="Forbidden" />
                  <set-header name="Content-Type" exists-action="override">
                      <value>application/json</value>
                  </set-header>
                  <set-body>@{
                      return Newtonsoft.Json.JsonConvert.SerializeObject(new {
                          error = new {
                              code = "IP_BLOCKED",
                              message = "Access denied: Your IP address is not allowed"
                          }
                      });
                  }</set-body>
              </return-response>
          </when>
          <when condition="@(context.LastError != null && context.LastError.Source.Equals("ip-filter"))">
              <return-response>
                  <set-status code="403" reason="Forbidden" />
                  <set-header name="Content-Type" exists-action="override">
                      <value>application/json</value>
                  </set-header>
                  <set-body>@{
                      return Newtonsoft.Json.JsonConvert.SerializeObject(new {
                          error = new {
                              code = "IP_BLOCKED",
                              message = "Access denied: Your IP address is not allowed",
                              source = context.LastError.Source,
                              reason = context.LastError.Reason
                          }
                      });
                  }</set-body>
              </return-response>
          </when>
      </choose>
  </on-error>
</policies>

정책 적용 예시 화면

접근 제한 테스트 및 차단 로그 분석

정책 적용 후 허용되지 않은 IP에서 접근을 시도하여 차단 기능을 테스트합니다.

허용 IP대역에서 접근했을 경우

허용 대역이 아닌 IP에서 접근했을 경우

Log Analytics에서 차단 로그 확인

차단 로그 확인을 위한 kusto 쿼리
Copy
ApiManagementGatewayLogs
| where TimeGenerated > ago(1h)
| where ResponseCode == 403
| project 
  TimeGenerated,
  CallerIpAddress,
  RequestUrl = Url,
  ResponseCode,
  ResponseSize,
  RequestHeaders,
  OperationName

IP 제한 정책 검증 완료
  • ✅ 허용되지 않은 IP에서 403 Forbidden 응답 확인
  • ✅ 사용자 정의 차단 메시지 정상 표시
  • ✅ Log Analytics에서 차단 이벤트 정확히 기록
정책 적용 시 주의사항
  • 개발자 IP 확인: 자신의 현재 IP가 허용 목록에 포함되어 있는지 확인
  • 프로덕션 준비: 운영 환경 적용 전 충분한 테스트 필요
  • Azure 서비스 대역 허용 여부: Azure Portal의 API Management 테스트 기능도 Azure 서비스 IP 대역에서 실행

✨ 결론

Azure API Management를 통한 Azure OpenAI 프롬프트 로깅은 다음과 같은 핵심 이점을 제공합니다:

  • 완전한 투명성: 모든 프롬프트와 응답의 상세 로깅
  • 스트리밍 지원: 2025년 업데이트로 실시간 스트리밍 로깅 지원
  • 사용량 추적: 구독키별 토큰 사용량 및 비용 분석
  • 보안 강화: IP 제한, 구독 관리, 사용량 제한
  • 확장성: 대용량 로그(최대 2MB)의 청크 단위 처리
운영 환경 권장사항

프로덕션 환경에서는 비용 최적화를 위해 로그 보존 정책을 설정하고, 알람 규칙을 구성하여 이상 사용량을 모니터링하는 것을 권장합니다.

이 포스트는 2025년 8월 기준 최신 Azure 공식 문서를 바탕으로 작성되었습니다. 최신 정보는 Microsoft Learn - Azure API Management Azure OpenAI 문서에서 확인하실 수 있습니다.

728x90
728x90

클라우드 컴퓨팅 요구 사항에 가장 적합한 옵션을 선택하는 데 도움이 되는 가이드

 

소개

 

클라우드 컴퓨팅은 애플리케이션과 서비스를 실행하는 강력하고 유연한 방법이지만, 지출을 최적화하는 방법을 모르면 혼란스럽고 비용이 많이 들 수 있습니다. Azure는 사용 패턴과 요구 사항에 따라 Azure 비용을 절감할 수 있는 다양한 옵션을 제공합니다. 이 글에서는 이러한 두 가지 옵션, 즉 컴퓨팅과 예약을 위한 Azure 절감 플랜을 비교하고 대조해 보겠습니다. 또한, 이러한 옵션을 결합하여 절감 효과와 유연성을 극대화하는 방법도 설명합니다. 이 글을 끝까지 읽으면 이러한 옵션을 활용하여 클라우드 컴퓨팅 비용을 절감하고 비즈니스 목표를 달성하는 방법을 더 잘 이해하게 될 것입니다.

 

Azure 컴퓨팅 비용 절감 플랜이란 무엇인가요? 

 

Azure 컴퓨팅 절약 플랜을 사용하면 1년 또는 3년 동안 고정 시간당 지출 약정을 하는 대가로 적격 컴퓨팅 리소스 사용량을 최대 65%까지 절약할 수 있습니다 [1] . 절약 플랜 혜택은 Azure Virtual Machines, Azure App Service, Azure Functions 프리미엄 플랜을 포함한 다양한 컴퓨팅 서비스에 제공됩니다. 여러 컴퓨팅 서비스에서 일관된 지출이 발생하는 경우 절약 플랜을 구매하면 전체 비용을 줄이는 데 도움이 될 수 있습니다. 

 

저축 플랜 할인은 컴퓨팅 인프라 요금(예: CPU, RAM, 스토리지)에 적용되며 컴퓨팅 서비스와 리전의 조합에 따라 달라집니다. 할인 규모는 시간당 약정이 아닌 약정 기간에 따라 결정됩니다. 저축 플랜은 할인을 제공하지만 리소스의 런타임 상태에는 영향을 미치지 않습니다. 저축 플랜 할인은 소프트웨어 라이선스 비용(예: Windows, Windows Server 또는 SQL Server)에는 적용되지 않습니다. Azure Hybrid Benefit을 통해 이러한 라이선스 비용을 절감할 수 있습니다 [2] .  

 

절약 플랜 모델에 따라 Azure는 적격 절약 플랜 적용 가능 사용량에 절약 플랜 할인을 적용합니다. 즉, 절약 플랜 할인율이 가장 높은 리소스의 사용량부터 할인됩니다. 할인된 금액은 시간당 약정에서 차감됩니다. 시간당 약정이 소진되면 남은 사용량은 종량제 요금으로 청구됩니다.

 

이것은 시간 단위 약정이므로, 한 시간 동안 약정을 완전히 소모할 만큼 적격 사용량이 충분하지 않더라도 해당 시간 전체 약정에 대한 요금이 청구됩니다. 

 

그림 1 Azure 절약 계획: 절약을 위한 글로벌하고 유연하며 자동화된 경로

 

Azure 절약 계획 - 자동으로 유연하게 적용 

 

저축 플랜은 서비스나 지역에 관계없이 가장 큰 혜택을 볼 수 있는 사용량에 자동으로 약정을 적용합니다 [3] . 저축 플랜 할인율이 가장 높은 리소스의 사용량이 항상 우선적으로 적용되므로 약정을 적극적으로 관리할 필요가 없습니다. 저축 플랜은 사용자의 사용 패턴에 따라 자동으로 조정됩니다. 

 

절약 플랜은 특정 Azure 지역이나 컴퓨팅 서비스에 국한되지 않습니다. 절약 플랜은 Azure Virtual Machines 및 Azure App Service를 포함한 6개 이상의 컴퓨팅 서비스에 대한 비용 절감 혜택을 제공할 수 있습니다. 포함된 모든 컴퓨팅 서비스 목록을 보거나 Azure 가격 계산기 , Azure 가격 페이지 또는 Azure 가격표를 다운로드 하여 절약 플랜 가격을 확인하세요  

 

저축 플랜은 전체 EA 청구 계정(등록) 또는 MCA 청구 프로필, 또는 특정 관리 그룹, 구독 또는 리소스 그룹 [4] 에 할인 혜택을 제공하도록 구성할 수 있습니다 . 언제든지 저축 플랜의 범위를 변경할 수 있습니다. 

 

저축 플랜의 혜택 범위는 변경할 수 있지만, 시간당 약정이나 기간은 변경할 수 없습니다. 또한, 저축 플랜은 사용하는 컴퓨팅 서비스 변경에 따라 본질적으로 조정 가능하므로, 저축 플랜을 취소하거나 변경할 수 없습니다.  

 

그림 2 하나의 계획, 모든 위치: 저축 계획의 글로벌 힘

 

Azure 예약이란 무엇인가요? 

 

Azure 예약을 사용하면 1년, 3년 또는 5년 사용 약정을 하는 대가로 특정 Azure 리소스 사용량을 최대 72%까지 절약할 수 있습니다 [5] . 예약은 하루 종일 지속적으로 실행되고 하나의 Azure 지역에서 운영되며 향후 1년, 3년 또는 5년 동안 인프라 요구 사항을 실질적으로 변경할 것으로 예상되지 않는 워크로드에 이상적입니다. Azure 예약은 Azure Virtual Machines, Azure SQL 데이터베이스, Azure Cosmos DB를 포함한 다양한 Azure 서비스에 사용할 수 있습니다. 특정 지역에서 특정 Azure 제품을 일관되고 지속적으로 사용하는 경우 해당 제품에 대한 예약을 구매하면 전체 비용을 줄이는 데 도움이 될 수 있습니다.

 

예약 할인은 인프라 요금(예: CPU, RAM, 스토리지)에 적용되며 Azure 제품 및 지역에 따라 다릅니다. 할인 플랜과 마찬가지로 예약의 약정 기간에 따라 할인율이 결정됩니다. 예약은 할인을 제공하지만 리소스의 런타임 상태에는 영향을 미치지 않습니다. 예약 할인은 소프트웨어 라이선스 비용(예: Windows, Windows Server, SQL Server)에는 적용되지 않습니다. 그러나 Azure Hybrid Benefit을 통해 이러한 라이선스 비용을 절감할 수 있습니다. 

 

예약을 구매하면 선불로 결제하고 특정 지역에서 특정 Azure 제품을 사용하도록 약정하게 됩니다. 매 시간마다 종량제 사용량이 평가되지만, 종량제 요금 대신 선불 예약 혜택이 일치하는 리소스에 자동으로 적용됩니다. 일치하는 예약이 모두 소진되면 남은 사용량은 절약 플랜 모델(사용 가능한 경우) 또는 종량제 요금으로 청구됩니다. 예약은 시간 단위 약정이므로, 한 시간 동안 예약을 완전히 소진할 만큼 적격 사용량이 충분하지 않더라도 매 시간 예약 요금이 발생합니다.

 

예약 제품은 동일한 유형의 예약인 경우 서로 호환됩니다. 예를 들어 Azure Dedicated Host, Azure VMware Solution, Azure Virtual Machines를 포함한 여러 컴퓨팅 예약을 한 번에 서로 교환할 수 있습니다 [6] . 또한 SQL Managed Instance 및 Elastic Pool을 포함한 여러 SQL Database 예약 유형을 서로 교환할 수 있습니다. 하지만 서로 다른 유형의 예약은 교환할 수 없습니다. 예를 들어 Azure Cosmos DB 예약을 SQL Database로 교환할 수 없습니다.

 

다른 지역의 유사한 유형의 예약을 교환하여 구매할 수도 있습니다. 예를 들어, 미국 서부 2 지역의 예약을 서유럽 지역의 예약으로 교환할 수 있습니다. 

 

Azure Reservations – 예측 가능한 모든 워크로드에 대한 엄청난 할인 

 

Azure 예약은 안정적이고 지속적으로 실행되는 워크로드에 가장 비용 절감 효과가 큰 옵션입니다. 예약 기간 동안 인프라 요구 사항이 변경되지 않을 것으로 예상되는 워크로드는 안정적인 것으로 간주됩니다. 하루 종일 실행되는 워크로드는 예약에 적합한 후보일 가능성이 높습니다. Azure 예약은 컴퓨팅, 데이터베이스, 분석을 포함한 여러 Azure 제품에 사용할 수 있습니다.  

 

VM 예약은 가상 머신 예약 인스턴스(VM RI)라고도 합니다. 이러한 예약은 큰 할인과 함께 인스턴스 크기 유연성 [7] 을 통해 더 큰 유연성을 제공합니다 . 이 기능을 사용하면 예약 할인을 동일한 VM 크기 그룹의 다른 VM에 적용할 수 있습니다. 예를 들어 Standard_DS3_v2 VM 예약을 구매하는 경우 DSv2 시리즈의 다른 VM 크기(예: Standard_DS1_v2, Standard_DS2_v2, Standard_DS3_v2 또는 Standard_DS4_v2)에 예약을 적용하도록 선택할 수 있습니다.  인스턴스 크기 유연성에 대해 자세히 알아보려면  이 문서를 검토하세요.

 

앞으로  VM의 인스턴스 크기 유연성은  유지되지만, Azure Virtual Machine, Azure Dedicated Host 및 Azure App Service 예약에 대한 인스턴스 시리즈 또는 지역 교환은 더 이상 지원되지 않습니다. 자세한 내용은 이 문서를 참조하세요.

 

지원되는 모든 서비스 목록을 보거나 Azure 가격 계산기 , Azure 가격 페이지 또는 Azure 가격 목록을 다운로드 하여 예약 가격을 확인하세요  

 

저축 플랜과 마찬가지로, 예약은 전체 EA 청구 계정 또는 MCA 청구 프로필, 또는 특정 관리 그룹, 구독 또는 리소스 그룹에 할인 혜택을 적용하도록 구성할 수 있습니다. 예약 범위는 언제든지 변경할 수 있습니다. 

 

저축 계획과 예약을 비교하는 방법은? 

 

이제 저축 계획과 예약이 무엇인지 설명했으니, 이 둘을 비교하고 대조하여 어떤 점이 다른지, 그리고 클라우드 컴퓨팅 지출을 최적화하는 데 어떻게 도움이 될 수 있는지 알아보겠습니다. 

 

사용 패턴과 요구 사항에 따라 절약 플랜과 예약은 인프라 비용 절감에 도움이 되는 두 가지 옵션입니다 [8] . 두 옵션 모두 Azure Hybrid Benefit과 결합하여 Windows Server 및 SQL Server 라이선스 비용을 절감할 수 있습니다. 하지만 두 옵션 중 하나를 선택하기 전에 고려해야 할 주요 차이점도 있습니다. 

 



전세  저축 계획 
목표  계획된 변경 없이 동일한 지역에서 지속적으로 실행되는 작업 부하  다양한 지역에서 실행되는 동적/진화하는 워크로드 
선불제 대비 절감 효과  최대 72%까지 절약하세요  최대 65%까지 절약하세요 
약속  특정 지역에서 특정 제품 사용(예: 일본 동부의 D2v4 VM)  시간당 금액(예: $5/시간) 
혜택 명령  먼저 적용됨  적용된  
용어  1년, 3년 또는 5년  1년 또는 3년 
결제 옵션  선불 또는 월별  선불 또는 월별 
수정 사항 
  • 교환 예약 1 
  • VM, 전용 호스트 또는 앱 서비스 예약을 할인 플랜으로 교환하세요 
  • 예약 취소 2 
취소 불가 

1 예약 교환 정책의 향후 변경 사항에 따라 

2 회전 12개월 기간 동안 50,000달러 USD에 적용됨 

 

예시 

 

이 섹션에서는 다양한 시나리오와 가정을 기반으로 Azure 예약과 Savings Plan for Compute를 비교하는 두 가지 예를 제시합니다. 이 예는 각 옵션의 잠재적인 절감 효과와 장단점, 그리고 결정에 영향을 미치는 요소를 보여주기 위한 것입니다. 두 예 모두 워크로드가 하루 24시간 운영된다고 가정합니다. 다음 예에 사용된 가격은 2024년 5월 기준 Azure 가격 계산기에서 가져온 것입니다.

 

예 1: 예약 

 

이 예시에서는 워크로드가 미국 동부와 미국 서부, 두 지역에 분산되어 있습니다. 워크로드는 각 지역에 있는 가상 머신 인스턴스 2개와 Azure SQL 데이터베이스 2개로 구동되며, 이러한 리소스에는 계획된 변경 사항이 없습니다. 3년 기간으로 예약을 구매하면 가장 큰 절감 효과를 얻을 수 있습니다. 

 

예약 예상          
서비스 유형 지역 설명 PAYG 월 비용
3년 할인
월별 비용 월별 저축
가상 머신 미국 동부 4 D2 v3(2개 vCPU, 8GB RAM)(3년 예약), Windows(라이선스 포함), OS 전용; 0개 관리 디스크 - S4; 지역 간 전송 유형, 미국 동부에서 미국 서부로의 5GB 아웃바운드 데이터 전송 548.96달러 31% 376.18달러 172.78달러
가상 머신 미국 서부 4 D2 v3(2개 vCPU, 8GB RAM)(3년 예약), Windows(라이선스 포함), OS 전용; 0개 관리 디스크 - S4; 지역 간 전송 유형, 미국 서부에서 미국 동부로의 5GB 아웃바운드 데이터 전송 610.28달러 34% 416.86달러 193.42달러
Azure SQL 데이터베이스 미국 동부 단일 데이터베이스, vCore, 일반 용도, 프로비저닝됨, 표준 시리즈(Gen 5), 로컬 중복, 2-2 vCore 인스턴스, 3년 예약, 32GB 스토리지, RA-GRS 백업 스토리지 중복성, 0GB 시점 복원, 0 x 5GB 장기 보존 745.94달러 35% 501.46달러 244.48달러
Azure SQL 데이터베이스 미국 서부 단일 데이터베이스, vCore, 일반 용도, 프로비저닝됨, 표준 시리즈(Gen 5), 로컬 중복, 2-2 vCore 인스턴스, 3년 예약, 32GB 스토리지, RA-GRS 백업 스토리지 중복성, 0GB 시점 복원, 0 x 5GB 장기 보존 792.30달러 35% 523.38달러 268.93달러
    2,697.49달러   1,817.88달러 879.61달러
             
부인 성명            
표시된 모든 가격은 미국 달러(USD)로 표시됩니다. 이는 견적이 아닌 추정치입니다. 최신 가격 정보는 https://azure.microsoft.com/pricing/calculator 에서 확인하세요 .
이 추정치는 2024년 5월 21일 오전 8시 52분 39초 UTC에 작성되었습니다.

 

예약은 단일 리전에만 적용되고, 두 개의 서로 다른 리전에 컴퓨팅 및 데이터베이스 서비스가 있으므로 총 4개의 예약이 필요합니다. 4개의 예약을 통해 월 $879.61의 비용을 절감할 수 있으며, 이는 3년 동안 $31,665.96의 비용 절감으로 이어집니다.  

 

예 2: 컴퓨팅을 위한 절약 계획 

 

이 시나리오에서 저희 고객사인 Fabrikam은 미국 서부, 서유럽, 동아시아의 세 개 주요 지역에 운영 시스템을 구축했습니다. 각 지역은 핵심 워크로드를 전담하는 리소스를 보유하고 있어 지속적인 운영을 보장합니다.

 

각 지역에서 현지 업무 시간을 기준으로 8시간 동안 운영되도록 설계된 워크로드를 통해 Fabrikam은 각 지역의 비수기 시간대에 따른 비용 절감 효과를 누릴 수 있습니다. 이러한 접근 방식은 리소스 활용도를 최적화할 뿐만 아니라 "태양을 따라가는" 모델에 부합하여 전 세계 고객에게 원활한 서비스를 제공합니다.

 

Fabrikam은 컴퓨팅 절감 플랜을 도입함으로써 1년 또는 3년 동안 일정한 양의 컴퓨팅 사용량(시간당 $ 단위)을 확보합니다. 그 대가로 종량제 요금제 대비 상당한 할인 혜택을 받습니다. 다음 예시는 Fabrikam이 미국 서부, 서유럽, 동아시아에서 운영되는 앱 서비스를 포괄하는 컴퓨팅 절감 플랜을 어떻게 활용하는지 보여줍니다.

 

저축 계획 추정          
서비스 유형 지역 설명 8시간/일 급여 3년 할인 월 비용 8시간/일 월별 저축 시간당 약속
앱 서비스 미국 서부 프리미엄 V3 티어; 1 P3V3(8코어, 32GB RAM, 250GB 스토리지); 3년 절약 플랜; Windows OS; 0 SNI SSL 연결; 0 IP SSL 연결; 0 사용자 정의 도메인; 0 표준 SLL 인증서; 0 와일드카드 SSL 인증서 42.88달러 24% 32.80달러 10.08달러 1.025달러
앱 서비스 서유럽 프리미엄 V3 티어; 1 P3V3(8코어, 32GB RAM, 250GB 스토리지); 3년 절약 플랜; Windows OS; 0 SNI SSL 연결; 0 IP SSL 연결; 0 사용자 정의 도메인; 0 표준 SLL 인증서; 0 와일드카드 SSL 인증서 43.26달러 24% 33.02달러 10.24달러 1.032달러
앱 서비스 동아시아 프리미엄 V3 티어; 1 P3V3(8코어, 32GB RAM, 250GB 스토리지); 3년 절약 플랜; Windows OS; 0 SNI SSL 연결; 0 IP SSL 연결; 0 사용자 정의 도메인; 0 표준 SLL 인증서; 0 와일드카드 SSL 인증서 48.26달러 26% 35.74달러 12.51달러 1.117달러
    3,066.00달러   2,317.01달러 32.83달러 1.025달러
               
부인 성명              
표시된 모든 가격은 미국 달러(USD)로 표시됩니다. 이는 견적이 아닌 추정치입니다. 최신 가격 정보는 https://azure.microsoft.com/pricing/calculator에서 확인하세요.
이 추정치는 2024년 6월 19일 오후 12시 22분 34초 UTC에 작성되었습니다.

 

예시에서는 종량제 요금과 지역별 할인율이 약간씩 다르다는 것을 보여줍니다. 미국 서부 지역은 일반적으로 앱 서비스 요금이 가장 낮은 반면, 동아시아 지역은 26%로 다른 지역보다 할인율이 높습니다(24%). 저희 워크로드는 지역별로 8시간 동안 운영되며, 지역 간 전환 시 할인 혜택을 순환적으로 적용합니다. 사용량 부족을 방지하려면 최소 시간당 약정이 적용되는 단일 할인 플랜을 선택하는 것이 가장 좋습니다. 따라서 Compute Savings Plan에 시간당 $1.205의 요금을 선택하게 됩니다. 수동 계산은 필요하지 않습니다. Azure Advisor가 사용자의 요구 사항에 맞는 적절한 기준을 추천해 드리며, 구매 시 과거 데이터를 기반으로 시간당 약정 제안이 표시됩니다.

 

이 사례는 전략적 계획과 컴퓨팅 절감 계획(Savings Plans for Compute)을 활용하여 달성할 수 있는 재정적 이점과 운영 효율성을 보여줍니다. "태양 추적(Follow the Sun)" 모델을 효과적으로 구현하여 지속적인 글로벌 운영을 유지하면서 절감 효과를 극대화하는 방법을 보여줍니다.

저축 계획과 예약을 모두 활용하는 방법 

  • 다음 순서대로 Azure Advisor 권장 사항을 활용하세요. 
  • 적절한 크기/종료 VM 
  • 이전에 구매한 미활용 예약을 교환하세요.  
  • VM, 전용 호스트 및 앱 서비스 예약을 절약 플랜으로 교환하세요 
  • 추천에 따라 구매 예약 
  • 추천에 따른 구매 저축 계획 

 

Microsoft Azure Consumption Commitment(MACC) 할인을 고려하는 방법은 무엇인가요?

 

많은 기업 고객은 기존 Microsoft Azure Consumption Commitment(MACC) 할인 [9] 을 받았을 수 있습니다 . 이는 일반적으로 1년 또는 3년 동안 Azure 서비스에 특정 금액을 지출하겠다는 약정에 따라 적용되는 할인입니다. MACC 할인은 적격 Azure 서비스의 종량제 요금에 적용되며 약정 수준 및 계약 조건에 따라 달라질 수 있습니다. 그러나 MACC 할인은 저축 플랜 또는 예약 할인과 중복 적용되지 않습니다. 즉, 저축 플랜이나 예약을 구매하는 경우 저축 플랜 또는 예약 할인에 MACC 할인이 추가되지 않습니다. 대신 두 할인 중 더 높은 할인이 적용됩니다.

 

요약

 

이 글에서는 Azure 비용 절감에 도움이 되는 두 가지 옵션인 컴퓨팅 및 예약에 대한 Azure 절감 플랜을 비교하고 대조해 보았습니다. 주요 내용은 다음과 같습니다.

 

  • 저축 플랜은 컴퓨팅 서비스의 인프라 비용을 절감할 수 있는 유연하고 포괄적인 방법을 제공합니다. 적격 컴퓨팅 서비스, 인스턴스 유형 또는 리전에 자동으로 적용되며, 요구 사항에 따라 변경할 수 있습니다. 전체 청구 범위에 걸쳐 저축 플랜을 공유하고 언제든지 범위를 변경할 수 있습니다. 약정 금액은 언제든지 늘릴 수 있지만, 약정 기간 종료 전에는 약정 금액을 줄이거나 취소할 수 없습니다. 저축 플랜은 최대 65%까지 절감할 수 있으며, Azure 하이브리드 혜택과 결합하여 라이선스 비용을 추가로 절감할 수 있습니다.
  • 예약은 서비스 인프라 비용을 절감할 수 있는 예측 가능하고 안정적인 방법입니다. 선불 비용을 지불하면 특정 서비스, 인스턴스 유형 및 지역을 예약할 수 있습니다. 예약은 언제든지 취소하거나 변경할 수 있으며, 12개월 롤링 윈도우당 미화 50,000달러의 한도가 적용됩니다. 또한, 동일한 패밀리 내에서 인스턴스 크기를 변경하거나 동일한 지리적 영역 내에서 지역을 변경하여 예약을 수정할 수도 있습니다. 단, 컴퓨팅 서비스가 아닌 서비스로 예약을 변경하는 것은 특정 조건에서만 가능합니다. 예약을 사용하면 최대 72%까지 비용을 절감할 수 있으며, Azure 하이브리드 혜택과 결합하여 라이선스 비용을 추가로 절감할 수 있습니다.
  • 예약은 컴퓨팅 외에도 더 많은 서비스를 포괄하지만, 특정 서비스, 인스턴스 유형 및 리전에 종속되기 때문에 절약 플랜보다 유연성이 떨어집니다. 예약은 안정적이고 예측 가능하며 계획된 변경 사항이 없는 워크로드에 적합합니다.
  • 예약 인스턴스는 가상 머신을 대상으로 하는 예약 유형입니다. 특정 VM 크기와 지역을 예약하고 VM 비용 할인을 받을 수 있습니다. 예약 인스턴스는 웹 서버, 데이터베이스 또는 일괄 처리와 같이 지속적으로 또는 장기간 실행되는 워크로드에 적합합니다.
  • 절약 플랜과 예약을 결합하여 절약 효과와 유연성을 극대화할 수 있습니다. 예약은 안정적이고 예측 가능한 워크로드에 사용할 수 있으며, 절약 플랜은 동적이고 변화하는 워크로드에 적합합니다. Azure는 예약 할인을 먼저 적용한 후, 절약 플랜 약정이 완전히 소진될 때까지 남은 사용량에 대해 절약 플랜 할인을 자동으로 적용합니다. 두 옵션 모두 적용되지 않는 사용량은 종량제 요금으로 청구됩니다. 사용하는 서비스, 인스턴스 유형 및 지역에 따라 다양한 유형의 예약 및 절약 플랜을 조합하여 사용할 수 있습니다.
  • Microsoft Azure Consumption Commitment(MACC) 할인이 있다면, 할인 플랜이나 예약 옵션을 비교할 때 함께 고려해 보세요. MACC 할인은 적격 Azure 서비스의 종량제 요금에 적용되며, 약정 수준 및 계약 조건에 따라 달라질 수 있습니다. 단, MACC 할인은 Savings Plan이나 예약 할인과 중복 적용되지 않습니다. Savings Plan이나 예약 중 하나를 구매하는 경우, 두 할인 중 더 높은 할인을 받게 됩니다.

 

이 글이 Azure 컴퓨팅 및 예약 절감 플랜을 선택하는 방법과 이를 결합하여 클라우드 컴퓨팅 지출을 최적화하는 방법을 이해하는 데 도움이 되었기를 바랍니다. 질문, 의견 또는 공유하고 싶은 경험이 있으시면 아래에 댓글을 남겨주세요. 여러분의 의견을 기다립니다.

 

참고문헌

 

[1] Azure 컴퓨팅 절감 계획이란 무엇입니까? - Microsoft Cost Management | Microsoft Learn

[2] Windows Server용 Azure Hybrid Benefit | Microsoft Learn

[3] Azure 절약 계획 할인이 적용되는 방식 - Microsoft Cost Management | Microsoft Learn

[4] 저축 계획 범위 - Microsoft Cost Management | Microsoft Learn

[5] Azure 예약이란 무엇입니까? - Microsoft Cost Management | Microsoft Learn

[6] Azure Reservations에 대한 셀프 서비스 교환 및 환불 - Microsoft Cost Management | Microsoft Learn

[7] 가상 머신 크기 유연성 -Azure Reserved VM Instances - Azure Virtual Machines | Microsoft Learn

[8] 저축 계획과 예약 중에서 결정 - Microsoft Cost Management | Microsoft Learn

[9] Microsoft Azure 사용 약정(MACC) 추적 - Microsoft 비용 관리 | Microsoft Learn

728x90
728x90

인수 합병은 일반적이지만 설계자, 영업 및 계정 팀이 두 조직 모두 Azure를 사용할 때 Azure 구독의 이동이 어떻게 발생하는지에 대한 질문을 받을 때 때때로 어려움을 겪는 것을 보았습니다. 이는 동일한 Azure AD 테넌트 내에서 또는 Azure AD 테넌트 이동 간에 있을 수 있습니다. 우리 중 몇 명은 때때로 구독이 이미 시행된 후에 참여하기 때문입니다.

 

다양한 유형의 마이그레이션을 살펴보기 전에 Microsoft 기업계약 계층 구조를 간략하게 요약해 보겠습니다.

 

조직에서 EA를 구매하면 구독을 만들고 Azure 리소스 배포를 시작할 수 있습니다. 고객은 CSP가 리소스를 제어하고 배포 및 CSP 파트너가 고객을 대신하여 티켓을 만드는 모든 기술 문제를 지원하는 고객과 파트너 간의 관계인 파트너를 통해 CSP를 구매할 수 있습니다.

 

아래 계층 구조는 기업계약입니다. 첫 번째 수준은 등록이며, 그 아래에서 고객은 여러 부서를 만들어 배포를 분리할 수 있습니다. 부서는 하나일 수도 있고 많을 수도 있습니다. 부서에서 계정을 만듭니다. 계정은 모든 구독이 만들어지는 컨테이너입니다. 기본적으로 계정 생성 과정에서 이메일 주소를 할당할 수 있습니다. 이 사람은 계정을 소유합니다. 계정을 만들 때마다 고유한 이메일 주소를 제공해야 합니다. 동일한 소유자를 가진 두 개의 EA 계정을 가질 수 없습니다.

 

가장 좋은 방법은 Microsoft 계정이 아닌 회사 및 학교 계정을 제공하는 것입니다. 사람이 언제 조직을 떠날 때를 생각해 보십시오. 😊

 

 

아래의 모든 시나리오를 고려할 때 마이그레이션은 두 가지 주요 유형으로 분류할 수 있습니다.

   비기술적 마이그레이션: 다운타임 없이 구독에 있는 리소스에 영향을 주지 않고 백 엔드에서 발생합니다.

   기술 마이그레이션: 여기에는 구독에 있는 전체 리소스를 평가하고 리소스를 다른 구독으로 이동할 수 있는지 여부를 확인하는 작업이 포함됩니다. 각 자원은 개별적으로 평가되며 한 자원이 다른 자원에 대한 종속성을 확인합니다.

 

시나리오:

아래에 언급된 마이그레이션 유형 개요:   

  서로 다른 두 EA 등록 간 이동

   1a. 첫 번째 단계

   1b. 두 번째 단계

   동일한 EA 등록 내의 EA 계정 간에 구독 이동

   한 테넌트에서 다른 테넌트로 Azure 구독 이동

    3a. 방법 1(디렉터리 변경

    3b. 방법 2(다시 만들기)

    3c. 방법

    3(ASR)

     CSP에서 EA로 구독 이동

     PAYG 구독을 EA로 이동

     MCA-Enterprise 구독을 EA로 이동

 

1. 서로 다른 두 EA 등록 간에 이동합니다.

이 시나리오에서 고객은 활성 EA 등록을 가지고 있으며 이 고객은 활성 EA 등록이 있는 Azure에도 있는 다른 엔터티 B를 획득했습니다. 둘 다 Azure에 있으므로 고객 A는 엔터티 B Azure 배포를 인수하려고 합니다. 고객은 단일 파트너를 통해서만 Microsoft에 지불하려고 합니다. 따라서 이러한 이동 필요성이 발생합니다. 또한 두 번째 요구 사항은 고객이 단일 랜딩 존을 통해 리소스를 관리할 수 있도록 여러 Azure AD 테넌트 및 단일 Azure AD 테넌트로 리소스를 병합하기 때문일 수 있습니다.

제 생각에는 합병을 두 단계로 나누는 것이 좋습니다. 첫 번째는 구독 이동(청구 전용)이고 두 번째 단계는 테넌트의 리소스 병합입니다.

 

1a. 첫 번째 단계:

(유형:NontechnicalMigration) 한 등록에서 다른 등록으로 구독 이동은 백 엔드에서 발생할 수 있습니다. 이 백 엔드 이동에는 구독 리소스에 대한 가동 중지 시간이 발생하지 않습니다. 원본 구독이 이동할 대상 EA 계정이 있어야 합니다. 고객은 MS 구독 관리 팀에 지원 사례를 제기하고 이메일을 통해 필요한 승인을 제공해야 합니다. 테넌트가 동일하게 유지된다는 것을 지원 엔지니어에게 알려야 합니다.

 

참고: 계정 소유자에게 사용되는 이메일 주소는 구독이 연결될 테넌트였습니다. 예를 들어 전자 메일이 Aquib.qureshi@contoso.com 경우 이 계정으로 만들어지는 모든 구독이 Azure AD 테넌트 contoso.com 매핑됩니다.

 

따라서 대상 Azure AD 테넌트에서 리소스를 이동하지 않으려는 것을 지원 팀에 알려야 합니다. 구독의 Azure AD 테넌트가 RBAC를 변경하면 Azure AD 앱 등록 및 구독의 많은 Azure AD 종속 서비스가 영향을 받을 수 있기 때문에 중요합니다.

 

하나의 Azure EA 등록에 둘 이상의 Azure AD 테넌트가 있을 수 있다고 생각하시나요? 대답은 예, 등록에는 임차인에 대한 제한이 없습니다. 하나의 등록에는 여러 EA 계정이 있을 수 있으며 각 계정에는 고유한 Azure AD 테넌트가 있을 수 있습니다. (여러 디렉토리를 관리하는 것이 쉽지 않기 때문에 선호되지 않습니다) 이 시나리오에서 엔터티 B에는 자체 Azure AD 테넌트가 있고 회사 A에는 이동 후 단일 Azure AD 등록에 상주하는 Azure AD 테넌트도 있습니다.

 

테넌트 외에도 명심해야 할 다른 사항은 원본 등록에서 구입한 예약 인스턴스입니다. 통화 A의 RI가 있는 구독을 이전하고 대상 EA 등록이 다른 통화 B로 구매된 경우 대상 EA 등록을 동시에 여러 통화로 청구할 수 없으므로 RI가 자동으로 취소됩니다.

 

 

1b. 두 번째 단계:

(유형:technicalMigration) 단일 Azure AD 테넌트에서 리소스 병합. 이 단계는 청구가 마이그레이션되면 실행됩니다. 앞서 언급했듯이 이는 각 리소스를 평가해야 하는 기술 마이그레이션입니다. 임차인 변경은 다양한 방법으로 처리할 수 있습니다. 3번 항목에서 자세히 설명하겠습니다.

 

 

2. 동일한 EA 등록 내의 EA 계정 간에 구독을 이동합니다.

(유형:NonTechnicalMigration) 이 시나리오는 한 명의 EA 계정 소유자가 사임하고 모든 구독을 인수하고 다른 EA 계정으로 이동하려는 경우에 발생할 수 있습니다. 이 단계는 쉽고 Azure Portal을 통해 수행할 수 있으며 MS에 지원 사례를 제기할 필요가 없습니다.

 

포털에 표시되는 동일한 대상 Azure AD 테넌트 확인 표시이며, 구독을 대상 Azure AD로 전송하지 않으려면 선택을 취소할 수 있습니다.

 

3. 한 테넌트에서 다른 테넌트로 Azure 구독 이동:

(유형:TechnicalMigration) 테넌트를 변경해야 하는 필요성은 여러 가지 이유로 발생하며, 첫 번째는 고객이 방화벽, WAF 및 네트워크 연결을 사용하여 배포된 랜딩 존을 가지고 있으며, Azure Policy는 고객 A Azure 배포의 다른 관리 그룹에 있는 BU 분리와 함께 구성되었습니다. 엔터티 B가 병합됨에 따라 고객 A의 IT 팀은 현재 Azure 배포를 관리하는 것과 유사한 방식으로 엔터티의 Azure 리소스를 관리하려고 합니다. 테넌트를 공존시키면서 더 나은 작업을 활용할 수 있는 여러 가지 방법이 있으므로 리소스를 단일 Azure AD 테넌트에 직접 병합하는 것으로 넘어서는 안 됩니다. 아래에서 몇 가지 방법을 강조하고 있습니다.

 

두 개의 Azure AD 테넌트가 있다는 것은 두 개의 서로 다른 사용자 리포지토리를 의미합니다. 고객 A 사용자가 엔터티 B의 Azure 구독을 관리하려고 할 때마다 사용자를 게스트로 초대한 다음 해당 게스트 사용자를 참가자 또는 관련 역할로 제공하여 Azure 리소스를 관리할 수 있도록 할 수 있습니다. 최근에는 두 Azure AD 테넌트 간의 사용자 동기화가 릴리스되어 사용자를 수동으로 초대할 필요가 없으며 자동화할 수 있습니다.Azure Lighthouse를 사용하여 서로 다른 두 Azure 테넌트에서 Azure 배포를 운영적으로 관리할 수 있습니다. 나는 이 주제에 대한 블로그를 썼습니다.엔터티 B가 허브 및 스포크 배포 모델을 사용하는 경우 vnet 피어링을 수행하고 방화벽, WAF 등이 있는 고객 A의 허브 네트워크를 활용할 수 있습니다.

 

Azure AD 테넌트 병합으로 이동하지 말고 테넌트와 리소스를 공존시켜야 하는 몇 가지 이유는 다음과 같습니다. 모든 서비스가 다중 테넌트를 지원하는 것은 아니지만 엔터티 B의 Azure 배포 환경 및 Azure에서 사용하는 서비스에 따라 달라지며 테넌트를 병합해야 하는 경우 계속 진행할 수 있습니다.

 

한 테넌트에서 다른 테넌트로 리소스를 이동하기로 결정했다고 가정합니다.

 

앞서 언급했듯이 이 단계는 여러 가지 방법으로 실행할 수 있습니다. 리소스의 중요도에 따라 어떤 것을 선택할지 결정할 수 있도록 하겠습니다.

 

 

3a. 접근 방식 1(디렉토리 변경):

구독을 클릭한 다음 "디렉토리 변경"을 클릭할 수 있습니다. 앞에서 설명한 대로 실행하기 전에 RBAC가 다시 설정되고, 관리 ID가 지원되는 리소스가 영향을 받고, 앱 등록에 Azure AD를 사용하는 서비스가 영향을 미칩니다. 따라서 이 단계를 수행하기 전에 모든 유형의 리소스를 하나씩 평가한 다음 실행하십시오. 실행하기 전에 영향을 받는 모든 리소스에 대한 솔루션이 있어야 합니다.

아래 Microsoft 문서에서는 영향을 받는 몇 가지 리소스를 간략하게 설명하지만 모든 리소스를 다루지는 않습니다.

https://learn.microsoft.com/en-us/azure/role-based-access-controltransfer-subscription#understand-the-impact-of-transferring-a-subscription

 

모든 구독 유형에서 이 디렉터리 변경 버튼이 활성화된 것은 아닙니다. CSP 구독을 사용하는 경우 이 옵션은 회색으로 표시됩니다.

 

고객이 더미 구독을 만든 다음 테스트하려는 리소스 유형을 배포한 다음 디렉터리 변경을 클릭하여 리소스가 작동하는지 또는 실패하는지 확인하는 것을 보았습니다.

 

 

3b. 접근 방식 2(재현):

이 옵션은 고객이 가동 중지 시간을 제어하려는 경우에 사용됩니다. 이전 접근 방식에서와 같이 더미 구독에서 리소스를 평가하고 가끔 만들어야 하는 경우가 많지만 여전히 확신이 떨어지고 마이그레이션 중에 문제가 발생하므로 이동 중에 문제 해결이 필요합니다. 따라서 이러한 상황을 방지하려면 대상 Azure AD 테넌트에 바인딩된 대상 구독에서 리소스를 병렬로 다시 만든 다음 DR을 수행하는 방법과 같이 장애 조치(failover)할 수 있습니다. 장애 복구를 수행할 가능성이 높습니다.

 

 

3c. 접근 방식 3(ASR):이 방법은 많은 사람들이 이 방법을 알지 못하기 때문에 덜 채택되고 VM 워크로드가 많은 경우에만 사용할 수 있습니다. ASR을 사용하여 서로 다른 두 테넌트 간에 복제할 수 있습니다. 원본 구독을 물리적 서버 배포로 간주하고 VNET에 어플라이언스를 배포한 다음 엔터티 B의 구독에서 호스트되는 VM에 에이전트를 푸시합니다. VM을 고객 A의 구독에 복제할 수 있습니다. 이는 Azure에서 Azure로의 ASR 시나리오와 동일하지 않지만 해결 방법입니다.

 

 

4. CSP에서 EA로 구독 이동:

(유형:TechnicalMigration) MS 지원은 백 엔드에서 구독을 이동할 수 없으며, 일반적으로 CSP 구독은 CSP 파트너가 만든 다른 테넌트에 상주하며 CSP에서 테넌트 변경이 불가능하므로 유일한 옵션은 리소스를 다시 만들어 이동하거나 ASR 접근 방식 3을 사용하는 것입니다.

 

 

5. PAYG 구독을 EA로 이동:

(유형:NonTechnicalMigration) 고객이 신용 카드를 통해 구매한 PAYG 구독. 이 구독은 다운타임 없이 백엔드의 EA 청구로 가져올 수 있습니다. 테넌트를 변경하려면 이전 섹션에서 언급한 단계를 따라야 합니다.

 

 

6. MCA-Enterprise 구독을 EA로 이동합니다.

(유형:NonTechnicalMigration) MCA는 미래이기 때문에 이는 흔하지 않은 접근 방식입니다. 그러나 MS 거버넌스 팀에 요청을 제기하여 MCA-Enterprise에서 EA 등록으로 이동할 수 있습니다. MS 거버넌스 팀과 연결하려면 계정 팀에 문의해야 합니다. 거버넌스 지원 팀에 정당성을 제공해야 해당 팀이 이 이동을 실행할 수 있습니다. 이것은 다운타임 없이 완전히 백엔드 이동입니다.

 

이것들은 구독의 주요 유형이며 인도에서 흔히 볼 수 있는 대부분의 유형을 다루었습니다. 위의 내용이 유용하고 원활한 마이그레이션에 도움이 되기를 바랍니다.

 

다음은 동료 동료의 몇 가지 유용한 링크입니다.

   Elan Shudnow: 아래 링크는 동일한 테넌트 내에서 한 구독에서 다른 구독으로 리소스를 이동하는 경우 도움이 될 수 있습니다.

   리소스 그룹 또는 리소스 이동기에서 이동 작업을 사용할 수 있습니다. 그러나 리소스가 이동 작업을 지원하는지 여부를 확인하려

   면 PowerShell 스크립트를 실행하여 유효성을 검사할 수 있습니다. https://github.com/ElanShudnow/AzureCode/tree/main/PowerShell/AzResourceMoveSupport

 

 

 

    Neha Tiwari: 아래 링크는 기술 마이그레이션을 수행할 때, 리소스 이동기를 사용하여 기술 마이그레이션을 수행할 때 또는 리소

    스 그룹에서 작업 이동을 수행할 때 실행 중에 염두에 두어야 할 모든 사항이 아래 블로그에 잘 문서화되어 있습니다.

https://techcommunity.microsoft.com/t5/azure-infrastructure-blog/detailed-csp-to-ea-migration-guidance-and-crucial-considerations/ba-p/3919364

 

 

즐거운 학습 되세요!

 

 

 

 

 

 

 

 

 

 

728x90

+ Recent posts