[Azure] Traffic Manager 정리

Traffic Manager는 DNS 응답으로 트래픽을 나누는 글로벌 부하 분산기입니다. 사용자가 도메인을 질의하면 라우팅 방식과 상태 확인 결과에 맞는 엔드포인트 주소를 돌려주고, 이후 연결은 사용자가 엔드포인트에 직접 맺습니다. 프로토콜과 위치를 가리지 않아 온프레미스까지 묶을 수 있지만, 장애 조치 속도가 DNS TTL과 클라이언트 캐시에 좌우된다는 점을 알고 써야 합니다.

1. Traffic Manager란

앞에서 정리한 Load Balancer, Application Gateway, Front Door는 모두 트래픽이 실제로 그 서비스를 지나갑니다. Traffic Manager는 트래픽 경로에 서지 않고 DNS 질의에만 답합니다. 온프레미스의 GSLB(Global Server Load Balancing)와 같은 개념입니다.

 

DNS 단계에서만 개입하므로 HTTP뿐 아니라 TCP, UDP 등 어떤 프로토콜에도 쓸 수 있고, Azure 밖의 서버나 IDC도 엔드포인트로 넣을 수 있습니다. 대신 TLS 종료, 캐시, WAF 같은 기능은 없고, 사용자가 이미 받아 둔 DNS 응답을 캐시하는 동안에는 장애가 나도 예전 주소로 계속 접속합니다.

2. 동작 방식

사용자의 DNS 질의에 정상 엔드포인트 주소를 돌려주고, 실제 연결은 사용자가 엔드포인트에 직접 맺는 흐름

 

서비스 도메인(www.1nfra.kr)은 Traffic Manager 프로필 이름(tm-1nfra-web.trafficmanager.net)을 가리키는 CNAME으로 만듭니다. 사용자의 DNS 리졸버가 이 이름을 질의하면 Traffic Manager는 라우팅 방식과 엔드포인트 상태를 보고 app-krc.azurewebsites.net 같은 엔드포인트 이름이나 IP를 응답합니다. 그다음 연결은 Traffic Manager를 거치지 않습니다.

 

루트 도메인(1nfra.kr)은 CNAME을 쓸 수 없으므로 Azure DNS의 별칭(alias) 레코드로 Traffic Manager 프로필을 가리키게 합니다.

3. 라우팅 방식

방식	동작	용도
Priority	우선순위(1~1000, 낮을수록 먼저)가 가장 높은 정상 엔드포인트만 응답	액티브-스탠바이, DR
Weighted	가중치(1~1000) 비율로 무작위 응답	점진적 전환, 부하 나누기
Performance	DNS 리졸버 IP 기준 지연 시간이 가장 짧은 엔드포인트 응답	여러 리전 중 가까운 곳
Geographic	질의 출발 지역에 매핑한 엔드포인트 응답	데이터 주권, 국가별 서비스
MultiValue	정상 엔드포인트 여러 개를 한 번에 응답	클라이언트 측 재시도
Subnet	출발 IP 대역별로 지정한 엔드포인트 응답	사내망, 특정 고객사 분리

Performance와 Geographic은 실제 사용자 IP가 아니라 사용자가 쓰는 DNS 리졸버의 IP를 기준으로 판단합니다. 해외 공용 DNS를 쓰는 사용자는 예상과 다른 엔드포인트를 받을 수 있습니다. Geographic에서 매핑되지 않은 지역의 질의는 NODATA로 응답하므로, World 지역을 받는 기본 엔드포인트를 꼭 둡니다.

4. 상태 확인과 장애 조치

Priority 방식에서 1순위 엔드포인트가 상태 확인에 실패하면 2순위 엔드포인트 주소를 응답하기까지의 흐름

 

설정	값
프로토콜, 포트, 경로	HTTP, HTTPS, TCP 중 선택 HTTP(S)는 기본 200 응답을 정상으로 판단
확인 간격	30초(일반) 또는 10초(빠른 확인)
허용 실패 횟수	0~9, 기본 3
시간 제한	30초 간격: 5~10초(기본 10초) 10초 간격: 5~9초(기본 9초)
DNS TTL	응답을 캐시할 시간. 짧을수록 빨리 전환되지만 DNS 질의가 늘어남

30초 간격, 허용 실패 3회, TTL 30초라면 엔드포인트가 죽은 뒤 연속 4번 실패해 Degraded가 되기까지 약 2분, 이후 캐시된 DNS 응답이 만료되기까지 30초 정도가 더 걸려 전체 전환에 3~4분이 걸립니다. 더 빨라야 하면 10초 간격과 짧은 TTL을 쓰되, 브라우저나 OS가 TTL보다 오래 캐시하는 경우도 있다는 점을 감안합니다.

5. 엔드포인트 종류

종류	대상
Azure 엔드포인트	DNS 이름이 있는 공인 IP, App Service, Cloud Service 등 Azure 리소스
외부 엔드포인트	온프레미스, 다른 클라우드의 FQDN 또는 IP 주소
중첩 엔드포인트	다른 Traffic Manager 프로필. 예: 상위는 Performance로 리전을 고르고, 하위는 Weighted로 리전 안에서 분산

6. Azure CLI로 만들어 보기

6.1 프로필 만들기

RG=rg-web
# Priority 방식, HTTPS /health 를 10초마다 확인, TTL 30초
az network traffic-manager profile create --resource-group $RG --name tm-web \
  --routing-method Priority --unique-dns-name tm-1nfra-web --ttl 30 \
  --protocol HTTPS --port 443 --path /health \
  --interval 10 --timeout 9 --max-failures 3

6.2 엔드포인트 추가와 확인

APP_KRC=$(az webapp show --resource-group $RG --name app-krc --query id -o tsv)
APP_JPE=$(az webapp show --resource-group $RG --name app-jpe --query id -o tsv)
TM="--resource-group $RG --profile-name tm-web"

az network traffic-manager endpoint create $TM --name ep-krc \
  --type azureEndpoints --target-resource-id $APP_KRC --priority 1
az network traffic-manager endpoint create $TM --name ep-jpe \
  --type azureEndpoints --target-resource-id $APP_JPE --priority 2

# IDC를 마지막 대기 엔드포인트로
az network traffic-manager endpoint create $TM --name ep-idc \
  --type externalEndpoints --target www-idc.1nfra.kr --priority 3

# 엔드포인트 상태와 실제 DNS 응답 확인
az network traffic-manager endpoint list $TM \
  --query "[].{name:name, status:endpointMonitorStatus}" -o table
nslookup tm-1nfra-web.trafficmanager.net

1순위 App Service를 중지한 뒤 몇 분 지나 nslookup 결과가 app-jpe로 바뀌면 장애 조치가 정상입니다. 엔드포인트 앞에 NSG나 방화벽이 있다면 AzureTrafficManager 서비스 태그를 허용해야 상태 확인이 통과합니다.

7. 운영 시 주의점

항목	확인할 것
DNS 캐시	장애 조치 시간은 상태 확인 시간 + TTL + 클라이언트 캐시입니다. 초 단위 전환이 필요하면 Front Door를 검토합니다.
HTTPS 인증서	사용자는 www.1nfra.kr로 접속하므로 모든 엔드포인트에 같은 도메인의 인증서가 있어야 합니다.
호스트 헤더	App Service 엔드포인트는 사용자 지정 도메인(www.1nfra.kr)을 각 앱에도 등록합니다.
상태 확인 허용	엔드포인트의 NSG, 방화벽에서 AzureTrafficManager 서비스 태그를 허용합니다.
Geographic	World 지역을 받는 엔드포인트가 없으면 매핑되지 않은 지역은 응답을 받지 못합니다.
루트 도메인	CNAME 대신 Azure DNS 별칭 레코드를 씁니다.

8. 정리

• Traffic Manager는 트래픽 경로에 서지 않고 DNS 응답으로 엔드포인트를 고르는 글로벌 부하 분산기입니다.
• 라우팅 방식은 Priority, Weighted, Performance, Geographic, MultiValue, Subnet 6가지이고, 판단 기준은 사용자가 아닌 DNS 리졸버 IP입니다.
• 프로토콜과 위치를 가리지 않는 대신, 장애 조치는 상태 확인 시간과 DNS TTL만큼 걸린다는 점을 설계에 반영합니다.

참고

• Microsoft Learn - Traffic Manager란?
• Microsoft Learn - Traffic Manager 라우팅 방법
• 다이어그램 아이콘: Azure Architecture Icons