이 참조 아키텍처는 가용성 및 강력한 재해 복구 인프라를 구축하기 위해, 여러 Azure 지역에서 N 계층 애플리케이션을 실행하기 위한 일련의 검증된 사례를 보여 줍니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
주 지역 및 보조 지역. 더 높은 가용성을 달성하기 위해 두 개의 지역을 사용합니다. 하나는 주 지역입니다. 다른 하나는 장애 조치(failover)를 위한 지역입니다.
Azure Traffic Manager. Traffic Manager는 들어오는 요청을 이 지역 중 하나에 라우팅합니다. 정상 작동 중에는 요청을 주 지역으로 라우팅합니다. 이 지역을 사용할 수 없게 되면 Traffic Manager가 보조 지역으로 장애 조치(failover)합니다. 자세한 내용은 Traffic Manager 구성 섹션을 참조하세요.
리소스 그룹. 주 지역, 보조 지역 및 Traffic Manager에 대해 별도의 리소스 그룹을 만듭니다. 이 방법으로 각 지역을 단일 리소스 모음으로 유연하게 관리할 수 있습니다. 예를 들어 다른 지역으로 이동하지 않고 한 지역을 다시 배포할 수 있습니다. 리소스 그룹을 연결하므로 애플리케이션의 모든 리소스를 나열하는 쿼리를 실행할 수 있습니다.
가상 네트워크 각 지역에 대해 별도의 가상 네트워크를 만듭니다. 주소 공간이 겹치지 않도록 합니다.
SQL Server Always On 가용성 그룹. SQL Server를 사용하는 경우 고가용성을 위해 SQL Always On 가용성 그룹을 사용하는 것이 좋습니다. 두 지역 모두에 SQL Server 인스턴스를 포함하는 단일 가용성 그룹을 만듭니다.
참고
또한 관계형 데이터베이스를 클라우드 서비스로 제공하는 Azure SQL Database를 고려합니다. SQL Database를 사용하면 가용성 그룹을 구성하거나 장애 조치(failover)를 관리할 필요가 없습니다.
가상 네트워크 피어링. 두 가상 네트워크를 피어링하여 주 지역에서 보조 지역으로 데이터 복제를 허용합니다. 자세한 내용은 가상 네트워크 피어링을 참조하세요.
구성 요소
- 가용성 집합을 사용하면 Azure에 배포한 VM이 클러스터의 격리된 여러 하드웨어 노드에 분산되도록 할 수 있습니다. Azure 내에서 하드웨어 또는 소프트웨어 오류가 발생하더라도 VM의 하위 집합에만 영향이 있고 전체 솔루션은 계속 작동하므로 계속 사용할 수 있습니다.
- 가용성 영역은 데이터 센터 오류로부터 애플리케이션과 데이터를 보호합니다. 가용성 영역은 Azure 지역 내에서 독립된 물리적 위치입니다. 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성됩니다.
- Azure Traffic Manager는 트래픽을 최적으로 분산하는 DNS 기반 트래픽 부하 분산 장치입니다. 고가용성 및 응답성을 갖춘 전 세계 Azure 지역 전체에서 서비스를 제공합니다.
- Azure 부하 분산 장치는 정의된 규칙 및 상태 프로브에 따라 인바운드 트래픽을 분산합니다. 부하 분산 장치는 짧은 대기 시간과 높은 처리량을 제공하고, 모든 TCP 및 UDP 애플리케이션을 처리할 수 있도록 최대 수백만 개의 흐름으로 확장됩니다. 공용 부하 분산 장치는 들어오는 클라이언트 트래픽을 웹 계층으로 분산하는 시나리오에 사용됩니다. 내부 부하 분산 장치는 비즈니스 계층의 트래픽을 백 엔드 SQL Server 클러스터로 분산하는 시나리오에 사용됩니다.
- Azure Bastion은 프로비전된 가상 네트워크의 모든 VM에 대한 안전한 RDP 및 SSH 연결을 제공합니다. Azure Bastion을 사용하여 가상 머신에서 RDP/SSH를 사용하여 안전한 액세스 권한을 계속 제공하며 RDP/SSH 포트가 외부 환경에 노출되는 상황에서 보호합니다.
권장 사항
다중 지역 아키텍처는 단일 지역에 배포하는 것보다 더 높은 가용성을 제공할 수 있습니다. 지역 가동 중단이 주 지역에 영향을 주는 경우 Traffic Manager를 사용하여 보조 지역으로 장애 조치(failover)할 수 있습니다. 이 아키텍처는 애플리케이션의 개별 하위 시스템이 고장난 경우에도 도움이 될 수 있습니다.
지역에서 고가용성을 달성하는 데 몇 가지 일반적인 접근 방식이 있습니다.
- 활성/수동(상시 대기). 트래픽이 한 지역으로 이동하면 다른 하나가 상시 대기 상태에서 기다립니다. 상시 대기는 항상 보조 지역의 VM이 할당되고 실행 중이라는 의미입니다.
- 활성/수동(수동 대기). 트래픽이 한 지역으로 이동하면 다른 하나가 수동 대기에서 기다립니다. 수동 대기는 장애 조치(failover)에 필요할 때까지 보조 지역의 VM이 할당되지 않는다는 것을 의미합니다. 이 방법은 실행하는 데 비용이 덜 들지만, 일반적으로 실패 상태에 있을 때 온라인 상태가 되는 데 더 오래 시간이 걸립니다.
- 활성/활성. 두 지역 모두 활성화되어 있으며, 요청이 두 지역 사이에서 부하 분산됩니다. 한 지역을 사용할 수 없게 해당 지역은 순환에서 제외됩니다.
이 참조 아키텍처는 장애 조치(failover)를 위해 Traffic Manager를 사용하여 활성/수동(상시 대기)을 중점적으로 다룹니다. 상시 대기를 위해 소수의 VM을 배포한 다음, 필요에 따라 규모를 확장할 수 있습니다.
지역을 쌍으로 연결
Azure 지역은 동일한 지역 내에서 다른 지역과 쌍을 이룹니다. 일반적으로 같은 지역 쌍에서 지역을 선택합니다. 예를 들어 미국 동부 2와 미국 중부입니다. 이에 따른 장점은 다음과 같습니다.
- 광범위한 가동 중단이 발생한 경우 모든 쌍 중에서 하나 이상의 지역에 대한 복구에 우선 순위가 지정됩니다.
- 계획된 Azure 시스템 업데이트는 순차적으로 쌍을 이루는 지역으로 출시되어 가동 중지 시간을 최소화할 수 있습니다.
- 쌍은 데이터 상주 요구 사항을 충족하기 위해 동일한 지역 내에 상주합니다.
그러나 두 지역 모두 애플리케이션에 필요한 모든 Azure 서비스를 지원하는지 확인합니다(지역별 서비스 참조). 지역 쌍에 대한 자세한 내용은 BCDR(무중단 업무 방식 및 재해 복구): Azure 쌍을 이루는 지역을 참조하세요.
Traffic Manager 구성
Traffic Manager를 구성할 때 다음 사항을 고려합니다.
- 라우팅. Traffic Manager는 여러 라우팅 알고리즘을 지원합니다. 이 문서에 설명된 시나리오는 우선 순위 라우팅(이전에는 장애 조치(failover) 라우팅이라고 함)을 사용합니다. 이 설정을 사용하면 Traffic Manager가 주 지역에 연결할 수 없는 경우가 아닌 한 모든 요청을 주 지역으로 보냅니다. 이때 자동으로 보조 지역으로 장애 조치(failover)됩니다. 장애 조치(failover) 라우팅 방법 구성을 참조하세요.
- 상태 프로브. Traffic Manager는 HTTP(또는 HTTPS) 프로브를 사용하여 각 지역의 가용성을 모니터링합니다. 프로브는 지정된 URL 경로에 대한 HTTP 200 응답을 확인합니다. 애플리케이션의 전반적인 상태를 보고하고 이 엔드포인트를 상태 프로브에 사용하는 엔드포인트를 생성하는 것이 좋습니다. 그렇지 않으면 애플리케이션의 중요한 부분이 실제로 실패할 때 프로브에서 정상 엔드포인트를 보고할 수 있습니다. 자세한 내용은 상태 엔드포인트 모니터링 패턴을 참조하세요.
Traffic Manager가 장애 조치(failover)할 때 클라이언트가 애플리케이션에 연결할 수 없는 기간이 있습니다. 그 기간은 다음과 같은 요인에 의해 영향을 받습니다.
- 상태 프로브가 주 지역에 연결할 수 없는지 검색해야 합니다.
- DNS 서버가 DNS TTL(time-to-live)에 따라 IP 주소에 대해 캐시된 DNS 레코드를 업데이트해야 합니다. 기본 TTL은 300초(5분)이지만 Traffic Manager 프로필을 만들 때 이 값을 구성할 수 있습니다.
자세한 내용은 Traffic Manager 모니터링 정보를 참조하세요.
Traffic Manager가 장애 조치(failover)를 수행하는 경우 자동 장애 복구(failback)를 구현하기 보다는 수동 장애 복구(failback)를 수행하는 것이 좋습니다. 그렇지 않으면 애플리케이션이 지역 간에 앞뒤로 대칭 이동하는 상황이 발생할 수 있습니다. 장애 복구(failback) 전에 모든 애플리케이션 하위 시스템이 정상 상태인지 확인합니다.
Traffic Manager는 기본적으로 자동 장애 복구(failback)를 수행합니다. 이런 문제를 방지하려면 장애 조치(failover) 이벤트 후 수동으로 주 지역의 우선 순위를 낮춥니다. 예를 들어 주 지역의 우선 순위가 1이고 보조 지역의 우선 순위를 2로 가정합니다. 장애 조치(failover) 후 자동 장애 복구(failback)를 방지하기 위해 주 지역의 우선 순위를 3으로 설정합니다. 다시 전환할 준비가 되면 우선 순위를 1로 업데이트합니다.
다음 Azure CLI 명령은 우선 순위를 업데이트합니다.
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type azureEndpoints --priority 3
또 다른 방법은 장애 복구(failback)할 준비가 될 때까지 엔드포인트를 일시적으로 사용하지 않도록 설정하는 것입니다.
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type azureEndpoints --endpoint-status Disabled
장애 조치(failover)의 원인에 따라 한 지역 내에서 리소스를 다시 배포해야 할 수 있습니다. 장애 복구(failback) 전에 운영 준비 상태 테스트를 수행합니다. 이 테스트는 다음과 같은 사항을 확인해야 합니다.
- VM이 올바르게 구성되어 있습니다. 필요한 모든 소프트웨어가 설치되어 있고, IIS가 실행 중인지 확인합니다.
- 애플리케이션 하위 시스템이 정상입니다.
- 기능을 테스트합니다. 예를 들어 웹 계층에서 데이터베이스 계층에 연결 가능한지 테스트합니다.
SQL Server Always On 가용성 그룹 구성
Windows Server 2016 이전 버전에서는 SQL Server Always On 가용성 그룹에 항상 도메인 컨트롤러가 필요하며, 가용성 그룹의 모든 노드가 동일한 AD(Active Directory) 도메인에 있어야 합니다.
가용성 그룹을 구성하려면:
최소한 두 개의 도메인 컨트롤러를 각 지역에 배치합니다.
각 도메인 컨트롤러에 고정 IP 주소를 지정합니다.
두 가상 네트워크를 피어링하여 통신을 사용하도록 설정합니다.
각 가상 네트워크에 대해 두 지역 모두에서 도메인 컨트롤러의 IP 주소를 DNS 서버 목록에 추가합니다. 다음 CLI 명령을 사용할 수 있습니다. 자세한 내용은 DNS 서버 변경을 참조하세요.
az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"두 지역의 SQL Server 인스턴스를 포함하는 WSFC(Windows Server 장애 조치(failover) 클러스터링) 클러스터를 만듭니다.
주 지역과 보조 지역 모두에서 SQL Server 인스턴스를 포함하는 SQL Server Always On 가용성 그룹을 만듭니다. 단계는 Extending Always On Availability Group to Remote Azure Datacenter (PowerShell)(원격 Azure 데이터 센터에 Always On 가용성 그룹 확장(PowerShell))를 참조하세요.
주 지역에 주 복제본을 배치합니다.
주 지역에 하나 이상의 보조 복제본을 배치합니다. 이 복제본을 자동 장애 조치(failover)를 사용하는 동기 커밋을 사용하도록 구성합니다.
보조 지역에 보조 복제본을 하나 이상 배치합니다. 이 복제본을, 성능상의 이유로 비동기 커밋을 사용하도록 구성합니다. (그렇지 않은 경우 모든 T-SQL 트랜잭션이 네트워크를 통해 보조 지역으로 왕복하는 동안 기다려야 합니다.)
참고
비동기 커밋 복제본은 자동 장애 조치(failover)를 지원하지 않습니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
가용성
복잡한 N 계층 앱에서는 보조 지역에서 전체 애플리케이션을 복제하지 않아도 될 수 있습니다. 대신 무중단 업무 방식을 지원하는 데 필요한 중요한 하위 시스템을 복제하기면 하면 됩니다.
Traffic Manager는 시스템에서 오류가 발생할 수 있는 지점입니다. Traffic Manager 서비스가 실패하면 클라이언트가 가동 중지 시간 동안 애플리케이션에 액세스할 수 없습니다. Traffic Manager SLA를 검토하고 Traffic Manager만 사용하는 것이 고가용성을 위한 비즈니스 요구 사항을 충족하는지 확인합니다. 그렇지 않은 경우 다른 트래픽 관리 솔루션을 장애 복구(Failback)로 추가합니다. Azure Traffic Manager 서비스가 실패하면 다른 트래픽 관리 서비스를 가리키도록 DNS의 CNAME 레코드를 변경합니다. (이 단계는 수동으로 수행해야 하며 DNS 변경 사항이 전파될 때까지 애플리케이션을 사용할 수 없습니다.)
SQL Server 클러스터의 경우 다음과 같은 두 가지 장애 조치(failover) 시나리오를 고려해야 합니다.
주 지역의 모든 SQL Server 데이터베이스 복제본이 실패합니다. 예를 들어 이런 장애가 지역 가동 중단 중에 발생할 수 있습니다. 그런 경우 Traffic Manager가 자동으로 프런트 엔드에서 장애 조치(failover)하더라도 가용성 그룹을 수동으로 장애 조치(failover)해야 합니다. SQL Server 가용성 그룹의 강제 수동 장애 조치(failover) 수행의 단계를 따릅니다. SQL Server 2016에서 SQL Server Management Studio, Transact-SQL 또는 PowerShell을 사용하여 강제 장애 조치(failover)를 수행하는 방법을 설명합니다.
경고
강제 장애 조치(failover)를 사용하면 데이터가 손실될 위험이 있습니다. 주 지역이 다시 온라인 상태가 되면 데이터베이스의 스냅샷을 만들고 tablediff를 사용하여 차이점을 찾습니다.
Traffic Manager는 보조 지역으로 장애 조치(failover)하지만 주 SQL Server 데이터베이스 복제본은 계속 사용할 수 있습니다. 예를 들어 SQL Server VM에 영향을 주지 않고 프런트 엔드 계층이 실패할 수 있습니다. 이 경우 인터넷 트래픽은 보조 지역으로 라우팅되며, 해당 지역은 여전히 주 복제본에 연결될 수 있습니다. 그러나 SQL Server 연결이 지역 간에 이루어지므로 대기 시간이 늘어납니다. 이 경우 다음과 같이 수동 장애 조치(failover)를 수행해야 합니다.
- 보조 지역의 SQL Server 데이터베이스 복제본을 동기 커밋으로 임시 전환합니다. 이 단계를 통해 장애 조치(failover) 중 데이터 손실이 발생하지 않게 합니다.
- 해당 복제본으로 장애 조치(failover)합니다.
- 주 지역으로 다시 장애 복구(failback)하는 경우 비동기 커밋 설정을 복원합니다.
관리 효율
배포를 업데이트할 때는 한 번에 하나의 지역만 업데이트하여 잘못된 구성이나 애플리케이션의 오류로 인한 글로벌 오류 발생 가능성을 줄입니다.
장애에 대한 시스템의 복원력을 테스트합니다. 다음은 테스트에 자주 사용되는 몇 가지 일반적인 오류 시나리오입니다.
- VM 인스턴스가 중단됩니다.
- CPU 및 메모리 같은 리소스 사용을 가중시킵니다.
- 네트워크 연결을 끊거나 지연시킵니다.
- 프로세스가 충돌합니다.
- 인증서가 만료됩니다.
- 하드웨어 오류를 시뮬레이트합니다.
- 도메인 컨트롤러에서 DNS 서비스를 중단합니다.
복구 시간을 측정하고 비즈니스 요구 사항이 충족되었는지 확인합니다. 오류 모드를 조합하여 테스트합니다.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.
Azure 가격 계산기를 사용하여 비용을 예측합니다. 기타 고려 사항은 다음과 같습니다.
Virtual Machine Scale Sets
Virtual Machine Scale Sets는 모든 Windows VM 크기에서 사용할 수 있습니다. 배포하는 Azure VM과 사용된 추가 기본 인프라 리소스(예: 스토리지 및 네트워킹)에 대해서만 요금이 청구됩니다. Virtual Machine Scale Sets 서비스에 대한 증분 요금은 없습니다.
단일 VM 가격 책정 옵션은 Windows VM 가격 책정을 참조하세요.
데이터베이스 가져오기
Azure SQL DBaas를 선택하는 경우 Always On 가용성 그룹 및 도메인 컨트롤러 머신을 구성할 필요가 없으므로 비용을 절감할 수 있습니다. 단일 데이터베이스에서 관리되는 인스턴스 또는 탄력적 풀에 이르는 몇 가지 배포 옵션이 있습니다. 자세한 내용은 Azure SQL 가격 책정을 참조하세요.
SQL Server VM 가격 책정 옵션은 SQL VM 가격 책정을 참조하세요.
부하 분산 장치
구성된 부하 분산 및 아웃바운드 규칙 수에 대한 요금만 청구됩니다. 인바운드 NAT 규칙은 무료입니다. 규칙을 구성하지 않으면 표준 Load Balancer에 대한 시간당 요금이 청구되지 않습니다.
Traffic Manager 가격 책정
Traffic Manager 청구는 수신된 DNS 쿼리 수를 기반으로 하며 10억 개 이상의 월간 쿼리를 수신하는 서비스에 대한 할인이 적용됩니다. 모니터링되는 각 엔드포인트에 대해서도 요금이 청구됩니다.
자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.
VNET-피어링 가격 책정
여러 Azure 지역을 사용하는 고가용성 배포는 VNET 피어링을 사용합니다. 동일한 지역 내의 VNET-피어링과 전역 VNET-피어링에 대해 서로 다른 요금이 부과됩니다.
자세한 내용은 가상 네트워크 가격 책정을 참조하세요.
DevOps
단일 Azure Resource Manager 템플릿을 사용하여 Azure 리소스 및 해당 종속성을 프로비전합니다. 동일한 템플릿을 사용하여 주 지역과 보조 지역 모두에 리소스를 배포합니다. 동일한 기본 워크로드에서 격리되도록 모든 리소스를 동일한 가상 네트워크에 포함합니다. 모든 리소스를 포함하면 워크로드의 특정 리소스를 DevOps 팀에 더 쉽게 연결하여 팀이 리소스의 모든 측면을 독립적으로 관리할 수 있습니다. 이러한 격리를 통해 DevOps 팀 및 서비스는 CI/CD(연속 통합 및 지속적인 업데이트)를 수행할 수 있습니다.
또한 다양한 Azure Resource Manager 템플릿을 사용하고 Azure DevOps Services와 통합하여 몇 분 안에 다양한 환경을 프로비전할 수 있습니다. 예를 들어 필요한 경우에만 프로덕션 유사 시나리오 또는 부하 테스트 환경을 복제하여 비용을 절감할 수 있습니다.
Azure Monitor를 사용하여 인프라의 성능을 분석 및 최적화하고 가상 머신에 로그인하지 않고 네트워킹 문제를 모니터링 및 진단하는 것이 좋습니다. Application Insights는 실제로 전체 Azure 환경의 상태를 확인하기 위한 풍부한 메트릭과 로그를 제공하는 Azure Monitor의 구성 요소 중 하나입니다. Azure Monitor는 인프라의 상태를 따르는 데 도움이 됩니다.
애플리케이션 데이터 계층의 낮은 성능은 심각한 결과를 초래할 수 있으므로 애플리케이션 코드를 지원하는 컴퓨팅 요소뿐 아니라 특정 데이터베이스에서 데이터 플랫폼도 모니터링해야 합니다.
애플리케이션이 실행되는 Azure 환경을 테스트하기 위해서는 애플리케이션 코드와 동일한 메커니즘을 통해 버전이 제어되고 배포되어야 하므로 DevOps 테스트 패러다임을 사용해 테스트하고 유효성을 검사할 수도 있습니다.
자세한 내용은 Microsoft Azure Well-Architected Framework의 운영 효율성 섹션을 참조하세요.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Donnie Trumpower | 선임 클라우드 솔루션 설계자
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.
다음 단계
관련 리소스
다음 아키텍처는 동일한 기술 중 일부를 사용합니다.