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

소개

클라우드 컴퓨팅은 애플리케이션과 서비스를 실행하는 강력하고 유연한 방법이지만, 지출을 최적화하는 방법을 모르면 혼란스럽고 비용이 많이 들 수 있습니다. 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 라이선스 비용을 절감할 수 있습니다. 하지만 두 옵션 중 하나를 선택하기 전에 고려해야 할 주요 차이점도 있습니다. 

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

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

예시 

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

예 1: 예약 

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

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

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

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

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

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

예시에서는 종량제 요금과 지역별 할인율이 약간씩 다르다는 것을 보여줍니다. 미국 서부 지역은 일반적으로 앱 서비스 요금이 가장 낮은 반면, 동아시아 지역은 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

인수 합병은 일반적이지만 설계자, 영업 및 계정 팀이 두 조직 모두 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

즐거운 학습 되세요!

점점 더 많은 고객이 Azure VMware Solution을 마이그레이션 대상으로 탐색하도록 요청하고 있으므로 많은 설계자와 사전 영업 담당자의 가장 일반적이고 첫 번째 문제 중 하나를 해결하는 것에 대해 생각했습니다. Azure VMware Solution 노드의 크기를 조정하는 방법은 무엇인가요? AVS 설계와 관련된 네트워크 설계 및 구성 요소에 대해 알아보기 전에. 대부분의 경우 고객은 온프레미스 워크로드에 맞는 데 필요한 노드 수와 해당 노드의 비용을 결정해야 합니다.이 블로그 전체에서 vCPU, 메모리 및 스토리지에 초점을 맞추는 이유는 무엇입니까? 예를 들어 AV36p의 한 노드에는 36개의 물리적 코어, 768GB 메모리 및 19.20TB NVMe 스토리지가 있습니다. 배포에 필요한 노드 수를 확인해야 합니다. 그리고 이를 기반으로 노드를 계속 추가할 것입니다.

여러 노드 유형의 사양은 여기에 언급되어 있습니다 https://learn.microsoft.com/en-us/azure/azure-vmware/introduction#hosts-clusters-and-private-cloudsAVS 

노드의 크기를 조정하려면 두 가지 주요 방법이 있습니다.

  수동 방법: 이 방법은 주로 사용 중인 vCPU, 메모리 및 스토리지 수를 기준으로 AVS 노드의 크기를 조정하는 것입니다. 따라서 

  기본적으로 VMware 클러스터의 현재 크기에 따라 AVS 노드의 크기를 조정합니다. VM에 16개의 vCPU가 있지만 4개만 활용하

  는 경우 실제 사용률이 아닌 AVS 노드의 전체 크기 조정에서 여전히 16개의 vCPU를 고려하기 때문에 예산 크기 조정이 될 수도

  있습니다.

  Azure Migrate 방법: 이 방법에서는 Azure Migrate와 같은 도구를 사용하여 평균 또는 최대 부하를 기반으로 VM의 사용률을 

  계산하고 이를 기반으로 AVS 노드의 크기를 정확하게 조정하는 데 도움이 됩니다. VM에 대해 16개의 vCPU를 구성했지만 4개만

  활용하더라도 4개의 vCPU만 고려하기 때문에 이 크기는 적절한 크기입니다. 따라서 사이즈는 정확하고 올바른 사이즈입니다.

  사용 가능한 또 다른 방법은 RVTools 가져오기 기반 평가입니다. 이것은 수동 방법으로 달성하는 것과 마찬가지로 있는 그대로의    크기 조정입니다. 이것은 UI 중심이며 수동 계산이 포함되지 않습니다.

어플라이언스 기반 방법과 관련된 단점은 일정 기간 동안 도구를 실행하고 성능 메트릭을 캡처하는 데 시간이 필요하다는 것입니다. AVS 노드의 즉각적인 크기 조정을 원하거나 예산 견적이 필요한 경우 있는 그대로의 크기 조정을 사용할 수 있습니다.

수동 방법을 사용하여 있는 그대로 크기를 조정하고 VMware 환경에 있는 모든 VM의 vCPU, 메모리 및 스토리지 사용률을 캡처하려면 RVTools가 이상적인 도구로 눈에 띕니다.

수동 방법

대부분의 VMware 관리자는 RVTools를 통해 VMware 클러스터를 내보내는 방법을 알고 있으며, 그렇지 않은 경우 웹 사이트에서 도구를 다운로드할 수 있습니다 https://www.robware.net/home 필요한 세부 정보가 포함된 'vminfo'를 포함하여 여러 탭을 찾을 수 있습니다. 이 탭에서 관련 숫자를 합산합니다.

CPU: VM과 연결된 vCPU를 표시합니다.

메모리: 할당된 메모리가 포함됩니다.

In-use-MiB: 현재 사용된 스토리지를 보여줍니다.

프로비저닝된 MiB: 할당된 스토리지가 포함됩니다. 외부 스토리지의 도움으로 요구 사항에 따라 스토리지를 확장할 수 있으므로 이 열은 고려하지 않으므로 In-use-MiB만 고려합니다.

AVS 노드 크기 조정:

총 vCPU, 메모리 및 사용 중인 스토리지를 얻으면 이를 Azure 노드가 제공할 수 있는 것과 비교해야 합니다. 예를 들어 보겠습니다. AVS 노드의 3개 노드(최소)는 아래 크기를 제공합니다. CPU 및 메모리 요구 사항에 따라 그에 따라 배포 크기를 조정해야 합니다. 스토리지 고려 사항은 약간 다르며 다음 섹션에서 노드에서 사용 가능한 공간을 계산하는 방법에 대해 자세히 살펴보겠습니다. 그러나 노드 크기를 조정하는 동안 주로 vCPU 및 메모리를 고려해야 하는데, 그 이유는 Azure NetApp 파일 또는 Azure Elastic SAN과 같은 원격 스토리지 옵션을 사용하여 스토리지를 확장할 수 있기 때문입니다. 이 시나리오에서는 스토리지 요구 사항에 맞게 노드 수를 확장할 필요가 없습니다.

이제 rvtools 크기에 따라 필요한 총 vCPU, 메모리 및 스토리지를 얻은 다음 요구 사항에 따라 AVS 노드 수의 크기를 조정할 수 있습니다.

스토리지 크기 조정:

AVS 노드에서 RAW 스토리지를 가져오며 사용 가능한 공간은 아래에 언급된 여러 요인에 따라 달라집니다.

  VM 스토리지 정책을 생성하는 동안 선택하는 RAID(RAID 1, 5 또는 6)

  스토리지 정책 중에 선택한 FTT(FTT 1, 2 및 3)

  사용 가능한 Slack 공간(SLA를 받으려면 최소 25%의 여유 공간이 필요함)

  체크섬(평균 5%)

  공간 효율성 비율(평균적으로 1.50이지만 저장되는 데이터와 얻을 수 있는 공간 효율성에 따라 다릅니다. 증가할 수도 있습니다)

  AVS의 스토리지 및 고려 사항에 대해 더 알고 싶다면 이 주제에 대한 이전 블로그를 참조할 수 있습니다.

https://www.azuredoctor.com/posts/Demystifying-Storage-types-in-AVS/

위에서 언급한 요인으로 인해 사용 가능한 공간이 달라집니다. 빠른 계산을 위해 가장 유용한 스토리지를 제공하는 AV36P에 대한 RAID 크기 조정을 아래에 캡처했습니다. FTT를 2에서 3으로 늘리려면 사용 가능한 스토리지는 줄어들지만 복원력은 더 높습니다. AVS의 SLA에 따라 노드가 6개 이상인 경우 최소 FTT 2를 선택해야 합니다.

고려 사항:-

체크섬: 5%

여유 공간: 25%

공간 효율 비율: 1.50

크기 조정의 예

AVS 노드 수를 얻는 방법에 대한 한 가지 예를 들어 보겠습니다. rvtool 후 500개의 vCPU와 3.5TB 메모리가 필요하며 90TB의 사용 가능한 스토리지가 필요하다는 것을 알게 되었습니다. AVS 크기 조정을 위해 AV36p SKU를 고려합니다. 이와 함께 1:4의 CPU 오버커밋을 고려할 것입니다. 따라서 1:4 오버커밋으로 500개의 vCPU를 맞으려면 4개의 노드, 36 x 4 = 144개의 물리적 코어, 144 x 4 = 576개의 vCPU가 필요합니다. 그러나 AVS AV36p의 4개 노드를 사용하면 768 x 4 = 3072GB의 메모리만 얻을 수 있습니다. 따라서 3.5TB의 메모리에 맞는 추가 노드가 하나 필요하므로 메모리가 4개의 노드를 선택할 때 병목 현상이 발생하기 때문에 총 5개의 AV36p 노드가 필요합니다. 5개의 AVS 노드를 사용하면 최대 77.6TB의 사용 가능한 스토리지만 제공되므로 ANF 또는 ESAN에서 추가 스토리지를 얻을 수 있습니다. 따라서 크기를 고려해야 하는 외부 저장소는 12.37TB입니다. 여기 있어. 전체 마이그레이션에 필요한 5개의 AV36p 노드입니다.

그러나 이는 크기가 있는 그대로이고 CPU 세대 및 NVMe 스토리지에 따라 실제 요구 사항이 감소할 수 있습니다. 기본적으로 배포 중에 3노드의 최소 클러스터 배포로 시작하여 VM을 마이그레이션하고 더 많은 메모리와 vCPU가 필요할 때 노드 수를 늘리기 시작합니다.

Azure Migrate 기반 크기 조정

수동 방법을 사용하여 수행한 위의 크기 조정은 Azure Migrate를 사용하여 보다 자동화된 방식으로 크기를 조정할 수 있습니다. Azure Migrate를 통해 수행하는 경우에도 스토리지 크기 조정 및 CPU 오버 커밋에 대한 메트릭 및 매개 변수는 동일하게 유지됩니다. 

Azure Migrate를 사용하여 수행할 수 있는 AVS 크기 조정에는 두 가지 주요 유형이 있습니다.

어플라이언스 기반: Azure Migrate 어플라이언스를 설치하고 성능 평가 또는 있는 그대로 크기 조정 내보내기

가져오기 기반: rvtools 내보내기가 있는 경우 있는 그대로의 크기 조정을 제공하는 Azure Migrate 프로젝트에서 Excel 파일을 가져올 수도 있습니다.

어플라이언스 기반

첫 번째 옵션에 대해 이야기해 보겠습니다., 이는 대상이 Azure VM일 때 사용된 프로세스와 매우 유사합니다.

즉, Azure Migrate 어플라이언스를 설치하고, vCenter Server 세부 정보를 추가하고, VM의 성능 기록을 수집하도록 합니다. 여기서 유일한 변경 사항은 Azure VM 기반 평가 보고서를 만드는 대신 AVS 평가를 선택한 다음 크기 조정을 위한 매개 변수를 제공해야 한다는 것입니다. 여기에서 vCPU, VM의 메모리 성능을 확인한 다음 AVS 노드에 대한 권장 사항을 제공하는 성능 기반 평가를 수행할 수 있습니다. 있는 그대로 원하는 경우 이를 수행하고 현재 vCPU 및 VM의 메모리를 기반으로 AVS 노드 수를 제공할 수도 있습니다.

Azure Migrate 기반 어플라이언스를 사용하여 모든 서버를 검색했다고 가정하면 평가를 만드는 방법으로 이동합니다.

AVS 평가를 선택합니다.

검색 원본이 Azure Migrate Appliance로 선택되어 있는지 확인합니다.

출력이 이러한 선택을 기반으로 하므로 올바른 매개변수 세트를 선택했는지 확인합니다.

평가할 서버를 선택합니다.

AVS 평가가 생성된 후 보고서의 출력입니다. 그러면 필요한 노드 수와 스토리지도 표시됩니다.

가져오기 기반

이는 RVTools 가져오기 방법을 기반으로 하는 그대로의 크기입니다. 스토리지 및 노드에 필요한 수동 계산은 없습니다. 

Azure Migrate 프로젝트에서 가져와야 하는 rvtool 내보내기 데이터가 필요하며 필요한 AVS 노드 크기 조정 및 스토리지를 제공하기 위해 계산을 수행합니다. Azure Migrate를 통해 이루어지지만 이 방법에는 어플라이언스 설치가 필요하지 않습니다. 현재 미리 보기로 제공됩니다.

평가를 생성하기 전에 이러한 모든 서버가 검색된 서버 아래에 표시되도록 RVtools를 가져와야 합니다.

RVTools의 미리보기 옵션 선택

검색된 서버가 rvtools 데이터로 채워져 있음을 알 수 있습니다.

이제 다시 한 번 평가를 만들지만 이번에는 Azure Migrate 어플라이언스 대신 가져온 서버를 선택합니다.

서버 선택.

평가 만들기.

이제 평가 화면의 출력에 AVS 평가 수가 1로 표시됩니다.

이 화면에는 생성된 총 평가 수가 표시됩니다.

평가를 열면 스토리지와 함께 필요한 AVS 노드의 전체 크기가 표시됩니다.

Azure 가격 계산기를 사용하여 AVS 비용 계산

이 섹션에서는 Azure 가격 계산기를 통해 샘플 AVS 크기 조정을 수행해 보겠습니다. 

여기에 Express Route Gateway, Azure Route 서버 또는 방화벽과 같은 네트워킹 구성 요소를 추가하지 않고 랜딩 존이 구성되고 준비되기를 바라며 AVS 비용 자체를 추정하고 있습니다.

https://azure.com/e/e39866f1330f4aa1b7b84e582940fb88이 블로그가 AVS 노드 평가에 도움이 되기를 바랍니다. 이 작업이 완료되면 네트워크 토론 및 전체 마이그레이션 계획을 빠르게 시작할 수 있습니다.즐거운 학습 되세요!