깡민쓰~IT Story

많은 조직이 추가 리소스를 클라우드로 이전하고 있으며, 클라우드 비용이 IT 예산에서 큰 비중을 차지하고 있습니다. Azure 비용 관리를 시작하면 비용을 절감하고 최적화하는 데 도움이 되는 기본 제공 가격 모델, 비용을 시각화하고 관리하는 데 도움이 되는 도구, 그리고 낭비를 줄이고 기존 리소스 활용도를 높이는 데 사용할 수 있는 검증된 모범 사례가 제공됩니다.

이 게시물에서는 Azure 가격 책정 구조의 핵심 요소인 5가지 비용 절감 옵션을 살펴보고, VM 크기 조정, 미사용 디스크 찾기, 워크로드를 컨테이너로 이전하는 등 비용 절감을 위한 7가지 모범 사례를 제시합니다.

이 기사에서는 Azure에서 비용을 절감하는 12가지 방법에 대해 알아봅니다.

1. Azure 예약 인스턴스
2. Azure 하이브리드 혜택
3. Azure 개발/테스트 가격
4. AWS와의 가격 매칭
5. Azure 비용 관리
6. VM 적정 크기 조정
7. B 시리즈 VM 사용
8. 컨테이너로 작업 부하 전환
9. 사용하지 않는 디스크 찾기 및 삭제
10. 데이터베이스 VM에서 탄력적 데이터베이스로 이동
11. 스토리지 계층화 사용
12. Cloud Volumes ONTAP을 사용하여 Azure 스토리지 비용 최적화

Azure 비용 절감 옵션 내장

Azure 클라우드는 비용 절감을 위한 여러 가지 기본 옵션을 제공합니다. Azure 비용 최적화 전략을 계획할 때 이러한 옵션을 잘 숙지해야 합니다.

1. Azure 예약 인스턴스

Azure를 사용하면 인스턴스를 예약하고 상당한 할인 혜택을 받을 수 있습니다. 예약 옵션은 세 가지입니다.

• 1년 예약 인스턴스 - 1년치를 선불로 지불해야 하며 대부분의 가상 머신에 대해 40-45% 할인이 제공됩니다.
• 3년 예약 인스턴스 - 3년치를 선불로 지불해야 하며 대부분의 가상 머신에 대해 60-65% 할인이 제공됩니다.
• 스팟 가격 책정 - Azure Marketplace에서 사용 가능한 용량에 대해 입찰하고 80-90% 할인된 가격으로 인스턴스를 받을 수 있습니다. 그러나 인스턴스는 사전 통지 없이 중단될 수 있으므로 특정 유형의 작업에만 적합합니다.

모든 VM 유형과 관리 서비스에 대한 예약된 가격 세부 정보를 확인하세요 .

2. Azure 하이브리드 혜택

Azure Hybrid Benefit은 Microsoft의 광범위한 기업 설치 기반을 활용하는 프로그램입니다. 이미 Windows Server 또는 SQL Server 라이선스를 보유하고 있고 온프레미스에서 사용 중이라면, 해당 라이선스를 클라우드로 가져올 수 있습니다.

Azure VM 비용에는 Microsoft 소프트웨어 라이선스 비용이 포함되므로 이미 라이선스가 있는 경우 VM 비용 할인을 받을 수 있으며, 기존 라이선스를 사용하여 Windows Server VM, SQL Server VM 및 관리형 SQL Database 서비스에 대한 할인도 받을 수 있습니다. 예약 인스턴스와 하이브리드 혜택 프로그램을 함께 사용하면 최대 80%까지 할인받을 수 있습니다.

또한 Windows Server와 SQL Server 2008을 Azure로 마이그레이션하면 3년 동안 보안 업데이트가 무료로 제공되므로 보안 및 규정 준수를 위해 라이선스를 계속 연장할 필요가 없습니다.

Azure Hybrid Benefit 계산기를 사용하여 소유한 라이선스 수에 따라 정확한 절감액을 추정해 보세요.  

3. Azure 개발/테스트 가격

Azure는 개발 및 테스트에 서비스를 사용하는 경우 대폭 할인된 가격을 제공합니다. 

• Microsoft 소프트웨어에 대해 Windows 및 SQL Server VM을 무료로 실행합니다. 이러한 VM은 일반적으로 Microsoft 소프트웨어 라이선스 비용 때문에 Linux VM보다 더 비싸지만 개발/테스트의 경우 Linux VM과 동일한 가격으로 제공됩니다.
• Azure SQL Database 최대 55% 할인
• 로직 앱 최대 50% 할인
• 기타 서비스에 대한 다양한 할인 - 자세한 내용은 여기를 참조하세요.

4. 가격 매칭

Azure는 유사 서비스에 대해 AWS 비용과 동일한 가격을 보장합니다. 가격은 AWS 가격 인하에 따라 3개월마다 조정됩니다. 가격 매칭은 다음 서비스에 대해 가능합니다.

• Linux VM - AWS EC2와 비교
• Azure Functions—AWS Lambda와 비교
• Block Blob Storage(ZRS HOT) - Amazon S3 Standard와 비교
• Block Blob Storage(ZRS COOL) - Amazon S3 Standard-Infrequent Access와 비교

5. Azure 비용 관리

비용 관리는 Azure Portal에 기본 제공되는 무료 도구입니다. Azure 서비스 비용 절감에 도움이 되는 데이터를 수집하고 분석을 지원합니다. Azure는 Azure Advisor, 비용 계산기, 비용 분석, Azure Budgets, 그리고 Azure와 다른 클라우드의 리소스 사용량 및 지출을 추적할 수 있는 Cloudyn 등 비용 계획 및 최적화를 위한 추가 도구를 제공합니다.

Azure 비용 최적화: 팁과 모범 사례

Azure에서 기존 리소스를 보다 효과적으로 활용하는 데 사용할 수 있는 검증된 모범 사례 몇 가지를 소개합니다.

6. VM 크기 조정

Azure는 다양한 하드웨어 및 성능 기능을 갖춘 광범위한 VM을 제공합니다. 동일한 워크로드에 여러 VM을 사용하여 가장 낮은 비용으로 가장 높은 처리량이나 성능을 제공하는 VM을 확인해 보세요. 가장 성능이 좋은 VM을 선택하고 자동 크기 조정을 사용하여 실제 워크로드에 맞게 VM 수를 자동으로 조정하세요.  

모든 VM이 100% 사용되었을 때 최적의 비용을 달성할 수 있다는 점을 기억하세요. Azure Monitor를 사용하여 메트릭을 모니터링하고, 자동 크기 조정이나 기타 방법을 사용하여 사용률에 따라 머신을 추가 및 제거하여 이 목표에 최대한 근접하도록 노력하세요.

7. B 시리즈 VM 사용

Azure는 일반적으로 유휴 상태이다가 갑자기 사용량이 급증하는 애플리케이션을 위해 설계된 B 시리즈 가상 머신을 제공합니다. B 시리즈 VM은 일반적으로 낮은 기본 CPU 성능 수준으로 실행되며, 이 낮은 성능이 워크로드에 적합한 한 크레딧이 누적됩니다. 사용량이 갑자기 급증하면 CPU 성능이 증가하고, 크레딧을 사용하여 추가 용량에 대한 "비용"을 지불합니다. 크레딧이 소진되면 머신은 기본 CPU 성능으로 돌아갑니다.

B 시리즈 VM은 동급 VM 대비 15~55% 할인 혜택을 제공합니다. 가용성이 필요하지만 가끔씩 높은 성능이나 처리량이 필요한 워크로드가 있는지 파악하여 B 시리즈 VM으로 이전하세요.

8. 컨테이너로 워크로드 전환

컨테이너는 VM보다 가볍습니다. 하나의 물리적 호스트에서 여러 컨테이너화된 애플리케이션을 실행할 수 있으며, 경우에 따라 호스트당 최대 수십 개의 컨테이너를 실행할 수 있습니다. 애플리케이션을 컨테이너로 리패키징하면 VM 사용률을 줄이고 비용을 크게 절감할 수 있습니다. 기존 Azure VM에서 Azure Kubernetes Service(AKS)와 같은 컨테이너 서비스로 애플리케이션을 전환하는 것을 고려해 보세요.

9. 사용하지 않는 디스크 찾기 및 삭제

Azure는 가상 머신을 삭제해도 가상 디스크를 삭제하지 않습니다. 디스크는 사용자가 식별하여 삭제할 때까지 계속 사용되며 비용이 발생합니다. Azure Portal의 디스크 화면에는 현재 저장소 계정에서 활성화된 모든 관리 가상 디스크가 표시됩니다. 각 디스크의 소유자를 확인하세요. 이 항목이 비어 있으면 해당 디스크가 어떤 VM에서도 사용되지 않으며 삭제될 가능성이 있음을 의미합니다.

Azure에 관리되지 않는 디스크가 있을 수도 있습니다. 디스크(클래식) 화면 에서 이러한 디스크를 검색하세요 . VM에 연결되지 않은 관리되지 않는 디스크를 찾은 경우 다음 지침 에 따라 스크립트를 실행하여 삭제하세요.

10. 데이터베이스 VM에서 Elastic Database로 이동

Azure에서 SQL Server 또는 기타 데이터베이스 서버를 실행하면 비용이 빠르게 증가할 수 있습니다. VM 자체도 비용이 많이 들고, 데이터베이스 인스턴스의 사용률이 낮은 경우가 많으며, 기존 온프레미스 배포 방식처럼 인스턴스 간에 부하를 분산하는 것도 쉽지 않습니다. 대부분의 경우 PaaS 모델로 전환하면(예: SQL Server 인스턴스에서 Azure SQL 서비스로 이전) 실제 사용된 데이터베이스 리소스에 대해서만 비용을 지불하기 때문에 비용이 크게 절감됩니다.

11. 스토리지 계층화 사용

Azure 배포 시 스토리지는 일반적으로 지속적인 비용에서 큰 부분을 차지합니다. Azure Blob Storage는 프리미엄, 핫, 쿨 및 보관 스토리지 계층(월 GB당 내림차순 가격)과 다양한 중복성 옵션을 제공합니다(중복성이 낮을수록 스토리지 비용이 절감됩니다). Azure 스토리지 가격 책정 관련 문서에서 다른 스토리지 서비스의 가격에 대해 자세히 알아보세요 .

덜 민감하거나 액세스 빈도가 낮은 데이터를 저비용 계층이나 중복성이 낮은 옵션으로 이동하면 비용을 절감할 수 있습니다. 애플리케이션에 스토리지 계층화 자동화를 구축하여 더 이상 필요하지 않은 데이터가 자동으로 저비용 계층으로 이동되도록 하세요.

*자본 비용(CAPEX)**과 **운영 비용(OPEX)**은 IT 인프라 투자나 클라우드 이전(Assessment 포함)에서 반드시 구분해야 할 핵심 개념입니다. 아래에서 각각의 정의, 차이점, 구분 이유를 자세히 설명드릴게요.

💰 1. 자본 비용 (CAPEX, Capital Expenditures)

✅ 정의:

• 초기 투자 비용으로, 물리적인 자산을 구매하거나 구축할 때 드는 비용입니다.
• 일반적으로 장기간(수년) 사용하는 자산에 대해 선불 형태로 지불합니다.

✅ 예시:

• 데이터센터 장비 구매 (서버, 스토리지, 네트워크)
• 소프트웨어 영구 라이선스 구매
• 빌딩 내 서버룸 공사 비용
• IT 인프라 구축 컨설팅 비용

✅ 회계 처리:

• 자산으로 분류되어 감가상각(depreciation) 처리됨 (예: 3~5년간 분할 비용 인식)

🛠 2. 운영 비용 (OPEX, Operating Expenditures)

✅ 정의:

• 운영 중 반복적으로 발생하는 비용으로, 서비스 유지를 위해 정기적으로 지출하는 비용입니다.
• 유지, 구독, 사용 기반의 비용입니다.

✅ 예시:

• 클라우드 서비스 구독 요금 (Azure, AWS 등)
• 서버 전기료, 냉방/공간 임대료
• 인건비, 유지보수 계약비
• 라이선스 연간 갱신 비용
• 백업/보안/모니터링 서비스 비용

✅ 회계 처리:

• 매월/매년 지출되며, 해당 회계 기간에 전액 비용 처리

🧾 3. CAPEX vs OPEX 비교

📊 4. Assessment에서 CAPEX와 OPEX를 구분하는 이유

🎯 이유 1: 비용 구조의 변화 분석

• 온프레미스 → 클라우드 전환 시 CAPEX 중심 구조 → OPEX 중심 구조로 바뀜
• 기업 입장에서는 지출 형태 변화가 재무적으로 큰 의미를 가짐

🎯 이유 2: ROI, TCO 평가 정확성

• 클라우드 이전에 따른 총소유비용(TCO) 계산 시:
  • CAPEX(서버 감가상각) vs OPEX(클라우드 사용료)로 비교
• ROI 산정 시 자본투자 대비 절감되는 연간 OPEX도 포함

🎯 이유 3: 비즈니스 의사결정 지원

• 자산으로 보유할지(내부 구축) vs 서비스로 사용할지(외부 위탁)
• 예산 집행 방식에 따라 재무팀, IT팀, 경영진의 관점이 다르므로 구분이 중요

📝 정리 문장 (Assessment 보고서용 표현 예시)

"본 Assessment에서는 기존 인프라의 자본 비용(CAPEX)과 클라우드 전환 시 발생하는 운영 비용(OPEX)을 구분하여 총소유비용(TCO) 분석을 수행하였으며, 비용 구조의 유연성 및 재무 투명성 확보 관점에서 클라우드 기반 모델이 유리함을 도출하였습니다."

RVTools is a free tool widely known in the VMware community and is a great resource for VMware administrators. With RVTools, you can manage ESX servers, virtual machines, and vCenter servers. It is also very easy to use and gives specific health check information about the environment, making it an essential VMware utility.

Installing RVTools: A Step-by-step Guide

Installing RVTools on your Windows machine is a straightforward process. Simply download the latest version from the official RVTools website, located here:

• RVTools – Download | RVTools (robware.net)

Run the installer, and follow the on-screen instructions. Remember, RVTools interacts directly with the VMware vSphere Management SDK. It means you must have VMware Tools installed on your virtual machines.

Navigating RVTools: A Closer Look at the Tabs

RVTools displays information through several tabs, each offering insight into different aspects of your VMware infrastructure. Some of the tabs VIAdmins reference most often include:

• vInfo tab: Displays general information about your virtual machines.
• vDisk tab: Provides detailed information about the disk properties of your virtual machines.
• vHealth tab: Conducts health checks and points out potential issues in your vSphere environment, including hosts, virtual machine

Unleashing the Power of RVTools for VMware Health Checks

RVTools isn’t just a tool for display information. It’s a great utility for conducting health checks within your vSphere environment. The vHealth tab is a “go-to” source of information for vSphere health checks. It checks for things like:

• VMware tools not installed or out of date
• Zombie VMDKs
• CD Drives connected
• Inconsistent folder names
• Overprovisioned hosts
• Other Best practices

These health checks are a great way to make sure your VMware environment runs smoothly. RVTools makes these checks easier by providing specific information and alerts on potential issues.

Leveraging RVTools for VMware Resource Management

RVTools is also an excellent tool for managing resources within your VMware environment. It provides insights into resource pools, memory, disks, partitions, network configurations, and more. You can monitor CPU usage, memory allocation, and even the status of your distributed switches and distributed ports.

RVTools Tabs and Features

The vInfo Tab

The vInfo tab in RVTools provides a comprehensive overview of your virtual machines, including their current power state, connection state, VMware Tools installed status, and ESX host data. Notably, the tab displays whether VMware Tools is installed, ensuring your VMs are running the latest version of this crucial software.

The vDisk Tab

The vDisk tab offers detailed information about your virtual machines’ disks. It provides specific information about each VM’s disks, memory, partitions, and network configurations. It also shows whether CD drives and USB devices are connected, proving useful when troubleshooting hardware issues.

The vHealth Tab

The vHealth tab takes health checks in your vSphere environment to a whole new level. It flags potential inconsistencies, such as outdated VMware Tools or inconsistent folder names, and helps you maintain the overall health of your ESX server and the VMs it hosts.

Efficiently Working with vCenter Server

RVTools interfaces smoothly with vCenter Server, providing administrators with a comprehensive overview of their vSphere environment.

This includes detailed information about ESX hosts, distributed switches, distributed ports, service consoles, VM kernels, and even license info. This data is invaluable when managing complex virtual environments.

Creating a Single XLSX Report

One of RVTools’ useful features is its ability to generate a single XLSX file report containing all the data it collects. Using an XLSX merge utility (included with RVTools), you can consolidate data from multiple vSphere environments into one comprehensive report. This feature saves time and simplifies data analysis, proving invaluable for VMware administrators.

RVToolsMergeExcelFiles.exe -input C:\myfiles\vcsa-site1-vHealth.xlsx;C:\myfiles\vcsa-site2-vHealth.xlsx -output C:\myfiles\allvcenters-vHealth.xlsxCopyCopy

SRM Placeholder and Other Advanced Features

RVTools also includes support for SRM Placeholder VMs used in disaster recovery scenarios. This feature and multipath info for iSCSI, FC, and NFS datastores make RVTools a versatile and powerful tool for managing VMware environments.

Referer. Learn how to configure autostart of virtual machine on VMware.

RVTools FAQs

1. What is RVTools and why is it beneficial for VMware environments? RVTools is a free utility that connects to your vSphere environment and collects detailed information about your ESX hosts, virtual machines, and other components. This tool is beneficial as it helps VMware administrators perform health checks, manage resources, and generate detailed reports efficiently.

2. How does RVTools interface with vCenter Server? RVTools interfaces smoothly with vCenter Server, providing a comprehensive overview of your vSphere environment. This includes details about ESX hosts, distributed switches, distributed ports, service consoles, and VM kernels, aiding in effectively managing your VMware environment.

3. Can RVTools provide specific information about distributed switches and ports? RVTools offers detailed insights into distributed switches and ports in your vSphere environment. It provides information about HBAs, NICs, switches, ports, distributed switches, and service consoles. This network data is invaluable for troubleshooting and planning network expansions.

4. How does RVTools assist with resource management in a VMware environment? RVTools provides detailed data about resource pools, helping VMware administrators manage resources more efficiently. It shows the allocation and usage of CPU, memory, disks, and partitions, which assists in balancing workloads and optimizing resource utilization across your VMware environment.

5. How does RVTools help with reporting? RVTools has a feature to generate a single XLSX report containing all the data it collects. Using an XLSX merge utility, you can consolidate data from multiple vSphere environments into one comprehensive report, simplifying data analysis and saving time for VMware administrators.

• 시나리오 : 최근의 업무에서 고객 중 한 명이 IT 자산의 패치 및 규정 준수 보고를 관리하는 데 따르는 어려움을 설명했습니다. 하이브리드 설정이었고 Azure를 포함한 여러 클라우드에 인프라가 분산되어 있었습니다. Windows가 있었지만 많은 부분이 SUSE 및 RedHat Linux 서버에 있었습니다. 고객은 중앙에서 패치 및 보고를 자동화하기를 원했습니다.
• 해결책 : 제목에서 알 수 있듯이 저희는 그들에게 Azure Update Manager를 도입하라고 요청했습니다. 온프레미스와 멀티 클라우드 에스테이트에 모두 적용되었습니다. 고객은 Azure Monitor를 사용하여 만든 규정 준수 대시보드를 가지고 있으며, 이는 요구 사항에 따라 사용자 지정되었습니다.

Azure 업데이트 관리자란 무엇입니까?

Azure Update Manager는 온프레미스 서버와 GCP, AWS, OCI, Azure와 같은 클라우드 공급자에 호스팅된 서버에 대한 패치를 예약하는 데 사용되는 클라우드 기반 솔루션입니다. Azure Update Manager 자체는 클라우드 서비스이므로 어플라이언스로 설치할 수 없습니다. 이 서비스는 추가 비용 없이 Azure에서 기본적으로 활성화됩니다. 따라서 요새나 방화벽처럼 이 서비스를 배포할 필요가 없습니다. 모든 서버는 확장 기능을 통해 AUM 서비스에 보고합니다. 따라서 기본적으로 후드 아래에는 Azure VM 또는 Azure Arc 지원 VM에 설치된 확장 기능입니다. 맞습니다. Azure Arc 지원 VM입니다. Azure 외부에 호스팅된 VM이 있고 Azure Update Manager를 사용하려면 먼저 해당 서버에서 Arc를 활성화해야 합니다. 그런 다음 AUM을 확장 기능으로 활성화할 수 있습니다.

서버가 AUM에 온보딩되면 AUM 서비스에 규정 준수 상태를 보고하고 Azure Portal에 있는 AUM 콘솔에서 패치를 예약할 수 있습니다. Azure Update Manager의 주요 작업은 다양한 구성에 따라 서버에 패치를 다운로드하도록 지시하는 것입니다. 머신에 패치를 다운로드할 위치를 지시하지 않습니다. 예를 들어 리포지토리 서버를 제공하지 않습니다. VM/서버가 AUM에서 패치를 다운로드하라는 지침을 받으면 머신의 로컬 구성에 따라 패치를 획득합니다. WSUS(Windows Server Update Server)와 같거나 인터넷을 통해 직접 또는 프록시 서버를 통해 패치를 획득합니다. 서버는 패치를 다운로드하기 위해 연결하고 완료되면 최신 규정 준수 상태를 AUM에 보고합니다.

Arc란 무엇입니까?

AUM에 대해 논의하고 심층적으로 살펴보기 전에 Arc에 대해 간략하게 살펴보겠습니다. Arc는 단일 창, 즉 Azure에서 모든 워크로드를 보고 중앙에서 관리할 수 있는 플랫폼을 제공합니다. Azure Monitor, Azure Update Manager, Defender 및 기타 여러 솔루션과 같은 Azure 서비스를 온프레미스 서버에 배포하는 데 도움이 됩니다. 이는 먼저 모든 서버에 Azure 연결된 머신 에이전트를 설치하여 수행됩니다. CMA가 설치되면 머신은 Arc 지원 서버가 됩니다. 여기에서 확장을 통해 원하는 Azure 솔루션을 활성화할 수 있습니다.

Arc-Enabled VM에 배포할 수 있는 확장 프로그램이 많이 있습니다. 아래 링크에 설명되어 있습니다.

https://learn.microsoft.com/en-us/azure/azure-arc/servers/manage-vm-extensions#windows-extensions

Arc Key Vault 확장을 사용하여 온프레미스 서버의 인증서 갱신에 대한 블로그 게시물을 작성했습니다. 아래에서 블로그를 찾을 수 있습니다.

https://www.azuredoctor.com/posts/arc-keyvault/

Windows 서버에서 AUM이 작동하는 방식:

이전에 언급했듯이 AUM은 서버가 패치 업데이트를 수신하고 연결할 리포지토리 서버를 제공하지 않고, 대신 오케스트레이터 역할을 하여 지정한 일정에 따라 서버에 패치를 다운로드하도록 알립니다. 예를 들어, 매월 마지막 날, 패치 화요일 이틀 후, 주간 또는 월간 타임라인 등입니다. 서버가 지침을 받으면 WSUS 리포지토리 또는 Microsoft 업데이트에 연결합니다. 이는 머신에 설정된 구성에 따라 달라집니다.

저는 고객이 데이터센터에 로컬로 WSUS 서버를 두고, Azure와 다른 클라우드 공급자에 WSUS를 두고, Windows 서버가 인터넷을 통해 Microsoft Update에서 직접 패치를 다운로드하지 않고 WSUS를 로컬 저장소로 사용하는 것을 보았습니다. 하지만 WSUS에 의존하고 싶지 않다면 프록시나 방화벽을 통해 Windows 업데이트 URL을 직접 허용 목록에 추가하면 서버가 그에 따라 최신 업데이트를 다운로드합니다.

Linux에서 AUM이 작동하는 방식:

리눅스에서 AUM의 동작은 윈도우 서버와 거의 같습니다. AUM은 리눅스 저장소를 제공하지 않지만 시스템이 구성된 저장소에서 업데이트를 받도록 합니다. AUM의 역할은 일정에 따라 업데이트를 트리거하는 것입니다.

Linux를 사용하는 AUM에는 여러 옵션이 있습니다. Linux 서버가 호스팅되는 위치에 따라 다릅니다.

온프레미스:

Linux 서버가 온프레미스에 호스팅된 경우 로컬 개인 저장소 또는 공개 저장소를 사용하여 OEM에서 최신 업데이트를 다운로드해야 합니다. SUSE 또는 RedHat 서버가 있고 SUSE Manager 또는 RedHat 위성 서버에 대한 라이선스가 있는 경우 이러한 서버는 저장소 역할을 하고 AUM은 규정 준수 확인, 패치 업데이트 일정 및 보고를 위한 오케스트레이터 역할을 합니다. SUSE Manager와 RedHat Satellite는 패치에 사용되며 유료 버전입니다. 신뢰할 수 있고 저렴하다고 생각되는 모든 저장소 서버 타사(3P)를 사용할 수 있습니다.

클라우드의 Linux:

Linux 서버가 Azure, GCP 또는 AWS에 호스팅된 경우. 특히 RedHat 및 SUSE와 같은 공급업체이고 Marketplace에서 라이선스를 구매했거나 Marketplace 이미지에서 배포한 경우 이러한 공급업체는 서버가 최신 업데이트를 다운로드할 수 있는 해당 지역에 로컬로 퍼블릭 클라우드 업데이트 인프라를 제공합니다. VNET 또는 VPC 외부이지만 동일한 지역 내의 퍼블릭 연결이 됩니다.

아래는 각 배포판의 링크와 업데이트 인프라를 제공하는 방식에 대한 설명입니다.

https://www.suse.com/c/accessing-suse-updates-in-aws-when-do-you-need-a-private-repository/

https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/

https://www.suse.com/c/azure-public-cloud-update-infrastructure-101/

https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/

https://learn.microsoft.com/en-us/azure/virtual-machines/workloads/redhat/redhat-rhui?tabs=rhel7

https://access.redhat.com/products/red-hat-update-infrastructure

아래 아키텍처는 Azure Arc와 Public 엔드포인트 및 Azure Private 엔드포인트의 연결을 보여줍니다. Private 엔드포인트를 배치할 위치도 보여줍니다.

아래 아키텍처는 WSUS와 Linux Repo 서버의 배치를 보여줍니다. 멀티 클라우드 설정을 보여줍니다.

이 아키텍처의 Visio 파일 다운로드

Azure Update Manager 비용:

서비스 비용에 대해 논의해 보겠습니다. AUM은 클라우드 서비스입니다. 어플라이언스가 없고 어플라이언스 고가용성 등에 비용을 지불할 필요가 없습니다. 이 모든 것이 서비스에 내장되어 있으므로 이 모든 것을 처리할 필요가 없습니다. Azure Servers용 AUM은 무료입니다. 바로 AUM을 활용할 수 있습니다. Azure Stack HCI 온프레미스에서 호스팅되는 서버가 있는 경우 AUM은 무료입니다. 온프레미스에서 호스팅되는 서버에는 요금이 부과됩니다. 서버당 월 5달러가 청구됩니다. Arc 지원 서버의 AUM은 세 가지 조건에서 무료입니다.

1. Arc를 통해 확장 보안 업데이트를 활성화한 경우
2. Defender for Servers Plan 2를 사용하는 경우
3. Azure Arc가 제공하는 Windows Server Management를 사용하면 활성 소프트웨어 보증이 있는 Windows Server 라이선스나 활성 구독 라이선스인 Windows Server 라이선스를 사용하는 고객은 AUM을 무료로 얻을 수 있습니다.

위 시나리오에 대한 자세한 내용은 아래 링크에서 확인하세요. https://learn.microsoft.com/en-us/azure/update-manager/update-manager-faq#are-there-scenarios-in-which-arc-enabled-server-isnt-charged-for-azure-update-manager

https://techcommunity.microsoft.com/blog/azurearcblog/announce-general-availability-windows-server-management-enabled-by-azure-arc/4303854

이 블로그가 여러분이 AUM을 더 빠르게 배포하고 올바른 아키텍처 패턴을 따르는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

이 블로그는 아직 Azure ESAN 저장소를 탐색하지 않았지만 ESAN과 그 기본 사항에 대해 들어봤지만 워크로드에 어떤 가치를 제공하는지 모르는 사람들을 위한 것입니다. 이 블로그를 읽으면 다음 질문에 답할 수 있는 통찰력을 얻을 수 있습니다.

1. ESAN을 사용해야 하는 이유는 무엇인가요? 디스크 관리 대신 이 서비스를 선택하면 가격상 이점이 있나요? 그리고 얼마나 비용을 절감할 수 있나요?
2. 프로덕션 워크로드에 ESAN을 고려할 수 있나요?
3. 내 워크로드에 ESAN을 배포하기 전에 고려해야 할 제한 사항은 무엇입니까?

ESAN 볼륨을 단계별로 생성하고 VM에 연결하는 방법은 다루지 않습니다. 이는 Microsoft 학습 문서에서 자세히 다룹니다.

기본 정보

시작해 보겠습니다. Azure Elastic SAN(ESAN)은 2022년 10월에 출시되었습니다. ESAN은 VM, AKS 및 AVS를 마운트하는 데 사용할 수 있는 iSCSI LUN을 제공합니다. 2022년 이후로 Elastic SAN에 많은 개선이 있었고 현재 대부분의 Azure 지역에서 이 서비스를 지원합니다.

Elastic SAN이 IOPS와 스토리지를 계산하는 방법 - ESAN을 만들고 기본 단위를 기반으로 1TiB씩 증가하는 총 IOPS와 처리량을 얻습니다. 1TiB의 기본 단위는 5000 IOPS와 200MBps 처리량을 제공합니다. 저렴한 스토리지만 원하는 경우 IOPS/처리량은 제공하지 않고 추가 스토리지만 제공하는 추가 용량 단위를 추가할 수 있습니다.

Elastic SAN의 한 가지 중요한 측면은 Elastic SAN을 생성할 때마다 ESAN의 전체 IOPS와 처리량이 여러 볼륨에서 공유된다는 것입니다.예를 들어, ESAN 20TiB를 생성하면 총 100,000 IOPS와 4000MBps 처리량을 얻게 됩니다.각각 200Gb의 볼륨 두 개를 생성하면 개별적으로 최대 80K IOPS와 1280MBps 처리량까지 확장할 수 있습니다.그러나 Elastic SAN의 부모 Base 단위에서 제공하는 총 IOPS와 처리량을 공유합니다.한 VM이 60K IOPS를 얻고 동시에 두 번째 VM에 50K IOPS가 필요한 경우 두 번째 VM은 40K IOPS만 얻게 되는데, 이는 ESAN의 20TiB에 대한 최대 한도가 100K IOPS이기 때문입니다.
최대 80K IOPS를 얻는 데 필요한 최소 볼륨은 106GiB이고 최대 1280GB/s를 얻으려면 최소 21GiB가 필요합니다.

이제 여러 애플리케이션에 대한 스토리지 요구 사항을 결합하여 단일 Elastic SAN에 넣을 수 있습니다. 비용과 통합 스토리지 이점을 얻을 수 있습니다.
기억해야 할 한 가지는 IOPS와 처리량이 동시에 필요한 모든 중요한 프로덕션 애플리케이션을 단일 ESAN에 넣을 수 없다는 것입니다. 따라서 여러 ESAN 인스턴스에 균등하게 분산해야 합니다. 이는 모든 앱이 동시에 필요한 경우 IOPS/처리량 때문에 ESAN을 해당 한계까지 확장해야 하거나 그렇지 않으면 ESAN이 조절을 시작하기 때문입니다.
200개의 볼륨 그룹을 가질 수 있으며, 하나의 볼륨 그룹은 최대 1000개의 볼륨을 가질 수 있습니다. 따라서 단일 ESAN에 많은 애플리케이션 세트를 모을 수 있습니다.

ESAN 볼륨 데이터는 네트워크를 통해 전송됩니다.

Azure 관리자라면 모든 VM에 디스크 및 네트워크 제한이 할당되어 있다는 사실을 이미 알고 계실 것입니다.VM SKU를 낮추면 제한도 낮아집니다.D4s_v5 크기의 VM에 4TB 프리미엄 SSD 디스크를 연결하는 경우 디스크 IOPS가 7500 IOPS이더라도 이 정도의 IOPS를 사용할 수 없습니다.VM 자체가 최대 6400 IOPS를 지원하기 때문입니다.더 높은 CPU와 메모리가 필요하지 않더라도 VM 크기를 변경하고 더 높은 SKU를 선택해야 합니다.Azure Elastic SAN은 네트워크를 사용하여 저장소에 연결하므로 VM 디스크 제한 제한은 적용되지 않습니다.하지만 이 경우에도 VM 네트워크 제한은 계속 적용됩니다.그러나 VM 네트워크 처리량은 항상 더 높은 편입니다.ESAN에 대한 iSCSI 기반 연결을 실행하는 것과 함께 워크로드에 충분한 네트워크 처리량이 남아 있는지 확인해야 합니다.

아래에서는 IOPS와 처리량을 충족하기 위해 다음으로 사용 가능한 SKU로 이동하는 위와 같은 문제에 직면했다면 관리형 디스크에서 Elastic SAN Volumes로 디스크를 이동하면 얼마나 많은 비용을 절감할 수 있는지 예를 들어 설명하겠습니다.

이제 ESAN이 디스크 스토리지와 비교했을 때 어떻게 배치되는지 비교해 보겠습니다. 또한 지금은 4TiB의 디스크 하나만 고려하겠습니다. ESAN을 고려할 때 일반적으로 더 큰 스토리지 크기의 조합인 Base Unit을 배포하면 모든 볼륨에서 사용할 수 있는 훨씬 더 높은 처리량을 얻을 수 있습니다. 이는 단일 디스크에서는 불가능합니다. 단일 VM에만 연결되어 있고 IOPS를 다른 VM과 공유할 수 없기 때문입니다.
참고: 더 높은 IOPS와 처리량을 제공하는 Performance Plus의 미리보기 기능은 고려하지 않았습니다. 자세한 내용은 아래 링크에서 확인하세요.

https://learn.microsoft.com/en-us/azure/virtual-machines/disks-enable-performance?tabs=azure-powershell

ESAN 대 프리미엄 SSD

Azure Premium SSD인 프로덕션 등급 디스크로 시작하겠습니다. 프로덕션 워크로드에 가장 많이 사용되는 디스크 중 하나입니다.
보시다시피 7500 IOPS와 250MB/s 처리량을 제공하는 4TB 디스크가 있었습니다. 이를 충족하기 위해 Elastic SAN의 2TiB 기본 단위와 용량 단위의 나머지 2TiB를 가져와야 했습니다.
디스크 하나만 있으면 월 266.40달러를 절약할 수 있습니다.

ESAN 대 표준 SSD

제 경험상, 고객은 종종 비생산적 작업 부하에 표준 SSD를 사용합니다. 처리량과 IOPS가 꽤 낮지만, 비생산적 작업 부하에 대한 저렴한 대안이 될 수 있으며, 여기서는 성능을 희생하여 비용을 절감할 수 있습니다.
그러나 이제 표준 SSD를 프리미엄인 Elastic SAN과 비교하면 아래 표에서 볼 수 있듯이 훨씬 더 높은 IOPS와 처리량을 얻을 수 있고 여전히 비용을 절감할 수 있습니다.
ESAN을 사용하면 5K IOPS를 얻고 표준 SSD는 4TiB의 작업 부하에서 500 IOPS를 제공합니다.
여전히 이러한 성능 향상으로 월 약 29.28달러의 비용을 절감할 수 있습니다.

ESAN 대 프리미엄 SSD v2

위의 프리미엄 v1 디스크 예를 살펴보면, 왜 프리미엄 SSD v2와 비교하지 않는지 궁금할 수 있습니다. 프리미엄 SSD v2는 훨씬 더 나은 성능을 제공하고 프리미엄 SSD v1 디스크보다 비용이 저렴합니다. 그럼, 여기 있습니다. 프리미엄 SSD v2의 기본 가격으로 3000 IOPS와 125MB/s 처리량을 얻을 수 있습니다. 이것을 ESAN과 비교하면 ESAN의 기본 단위 1개와 용량 단위 3TiB를 얻을 수 있으며, 한 달에 약 70.90달러를 절약할 수 있습니다. 이 시나리오에는 몇 가지 고려 사항이 있습니다.

1. ESAN은 지역 또는 지역적으로 배포된 VM에서 사용할 수 있습니다. 그러나 Premium SSDv2는 VM이 ​​영역에 있어야 합니다.
2. VM이 가용성 집합에 있거나 지역적으로 배포된 경우 이 디스크를 사용할 수 없습니다.
3. ESAN은 특정 구역에 배포해야 하지만, VM은 지역 내의 모든 구역에서 연결할 수 있습니다. 더 나은 성능을 얻으려면 VM과 ESAN을 같은 구역에 두는 것이 좋습니다.

AVS 시나리오: ESAN 대 ANF 표준

ESAN은 iSCSI 프로토콜을 통해 VM에 연결된 블록 스토리지입니다. ANF는 NFS 또는 SMB 프로토콜을 통해 사용할 수 있는 NAS입니다.
ESAN은 Azure VMware 솔루션 시나리오에서도 사용할 수 있으므로 ESAN과 ANF를 비교하는 것이 좋습니다. ANF는 AVS 워크로드에도 지원되기 때문입니다.
일반적인 읽기/쓰기 I/O인 8KB IOPS를 고려해 보겠습니다. 데이터베이스가 있는 경우 더 높을 수 있으며 웹 또는 앱 서버인 경우 달성된 IOPS가 증가하거나 감소할 수 있는 기준에 따라 더 낮을 수도 있습니다.
표준 계층인 저렴한 ANF 계층을 고려해 보았습니다.
ESAN을 고려하면 월 271달러의 전반적인 절감 효과를 얻을 수 있습니다.

하지만 강조하고 싶은 몇 가지 고려사항이 있습니다.

1. ESAN과 함께 AVS를 사용하려면 ESAN에 대한 개인 엔드포인트를 배포해야 합니다. 개인 엔드포인트의 가격을 알고 있다면 GB당 인바운드 및 아웃바운드 데이터 전송에 약간의 요금이 부과됩니다. 이는 개인 엔드포인트 가격 페이지에서 확인할 수 있습니다. 따라서 매월 ESAN으로의 데이터 전송에 따라 대역폭 비용이 발생합니다. AVS와 함께 ANF를 배포할 때는 이런 일이 발생하지 않습니다. ANF는 VNET에 배포되므로 관련 데이터 전송 비용을 걱정할 필요가 없습니다.
2. ESAN은 현재 스토리지만 제공하지만 ANF는 AVS와 함께 스토리지 측면에서 성숙한 서비스입니다. ANF 데이터 저장소에 호스팅된 VM에 대한 클라우드 백업 확장을 제공합니다. https://learn.microsoft.com/en-us/azure/azure-vmware/install-cloud-backup-virtual-machines
3. ANF는 Azure의 SAP에서 지원되지만 ESAN은 아직 지원되지 않습니다.

제한 사항 및 고려 사항:

Elastic SAN은 불과 2년 된 서비스이므로 많은 개선 사항이 아직 로드맵에 있습니다. 워크로드에 ESAN을 배포하는 것을 고려하기 전에 아래 고려 사항을 염두에 두어야 합니다.

1. Azure 사이트 복구를 통해 VM을 다른 지역으로 복제하는 경우 VM에 연결된 ESAN 볼륨은 지원되지 않습니다.
2. Azure Backup을 통한 ESAN Volume 백업은 현재 GA가 아닙니다. 현재로서는 공개 미리보기에서 사용할 수 없습니다.
3. 백업은 미리보기에 있는 볼륨 스냅샷을 통해 사용할 수 있으며, 이는 ESAN 기능입니다. 이러한 백업 및 DR 기능은 Azure Marketplace 지원 어플라이언스를 통해 백업 도구를 사용하는 경우 타사를 통해 달성할 수 있습니다.
4. Azure VM의 SAP는 현재 ESAN에서 지원되지 않으며, Azure Managed Disk 및 ANF에서만 지원됩니다.
5. 일반 디스크의 스냅샷을 찍은 다음 이를 통해 ESAN 볼륨을 만들 수 있습니다. 이는 미리보기 상태이며 ESAN 볼륨으로 이동하는 데 사용할 수 있습니다.
6. DC 마이그레이션을 평가하고 크기를 조정하는 데 Azure Migrate를 사용하는 경우 해당 도구는 현재 마이그레이션뿐 아니라 평가 대상으로도 관리형 디스크만 지원합니다.
   https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-snapshots?tabs=azure-portal#create-a-volume-from-a-managed-disk-snapshot

위의 비교와 설명이 ESAN이 귀하의 배포에 더 적합한지 확인하고 비용 절감을 달성하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

• 시나리오 : 고객이 하나의 Enterprise 계약 등록을 했고, 그 등록 내에 두 개의 회사를 두고 싶어하는 시나리오를 여러 번 접했습니다. 이 회사들은 같은 모회사에 속해 있지만, IT 인프라와 정책이 다르기 때문에 별도의 Entra Tenants(Azure AD)를 원했습니다. 하지만 청구 파트너를 통해 서명된 단일 Enterprise 계약 등록을 공유하고 싶어했습니다.
• 해결책 : 청구 파트너를 통해 Enterprise Agreement(EA)에 서명하면 결코 단일 Entra 테넌트에 묶이지 않습니다. 하나의 EA는 여러 Entra 테넌트와 연결된 여러 Enrollment 계정을 가질 수 있습니다.

이 블로그는 합병, 인수 전환에 참여하는 사전 판매 담당자가 사용할 수 있습니다. 또한 여러 계약 유형 간에 구독을 이동하는 방법을 알고 싶다면 이전 블로그 게시물을 참조할 수 있습니다. https://www.azuredoctor.com/posts/mergers-and-acquisitions-on-azure/

우리는 한 회사가 IT 인프라를 별도로 관리하는 분사 법인에 대해 별도의 테넌트를 만들고 싶어하지만, 모회사와 Azure 청구를 공유하고 싶어하는 시나리오를 살펴볼 것입니다. 이는 두 번째 법인이 더 큰 회사 그룹의 일부이고 좋은 할인을 협상했으며 그것을 공유하고 싶어하기 때문일 수 있습니다.

주의하세요. 이는 임시 설정일 수도 있습니다. 분사된 법인이 청구 파트너와 새로운 Enterprise Agreement를 설정할 수 없는 시나리오를 가정해 보겠습니다. 분사된 법인이 청구 파트너에게 새로운 법인의 이름을 공개하고 싶지 않고 모든 분사 및 IT 인프라 작업을 비밀리에 수행하고 싶어하기 때문입니다.

그들은 새로운 Entra 테넌트에서 Azure 구독을 설정하고 IT 설정 작업을 할 수 있습니다. 나중에 공식 이름과 등록 작업이 완료되면 새로운 Enterprise Agreement를 구매하고 새로운 EA에서 구독을 새로운 Enterprise Enrollment로 옮길 수 있습니다. 이는 다운타임 없이 Azure 서비스를 재배포하지 않고 완전히 백엔드 이동이 될 수 있습니다. 구독 이동에 대한 자세한 내용은 위에 언급된 블로그를 참조하십시오.

Entra Tenant 생성

고객들 사이에서 제가 발견한 오해 중 하나는 Entra 테넌트는 파트너를 통해 계약을 체결한 후에만 생성될 수 있다는 것입니다. 하지만 실제로 고객은 여러 테넌트를 생성할 수 있습니다. 그리고 테넌트가 생성되면 사용자 ID를 사용하여 등록 계정을 생성할 수 있으므로 구독이 생성될 때마다 사용자 ID의 새 Entra 테넌트에 연결됩니다.

이것이 어떻게 달성될 수 있는지 살펴보겠습니다.

먼저 portal.azure.com을 탐색하고 Entra ID(이전 Azure Active Directory)를 검색합니다.

테넌트 관리를 클릭하면 아래 창이 열리고, 거기에 액세스 가능한 모든 디렉터리가 표시됩니다.

B2C가 아닌 Entra ID를 선택하세요.

이 단계에서는 새 조직의 이름과 새 Entra Tenant를 지정해야 합니다.

goto users로 가서 새로 만든 Entra Tenant에서 사용자 계정을 만듭니다. 이제 Entra Tenant와 사용자를 성공적으로 만들었으므로 다음 단계로 진행할 수 있습니다.

등록 계정 생성

엔터프라이즈 등록에서 여러 등록 계정을 만들 수 있습니다. 기본적으로 등록 계정에서 구독이 생성되면 등록 계정 소유자의 Entra ID와 연결됩니다.

계속해서 등록 계정을 만들어 보겠습니다. 등록 계정을 만들려면 등록에 대한 Enterprise 관리자 역할이 있어야 합니다.

Azure Portal에 로그인하고 Cost Management + Billing으로 이동합니다. 그리고 Enterprise 등록을 선택합니다.

계정을 클릭하면 모든 등록 계정이 열립니다.

참고 사항: 아래 단계를 실행하기 전에 엔터프라이즈 계약의 권한 수준을 직장 또는 학교 교차 테넌트로 변경해야 합니다.

https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/direct-ea-administration#view-and-manage-enrollment-policies

추가를 클릭하고 계정 소유자 이메일을 지정하세요. 이것은 새로 만든 entra 테넌트에 있는 entra 사용자 ID입니다.

이제 두 개의 다른 Entra 테넌트에 두 개의 등록 계정이 있습니다. 등록 계정에서 구독을 생성할 때마다 해당 구독은 새 Entra 테넌트에 연결됩니다.

Enterprise Agreement는 곧 종료되고 고객은 MCA로 전환합니다. MCA에서 동일한 것을 달성하는 방법에 대한 블로그를 곧 쓸 것입니다. 그리고 네, MCA-E에서도 동일한 것이 가능하다는 것을 보았습니다.

콘텐츠 검증을 도와준 Darshit Shah 에게 특별 감사드립니다 .

이 블로그가 분사 시 적절한 기업 계약과 세입자 협회를 설계하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

기본 인터넷 접속 서비스 종료에 대한 공지를 읽어보셨을 수도 있지만, 아직 읽어보지 않으셨다면 여기에서 읽어보시기 바랍니다.

https://azure.microsoft.com/en-us/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet- 입장/

따라서 2025년 9월 30일 이후에는 새로 만든 Azure VM에서 기본 인터넷 액세스가 작동하지 않습니다. 영향을 알고 있는 고객은 이미 워크로드를 위해 인터넷에 접속하기 위해 명시적 아웃바운드 방식으로 전환하기 시작했습니다. 이 변경 사항의 내용, 영향 및 사용할 수 있는 솔루션에 대해 여전히 확신이 서지 않는다면 이 블로그가 도움이 될 것입니다.

• 시나리오 : VNET에서 실행되는 VM이 ​​여러 개 있습니다. 서브넷에 할당된 사용자 정의 경로가 없고 인터넷으로 0.0.0.0/0 트래픽을 보내는 경로도 없습니다. 이 시나리오에서 VM이 인터넷에 연결하려고 하면 여전히 가능합니다. (NSG에 인터넷 바운드 차단 규칙이 없는 경우) VM의 인터넷은 Azure에서 제공하는 동적 IP를 사용합니다. 이는 새로 만든 VM에 대해 2025년 9월 30일에 작동이 중단되며 기존 VM에는 영향을 미치지 않습니다.
• 저는 IP를 제어하지 않고 기본적으로 인터넷 아웃바운드를 하는 것은 어차피 위험한 시나리오라고 생각합니다. 따라서 아웃바운드 인터넷 연결에 대한 일관된 동작을 위해 아래 접근 방식을 사용하는 것이 좋습니다.
• 해결 방법 : Azure에서 제공하는 동적 공용 IP에 의존하는 대신 아래 옵션을 사용하여 명시적 아웃바운드 인터넷 통신으로 전환할 수 있습니다.
  • NAT 게이트웨이
  • Azure 방화벽 / NGFW
  • 인스턴스 레벨 공용 IP
  • 로드 밸런서 - 아웃바운드 규칙

Azure NAT 게이트웨이

이것은 Microsoft에서 가장 간단하고 권장하는 옵션입니다. 이 프로세스는 NAT 게이트웨이를 배포하는 것입니다. NAT GW에는 VNET이 필요하지 않습니다. 이를 최소한 하나의 서브넷에 연결하여 해당 서브넷의 아웃바운드 트래픽이 NAT 게이트웨이 서비스를 통해 이동하도록 해야 합니다. NAT 게이트웨이는 사용자가 제어하는 ​​정적 공용 IP 또는 정적 공용 IP 접두사를 갖습니다.

Azure 방화벽 / NGFW

또 다른 선호되는 옵션은 허브 앤 스포크 아키텍처 패턴을 사용하는 것입니다. 여기서 허브 네트워크에 Azure Firewall을 배포합니다. 그리고 모든 스포크는 스포크로 작동하는 워크로드 VNET이 됩니다. 워크로드 VNET에 사용자 정의 경로가 있어 인터넷 트래픽(0.0.0.0/0)을 Azure Firewall로 가리킵니다. 최적화된 비용을 위해 비용 효율성을 제공하는 Azure Firewall의 기본 SKU 또는 표준 SKU를 배포할 수 있습니다.

다음은 Microsoft 문서에서 발췌한 허브 앤 스포크 아키텍처의 예입니다.

마찬가지로 Palo Alto, Fotigate, checkpoint 등과 같은 타사 NGFW 장치를 Hub 가상 네트워크에 둘 수 있습니다. 이러한 장치는 방화벽을 수용하고 모든 인터넷 아웃바운드 트래픽을 방화벽으로 향하게 합니다.

인스턴스 수준 공용 IP 주소

VM에 직접 공용 IP 주소를 할당할 수 있습니다. 이 접근 방식은 인스턴스 수준 공용 IP 주소로 알려져 있으며, 명시적 인터넷 아웃바운드 연결을 제공합니다. 이는 주로 Azure에서 NVA 및 NGFW 배포에 사용됩니다. 또는 DMZ 워크로드에 사용할 수 있습니다. NIC로 이동한 다음 ipconfig, -> 공용 IP 주소 할당으로 이동합니다. 이 옵션은 가장 선호되지 않는 접근 방식이며 환경에 공용 IP가 너무 많으면 노출 위험이 증가하므로 일반 워크로드에는 권장되지 않습니다.

로드 밸런서 - 아웃바운드 규칙

이 상황을 처리하는 또 다른 방법은 표준 로드 밸런서를 만든 다음 아웃바운드 규칙을 만드는 것입니다. 아웃바운드 규칙 없이 인바운드 공용 IP로만 표준 로드 밸런서를 만들면 인터넷이 작동하지 않습니다. 아웃바운드 규칙을 명시적으로 만들고 인터넷 액세스가 작동하도록 프로토콜과 SNAT 포트 수를 지정해야 합니다.

모든 작업 부하에 로드 밸런서를 사용할 수는 없지만 표준 LB와 이미 연결된 DMZ에 웹 서버가 있는 경우 아웃바운드 규칙 방식을 사용할 수 있습니다.

위의 접근 방식이 Azure에서 네트워크 아키텍처에 대한 정보에 입각한 결정을 내리고 2025년 9월 마감일 전에 필요한 조정을 수행하여 중단을 방지하는 데 도움이 되기를 바랍니다.

즐겁게 학습하세요!

이 블로그에서는 Traffic Manager와 Application Gateway를 사용하여 단일 FQDN이지만 다른 포트를 사용하여 여러 SAP 애플리케이션에 액세스하는 방법을 보여드리겠습니다. 이는 프록시 역할을 하는 웹 디스패처 뒤에 여러 SAP 서버가 있는 SAP 고객에게 일반적인 시나리오입니다. Traffic Manager와 Application Gateway를 사용하면 SAP 애플리케이션에 대한 고가용성, 부하 분산 및 URL 라우팅을 달성할 수 있습니다. 또한 다른 포트에서 다른 SAP 애플리케이션에 액세스하는 데 동일한 FQDN을 사용하여 최종 사용자 경험을 간소화할 수 있습니다. 또한 재해나 DR Drill이 발생하는 경우 수동 개입 없이 사용자가 DR 지역으로 원활하게 리디렉션되어야 합니다.

이 시나리오를 설명하기 위해 Windows Server 2019와 IIS를 실행하는 Azure VM을 백엔드 서버로 사용하겠습니다(웹 디스패처라고 가정).한 VM은 포트 8443에서 S4 애플리케이션을 호스팅하고 동일한 VM은 포트 4443에서 EWM 애플리케이션을 호스팅합니다.두 웹사이트 모두 DNS에 등록된 동일한 호스트 이름 webdisp.azurequreshi.com에서 접속할 수 있습니다.또한 각 지역에 하나씩 두 개의 Application Gateway를 사용합니다.마지막으로 Traffic Manager 프로필을 사용하여 우선 순위 라우팅 방법에 따라 두 Application Gateway에 트래픽을 분산합니다.따라서 요청은 DC에만 도달합니다.DR Application Gateway에 대한 요청은 DC Application Gateway 상태 프로브가 다운된 후에만 전송됩니다.

따라서 이 시나리오에서 최종 사용자는 s4.azurequreshi.com:8443 또는 ewm.azurequreshi.com:4443과 같은 개별 URL을 사용하여 앱을 열지 않습니다. webdisp.azurequreshi.com:8443을 사용하면 S4 앱이 열립니다. 마찬가지로 webdisp.azurequreshi.com:4443을 사용하면 EWM 앱이 열립니다.

이 글에서는 위의 시나리오를 달성하는 데 도움이 되는 트래픽 관리자와 애플리케이션 게이트웨이의 설정을 공유하겠습니다. 저는 제 웹사이트를 호스팅한 더미 IIS 서버를 사용하고 있지만, 설정에서 이것을 SAP 웹 디스패처로 대체하고 애플리케이션 게이트웨이 뒤에 웹 디스패처를 호스팅할 수 있습니다.

다음 다이어그램은 아키텍처의 개요를 보여줍니다.

그럼, 웹사이트를 호스팅하는 실제 서버부터 시작해 봅시다. 아래는 IIS의 바인딩입니다. 이것은 단지 웹사이트의 데모 설정일 뿐입니다. 실제 SAP 앱은 다를 것입니다. 여기서의 의도는 s4.azurequreshi.com이라는 호스트 이름에서 4443에 호스팅된 웹사이트를 강조하는 것입니다.

마찬가지로, 아래 스크린샷은 다른 웹사이트를 보여줍니다. 동일한 것을 별도의 웹서버에 호스팅할 수도 있습니다.

애플리케이션 게이트웨이 설정:

애플리케이션 게이트웨이의 프런트엔드 IP를 확인해 보겠습니다.

이제 리스너 설정을 살펴보겠습니다.

두 웹사이트를 위한 애플리케이션 게이트웨이의 간단한 멀티 사이트 리스너. 두 리스너의 차이점은 포트입니다. 8443과 4443.

이제 백엔드 설정

유일한 변경 사항은 백엔드에서 내 웹사이트가 s4.azurequreshi.com에 호스팅되기 때문에 호스트 이름만 webdisp.azurequreshi.com 대신 s4.azurequreshi.com으로 변환한다는 것입니다.

2번째 http 설정에서도 동일한 설정을 볼 수 있습니다.

건강 탐침은 이렇게 생겼습니다.

이제 규칙 구성입니다. 아주 간단한 기본 규칙은 조정하지 않습니다.

그리고 백엔드 설정.

지금까지는 단일 IP만 유지했지만, 두 개의 다른 웹사이트에 대해 두 개의 백엔드 풀을 가질 수 있습니다. 하나는 S4용이고 다른 하나는 EWM용입니다. 또한, 애플리케이션 게이트웨이에서 백엔드 풀을 해당 규칙과 연결할 수 있습니다.

여기까지 따라왔다면, 애플리케이션 게이트웨이 URL로 웹사이트를 열 수 있고, 데스크톱에서 호스트 이름을 입력하면 해당 웹사이트로 리디렉션됩니다. 테스트를 위해 호스트 이름 webdisp.azurequreshi.com을 애플리케이션 게이트웨이 IP로 지정합니다.

남인도의 애플리케이션 게이트웨이 설정과 웹사이트 구성을 복제해야 합니다. 웹 서버를 종료하거나 Azure Site Recovery를 통해 복제할 수 있습니다.

위의 설정이 완료되면 Traffic Manager 구성을 진행할 수 있습니다.

트래픽 관리자

이는 능동/수동 DR이므로 트래픽 관리자에서 우선순위 기반 라우팅을 구성해야 합니다.

교통 관리자의 건강 상태를 살펴보세요.

이 설정으로 트래픽 관리자는 트래픽을 DC(인도 중부)로만 보냅니다. 엔드포인트가 저하되면 트래픽 관리자가 클라이언트에 DR IP 주소를 제공합니다.

마지막 단계는 URL의 CNAME을 트래픽 관리자로 설정하는 것입니다. nslookup을 실행하면 다음을 찾을 수 있습니다.

결과

웹사이트가 열리는 방식은 다음과 같습니다. 이는 SAP S4와 EWM의 구체적인 스크린샷은 아니지만 이 앱 게이트웨이와 트래픽 관리자 설정은 동일합니다.

작업을 검토하고 이 블로그 게시물을 쓰는 데 영감을 준 요구 사항을 공유해 주신 Nishant Roy에게 감사드립니다.

즐거운 학습이 되세요!