고가용성을 위해 여러 Azure Stack Hub 지역에서 N 계층 애플리케이션 실행
이 참조 아키텍처는 가용성 및 강력한 재해 복구 인프라를 달성하기 위해 N 계층 애플리케이션 여러 Azure Stack Hub 지역에서 실행하기 위한 검증된 사례 집합을 보여 줍니다. 이 문서에서 Traffic Manager는 고가용성을 달성하는 데 사용되지만, Traffic Manager가 사용자 환경에서 선호되는 선택이 아닌 경우 고가용성 부하 분산 장치 쌍을 대체할 수도 있습니다.
참고
아래 아키텍처에 사용된 Traffic Manager는 Azure에서 구성해야 하며 Traffic Manager 프로필을 구성하는 데 사용되는 엔드포인트는 공개적으로 라우팅 가능한 IP여야 합니다.
아키텍처
이 아키텍처는 SQL Server를 통한 N 계층 애플리케이션에 나와 있는 아키텍처를 기반으로 합니다.
주 지역 및 보조 지역. 더 높은 가용성을 달성하기 위해 두 개의 지역을 사용합니다. 하나는 주 지역입니다. 다른 하나는 장애 조치(failover)를 위한 지역입니다.
Azure Traffic Manager. Traffic Manager는 들어오는 요청을 이 지역 중 하나에 라우팅합니다. 정상 작동 중에는 요청을 주 지역으로 라우팅합니다. 이 지역을 사용할 수 없게 되면 Traffic Manager가 보조 지역으로 장애 조치(failover)합니다. 자세한 내용은 Traffic Manager 구성 섹션을 참조하세요.
리소스 그룹. 주 지역인 보조 지역에 대해 별도의 리소스 그룹을 만듭니다. 따라서 각 지역을 단일 리소스 모음으로 유연하게 관리할 수 있습니다. 예를 들어 다른 지역으로 이동하지 않고 한 지역을 다시 배포할 수 있습니다. 리소스 그룹을 연결하므로 애플리케이션의 모든 리소스를 나열하는 쿼리를 실행할 수 있습니다.
가상 네트워크 각 지역에 대해 별도의 가상 네트워크를 만듭니다. 주소 공간이 겹치지 않도록 합니다.
SQL Server Always On 가용성 그룹. SQL Server를 사용하는 경우 고가용성을 위해 SQL Always On 가용성 그룹을 사용하는 것이 좋습니다. 두 지역 모두에 SQL Server 인스턴스를 포함하는 단일 가용성 그룹을 만듭니다.
VNET에서 VNET으로 VPN 연결. Azure Stack Hub에서 VNET 피어링을 아직 사용할 수 없으므로 VNET 간 VPN 연결을 사용하여 두 VNET을 연결합니다. 자세한 내용은 Azure Stack Hub의 VNET-VNET 을 참조하세요.
권장 사항
다중 지역 아키텍처는 단일 지역에 배포하는 것보다 더 높은 가용성을 제공할 수 있습니다. 지역 가동 중단이 주 지역에 영향을 주는 경우 Traffic Manager를 사용하여 보조 지역으로 장애 조치(failover)할 수 있습니다. 이 아키텍처는 애플리케이션의 개별 하위 시스템이 고장난 경우에도 도움이 될 수 있습니다.
지역에서 고가용성을 달성하는 데 몇 가지 일반적인 접근 방식이 있습니다.
활성/수동(핫 대기 상태) 트래픽이 한 지역으로 이동하면 다른 하나가 상시 대기 상태에서 기다립니다. 상시 대기는 항상 보조 지역의 VM이 할당되고 실행 중이라는 의미입니다.
콜드 대기 상태의 활성/수동 트래픽이 한 지역으로 이동하면 다른 하나가 수동 대기에서 기다립니다. 수동 대기는 장애 조치(failover)에 필요할 때까지 보조 지역의 VM이 할당되지 않는다는 것입니다. 이 방법은 실행하는 데 비용이 덜 들지만, 일반적으로 실패 상태에 있을 때 온라인 상태가 되는 데 더 오래 시간이 걸립니다.
활성/활성. 두 지역 모두 활성화되어 있으며, 요청이 두 지역 사이에서 부하 분산됩니다. 한 지역을 사용할 수 없게 되면 회전이 중단됩니다.
이 참조 아키텍처는 장애 조치(failover)를 위해 Traffic Manager를 사용하여 활성/수동(상시 대기)을 중점적으로 다룹니다. 핫 대기를 위해 적은 수의 VM을 배포한 다음 필요에 따라 스케일 아웃할 수 있습니다.
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 externalEndpoints --priority 3
또 다른 방법은 장애 복구(failback)할 준비가 될 때까지 엔드포인트를 일시적으로 사용하지 않도록 설정하는 것입니다.
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type externalEndpoints --endpoint-status Disabled
장애 조치(failover)의 원인에 따라 한 지역 내에서 리소스를 다시 배포해야 할 수 있습니다. 장애 복구(failback) 전에 운영 준비 상태 테스트를 수행합니다. 이 테스트는 다음과 같은 사항을 확인해야 합니다.
VM이 올바르게 구성되어 있습니다. 필요한 모든 소프트웨어가 설치되어 있고, IIS가 실행 중인지 확인합니다.
애플리케이션 하위 시스템이 정상입니다.
기능을 테스트합니다. 예를 들어 웹 계층에서 데이터베이스 계층에 연결 가능한지 테스트합니다.
SQL Server Always On 가용성 그룹 구성
Windows Server 2016 이전 버전에서는 SQL Server Always On 가용성 그룹에 항상 도메인 컨트롤러가 필요하며, 가용성 그룹의 모든 노드가 동일한 AD(Active Directory) 도메인에 있어야 합니다.
가용성 그룹을 구성하려면:
최소한 두 개의 도메인 컨트롤러를 각 지역에 배치합니다.
각 도메인 컨트롤러에 고정 IP 주소를 지정합니다.
VPN을 만들어 두 가상 네트워크 간의 통신을 사용하도록 설정합니다.
각 가상 네트워크에 대해 두 지역 모두에서 도메인 컨트롤러의 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)를 지원하지 않습니다.
가용성 고려 사항
복잡한 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 Cloud 패턴에 대해 자세히 알아보려면 클라우드 디자인 패턴을 참조하세요.