이 예제 시나리오는 고가용성 및 재해 복구를 위해 빌드된 복원력 있는 다중 계층 애플리케이션을 배포해야 하는 모든 산업에 적용됩니다. 이 시나리오에서는 애플리케이션이 세 계층으로 구성됩니다.
- 웹 계층: 사용자 인터페이스를 포함하는 최상위 계층입니다. 이 계층은 사용자 상호 작용을 구문 분석하고 작업을 다음 계층으로 전달하여 처리합니다.
- 비즈니스 계층: 사용자 상호 작용을 처리하고 다음 단계에 대한 논리적 결정을 내립니다. 이 계층은 웹 계층과 데이터 계층을 연결합니다.
- 데이터 계층: 애플리케이션 데이터를 저장합니다. 일반적으로 데이터베이스, 개체 스토리지 또는 파일 스토리지가 사용됩니다.
일반적인 애플리케이션 시나리오에는 Windows 또는 Linux에서 실행되는 모든 업무상 중요한 애플리케이션이 포함됩니다. SAP 및 SharePoint 같은 기성품 애플리케이션 또는 사용자 지정 LOB(기간 업무) 애플리케이션이 이에 해당합니다.
잠재적인 사용 사례
관련된 다른 사용 사례는 다음과 같습니다.
- SAP 및 SharePoint처럼 복원력이 뛰어난 애플리케이션 배포
- LOB(기간 업무) 애플리케이션을 위한 비즈니스 연속성 및 재해 복구 계획 디자인
- 재해 복구를 구성하고 규정 준수를 위해 관련 연습 수행
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
- 영역을 지원하는 지역의 두 가용성 영역에 걸쳐 각 계층에 VM을 배포합니다. 다른 지역에서는 한 가용성 집합의 각 계층에 VM을 배포합니다.
- 데이터베이스 계층에서는 Always On 가용성 그룹을 사용하도록 구성할 수 있습니다. 이 SQL Server 구성에서는 가용성 그룹 내의 기본 읽기/쓰기 복제본 하나가 최대 8개의 보조 읽기 전용 복제본으로 구성됩니다. 주 복제본에 문제가 발생하면 가용성 그룹은 기본 읽기/쓰기 작업을 보조 복제본 중 하나로 장애 조치(failover)하여 애플리케이션을 계속 사용할 수 있도록 합니다. 자세한 내용은 SQL Server에 대한 Always On 가용성 그룹 개요를 참조하세요.
- 재해 복구 시나리오의 경우 재해 복구에 사용되는 대상 지역에 SQL Always On 비동기 기본 복제를 구성할 수 있습니다. 또한 데이터 변경 속도가 Azure Site Recovery에서 지원되는 한도를 초과하지 않는 경우 대상 지역으로 Azure Site Recovery 복제를 구성할 수 있습니다.
- 사용자는 Traffic Manager 엔드포인트를 통해 프런트 엔드 ASP.NET 웹 계층에 액세스합니다.
- Traffic Manager는 주 원본 지역의 기본 공용 IP 엔드포인트로 트래픽을 리디렉션합니다.
- 공용 IP는 공용 부하 분산 장치를 통해 웹 계층 VM 인스턴스 중 하나에 대한 호출을 리디렉션합니다. 모든 웹 계층 VM 인스턴스는 한 서브넷에 있습니다.
- 웹 계층 VM에서 각 호출은 내부 부하 분산 장치를 통해 비즈니스 계층의 VM 인스턴스 중 하나로 라우팅되어 처리됩니다. 모든 비즈니스 계층 VM은 별도의 서브넷에 있습니다.
- 작업은 비즈니스 계층에서 처리되고 ASP.NET 애플리케이션은 Azure 내부 부하 분산 장치를 통해 백 엔드 계층의 Microsoft SQL Server 클러스터에 연결합니다. 이러한 백 엔드 SQL Server 인스턴스는 별도의 서브넷에 있습니다.
- Traffic Manager의 보조 엔드포인트는 재해 복구에 사용되는 대상 지역에 공용 IP로 구성됩니다.
- 주 지역이 중단될 경우 Azure Site Recovery 장애 조치(failover)가 호출되고 애플리케이션이 대상 지역에서 활성화됩니다.
- Traffic Manager 엔드포인트는 자동으로 클라이언트 트래픽을 대상 지역의 공용 IP로 리디렉션합니다.
구성 요소
- 가용성 집합을 사용하면 Azure에 배포한 VM이 클러스터의 격리된 여러 하드웨어 노드에 분산되도록 할 수 있습니다. Azure 내에서 하드웨어 또는 소프트웨어 오류가 발생하더라도 VM의 하위 집합에만 영향이 있고 전체 솔루션은 계속 작동하므로 계속 사용할 수 있습니다.
- 가용성 영역은 데이터 센터 오류로부터 애플리케이션과 데이터를 보호합니다. 가용성 영역은 Azure 지역 내에서 독립된 물리적 위치입니다. 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성됩니다.
- Azure Site Recovery를 사용하여 VM을 다른 Azure 지역에 복제하면 비즈니스 연속성 및 재해 복구 요구 사항을 충족할 수 있습니다. 규정 준수 요구 사항을 충족하도록 정기적인 재해 복구 훈련을 수행할 수 있습니다. VM은 원본 지역에서 중단이 발생한 경우 애플리케이션을 복구할 수 있도록 선택한 지역에 지정된 설정을 사용하여 복제됩니다.
- Azure Traffic Manager는 트래픽을 글로벌 Azure 지역의 서비스에 적절하게 분산하는 한편, 고가용성과 빠른 응답성을 제공하는 DNS 기반 트래픽 부하 분산 장치입니다.
- Azure 부하 분산 장치는 정의된 규칙 및 상태 프로브에 따라 인바운드 트래픽을 분산합니다. 부하 분산 장치는 짧은 대기 시간과 높은 처리량을 제공하고, 모든 TCP 및 UDP 애플리케이션을 처리할 수 있도록 최대 수백만 개의 흐름으로 확장됩니다. 공용 부하 분산 장치는 들어오는 클라이언트 트래픽을 웹 계층으로 분산하는 시나리오에 사용됩니다. 내부 부하 분산 장치는 비즈니스 계층의 트래픽을 백 엔드 SQL Server 클러스터로 분산하는 시나리오에 사용됩니다.
대안
- 인프라의 어떤 것도 운영 체제에 종속되지 않으므로 Windows를 다른 운영 체제로 대체할 수 있습니다.
- Linux용 SQL Server는 백 엔드 데이터 저장소를 대체할 수 있습니다.
- 데이터베이스를 사용 가능한 아무 표준 데이터베이스 애플리케이션으로 대체할 수 있습니다.
시나리오 정보
이 시나리오에서는 ASP.NET 및 Microsoft SQL Server를 사용하는 다중 계층 애플리케이션을 보여줍니다. 가용성 영역을 지원하는 Azure 지역에서, 원본 지역의 VM(가상 머신)을 여러 가용성 영역에 배포하고 재해 복구에 사용되는 대상 지역에 VM을 복제할 수 있습니다. 가용성 영역을 지원하지 않는 Azure 지역에서는 가용성 집합 내에 VM을 배포하고 대상 영역에 VM을 복제할 수 있습니다.
지역 간에 트래픽을 라우팅하려면 전역 부하 분산 장치가 필요합니다. 다음의 두 가지 주요 Azure 제품이 있습니다.
- Azure Front Door
- Azure Traffic Manager
부하 분산 장치를 선택할 때 요구 사항과 두 제품의 기능 집합을 고려합니다. 얼마나 빨리 장애 조치(failover)를 원하나요? TLS 관리의 오버헤드를 감수할 수 있으신가요? 조직 비용에 제약 조건이 있나요?
Front Door에는 SSL 오프로드, 경로 기반 라우팅, 빠른 장애 조치(failover), 캐싱 등의 레이어 7 기능이 있어 애플리케이션의 성능과 고가용성을 향상시킬 수 있습니다. 인프라가 Azure 네트워크에 더 빨리 온보딩되기 때문에 패킷 이동 시간이 단축될 수 있습니다.
Front Door에서는 새 홉을 추가하므로 보안 작업이 추가됩니다. 아키텍처가 규정 요구 사항을 준수하는 경우 추가 트래픽 TLS 종료 지점에 대한 제한이 있을 수 있습니다. Front Door에서 선택한 TLS 암호화 도구 모음은 조직의 보안 기준을 충족해야 합니다. 또한 Front Door는 백 엔드 서비스가 Microsoft에서 사용하는 인증서를 사용할 것으로 예상합니다.
또 다른 고려 사항은 비용입니다. 아키텍처는 추가 비용을 정당화하기 위해 광범위한 기능 집합(단순한 장애 조치(failover) 아님)을 활용해야 합니다.
Traffic Manager는 DNS 기반 부하 분산 서비스입니다. DNS 수준에서만 균형을 맞추고 장애 조치(fails over)합니다. 이러한 이유로 DNS 캐싱 및 시스템에서 DNS TTL 값을 준수하지 않는 것과 관련된 일반적인 문제가 발생하여 Front Door만큼 빠르게 장애 조치(failover)할 수 없습니다.
필요한 경우 두 부하 분산 장치를 결합할 수 있습니다. 예로, DNS 기반 장애 조치(failover)를 원하지만 트래픽 관리 인프라 앞에 POP 환경을 추가하려는 경우를 들 수 있습니다.
이 아키텍처는 경량이므로 Traffic Manager를 사용합니다. 장애 조치(failover) 타이밍은 설명용으로 충분합니다.
고려 사항
확장성
크기 조정 요구 사항에 따라 각 계층에서 VM을 추가 또는 제거할 수 있습니다. 이 시나리오에서는 부하 분산 장치를 사용하므로 애플리케이션 가동 시간에 영향을 주지 않고 계층에 더 많은 VM을 추가할 수 있습니다.
다른 확장성 항목은 Azure 아키텍처 센터의 성능 효율성 검사 목록을 참조하세요.
보안
프론트 엔드 애플리케이션 계층으로 전송되는 모든 가상 네트워크 트래픽은 네트워크 보안 그룹을 통해 보호됩니다. 규칙은 프런트 엔드 애플리케이션 계층 VM 인스턴스만 백 엔드 데이터베이스 계층에 액세스할 수 있도록 트래픽 흐름을 제한합니다. 비즈니스 계층 또는 데이터베이스 계층에는 아웃바운드 인터넷 트래픽이 허용되지 않습니다. 공격 공간을 줄이기 위해 직접 원격 관리 포트가 열려 있지 않습니다. 자세한 내용은 Azure 네트워크 보안 그룹을 참조하세요.
보안 시나리오 설계에 대한 일반적인 지침은 Azure 보안 설명서를 참조하세요.
가격 책정
Azure Site Recovery를 사용하여 Azure VM에 대한 재해 복구를 구성하면 지속적으로 다음 요금이 부과됩니다.
- VM당 Azure Site Recovery 라이선스 비용.
- 원본 VM 디스크에서 다른 Azure 지역으로 데이터 변경 내용을 복제하기 위한 네트워크 송신 비용. Azure Site Recovery는 기본 압축을 사용하여 데이터 전송 요구 사항을 약 50% 줄입니다.
- 복구 사이트의 스토리지 비용. 일반적으로 원본 지역 스토리지와 복구용 스냅샷으로 복구 지점을 유지하는 데 필요한 추가 스토리지를 합친 양과 동일합니다.
가상 머신 6개를 사용하는 3계층 애플리케이션에 대한 재해 복구를 구성할 수 있는 샘플 비용 계산기가 제공됩니다. 모든 서비스는 비용 계산기에 미리 구성되어 있습니다. 특정 사용 사례의 가격 책정이 어떻게 변동되는지 확인하려면 예상 사용량에 맞게 변수를 적절하게 변경하세요.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Sujay Talasila | 주요 제품 잠재 고객
다음 단계
관련 참고 자료
추가 고가용성 및 재해 복구 참조 아키텍처는 다음을 참조하세요.
- 다중 지역 N 계층 애플리케이션
- 다중 지역 부하 분산
- [프라이빗 데이터베이스가 있는 다중 지역 앱] [Multi-region-app-with-private-database]
- 엔터프라이즈급 재해 복구