대규모 VNet 간 연결을 위한 MSEE 헤어핀 라우팅에서 AVNM 메시로의 마이그레이션

서론

대규모 Azure 배포에서 일반적인 패턴 중 하나는 VNet 간(VNet-to-VNet) 트래픽을 MSEE(Microsoft Enterprise Edge) 라우터를 통해 라우팅하는 것입니다. 이는 허브 앤 스포크(Hub-and-Spoke) 토폴로지에서 스포크 VNet들이 ExpressRoute 회선을 통해 헤어핀(Hairpin) 방식으로 서로 통신할 때 발생합니다. 즉, 트래픽이 Azure 데이터 센터를 나갔다가 MSEE를 거쳐 다시 데이터 센터로 들어와 목적지 VNet에 도달하는 방식입니다.

이 패턴은 작동은 하지만, 동서(East-West) 트래픽을 위한 장기적인 연결 모델로 설계된 것은 아닙니다. AVNM(Azure Virtual Network Manager) 메시 연결성과 최근의 확장성 개선(최대 5,000개의 VNet을 지원하는 대규모 메시 및 연결된 VNet 전체에서 최대 20,000개의 프라이빗 엔드포인트를 지원하는 HSPE(High-Scale Private Endpoints) 포함)을 통해, 기업은 이제 VNet 간 트래픽에서 MSEE 의존성을 제거하고 직접적인 데이터 센터 내 라우팅 모델로 마이그레이션할 수 있습니다.

이 문서에서는 마이그레이션이 유용한 이유, 새로운 확장성 제한, 필수 기능 활성화 방법, 그리고 서비스 중단을 최소화하며 마이그레이션을 수행하는 방법을 설명합니다.

대상 독자

이 마이그레이션은 다음과 같은 경우에 가장 적합합니다. 50개 이상의 스포크 VNet이 ExpressRoute 헤어핀 라우팅을 통해 동서 통신을 하고 있거나, VNet 피어링 제한에 도달하고 있거나, 내부 트래픽으로 인한 ExpressRoute 사용량을 줄이고 싶거나, 중앙에서 관리되는 단순한 연결 모델이 필요한 기업이 대상입니다. 대부분의 동서 트래픽 흐름이 검사를 위해 허브 방화벽을 통과해야 하더라도, 직접 통신이 허용된 흐름에 대해서는 연결 관리를 단순화할 수 있습니다.

VNet 간 통신에 MSEE 헤어핀 라우팅을 권장하지 않는 이유

스포크 VNet이 MSEE를 통해 통신할 때 트래픽은 다음과 같은 비효율적인 경로를 따릅니다.

스포크 A → 허브 VNet → ExpressRoute 게이트웨이 → MSEE → ExpressRoute 게이트웨이 → 허브 VNet → 스포크 B

• 단일 장애점(SPOF): MSEE는 동서 트래픽의 공유 의존성이 됩니다. MSEE 장애나 용량 제한은 토폴로지의 모든 VNet 쌍에 영향을 미칠 수 있습니다.
• 높은 지연 시간: 트래픽이 스포크 간 통신을 위해 데이터 센터를 나갔다 돌아올 필요가 없습니다. 직접 메시는 동서 트래픽을 데이터 센터 내부 경로에 유지하므로 일반적으로 MSEE 헤어핀보다 지연 시간이 낮습니다.
• 대역폭 제약: MSEE 회선은 대역폭이 유한합니다. 동서 트래픽을 이 회선으로 라우팅하면 온프레미스로 향하는 남북(North-South) 트래픽과 경쟁하게 되어 회선이 포화될 수 있습니다.
• 규모에 따른 운영 리스크: 대규모 배포는 MSEE 인프라에 상당한 부하를 주어 수천 개의 VNet이 있는 환경에서 확장성, 안정성 및 운영상의 우려를 낳습니다.

수동 피어링이 실질적인 대안이 되지 못했던 이유

가장 명백한 대안인 모든 스포크 쌍 간의 직접 VNet 피어링은 MSEE 의존성을 해결하지만, 자체적인 운영 복잡성을 초래합니다.

• 조합의 폭발적 증가: N개의 스포크를 연결하려면 N × (N - 1) / 2개의 피어링 관계가 필요합니다. 100개의 스포크라면 4,950개의 피어링이 필요하고, 1,000개라면 거의 500,000개에 육박합니다.
• 관리 오버헤드: 각 피어링을 개별적으로 프로비저닝, 모니터링 및 유지 관리해야 합니다. 이는 구성 드리프트(Drift), 감사 및 운영 부하를 증가시킵니다.

AVNM 메시가 이를 해결하는 방법

AVNM 메시는 그룹 기반의 연결성을 제공합니다. VNet 집합을 네트워크 그룹으로 정의하고 메시 연결 구성을 적용하면, AVNM이 모든 멤버 간에 양방향 연결을 자동으로 구축합니다.

메시로 연결된 VNet 간의 트래픽은 Azure 데이터 센터 내에 머뭅니다. MSEE를 거치지 않고, 허브를 거치지 않으며, 수동으로 피어링을 관리할 필요도 없습니다.

• 한 번 정의로 전체 연결: 단일 메시 구성으로 그룹 내의 모든 VNet을 다른 모든 VNet과 연결합니다.
• 중앙 집중식 관리: 네트워크 그룹에서 VNet을 추가하거나 제거하면 AVNM이 자동으로 연결을 조정합니다.
• 직접 스포크 간 경로: 트래픽이 허브와 MSEE를 모두 우회하여 VNet 간에 직접 흐릅니다.
• 동적 멤버십: Azure Policy를 사용하여 태그나 리소스 그룹 조건에 따라 새 VNet을 자동으로 등록할 수 있습니다.

대규모 토폴로지 마이그레이션 방법

대규모 메시(High-scale mesh)를 사용하면 최대 5,000개의 VNet과 메시 내 20,000개의 프라이빗 엔드포인트까지 대규모 토폴로지를 마이그레이션할 수 있습니다.

확장성 — 표준 메시 vs. 대규모 메시

대규모 프라이빗 엔드포인트(HSPE) 활성화

메시 규모가 커짐에 따라 연결된 VNet 전체에 배포된 프라이빗 엔드포인트의 수도 증가합니다. 기본 플랫폼 제한(VNet당 1,000개, 연결된 VNet 및 메시 전체에서 2,000개)은 대규모 환경에서 빠르게 도달할 수 있습니다. HSPE를 활성화하면 이러한 제한이 각각 5,000개와 20,000개로 상향됩니다.

대규모 메시 마이그레이션의 경우, 환경이 표준 프라이빗 엔드포인트 제한에 도달할 것으로 예상된다면 아래 단계에 따라 미리 HSPE를 활성화하십시오.

1단계 — 각 VNet 준비

1. 프라이빗 엔드포인트를 포함하는 모든 서브넷에서 프라이빗 엔드포인트 네트워크 정책이 Enabled 또는 RouteTableEnabled로 설정되어 있는지 확인합니다. 이는 필수 전제 조건입니다.
2. VNet 레벨 속성인 PrivateEndpointVNetPolicies를 Basic으로 설정합니다. 이렇게 하면 VNet에서 HSPE가 활성화됩니다.

2단계 — 메시 구성에서 HSPE 활성화

AVNM 메시 연결 구성에서 대규모 프라이빗 엔드포인트(High-scale private endpoints) 옵션을 활성화합니다. AVNM은 메시 내의 모든 VNet이 HSPE로 구성되었는지 유효성을 검사합니다. 구성이 누락된 VNet이 있으면 배포가 차단되고 명확한 오류 메시지가 표시됩니다.

3단계 — 배포

연결 구성을 배포합니다. AVNM이 메시 전체에 HSPE를 적용합니다.

HSPE 활성화 시 동작 변경 사항

• 잠깐의 연결 재설정: HSPE를 활성화하거나 비활성화하면 VNet 내의 기존 프라이빗 엔드포인트 연결에 대해 약 1초간의 일회성 연결 재설정이 발생합니다. 이를 점검 시간(Maintenance window) 동안 계획하십시오.
• PE별 입/출력 바이트 모니터링 불가: HSPE는 각 프라이빗 엔드포인트 IP를 VNet의 다른 IP처럼 취급하므로, PE별 트래픽 카운터가 제거됩니다. PE별 메트릭이 필요한 경우 활성화 전에 대안을 검토하십시오.
• 온프레미스 PE 트래픽 과금 변경: 온프레미스에서 시작된 PE 트래픽은 개별 프라이빗 엔드포인트 리소스가 아닌 게이트웨이 VNet에 합산되어 청구됩니다. 전체 청구 금액은 변하지 않습니다.

다운타임을 피하는 방법

• 기존 피어링과 메시의 공존: AVNM은 명시적으로 구성하지 않는 한 수동으로 생성된 피어링을 삭제하지 않습니다.
• 자동 트래픽 전환: 메시가 배포되면 스포크 간 트래픽은 직접 라우팅됩니다. 메시가 제거되더라도 MSEE 헤어핀 경로는 그대로 유지됩니다.
• 허브 구성 요소 재구성 불필요: 허브의 방화벽, 게이트웨이 및 NVA는 계속 작동합니다. 온프레미스 트래픽은 여전히 허브 게이트웨이를 통해 흐릅니다.
• 간편한 롤백: 검증 기간 동안 MSEE 헤어핀 경로를 유지하여, 문제가 발생한 VNet을 네트워크 그룹에서 제거하거나 메시 구성을 해제함으로써 이전 경로로 되돌릴 수 있습니다.

보안 및 동서 트래픽 검사

일반적인 우려는 직접 메시 연결이 허브 방화벽이나 네트워크 가상 어플라이언스(NVA)를 우회하는지 여부입니다. 답변은 현재 검사가 어떻게 적용되고 있는지에 따라 다릅니다.

• 메시는 라우팅 정책이 아닌 연결성을 제공합니다: 스포크 서브넷에 트래픽을 허브 NVA나 방화벽으로 보내는 UDR이 있는 경우, 해당 UDR이 계속 적용되어 검사가 필요한 흐름을 방화벽 경로로 유지할 수 있습니다.
• 보안 관리자 규칙(Security Admin Rules)을 통한 중앙 제어: 방화벽 검사가 필요 없는 흐름에 대해, AVNM 보안 관리자 규칙을 사용하여 네트워크 그룹 전체에 걸쳐 네트워크 수준의 허용 또는 거부 정책을 적용할 수 있습니다.
• 적절한 혼합 사용: 승인된 흐름에는 메시를 통해 직접 연결을 제공하고, 보안 경계가 필요한 곳에는 보안 관리자 규칙을 적용하십시오.

권장 사항: 마이그레이션 전에 현재 방화벽을 통과하는 스포크 간 흐름을 파악하십시오. 각 흐름에 대해 UDR을 유지하여 검사를 계속할지, 아니면 UDR을 제거하여 직접 메시 경로를 허용할지 결정하십시오.

마이그레이션 순서 및 프로세스

MSEE 헤어핀 라우팅에서 AVNM 메시로의 마이그레이션은 설계상 비중단 방식으로 진행됩니다. 메시 연결은 기존 피어링 위에 오버레이되며 동서 트래픽에 대해 라우팅 우선순위를 갖습니다. 기존의 허브 앤 스포크 토폴로지를 먼저 철거할 필요가 없습니다.

권장 단계

1. 메시 토폴로지 설계: VNet을 지역별로 메시 그룹으로 그룹화합니다. 메시당 250개 이상의 VNet이 예상되는 경우, 미리 AllowHighScaleConnectedGroup 기능 플래그를 등록하십시오.
2. 네트워크 관리자 및 네트워크 그룹 생성: AVNM 범위가 모든 관련 구독을 포함하는지 확인합니다. 초기 마이그레이션에는 정적 멤버십을 사용하고, 지속적인 등록을 위해서는 Azure Policy를 통한 동적 멤버십을 사용하십시오.
3. 메시 내 모든 VNet에서 HSPE 활성화: 메시 내에 2,000개 이상의 PE가 필요한 경우 HSPE 활성화 단계를 따르십시오. 잠깐의 연결 재설정을 고려하여 점검 시간 동안 변경을 예약하십시오.
4. AVNM 메시 연결 구성 생성: 네트워크 그룹을 선택하고, 메시 토폴로지를 활성화하고, 대규모 프라이빗 엔드포인트를 활성화합니다. 지역 간 연결이 필요한 경우 글로벌 메시를 활성화합니다.
5. 단계적 배포: 파일럿 지역이나 비프로덕션 환경부터 시작하십시오. 운영 환경으로 확장하기 전에 유효 경로(Effective routes), 스포크 간 연결성, 허브를 통한 온프레미스 연결성, 프라이빗 엔드포인트 도달 가능성 및 VNet 흐름 로그 패턴을 검증하십시오.

마이그레이션 중 및 이후의 경로 동작

마이그레이션 중에는 메시와 MSEE가 공존할 수 있습니다. 메시로 연결된 VNet은 목적지에 대한 직접 경로를 수신하며, 기존 ExpressRoute 게이트웨이 경로는 온프레미스 목적지에 대해 계속 작동합니다. UDR은 시스템 경로보다 우선하므로, UDR이 있는 경우 강제 터널링 및 방화벽 검사 패턴은 그대로 유지됩니다.

• 메시 목적지: UDR이 경로를 재정의하지 않는 한, 메시로 연결된 VNet 간의 트래픽은 MSEE를 헤어핀하지 않고 직접 이동합니다.
• 온프레미스 목적지: ExpressRoute는 온프레미스 네트워크에 대한 남북 연결을 계속 제공합니다.
• 게이트웨이 전송: 게이트웨이 전송을 사용하는 설계에서 스포크는 허브 게이트웨이를 통해 온프레미스에 계속 도달할 수 있습니다.

Infrastructure-as-Code (IaC) 고려 사항

Terraform, Bicep 또는 ARM 템플릿을 통해 VNet 피어링을 관리하는 경우, 검증이 완료된 후에만 AVNM 메시를 새로운 정보의 소스(Source of Truth)로 취급하십시오.

1. 메시 먼저 배포: AVNM 메시는 기존 피어링과 공존할 수 있으므로, 메시 경로를 검증하기 전에는 IaC에서 피어링 리소스를 제거하지 마십시오.
2. 트래픽 경로 검증: 유효 경로, Connection Monitor 및 흐름 로그를 사용하여 트래픽이 예상대로 메시를 사용하는지 확인합니다.
3. 드리프트 방지: 특히 여러 팀이 네트워크 리소스를 관리하는 환경에서는 기존 피어링을 제거하기 전에 파이프라인 상태와 수명 주기 설정을 검토하십시오.
4. AVNM 코드화: 네트워크 관리자, 네트워크 그룹, 구성 및 배포를 IaC로 관리하여 메시가 통제된 연결 모델이 되도록 하십시오.

메시 전반의 DNS 확인

메시 연결성 자체가 DNS 확인 동작을 변경하지는 않습니다. 스포크 VNet이 이미 허브에서 관리되는 프라이빗 DNS 영역에 연결되어 있다면 해당 링크가 이름 확인을 계속 결정합니다. 스포크가 허브의 사용자 지정 DNS 서버를 사용하는 경우, 마이그레이션 중의 UDR 변경이 DNS 트래픽 경로를 의도치 않게 변경하지 않는지 확인하십시오.

마이그레이션 예시 — 두 개의 허브 앤 스포크 토폴로지를 단일 메시로 통합

이 예시는 기업이 기존 MSEE 경로를 검증 기간 동안 유지하면서 두 개의 지역 허브 앤 스포크 환경을 하나의 중앙 관리형 AVNM 메시로 마이그레이션하는 방법을 보여줍니다.

현재 상태 — MSEE 헤어핀이 있는 두 개의 허브 앤 스포크 토폴로지

Contoso Corp는 미국 동부 지역에서 두 개의 허브 앤 스포크 토폴로지를 운영하고 있습니다.

현재 트래픽 흐름:

• 토폴로지 A 내 스포크 간: 스포크-A-01 → Hub-A → ER-GW-A → MSEE → ER-GW-A → Hub-A → 스포크-A-02
• 토폴로지 간 스포크 간: 스포크-A-01 → Hub-A → ER-GW-A → MSEE → ER-GW-B → Hub-B → 스포크-B-01

모든 스포크 간 패킷은 데이터 센터를 나가서 MSEE를 거쳐 다시 들어옵니다. 1,000개의 스포크가 동서 트래픽을 생성함에 따라 MSEE는 공유 단일 장애점이 되고 모든 흐름에 지연 시간을 추가합니다.

목표 상태 — 1,000개의 VNet이 포함된 단일 AVNM 메시

Contoso의 목표는 1,000개의 모든 스포크 VNet을 단일 AVNM 메시로 통합하여 동서 트래픽 경로에서 MSEE를 제거하는 것입니다.

• 모든 스포크 간 트래픽 쌍: 스포크-A-01 → 직접 → 스포크-B-01. 트래픽은 데이터 센터 내에 머물며 직접 메시 경로를 사용합니다.
• MSEE의 역할: MSEE는 남북 온프레미스 트래픽만 담당합니다. ExpressRoute 헤어핀 경로에서 동서 부하가 제거됩니다.

마이그레이션 실행

0단계 — 사전 작업

• 기능 등록: 메시가 표준 제한인 250개를 초과하는 1,000개의 VNet을 포함하므로, Contoso는 구독에 AllowHighScaleConnectedGroup 기능 플래그를 등록합니다. 이를 통해 최대 5,000개의 VNet에 대한 대규모 메시 지원이 활성화됩니다.
• 프라이빗 엔드포인트 인벤토리 확인: 1,000개 VNet에 10,000개의 PE가 있으므로 표준 메시 PE 제한인 2,000개를 초과합니다. 따라서 HSPE를 반드시 활성화해야 합니다.

1단계 — 1,000개 모든 스포크 VNet에서 HSPE 활성화

• 배치 1: 점검 시간 동안 토폴로지 A의 모든 500개 스포크 VNet에서 지침에 따라 HSPE를 활성화합니다.
• 배치 2: 토폴로지 B의 모든 500개 스포크에도 동일한 구성을 적용합니다.
• 예상 영향: HSPE 활성화 시 각 VNet의 기존 PE 연결에 잠깐의 재설정이 발생할 수 있습니다. 점검 시간 동안 진행하십시오.

2단계 — AVNM 메시 생성

1. 1,000개 스포크 VNet을 모두 포함하는 관리 그룹 범위로 네트워크 관리자를 생성합니다.
2. Azure Policy와 태그를 사용하는 동적 멤버십으로 eastus-mesh-all-spokes라는 단일 네트워크 그룹을 정의합니다.
3. 메시 연결 구성을 생성합니다. 토폴로지는 Mesh, 네트워크 그룹은 eastus-mesh-all-spokes, 대규모 프라이빗 엔드포인트는 Enabled, 모든 VNet이 동일 지역에 있으므로 글로벌 메시는 필요 없음으로 설정합니다.
4. 구성을 초안으로 저장하고 아직 배포하지 않습니다.

3단계 — 단계적 배포

• Wave 1 — 파일럿: 임시 네트워크 그룹을 사용하거나 일부 VNet에만 태그를 지정하여 50개의 개발/테스트용 스포크에 메시 구성을 배포합니다. 유효 경로에 메시 목적지에 대한 다음 홉 유형이 ConnectedGroup으로 표시되는지, 직접 경로를 통한 연결성, PE 도달 가능성, 온프레미스 연결 유지 여부 등을 검증합니다.
• Wave 2 — 소규모 운영 트래픽 VNet: 파일럿 성공 후 소규모 운영 트래픽 VNet에 태그를 지정합니다. 동적 네트워크 그룹이 이를 자동으로 감지합니다. 구성을 재배포하고 동일한 체크리스트를 확인하며 동서 트래픽이 ExpressRoute 헤어핀 경로에서 벗어나는지 모니터링합니다.
• Wave 3 — 나머지 모든 운영 VNet: 나머지 모든 스포크에 태그를 지정하고 구성을 배포합니다. 이제 1,000개의 모든 스포크가 메시에 포함됩니다.
• 무중단 마이그레이션: Wave 2와 3 동안 기존 MSEE 헤어핀 라우팅은 계속 작동합니다. 메시에 아직 포함되지 않은 VNet은 MSEE를 통해 통신하고, 이미 포함된 VNet은 메시를 통해 직접 통신합니다. 이를 통해 마이그레이션 중 연결 공백을 피할 수 있습니다.

4단계 — 마이그레이션 후 검증

배포 후, 기존 경로를 폐쇄하기 전에 메시가 활성화되었고 트래픽이 예상 경로를 따르는지 확인합니다.

1. 유효 경로: 스포크 서브넷이 게이트웨이나 MSEE 대신 피어 VNet 접두사에 대한 직접 경로를 표시하는지 확인합니다.
2. Connection Monitor: 대표적인 스포크 간 흐름을 추적하고 마이그레이션 전후의 지연 시간 및 도달 가능성을 비교합니다.
3. VNet 흐름 로그: 동서 트래픽이 예상된 메시 경로와 일치하고 ExpressRoute 게이트웨이 경로를 더 이상 거치지 않는지 확인합니다.
4. Network Watcher 토폴로지: 결과적인 연결 모델을 시각화하고 대상 네트워크 그룹에 누락된 VNet이 없는지 식별합니다.

메시 배포 후에도 트래픽이 여전히 헤어핀 중이라면 시스템 경로를 재정의하는 UDR, 네트워크 그룹에서 누락된 스포크, 대상 지역에 커밋되지 않은 배포, 또는 기존 피어링을 재생성하는 IaC 파이프라인 등을 확인하십시오.

롤백

• MSEE가 유지되는 동안의 빠른 롤백: 네트워크 그룹에서 해당 VNet을 제거하거나 메시 연결 구성을 배포 해제합니다. AVNM은 자신이 생성한 연결만 제거하므로 트래픽은 기존 MSEE 헤어핀 경로로 돌아갑니다.
• 기존 경로 폐쇄 후의 롤백: 이전 피어링이나 경로 의존성이 이미 제거된 경우, 롤백을 위해 해당 리소스를 다시 프로비저닝해야 하며 더 긴 작업 시간이 필요할 수 있습니다.
• 권장 사항: 메시 배포 후 최소 2주 동안은 MSEE 헤어핀 경로를 유지하고 트래픽 패턴을 모니터링한 후에만 기존 경로를 제거하십시오.

전후 요약 비교

맺음말

AVNM 메시로 마이그레이션한다고 해서 기존 네트워크를 철거할 필요는 없습니다. 허브 게이트웨이, 방화벽 및 NVA는 오늘날과 동일하게 계속 작동합니다. 바뀌는 것은 동서 스포크 간 트래픽이 불필요하게 데이터 센터를 나가는 일이 없어진다는 점입니다.

• MSEE는 동서 트래픽용 도구가 아닙니다. ExpressRoute 회선에서 내부 트래픽을 제거하는 것은 안정성과 용량 측면의 개선입니다.
• AVNM 메시는 복잡한 피어링 조합을 그룹 기반의 의도로 대체합니다. 운영 모델은 VNet의 수가 아니라 그룹의 수에 따라 확장됩니다.
• 대규모 메시와 HSPE는 한계를 제거합니다. 메시당 최대 5,000개의 VNet과 20,000개의 프라이빗 엔드포인트를 지원합니다.
• 마이그레이션은 단계적이고 가역적입니다. 메시는 기존 경로와 공존하며, 레거시 경로를 제거하기 전에 단계별로 검증할 수 있습니다.

비프로덕션 환경에서 파일럿 메시로 시작하여 트래픽 전환을 확인하고 점진적으로 확장해 보십시오.

참고 자료

• Azure 가상 네트워크 관리자의 연결 구성
• 프라이빗 엔드포인트 가상 네트워크 제한 늘리기
• Azure 가상 네트워크 관리자를 사용하여 메시 토폴로지 만들기
• Azure 가상 네트워크 관리자의 보안 관리자 규칙
• Terraform을 사용하여 Azure 가상 네트워크 관리자로 메시 네트워크 토폴로지 만들기