다중 리전 네트워크 설계

이 문서에서는 여러 지역에 걸쳐 있는 Azure 네트워크를 디자인하는 방법을 설명합니다. 다중 리소스 네트워크는 지역 가동 중단에 대한 고가용성을 제공하고, 대기 시간이 짧은 지리적으로 분산된 사용자에게 서비스를 제공하며, 규제 데이터 보존 요구 사항을 지원합니다.

이 문서에서 다루는 내용

이 문서에서는 영역 중복성과 지역 중복성의 비교, 지역 간 라우팅 전략, 다중 지역 배포를 위한 허브 토폴로지 선택, 활성-활성 및 활성-수동 장애 조치 패턴, 그리고 복제 지연 시간 고려 사항을 다룹니다.

이 문서가 필요한 사람

환경이 다음 조건과 일치하는 경우 이 문서를 읽어보세요.

워크로드에는 전체 Azure 지역 오류에 대한 재해 복구 보호가 필요합니다.
여러 지역에서 사용자에게 서비스를 제공하고 네트워크 대기 시간을 최소화해야 합니다.
규정 또는 규정 준수 요구 사항은 데이터가 특정 지리적 경계 내에 있어야 합니다.
비즈니스 연속성 목표는 단일 지역에서만 충족할 수 없는 RTO(복구 시간 목표)를 정의합니다.

워크로드가 단일 지역에서 작동하고 영역 중복 배포가 가용성 요구 사항을 충족하는 경우 아직 다중 리전 디자인이 필요하지 않을 수 있습니다. 허브 및 스포크 토폴로지로 시작하거나 한 지역에서 Virtual WAN 나중에 확장합니다.

리프트 앤 시프트 포커스: 레거시 워크로드는 지역 간에 활성-활성을 실행할 수 없는 경우가 많습니다. 전체 활성-활성 디자인이 아닌 Azure Site Recovery 및 복구 지역의 허브를 사용하여 재해 복구를 계획합니다.

현대화 중점: 필요 시 지역 간 피어링이 가능하도록 겹치지 않는 주소 공간을 사용하여, 영역 중복 SKU와 함께 고객 대상 앱을 두 지역에 걸쳐 active-active로 배포합니다.

크로스 클라우드 중심: Azure Virtual WAN을 사용하여 여러 리전과 지사를 연결하고, 크로스 클라우드 트랜짓과 함께 리전 간 라우팅을 계획하세요.

Azure 서비스 및 기능

다음 표에는 다중 지역 네트워킹을 지원하는 Azure 서비스 및 기능이 나와 있습니다.

서비스 또는 기능	다중 리전 설계에서의 역할	자세히 알아보기
Azure 트래픽 관리자	모든 프로토콜에 대한 지역 간 DNS 기반 트래픽 라우팅	Traffic Manager 개요
Azure Front Door	엣지에서 CDN 및 WAF를 통한 HTTP/HTTPS 전역 부하 분산	Front Door 개요
전역 VNet 피어링	서로 다른 지역의 가상 네트워크 간 프라이빗, 높은 대역폭 연결	가상 네트워크 피어링
ExpressRoute Global Reach	Azure 백본을 통해 온-프레미스 사이트를 서로 연결합니다.	ExpressRoute Global Reach
Azure Virtual WAN(다중 허브)	자동 허브 간 라우팅을 사용하여 Microsoft 관리되는 글로벌 전송	Virtual WAN 글로벌 전송
AZURE VIRTUAL NETWORK MANAGER(AVNM)	지역 간 피어링 토폴로지 및 네트워크 그룹 관리 자동화	AVNM 개요

다중 리전에 여러 가상 네트워크가 필요한 이유

VNet(가상 네트워크)은 단일 지역에 걸쳐 있습니다. 해당 VNet 내의 서브넷은 지역의 모든 가용성 영역에 걸쳐 있지만 VNet 자체는 지역 경계를 넘어 확장할 수 없습니다. 따라서 다중 리전 네트워킹은 지역당 하나 이상의 여러 VNet을 배포하고 지역 간 서비스와 연결하는 것을 의미합니다.

이 기본적인 제약 조건은 모든 멀티 리전 설계를 좌우합니다:

각 지역에는 고유한 VNet 주소 공간(피어링을 위해 다른 지역과 겹치지 않는)이 필요합니다.
지역 간 트래픽에는 명시적 연결 메커니즘인 글로벌 VNet 피어링, Virtual WAN 허브 간 또는 게이트웨이 기반 라우팅이 필요합니다.
글로벌 부하 분산 서비스(Traffic Manager 또는 Front Door)는 사용자를 올바른 지역 배포로 안내합니다.

서브넷 및 주소 계획 지침은 IP 주소 계획을 참조하세요.

가용성 영역 및 지역 중복성

다중 리전 토폴로지 설계 전에 Azure 두 가지 수준의 인프라 중복성을 이해합니다.

Level	~에 대항하여 보호하다	메커니즘	예시
가용성 영역	지역 내의 단일 데이터 센터 오류	독립적인 전원, 냉각 및 네트워킹을 사용하여 데이터 센터를 물리적으로 분리	3개 영역에 배포된 영역 중복 Azure Firewall
지역 중복	전체 지역 오류(자연 재해, 광범위한 중단)	둘 이상의 Azure 지역에 워크로드 배포	미국 동부 및 미국 서부의 active-active 웹 애플리케이션

영역 중복성부터 시작합니다. 영역 중복 배포는 다중 리전 라우팅의 복잡성 없이 가장 일반적인 오류 시나리오(단일 데이터 센터 문제)로부터 보호합니다. 비즈니스에서 지역 전체 중단에 대한 보호가 필요하거나 지리적으로 분산된 사용자에게 서비스를 제공해야 하는 경우 지역 중복성을 추가합니다.

영역 중복 네트워크 서비스 참조

다음 표에서는 핵심 네트워크 서비스에 대한 영역 중복 배포 옵션을 보여 줍니다. 워크로드를 실행하는 모든 지역에 배포합니다.

서비스	영역 중복 옵션	Notes
Azure Firewall	가용성 영역 간 배포	지역의 3개 영역 모두에 분산
표준 부하 분산 장치 (표준 Load Balancer)	영역 중복형 프런트엔드	표준 SKU의 기본 동작
Application Gateway v2	영역 중복 배포	Standard_v2 또는 WAF_v2 SKU 필요
VPN 게이트웨이	영역 중복 SKU를 사용하는 active-active	AZ 접미사가 붙은 SKU를 사용하세요(VpnGw1AZ, VpnGw2AZ 등)
ExpressRoute 게이트웨이	영역 중복 SKU	ErGw1AZ, ErGw2AZ 또는 ErGw3AZ 사용
Azure Bastion	영역 중복(미리 보기)	기본, 표준 및 프리미엄 SKU
NAT 게이트웨이(StandardV2)	Zone-redundant	StandardV2 SKU 필요; 표준 SKU는 영역 전용입니다.

지역 간 트래픽 라우팅 방법을 선택하는 방법

다음 의사 결정 테이블을 사용하여 지역 간 트래픽 라우팅에 적합한 서비스를 선택합니다.

요구 사항	권장 서비스	작동 방식
모든 프로토콜(HTTP, TCP, UDP)에 대한 다중 지역 장애 조치(failover) 또는 부하 분산	Azure 트래픽 관리자	DNS 확인을 통해 최상의 엔드포인트 IP를 반환합니다. 클라이언트는 엔드포인트에 직접 연결합니다. 장애 조치 속도는 DNS TTL(일반적으로 30~300초)에 따라 달라집니다.
CDN, WAF 및 신속한 장애 조치를 지원하는 글로벌 HTTP/HTTPS 부하 분산	Azure Front Door	에지 PoP(접속 지점)에서 연결을 종료합니다. 요청을 가장 가까운 정상 백 엔드로 라우팅합니다. DNS TTL에 의존하지 않는 초 단위의 연결 수준 장애 조치를 제공합니다.
지역 간 프라이빗 백 엔드 트래픽(복제, 내부 API)	전역 VNet 피어링	Microsoft 백본을 통해 지역 간에 VNet을 연결합니다. 피어링이 전이적이지 않습니다. 각 피어링 관계는 명시적입니다. Per-GB 데이터 전송 요금이 적용합니다.
Azure 통해 온-프레미스 사이트 간 연결	ExpressRoute Global Reach	허브 라우터를 트래버스하지 않고 온-프레미스 위치가 Microsoft 백본을 통해 통신할 수 있도록 두 개의 ExpressRoute 회로를 연결합니다.

팁 (조언)

이러한 서비스를 결합합니다. 예를 들어 사용자 연결 HTTP 트래픽에 Front Door를 사용하고 지역 간 백 엔드 복제에 전역 VNet 피어링을 사용합니다.

다중 리전 허브 토폴로지를 선택하는 방법

지역 간에 네트워크를 확장하기로 결정한 후 지역 간 연결을 관리하기 위한 허브 패턴을 선택합니다.

요인	지역별 허브 (기존)	Virtual WAN 다중 허브
지역 간 연결	고객은 지역 허브 간에 글로벌 VNet 피어링을 구성하고 UDR을 관리합니다.	자동 허브 간 라우팅: 기본적으로 모든 Virtual WAN 허브 상호 연결
Management	라우팅, 방화벽 규칙 및 피어링에 대한 모든 고객 제어	정책 기반 관리를 사용하는 Microsoft 관리형 허브 인프라
적합한 대상	세분화된 라우팅 제어, 사용자 지정 NVA 또는 기존 허브 투자가 필요한 조직	여러 지역에 걸쳐 있거나, 30개 이상의 지사가 있거나, 관리형 인프라를 선호하는 조직
글로벌 전송	각 허브 쌍 간에 명시적 피어링 + UDR 구성 필요	기본 제공: 두 허브 간의 트래픽이 자동으로 라우팅됩니다.
Scaling	수동으로 허브 및 피어링 추가(AVNM을 자동화할 수 있습니다).	Virtual WAN 구성을 통해 허브 추가: 라우팅이 자동으로 업데이트됨
비용 모델	별도로 청구되는 허브 VNet 리소스(방화벽, 게이트웨이, 피어링)	Virtual WAN 단위 가격 책정 및 연결된 리소스

허브 및 스포크 및 단일 지역의 Virtual WAN 대한 자세한 비교는 허브 및 스포크 토폴로지 및 Virtual WAN 참조하세요.

디자인 고려 사항

리프트 앤 시프트 다중 지역 디자인 포커스

가용성 영역이나 지역에 걸쳐 배포할 수 없는 레거시 워크로드의 경우, active-active 아키텍처보다는 재해 복구를 고려해 설계하고 Azure Site Recovery를 사용하여 복구 지역에 복제합니다.
장애 조치 트래픽도 동일한 공유 서비스를 사용할 수 있도록 기본 허브를 미러링하는 허브를 복구 지역에 구축합니다.
Azure Traffic Manager 또는 DNS 장애 조치(failover)를 사용하여 지역 가동 중단 중에 사용자를 리디렉션합니다.
장애 조치 중 및 이후의 피어링에서 충돌을 방지하려면 복구 리전 주소 공간이 주 리전과 겹치지 않도록 유지하세요.

다중 지역 디자인 포커스 현대화

최고 수준의 복원력을 위해 영역 중복 SKU를 사용하여 두 지역에 고객 대상 워크로드를 active-active로 배포합니다.
active-active 스포크에서 나중에 다시 주소 지정 없이 전역 VNet 피어링을 사용할 수 있도록 겹치지 않는 주소 범위를 주 및 백업 지역에 할당합니다.
앱 유형별로 배달 계층을 선택합니다. 웹앱의 경우 Azure Front Door, 비 웹앱의 경우 Traffic Manager를 선택하여 지역 공용 엔드포인트에 분산합니다.
백 엔드에 도달하기 전에 인바운드 트래픽을 검사할 수 있도록 허브 방화벽(SNAT 및 DNAT)을 사용하여 각 지역의 퍼블릭 엔드포인트를 전면에 배치합니다.

클라우드 간 다중 리전 설계 중점

Azure Virtual WAN을 사용하여 자동 전체 메시 라우팅으로 여러 Azure 지역, 지사 및 클라우드 에지를 상호 연결하세요.
지역 및 클라우드에서 요약되고 겹치지 않는 주소 범위를 계획하여 전송 라우팅이 단순하게 유지되도록 합니다.
지역 보안 허브에서 클라우드 간 IPsec 연결을 종료하고 Virtual WAN 허브 간 라우팅을 처리하도록 합니다.
Front Door 또는 Traffic Manager를 사용하여 여러 지역에 걸쳐 공용 인그레스 트래픽을 분산하고, 각 지역 허브 방화벽에서 검사를 유지합니다.

사전 요구 사항

다중 리전 네트워크를 설계하기 전에 다음을 갖추었는지 확인하세요:

단일 지역 토폴로지 배포 및 테스트 허브 및 스포크 또는 Virtual WAN으로 시작합니다.
정의된 고가용성 및 재해 복구 요구 사항: RTO, RPO(복구 지점 목표) 및 규정 준수 의무.
모든 지역에서 겹치지 않는 IP 주소 계획을 만들었습니다. IP 주소 계획을 참조하세요.
지역 중복과 영역 중복만 필요한 워크로드를 식별했습니다.

활성-활성 배포 및 활성-수동 배포 패턴

다중 리전 배포 모델은 정상 운영 중과 리전 장애 발생 시 트래픽 흐름이 어떻게 결정되는지를 좌우합니다.

Active-active

두 지역 모두 동시에 트래픽을 제공합니다. Traffic Manager 또는 Front Door와 같은 전역 부하 분산 장치는 근접, 성능 또는 가중치에 따라 지역 간에 요청을 분산합니다.

액티브-액티브를 사용해야 하는 경우:

애플리케이션은 지역별 상태 종속성 없이 모든 지역의 요청을 처리할 수 있습니다.
가능한 한 가장 낮은 RTO가 필요합니다(정상 상태의 하위 지역이 이미 트래픽을 처리하고 있으므로 페일오버가 즉시 이루어지기 때문입니다).
정상 작동(비용 효율성)을 수행하는 동안 두 지역에서 용량을 사용하려고 합니다.

네트워킹 고려 사항:

두 지역 모두 방화벽, 게이트웨이 및 부하 분산 장치를 포함하여 동일한 네트워크 인프라를 가져야 합니다.
지역 간 데이터 복제는 두 배포를 모두 최신 상태로 유지해야 합니다.
DNS TTL 및 상태 프로브 간격은 Traffic Manager에서 트래픽을 이동하는 빈도를 결정합니다. Front Door는 더 빠른 연결 수준 장애 조치(failover)를 제공합니다.

Active-passive

한 지역(기본)이 모든 트래픽을 처리합니다. 보조 지역은 준비 상태를 유지하지만 장애 조치(failover) 이벤트까지 사용자 요청을 처리하지 않습니다.

활성-수동을 사용하는 경우:

애플리케이션에 엄격한 쓰기 지역 요구 사항이 있거나 상태를 쉽게 복제할 수 없습니다.
비용 제약 조건으로 인해 두 지역에서 전체 용량을 동시에 실행할 수 없습니다.
RTO 허용 오차는 보조 지역을 활성화하는 데 필요한 시간을 허용합니다.

네트워킹 고려 사항:

대기 지역의 네트워크 인프라는 장애 조치가 발생할 때까지 더 낮은 티어 또는 축소된 용량을 사용할 수 있습니다.
자동 장애 조치에는 적절한 임계값이 설정된 상태 확인 프로브가 필요합니다(플래핑 방지).
정기적으로 장애 조치(failover)를 테스트합니다. 유효성을 검사하지 않으면 수동 지역의 네트워크 구성이 드리프트될 수 있습니다.
지역 간에 경로 테이블과 NSG 규칙을 동기화된 상태로 유지합니다. 코드 기반 인프라 템플릿을 사용하여 수동 지역이 주 지역의 보안 상태와 일치하는지 확인합니다.
수동 지역에서 VPN 또는 ExpressRoute 게이트웨이를 미리 프로비전합니다. 게이트웨이 프로비저닝은 20~45분이 걸릴 수 있습니다. 이는 대부분의 RTO 대상에 비해 너무 느립니다.

활성-활성 및 활성-수동 네트워킹 중에서 선택

활성-활성 네트워킹과 활성-수동 네트워킹 중에서 선택하는 것은 네트워크 크기 조정, 비용 및 운영 복잡성에 영향을 줍니다.

고려 사항	Active-active	Active-passive
네트워크 용량	두 지역의 전체 용량	보조 지역의 용량 감소(페일오버 시 크기 조정)
게이트웨이 프로비저닝	두 지역에서 항상 켜기	미리 프로비전되었지만 더 작은 계층을 사용할 수 있음
지역 간 데이터 동기화	연속 양방향 복제 트래픽	스탠바이로의 단방향 비동기 복제
방화벽 규칙	동일한 규칙 집합( 둘 다 적극적으로 적용됨)	동일한 규칙 집합이지만 비활성 규칙 집합은 거의 사용되지 않습니다.
IP 주소 지정	두 지역 모두 글로벌 로드 밸런서에 경로를 광고합니다	장애 조치 시까지는 주 지역만 광고합니다.
운영 위험	아래쪽: 두 경로가 계속 실행됨	높음: 수동 경로가 드리프트되거나 테스트되지 않은 구성이 있을 수 있습니다.

데이터 복제 및 대기 시간

지역 간 복제는 애플리케이션 디자인에 영향을 주는 네트워크 대기 시간을 도입합니다. 동일한 지리 내의 Azure 지역은 일반적으로 가까운 쌍에 대해 1~10ms 왕복 대기 시간(예: 미국 동부에서 미국 동부 2) 및 먼 쌍(예: 미국 동부에서 미국 서부)의 경우 30~70ms를 나타냅니다. 대서양 횡단 또는 태평양 횡단 지역 쌍은 100ms를 초과할 수 있습니다.

주요 디자인 고려 사항:

복제 토폴로지: 대기 시간이 짧은 지역 쌍(< 10ms)에 대해서만 동기 복제를 선택합니다. 애플리케이션 성능 저하를 방지하려면 먼 쌍에 비동기 복제를 사용합니다.
대역폭 계획: 복제 처리량 요구 사항을 예측하고 GB당 글로벌 VNet 피어링 데이터 전송 비용을 고려합니다. 서로 멀리 떨어진 리전 간의 대용량 복제는 상당한 데이터 송신 요금을 발생시킬 수 있습니다.
충돌 해결: 양방향 쓰기가 있는 활성-활성 패턴에는 애플리케이션 또는 데이터베이스 계층에서 충돌 해결 전략이 필요합니다. 네트워크는 연결을 제공하지만 애플리케이션은 쓰기 충돌을 처리해야 합니다.
PaaS 복제를 위한 프라이빗 엔드포인트: 지역 간에 Azure SQL, Cosmos DB 또는 스토리지를 복제할 때 각 지역의 프라이빗 엔드포인트를 사용하여 Microsoft 백본에서 복제 트래픽을 유지하고 공용 인터넷 노출을 방지합니다.

비용 고려 사항

다중 리전 네트워킹은 중복된 인프라 및 지역 간 데이터 전송을 통해 비용을 증가합니다. 다음과 같은 기본 비용 동인을 중심으로 예산을 계획합니다.

지역 간 데이터 전송: 글로벌 VNet 피어링 및 Virtual WAN 허브 간 트래픽은 지역 경계를 넘는 데이터에 대해 GB당 요금이 발생합니다. 같은 지역에 있는 피어링된 VNet 간의 지역 내 트래픽은 동일 영역 간에는 추가 비용이 없고, 영역 간에는 더 낮은 요율이 적용됩니다.
중복된 네트워크 어플라이언스: 각 지역에는 자체 방화벽, 부하 분산 장치 및 게이트웨이 인스턴스가 필요합니다. 액티브-액티브 배포는 이러한 비용을 두 배로 늘립니다. 활성-수동 배포는 대기 지역에서 더 작은 계층을 사용하고 장애 조치(failover) 중에 확장하여 비용을 절감할 수 있습니다.
글로벌 부하 분산 요금: Traffic Manager 및 Front Door는 모두 처리된 DNS 쿼리 또는 요청에 따라 요금이 청구됩니다. Front Door는 에지 PoP에서 백 엔드로의 데이터 전송에 대해 추가 요금을 부과합니다.
ExpressRoute 및 VPN Gateway: 다중region 디자인에는 종종 각 지역의 게이트웨이 인스턴스가 필요합니다. 여러 지역을 연결하는 ExpressRoute 회로는 월별 포트 요금 및 GB당 요금제 데이터 요금을 추가합니다.
트래픽 지역성을 사용하여 최적화: 지역 간 호출을 최소화하도록 애플리케이션 계층을 디자인합니다. 복제 대역폭 및 대기 시간에 민감한 쿼리를 줄이기 위해 각 지역의 컴퓨팅과 공동 배치된 읽기 복제본을 유지합니다.

보안 고려 사항

다중Region 네트워크는 단일 지역 배포 외에 보안 고려 사항을 도입합니다.

트래픽은 Microsoft 백본 네트워크를 통해 전송됩니다. 모든 지역 간 트래픽은 Global VNet 피어링 또는 Virtual WAN 허브 간 연결을 통해 공용 인터넷이 아니라 Microsoft 백본 네트워크를 통과합니다.
모든 지역에 영역 중복 방화벽을 배포합니다. 각 지역 허브는 트래픽 검사를 위해 자체 방화벽 인스턴스가 필요합니다. 영역 오류 시 보안을 유지하기 위해 가용성 영역에 방화벽을 배포합니다.
Front Door WAF는 에지 보안을 제공합니다. Front Door를 사용하면 Front Door에 통합된 웹 애플리케이션 방화벽이 트래픽이 어느 지역 배포에 도달하기 전에 이를 검사합니다. 네트워크 에지에서 첫 번째 방어 계층을 제공합니다.
DNS 장애 조치를 신중하게 계획하세요. Traffic Manager 장애 조치(failover)는 DNS TTL에 따라 달라집니다. TTL이 짧을수록 장애 조치(failover)가 더 빨라지지만 DNS 쿼리 볼륨이 증가합니다. Front Door는 클라이언트 DNS 캐시 만료에 의존하지 않는 연결 수준 장애 조치(failover)를 제공합니다.
ExpressRoute Global Reach 트래픽은 비공개로 유지됩니다. Global Reach를 통해 연결된 온-프레미스 사이트 간의 트래픽은 공용 인터넷에 연결되지 않습니다. 회로 간의 Microsoft 백본에 유지됩니다.
지역 간 복제 채널을 보호합니다. 글로벌 VNet 피어링을 통해 백 엔드 복제 트래픽은 기본적으로 비공개이지만 전송 중인 중요한 데이터에 대해 네트워크 보안 그룹 및 암호화를 적용합니다.

다중 리전 설계에 이 가이드의 다른 섹션에서 다루는 특정 시나리오가 포함되어 있는 경우 다음을 참조하세요.

허브 및 스포크 토폴로지: 다중 리전 배포를 위한 지역별 허브 디자인 패턴입니다.
Virtual WAN: 자동 허브 간 라우팅이 포함된 다중 허브 패턴.
지역 간 연결: 피어링, 글로벌 도달률 및 허브 간 연결 옵션에 대한 자세한 지침입니다.
VNet 및 서브넷: 지역별 VNet 디자인 및 서브넷 계획.
IP 주소 계획: 지역 간에 겹치지 않는 주소 공간입니다.
Azure Firewall 및 트래픽 검사: 각 지역 허브에 영역 중복형 방화벽 배치.

자세히 알아보기

이 문서에서 설명하는 서비스 및 개념에 대한 자세한 내용은 다음 리소스를 참조하세요.

다음 단계

팁 (조언)

직접 탐색하시겠습니까? 개요 탐색기로 돌아가서 기능별로 다음 문서를 찾습니다.

리프트 앤 시프트 과정의 다음 단계:

온-프레미스 네트워크에 연결: 재해 복구를 계획한 후 온-프레미스에 대한 VPN 또는 ExpressRoute 연결을 설정합니다.

현대화 과정의 다음 단계:

인터넷 수신 패턴 디자인: 고객 트래픽이 주 및 백업 지역에서 애플리케이션에 도달하는 방법을 결정합니다.

멀티클라우드 여정의 다음 단계:

다른 클라우드로 암호화된 터널을 설정합니다: 다중 리전 계획 후 클라우드 간 VPN 연결을 구성합니다.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-07-01