피드백 편집

Azure의 Windows N 계층 애플리케이션

Blob Storage
DNS
Load Balancer
Virtual Network
Virtual Machines

이 참조 아키텍처는 데이터 계층에 대해 Windows의 SQL Server 사용하여 N 계층 애플리케이션에 대해 구성된 VM(가상 머신) 및 가상 네트워크를 배포하는 방법을 보여 줍니다.

아키텍처

Microsoft Azure를 사용하는 N계층 아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

이 아키텍처의 구성 요소는 다음과 같습니다.

일반

  • 리소스 그룹. 리소스 그룹은 Azure 리소스를 그룹화하여 수명, 소유자 또는 기타 기준에 따라 관리할 수 있도록 하는 데 사용됩니다.

  • 가용성 영역. 가용성 영역은 Azure 지역 내의 물리적 위치입니다. 각 영역은 독립적인 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성됩니다. 영역에 VM을 배치하면 애플리케이션이 영역 내의 오류에 대한 복원력이 향상됩니다.

네트워킹 및 부하 분산

  • 가상 네트워크 및 서브넷. 모든 Azure VM은 서브넷으로 분할할 수 있는 가상 네트워크에 배포됩니다. 각 계층에 대해 별도의 서브넷을 만듭니다.

  • Application Gateway. Application Gateway 계층 7 부하 분산 장치입니다. 이 아키텍처에서 HTTP 요청을 웹 프런트 엔드로 라우팅합니다. 또한 application Gateway는 일반적인 악용 및 취약점으로부터 애플리케이션을 보호하는 WAF(웹 애플리케이션 방화벽)을 제공합니다.

  • Load Balancer Azure 표준 Load Balancer 사용하여 웹 계층에서 비즈니스 계층으로, 비즈니스 계층에서 SQL Server 네트워크 트래픽을 분산합니다.

  • NSG(네트워크 보안 그룹). NSG를 사용하여 가상 네트워크 내의 네트워크 트래픽을 제한합니다. 예를 들어 여기에 표시된 3계층 아키텍처에서 데이터베이스 계층은 비즈니스 계층 및 관리 서브넷뿐 아니라 웹 프론트 엔드의 트래픽을 허용하지 않습니다.

  • DDoS Protection. Azure 플랫폼이 DDoS(분산 서비스 거부) 공격에 대한 기본 보호를 제공하지만 DDoS Protection 표준을 사용하는 것이 좋습니다. 그러면 DDoS 완화를 강화하게 됩니다. 보안 고려 사항을 참조하세요.

  • Azure DNS. Azure DNS는 DNS 도메인에 대한 호스팅 서비스입니다. 이 서비스는 Microsoft Azure 인프라를 사용하여 이름 확인을 제공합니다. Azure에 도메인을 호스트하면 다른 Azure 서비스와 동일한 자격 증명, API, 도구 및 대금 청구를 사용하여 DNS 레코드를 관리할 수 있습니다.

가상 머신

  • SQL Server Always On 가용성 그룹입니다. 복제 및 장애 조치(failover)를 사용하여 데이터 계층에서 높은 가용성을 제공합니다. 장애 조치(failover)에 대해 WSFC(Windows Server 장애 조치 클러스터) 기술을 사용합니다.

  • AD DS(Active Directory Domain Services) 서버. 장애 조치(failover) 클러스터 및 관련 클러스터형 역할에 대한 컴퓨터 개체는 AD DS(Active Directory Domain Services)에서 만들어집니다.

  • 클라우드 감시. 장애 조치(failover) 클러스터는 쿼럼이 있는 것으로 알려진 해당 노드의 절반을 초과하여 실행되어야 합니다. 클러스터에 노드가 두 개만 있는 경우 네트워크 파티션으로 인해 각 노드가 주 노드라고 생각할 수 있습니다. 그 경우에 연결을 차단하고 쿼럼을 설정할 감시가 필요합니다. 감시는 쿼럼을 설정하려면 연결 차단기로 작동할 수 있는 공유 디스크 같은 리소스입니다. 클라우드 감시는 Azure Blob Storage를 사용하는 감시의 한 유형입니다. 쿼럼의 개념에 대한 자세한 알려면 클러스터 및 풀 쿼럼 이해를 참조합니다. 클라우드 감시에 대한 자세한 내용은 장애 조치(Failover) 클러스터에 대한 클라우드 감시 배포를 참조하세요.

  • Jumpbox. 요새 호스트라고도 합니다. 일반적으로 관리자가 다른 VM에 연결하는 데 사용하는 네트워크의 보안 VM입니다. jumpbox는 안전 목록에 있는 공용 IP 주소의 원격 트래픽만 허용하는 NSG를 사용합니다. NSG는 RDP(원격 데스크톱 프로토콜) 트래픽을 허용해야 합니다. Azure는 이러한 요구를 충족하기 위해 관리형 솔루션 Azure Bastion 을 제공합니다.

권장 사항

개발자의 요구 사항이 여기에 설명된 아키텍처와 다를 수 있습니다. 여기서 추천하는 권장 사항을 단지 시작점으로 활용하세요.

가상 머신

VM 구성에 대한 권장 사항은 Azure에서 Windows VM 실행을 참조하세요.

가상 네트워크

가상 네트워크를 만들 때 각 서브넷의 리소스에 필요한 IP 주소 수를 결정합니다. CIDR 표기법을 사용하여 필요한 IP 주소에 충분히 큰 서브넷 마스크 및 네트워크 주소 범위를 지정합니다. 표준 개인 IP 주소 블록(10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16)에 해당하는 주소 공간을 사용합니다.

나중에 가상 네트워크와 온-프레미스 네트워크 간에 게이트웨이를 설정해야 하는 경우 온-프레미스 네트워크와 겹치지 않는 주소 범위를 선택합니다. 가상 네트워크를 만든 후에는 주소 범위를 변경할 수 없습니다.

기능 및 보안 요구 사항을 염두에 두고 서브넷을 구성합니다. 동일한 계층이나 역할에 속한 모든 VM은 동일한 서브넷에 속해야 합니다. 이때 서브넷은 보안 경계가 될 수 있습니다. 가상 네트워크 및 서브넷 디자인에 대한 자세한 내용은 Azure Virtual Network 계획 및 디자인을 참조하세요.

Application Gateway

Application Gateway 구성에 대한 자세한 내용은 Application Gateway 구성 개요를 참조하세요.

부하 분산 장치

VM을 인터넷에 직접 노출시키는 대신 각 VM에 개인 IP 주소를 부여합니다. 클라이언트는 Application Gateway와 연결된 공용 IP 주소를 사용하여 연결합니다.

네트워크 트래픽이 VM으로 전달되도록 부하 분산 장치 규칙을 정의합니다. 예를 들어 HTTP 트래픽을 허용하려면 프론트 엔드 구성의 포트 80을 백엔드 주소 풀의 포트 80으로 매핑합니다. 클라이언트가 포트 80으로 HTTP 요청을 전송하면 부하 분산 장치가 소스 IP 주소를 포함하는 해싱 알고리즘을 사용하여 백엔드 IP 주소를 선택합니다. 클라이언트 요청은 백 엔드 주소 풀의 모든 VM에 걸쳐 분산됩니다.

네트워크 보안 그룹

NSG 규칙을 사용하여 계층 사이의 트래픽을 제한합니다. 위에 표시된 3계층 아키텍처에서 웹 계층은 데이터베이스 계층과 직접 통신하지 않습니다. 이 규칙을 적용하려면 데이터베이스 계층이 웹 계층 서브넷에서 들어오는 트래픽을 차단해야 합니다.

  1. 가상 네트워크에서 모든 인바운드 트래픽을 거부합니다. (규칙에 VIRTUAL_NETWORK 태그를 사용합니다.)
  2. 비즈니스 계층 서브넷의 인바운드 트래픽을 허용합니다.
  3. 데이터베이스 계층 서브넷 자체의 인바운드 트래픽을 허용합니다. 이 규칙은 데이터베이스 복제와 장애 조치에 필요한 데이터베이스 VM 간 통신을 허용합니다.
  4. jumpbox 서브넷에서 RDP 트래픽(3389 포트)을 허용합니다. 관리자는 이 규칙을 사용하여 jumpbox에서 데이터베이스 계층에 연결할 수 있습니다.

첫 번째 규칙보다 우선 순위가 높은 규칙 2 - 4를 만들어 재정의합니다.

SQL Server Always On 가용성 그룹

SQL Server의 고가용성을 위해 Always On 가용성 그룹을 사용하는 것이 좋습니다. Windows Server 2016 전 버전에서는 Always On 가용성 그룹에 도메인 컨트롤러가 필요하며, 가용성 그룹의 모든 노드가 동일한 AD 도메인에 속해야 합니다.

다른 계층은 가용성 그룹 수신기를 통해 데이터베이스에 연결됩니다. 수신기는 SQL 클라이언트가 SQL Server의 물리적 인스턴스의 이름을 알지 못해도 연결할 수 있도록 해 줍니다. 데이터베이스에 액세스하는 VM은 도메인에 연결되어야 합니다. 클라이언트(여기서는 다른 계층)는 DNS를 사용하여 수신기의 가상 네트워크 이름을 IP 주소로 해석합니다.

다음과 같이 SQL Server Always On 가용성 그룹을 구성합니다.

  1. WSFC(Windows Server 장애 조치 클러스터링) 클러스터, SQL Server Always On 가용성 그룹과 주 복제본을 만듭니다. 자세한 내용은 Always On 가용성 그룹 시작을 참조하세요.

  2. 고정 개인 IP 주소를 사용하여 내부 부하 분산 장치를 만듭니다.

  3. 가용성 그룹 수신기를 만든 다음 수신기의 DNS 이름을 내부 부하 분산 장치의 IP 주소로 매핑합니다.

  4. SQL Server 수신 포트(기본값: TCP 포트 1433)에 대한 부하 분산 장치 규칙을 만듭니다. 부하 분산 장치 규칙은 Direct Server Return이라고도 불리는 부동 IP를 지원해야 합니다. 이로 인해 VM은 클라이언트에 직접 응답하여 주 복제본에 대한 직접 연결을 지원하게 됩니다.

    참고

    부동 IP가 지원된 경우에는 부하 분산 장치 규칙의 프론트 엔드 포트 번호가 백엔드 포트 번호와 같아야 합니다.

SQL 클라이언트가 연결을 시도하면 부하 분산 장치가 연결 요청을 주 복제본으로 라우팅합니다. 다른 복제본으로의 장애 조치(failover)가 이루어지면 부하 분산 장치는 자동으로 새로운 요청을 새로운 주 복제본에 라우팅합니다. 자세한 내용은 SQL Server Always On 가용성 그룹에 대한 ILB 수신기 구성을 참조하세요.

장애 조치(failover)가 진행되는 동안에는 기존 클라이언트 연결이 닫힙니다. 장애 조치(failover)가 완료되면 새로운 연결이 새로운 주 복제본으로 라우팅됩니다.

애플리케이션에서 쓰기보다 읽기가 훨씬 많이 발생한다면 읽기 전용 쿼리 중 일부를 보조 복제본으로 부하 분산할 수 있습니다. 수신기를 사용하여 읽기 전용 보조 복제본에 연결(읽기 전용 라우팅)을 참조하세요.

가용성 그룹의 수동 장애 조치(failover)를 강제로 수행하여 배포 환경을 테스트합니다.

Jumpbox

이 아키텍처와 같이 프라이빗 가상 네트워크에서 가상 머신을 실행하는 경우 소프트웨어 설치, 패치 등을 위해 가상 머신에 액세스해야 합니다. 그러나 이러한 컴퓨터를 공용 인터넷에서 액세스할 수 있게 하는 것은 공격 표면을 크게 증가하기 때문에 좋지 않습니다. 대신 jumpbox가 중간 액세스 계층으로 사용됩니다.

이전에는 고객이 관리하는 VM을 jumpbox로 사용할 수 있었습니다. 이 시나리오에서는 다음 권장 사항이 적용됩니다.

  • 공용 인터넷에서 애플리케이션 워크로드를 실행하는 VM으로 RDP 액세스를 허용하지 않습니다. 대신 이러한 VM에 대한 모든 RDP 액세스는 jumpbox를 통과해야 합니다. 관리자는 jumpbox에 로그인한 다음 jumpbox에서 다른 VM에 로그인합니다. jumpbox는 인터넷에서 RDP 트래픽을 허용하지만 알려진 안전한 IP 주소에서만 가능합니다.
  • jumpbox에는 최소 성능 요구 사항이 있으므로 작은 VM 크기를 선택합니다. jumpbox에 대한 공용 IP 주소를 만듭니다. jumpbox를 다른 VM과 동일한 가상 네트워크에 배치하지만 별도의 관리 서브넷에 배치합니다.
  • jumpbox를 보호하려면 안전한 공용 IP 주소 집합의 RDP 연결만 허용하는 NSG 규칙을 추가합니다. 관리 서브넷으로부터 수신되는 RDP 트래픽을 허용하도록 다른 서브넷에 대한 NSG를 구성합니다.

고객 관리 VM의 경우 이러한 모든 규칙이 적용됩니다. 그러나 현재 권장 사항은 AZURE AD 보호 뒤에 있는 RDP 또는 SSH에 HTML5 액세스를 허용하는 관리되는 jumpbox 솔루션인 Azure Bastion을 사용하는 것입니다. 이는 고객에 대한 TCO(총 소유 비용)가 궁극적으로 더 낮은 훨씬 간단한 솔루션입니다.

고려 사항

확장성

확장 집합

웹 및 비즈니스 계층의 경우 별도의 VM을 배포하는 대신 가상 머신 확장 집합 을 사용하는 것이 좋습니다. 확장 집합을 통해 동일한 VM 집합을 쉽게 배포하고 관리하며, 성능 메트릭에 따라 VM의 크기를 자동으로 조정할 수 있습니다. VM들의 부하가 늘어나면 부하 분산 장치에 VM이 자동으로 추가됩니다. VM을 신속하게 확장해야 하거나 자동 확장이 필요한 경우 확장 집합을 사용합니다.

확장 집합에 배포된 VM을 구성하는 방법에는 두 가지가 있습니다.

  • VM이 배포된 후에 확장명을 사용하여 VM을 구성합니다. 이렇게 하면 확장명이 없는 VM보다 새 VM 인스턴스를 시작하는 데 시간이 더 오래 걸릴 수 있습니다.

  • 사용자 지정 디스크 이미지를 사용하여 관리 디스크를 배포합니다. 이 옵션을 사용하면 배포 시간이 단축될 수 있습니다. 하지만 그러러면 이미지를 최신 상태로 유지해야 합니다.

자세한 내용은 확장 집합 디자인 고려 사항을 참조하세요.

팁

자동 확장 솔루션을 사용할 때는 사전에 미리 프로덕션 수준 워크로드로 테스트해야 합니다.

구독 제한

각 Azure 구독에는 지역당 최대 VM 개수를 비롯해 기본적인 제한이 적용됩니다. 지원 요청을 제출하여 제한을 늘릴 수 있습니다. 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.

Application Gateway

Application Gateway 고정 용량 모드 또는 자동 크기 조정 모드를 지원합니다. 고정 용량 모드는 워크로드가 일관적이고 예측 가능한 시나리오에 유용합니다. 가변 트래픽이 있는 워크로드에 자동 크기 조정 모드를 사용하는 것이 좋습니다. 자세한 내용은 자동 크기 조정 및 영역 중복 Application Gateway v2를 참조하세요.

가용성

가용성 영역은 단일 지역 내에서 최상의 복원력을 제공합니다. 더 높은 가용성이 필요한 경우 장애 조치(failover)를 위해 Azure Traffic Manager를 사용하여 두 지역에 애플리케이션을 복제하는 것이 좋습니다. 자세한 내용은 고가용성을 위한 다중 지역 N 계층 애플리케이션을 참조하세요.

모든 지역에서 가용성 영역을 지원하는 것은 아니며 모든 영역에서 모든 VM 크기가 지원되지는 않습니다. 다음 Azure CLI 명령을 실행하여 지역 내의 각 VM 크기에 대해 지원되는 영역을 찾습니다.

az vm list-skus --resource-type virtualMachines --zone false --location <location> \
    --query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table

가용성 영역을 지원하지 않는 지역에 이 아키텍처를 배포하는 경우 각 계층에 대한 VM을 가용성 집합 내에 배치합니다. 동일한 가용성 집합 내의 VM은 중복성을 위해 여러 물리적 서버, 컴퓨팅 랙, 스토리지 단위 및 네트워크 스위치에 배포됩니다. 확장 집합은 자동으로 배치 그룹을 사용합니다. 이 기능은 암시적인 가용성 집합으로 작동합니다.

가용성 영역에 배포할 때 Azure Load Balancer 표준 SKU 및 Application Gateway v2 SKU를 사용합니다. 이러한 SKU는 영역 간 중복성을 지원합니다. 자세한 내용은 다음을 참조하세요.

단일 Application Gateway 배포는 게이트웨이의 여러 인스턴스를 실행할 수 있습니다. 프로덕션 워크로드의 경우 두 개 이상의 인스턴스를 실행합니다.

상태 프로브

Application Gateway 및 Load Balancer 둘 다 상태 프로브를 사용하여 VM 인스턴스의 가용성을 모니터링합니다.

  • Application Gateway 항상 HTTP 프로브를 사용합니다.
  • Load Balancer HTTP 또는 TCP를 테스트할 수 있습니다. 일반적으로 VM이 HTTP 서버를 실행하는 경우 HTTP 프로브를 사용합니다. 그렇지 않으면 TCP를 사용합니다.

프로브가 시간 제한 기간 내에 인스턴스에 연결할 수 없는 경우 게이트웨이 또는 부하 분산 장치는 해당 VM에 트래픽 전송을 중지합니다. 프로브는 계속 확인하고 VM을 다시 사용할 수 있게 되면 VM을 백 엔드 풀로 반환합니다.

HTTP 프로브는 지정된 경로에 HTTP GET 요청을 보내고 HTTP 200 응답을 수신 대기합니다. 이 경로는 루트 경로("/")일 수도 있고, 애플리케이션의 상태를 확인하는 일부 사용자 지정 로직을 구현하는 상태 모니터링 엔드포인트일 수도 있습니다. 엔드포인트는 익명의 HTTP 요청을 허용해야 합니다.

상태 프로브에 대한 자세한 내용은 다음을 참조하세요.

상태 프로브 엔드포인트 디자인에 대한 고려 사항은 상태 엔드포인트 모니터링 패턴을 참조하세요.

비용 최적화

Azure 가격 계산기를 사용하여 비용을 예측합니다. 다음은 몇 가지 다른 고려 사항입니다.

가상 머신 크기 집합

가상 머신 확장 집합은 모든 Windows VM 크기에서 사용할 수 있습니다. 배포하는 Azure VM 및 스토리지 및 네트워킹과 같이 사용된 추가 기본 인프라 리소스에 대해서만 요금이 청구됩니다. 가상 머신 확장 집합 서비스에 대한 증분 요금은 없습니다.

단일 VM 가격 책정 옵션은 Windows VM 가격 책정을 참조하세요.

데이터베이스 가져오기

Azure SQL DBaas를 선택하는 경우 Always On 가용성 그룹 및 도메인 컨트롤러 컴퓨터를 구성할 필요가 없으므로 비용을 절감할 수 있습니다. 단일 데이터베이스에서 관리되는 인스턴스 또는 탄력적 풀까지 몇 가지 배포 옵션이 있습니다. 자세한 내용은 Azure SQL 가격 책정을 참조하세요.

SQL Server VM 가격 책정 옵션은 SQL VM 가격 책정을 참조하세요.

부하 분산 장치

구성된 부하 분산 및 아웃바운드 규칙 수에 대해서만 요금이 청구됩니다. 인바운드 NAT 규칙은 무료입니다. 규칙이 구성되지 않은 경우 표준 Load Balancer 시간당 요금이 부과되지 않습니다.

자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.

보안

가상 네트워크는 Azure의 트래픽 격리 경계입니다. 기본적으로 한 가상 네트워크의 VM은 다른 가상 네트워크의 VM과 직접 통신할 수 없습니다. 그러나 가상 네트워크 피어링을 사용하여 가상 네트워크를 명시적으로 연결할 수 있습니다.

NSG. NSG( 네트워크 보안 그룹 )를 사용하여 인터넷과 트래픽을 제한합니다. 자세한 내용은 Microsoft 클라우드 서비스 및 네트워크 보안을 참조하세요.

DMZ. NVA(네트워크 가상 어플라이언스)를 추가하여 인터넷과 Azure 가상 네트워크 사이에 DMZ를 만드는 것도 좋은 방법입니다. NVA는 방화벽, 패킷 조사, 감사, 사용자 지정 라우팅과 같은 네트워크 관련 작업을 수행하는 가상 어플라이언스를 통칭하는 용어입니다. 자세한 내용은 Azure와 인터넷 사이에 DMZ 구현을 참조하세요.

암호화. 중요한 미사용 데이터를 암호화하고 Azure Key Vault를 사용하여 데이터베이스 암호화 키를 관리합니다. Key Vault는 암호화 키를 HSM(하드웨어 보안 모듈)에 저장합니다. 자세한 내용은 Azure VM에서 SQL Server에 대한 Azure Key Vault 통합 구성을 참조하세요. 또한 Key Vault에 데이터베이스 연결 문자열과 같은 애플리케이션 비밀을 저장하는 것이 좋습니다.

DDoS 보호. Azure 플랫폼은 기본적으로 기본 DDoS 보호를 제공합니다. 이 기본 보호는 전체 Azure 인프라를 보호할 대상으로 지정합니다. 기본 DDoS 보호가 자동으로 설정되지만 DDoS Protection 표준을 사용하는 것이 좋습니다. 표준 보호는 애플리케이션의 네트워크 트래픽 패턴을 기반으로 적응형 조정을 사용하여 위협을 검색합니다. 그러면 인프라 수준의 DDoS 정책에 의해 알려지지 않을 수 있는 DDoS 공격에 대한 완화를 적용할 수 있습니다. 표준 보호는 Azure Monitor를 통해 경고, 원격 분석 및 분석도 제공합니다. 자세한 내용은 Azure DDoS Protection: 모범 사례 및 참조 아키텍처를 참조하세요.

운영 우수성

모든 주요 리소스와 해당 종속성은 이 아키텍처의 동일한 가상 네트워크에 있으므로 동일한 기본 워크로드에서 격리됩니다. 이러한 사실을 통해 워크로드의 특정 리소스를 팀에 쉽게 연결할 수 있으므로 팀이 해당 리소스의 모든 측면을 독립적으로 관리할 수 있습니다. 이러한 격리를 통해 DevOps는 CI/CD(연속 통합 및 지속적인 업데이트)를 수행할 수 있습니다.

또한 다양한 배포 템플릿을 사용하고 Azure DevOps Services 통합하여 몇 분 안에 다양한 환경을 프로비전할 수 있습니다. 예를 들어 시나리오와 같은 프로덕션을 복제하거나 필요한 경우에만 테스트 환경을 로드하여 비용을 절감할 수 있습니다.

이 시나리오에서는 가상 머신이 맬웨어 방지 및 보안 에이전트와 같은 특정 추가 소프트웨어를 설치할 가능성을 제공하므로 Virtual Machine 확장을 사용하여 구성됩니다. VM 확장은 VM을 만들 때만 설치되고 실행됩니다. 즉, 이후 단계에서 운영 체제가 잘못 구성된 경우 운영 체제를 올바른 상태로 되돌리려면 수동 개입이 필요합니다.

구성 관리 도구, 특히 DSC(Desired State Configuration)는 이 아키텍처에서 Active Directory 및 SQL Server Always On 가용성 그룹을 구성하는 데 사용됩니다.

Azure Monitor를 사용하여 인프라의 성능을 분석 및 최적화하고 가상 머신에 로그인하지 않고 네트워킹 문제를 모니터링 및 진단하는 것이 좋습니다. Application Insights는 실제로 전체 Azure 환경의 상태를 확인하기 위한 풍부한 메트릭과 로그를 제공하는 Azure Monitor의 구성 요소 중 하나입니다. Azure Monitor는 인프라의 상태를 따르는 데 도움이 됩니다.

애플리케이션의 데이터 계층 성능이 낮으면 심각한 결과를 초래할 수 있으므로 애플리케이션 코드를 지원하는 컴퓨팅 요소뿐만 아니라 데이터 플랫폼, 특히 데이터베이스도 모니터링해야 합니다.

애플리케이션이 실행되는 Azure 환경을 테스트하려면 애플리케이션 코드와 동일한 메커니즘을 통해 버전 제어 및 배포해야 합니다. 그런 다음 DevOps 테스트 패러다임을 사용하여 테스트하고 유효성을 검사할 수 있습니다.

자세한 내용은 Azure Well-Architected Framework의 운영 우수성 섹션을 참조하세요.

다음 단계