[VNet] 다중 지역에 배포하는 고가용성 구현을 위한 Traffic Manager 시나리오
VNet
작성자
Roronoa
작성일
2020-09-25 16:27
조회
4043
다중 지역에 배포하는 고가용성 구현을 위한 Traffic Manager 시나리오를 구현 해보자. 수학으로 말하면 집합(정석의 1장)인 Azure DNS 와 Traffic Manager 보자.수학의 집합이라 표현한것은 모든 트레픽 모든 프로덕트의 가장 앞단에 있기 때문입니다. 사실 Azure DNS 가 가장 앞이긴 하지만... DNS 다음으로 나오며 가격은 100만 DNS 쿼리당 648원이정도면 꽁짜나 다름없지 않을까 생각됩니다. 물론 꽁짜는 아닙니다. 또한 계산을 잘해보면 많은 유저와 많은 트래픽에서는 꽤나 비싸집니다. 알다시피 DNS 기반 서비스 이므로 도메인과 아이피를 연결 해주는 서비스입니다.예를 들어 naver.com이 있다면 naver.com 이 가지고 있는 xxx.xxx.xxx.xxx 숫자 IP주소와 naver.com 도메인이 연결되어 VM으로 글로벌하게 분산되어 접속 할 수 있다.일반적으로 잘나가시는 Akamai, Azure Traffic Manager, Dyn 등등 이 비슷한 서비스라 할 수 있다.
DNS 로 되는 도메인 기반 이므로 아이피 기반으로 라우팅은 불가능하며 학교 다닐 때 열심히 배웠던 OSI 7계층의 L7 계층의 DNS 기반 로드 밸런서 라고 생각하면 됩니다. 온프레미스 시절 이런 GSLB를 장비로사려면 수 천 만원에서 수 억 이었습니다. 그러나 세상은 바꿨죠. 사실 고가용성을 고려하는 회사도 비용을 줄이기 위한 작업은 클라우드에서 필수적입니다. 일단은 Traffic Manager를 사용을 고려한다면 이미 어느 정도 작은 회사는 아니며 글로벌로 서비스를 하기 위한 필수 서비스 입니다.
자 그래서 이 Traffic Manager 를 쓰는 방법을 다양한 시나리오를 가지고 알아보도록 합시다.
위에 그림은 전세계의 Azure Datacenter 위치이며 그중에 3개의 지역 미국 동부, 서부 유럽, 한국 중부 에 우리는 서비스를 배포합니다.
기본 아키텍쳐 시나리오 설명
위 아키텍쳐는 Visio로 (한땀 한땀 ?) 만들어진 아키텍쳐이며 3계층 아키텍쳐이며 3개의 지역에 배포되어지며 주지역은 한국 중부, 미국 동부, 서부 유럽으로 배포된 지역입니다. 3Tier가 3개의 지역에 각각이 있는 이유는 각각의 전세계 글로벌 서비스이며 각 지역에 골고루 같은 3 Tier가 각각 반응하며 빠른 서비스를 위해서 각 대륙에 하나씩 있는 각 티어가 접속자의 위치에서 가장 빠른 퍼포먼스를 주는 쪽으로 트레픽이 전달되어 가장 적은 레이턴시를 보이기 위한 기본 아키텍쳐입니다.
네트워크 (트래픽 매니저와 DNS 관리) -Traffic Manager 는 공통 리소스라서 네트워크 리소스 그룹에 선택 하며 한개의 지역에 리소스를 적용시키면 Failover시 한번에 컨트롤이 어려움
가상네트워크 - 각 지역은 다른 가상 네트워크를 독자적으로 한개 씩 사용하며 다른 지역과 글로벌 피어링 연결
데이터베이스 - ASync 비동기식으로 복제 유지
배포된 지역
한국 중부(주 지역)
미국 동부(주 지역)
서부 유럽(주 지역)
윗 그림은 왜 빨간색 빈칸으로 블로 처리를 했나?
단순한 3Tier 구조이므로 굳이 복잡한 그림을 단순화 시켰다.
왜 그럼 3개의 지역에 배포를 했나?
만약 한국 중부만 리소스를 만든다면 브라질에 있는 유저는 접속을 하기 위해서 유럽 돌아 아프리카 돌아 아시아 돌아 한국으로 오게 된다.
스피드테스트 그림
위에 스피드 테스트 그림을 보자. 한국 지역에서 내가 한국 데이터센터에서 파일을 받는다면 레이턴시가 13ms 이나 브라질 데이터센터에서 가져오면 313ms 이다. 이야..! 이거는 파일이 작은거고 만약 조금 큰파일을 받는다면 엄청나게 느리다. 그래서 각 지역에 배포를 하면 그 지역에서는 매우 빠른 레이턴시를 가져오게 되므로 이런 아키텍쳐가 필요한 이유이다. 쉽게 말하면 내가 브라질에 여행을 하는 상황에 한국만 서버가 배포되있는 한국 로컬 정부서비스를 이용한다고 생각해보자. 로딩하는데 엄청난 오랜 시간때문에 한국정부 서비스를 사용하기는 정말 힘들수 있다. 그러나 만약 위와 같은 그림으로 다양한 지역에 서비스를 배포한다면 그 근처에서 가까운 위치는 빠른 반응속도를 자랑할것이다.
장점만 있나?
듣고 보니 무조건 좋다. 하지만 그건 고객중심 생각이며 서버를 저렇게 3군대에 배포한다면 1군대 배포하는것보다 3배 비용이 증가한다. 세상은 비용이 들지 않으면 좋아지지 않는것은 당연하며 만약 전세계 모든 사람이 한국 로컬 정부 서비스를 이용하지 않는다면 굳이 3군대 이상 지역에 배포할 이유가 있을까? 그래서 비지니스 니즈와 서비스의 영역은 항상 결합되어 있어야 한다. 물론 CDN을 쓰면 더 좋은 결과를 얻는다. 정적 오브젝트 스토리지와 CDN 결합으로 정적파일과 DSA(Dynamic Site Acceleration)으로 위에 아키텍쳐보다 더 빠른 서비스도 가능하긴 하지만 여기서 가장 포인트는 CDN이 아니므로 이부분은 스킵하겠다.
빨간색 화살표가 핵심이다
빨간색 화살표의 Azure Traffic Manager가 Azure DNS의 뒤에 위치해서 도메인 기반으로 다양한 시나리오에 맞춰 분기가 되어 전세계로 퍼지게 해주는 역활을 하기 때문이다. 배포는 쉬워서 굳이 만들지 않았다. 그러나 가장 중요한 이해가 필요한 부분은 시나리오이다. 어떤 시나리오를 어떻게 조합해서 내가 원하는 분기를 정확하게 만드는지가 가장 핵심이다.
트래픽 매니저의 동작 이론 방법
1번
유저는 Recursive DNS 서비스 들로 DNS를 전송해서 www.example.com 이라는 이름을 확인 하게 됩니다. Recursive DNS 서비스들은 DNS를 직접 호스팅 하지 않으며 클라이언트에서 DNS 이름을 확인하는데 필요한 작업을 오프로드 합니다.
2번
DNS 이름을 확인하기 위해서 Recursive DNS 는 example.com을 찾게 되고 Root NS,TLD NS, Authoritative Name Server(Azure DNS or Route 53) 를 통해서 www.example.com 은 example.trafficmanager.net을 CNAME record 를 보내줍니다
3번
Recursive DNS 서비스는 trafficmanager.net의 DNS 이름을 찾게 되고 example.trafficmanager.net.의 DNS record를 보내줍니다
4번
Traffic Manager 가 요청을 받으면 여러가지 라우팅 메소드에 따라 엔드포인트를 선택합니다
5번
선택된 엔드포인트는 DNS CName record를 반환합니다 (example.eu.cloudapp.net)
6번
Recursive DNS가 cloudapp.net이라는 NS를 찾고 example.eu.cloudapp.net 의 DNS 레코드를 요청하고 유럽지역에 엔드포인트의 IP 주소를 포함하는 A record가 반환됩니다
7번
Recursive DNS들이 모든 결과를 합체 시켜 클라이언트 유저에게 단일 DNS 응답을 반환합니다
8번
클라이언트 유저는 단일 DNS의 결과를 받고 지정 IP주소를 연결합니다.클라이언트는 Traffic Manager를 통해서 아니라 직접 엔드포인트로 연결됩니다.
시나리오
유저 (한국유저,일본유저,미국유저,캐나다유저,스페인 유저,독일 유저)
6명의 유저가 각각 자신의 지역에 살고 있습니다. 단순한 Traffic Manager 프로필 한개가 퍼포먼스 라우팅으로 되어 있으며 3개의지역(한국 중부, 미국 동부, 서부 유럽) 데이터센터에 서버들이 존재 합니다.
시나리오 1 - 퍼포먼스 위주의 가장 빠른 반응 속도에 따라 라우팅 하는 방법 (Performance)
퍼포먼스라우팅은 한국 유저가 한국에 있다면 Traffic Manager가 가 여러위치에서 검색해서 가장 빠른 반응 속도을 보이는 데이터 센터를 상태 확인 하고 있다가 이 대기시간이 가장 빠른 위치에 트래픽을 보내주는 역활을 합니다. 만약 일본 유저가 있다면 한국 서버가 가장 빠른 퍼포먼스를 보여주기 때문에 한국서버로 보내고 미국 유저는 미국 서버가 가장 빠른 대기 시간을 보내기 때문에 미국 서버로 보냅니다. 일반적으로는 대기 시간이 가장 짧은 데이터 센터는 지리적으로 가장 가까운 센터입니다.
그러나 Performance 라우팅이 지리적으로 기준을 가지고 가깝게 지정되는 것이 아니라 Traffic Manager 내부에 IP 주소 범위와 Azure 데이터 센터와 반응 하는 왕복 시간을 체크하는 레이턴시 테이블이 있습니다. 밑에 테이블을 보면 아이피 주소 범위를 DNS 쿼리해서 레이턴시를 관리하는 테이블이 존재하며, Traffic Manager가 DNS 요청의 Recursive DNS 원본 IP 주소를 찾아서 가장 빠른 지역대를 테이블에서 확인한 후에 가장 빠른 Endpoint에 트래픽을 보내줍니다.
Traffic Manager는 클라이언트에서 직접 DNS 쿼리를 수신하지 않으며 DNS 쿼리는 Recursive DNS 서비스에서 제공됩니다. 그러므로 가장 가까운 엔드포인트가 무엇인지 결정하는 데 사용되는 IP주소는 클라이언트 IP 주소가 아니라 Recursive DNS 서비스의 IP 주소입니다.
Traffic Manager는 인터넷 대기 시간 테이블을 정기적으로 업데이트 합니다.
시나리오 2 - 엔드포인트의 지리적 위치(가장 가까운 지역으로 보냄)로 라우팅 하는 방법(Geographic)
만약 지리적 위치에 따라 데이터의 독립성과 콘텐츠 및 사용자 환경의 지역화를 준수한다면 이 시나리오가 적합합니다. 한국 미국 일본 모두 다른 룰이나 지역 법에 따라 다른 서비스를 해야 할 경우에 지리적으로 세분화 할수 있으며 지역을 세분화 시킨 그룹도 사용할 수 있습니다.. 한마디로 일본 지역에 접속해야 하는 일본 사람은 일본 서버에만 접속 하도록 보내고 미국서버에 접속해야 하는 사람은 미국 서버에 보내고 한국 사람은 한국 서버로 접속하도록 해줄수 있습니다.
시나리오 3 - 가중치 적용 트래픽(1-1000으로 가중치를 주어서 우선순위 정함) 라우팅 방법(Weight)
가중치 테이블을 가지고 가중치를 1에서 1000으로 가중치를 주어서 우선 순위를 정합니다. 테스트 서버를 두고 본서버와 스왑할때 점진적으로 가중치를 주고 트래픽을 줄수 있습니다.
시나리오 4 - 우선 순위 트래픽(순서를 미리 정함) 라우팅 방법 (Priority)
예를 들어 우선순위를 서울 일본 미국으로 정해 놓는다면 기본적으로 우선순위가 서울이라면 모든트래픽을 서울 로 보내고 서울이 사용할수 없는 경우 일본으로 보내며 일본도 사용할 수 없다면 미국으로 보내는 시나리오에 적합합니다.
시나리오 5 - 서브넷 기반 으로 라우팅 (Subnet)
서브넷 라우팅을 사용하면 특정 IP 주소 범위를 엔드 포인트에 매핑할 수 있습니다.
시나리오 6 - 다중값 라우팅 (Multi-Values) - 여러개의 엔드포인트를 단일 쿼리 응답에 반응하게 함
다중값 트래픽 라우팅은 여러개의 정상 엔드포인트를 반환할 수 있으며 DNS 조회 하지 않고 다시 시도 할수 있는 옵션이 클라이언트에 주어지므로 에플리케이션 안정성이 좀더 높아지는 시나리오에 사용할 수 있습니다. IPv4 IPv6를 사용하여 사용하는 시나리오 입니다.
시나리오 7 - 중첩 프로필로 1-6번 기능을 혼합하여 사용하는 방법
https://docs.microsoft.com/ko-kr/azure/traffic-manager/traffic-manager-nested-profiles
7-1 성능 + 가중치 결합 사용 라우팅
7-2 성능 + 우선순위 결합 사용 라우팅
7-3 성능 + 지리적 결합 사용 라우팅
7-4 지리적 + 성능 결합 사용 라우팅
7-5 가중치 + 성능 결합 사용 라우팅
이런 시나리오와 더 많은 시나리오가 존재할 수 있으며 중첩은 10개까지 가능하며 루프로 개속 돌게 만드는 시나리오는 가능하지 않습니다. 중첩을 사용한다고 해서 추가 비용이 필요한것은 아닙니다. 맨 위에 상위의 프로필을 부모 프로필라고 하며 그 밑에 자식 프로필을 놓을수 있으며
이런 방식으로 중첩으로 구성하면 다양한 시나리오가 가능합니다.
DNS 로 되는 도메인 기반 이므로 아이피 기반으로 라우팅은 불가능하며 학교 다닐 때 열심히 배웠던 OSI 7계층의 L7 계층의 DNS 기반 로드 밸런서 라고 생각하면 됩니다. 온프레미스 시절 이런 GSLB를 장비로사려면 수 천 만원에서 수 억 이었습니다. 그러나 세상은 바꿨죠. 사실 고가용성을 고려하는 회사도 비용을 줄이기 위한 작업은 클라우드에서 필수적입니다. 일단은 Traffic Manager를 사용을 고려한다면 이미 어느 정도 작은 회사는 아니며 글로벌로 서비스를 하기 위한 필수 서비스 입니다.
자 그래서 이 Traffic Manager 를 쓰는 방법을 다양한 시나리오를 가지고 알아보도록 합시다.
위에 그림은 전세계의 Azure Datacenter 위치이며 그중에 3개의 지역 미국 동부, 서부 유럽, 한국 중부 에 우리는 서비스를 배포합니다.
기본 아키텍쳐 시나리오 설명
위 아키텍쳐는 Visio로 (한땀 한땀 ?) 만들어진 아키텍쳐이며 3계층 아키텍쳐이며 3개의 지역에 배포되어지며 주지역은 한국 중부, 미국 동부, 서부 유럽으로 배포된 지역입니다. 3Tier가 3개의 지역에 각각이 있는 이유는 각각의 전세계 글로벌 서비스이며 각 지역에 골고루 같은 3 Tier가 각각 반응하며 빠른 서비스를 위해서 각 대륙에 하나씩 있는 각 티어가 접속자의 위치에서 가장 빠른 퍼포먼스를 주는 쪽으로 트레픽이 전달되어 가장 적은 레이턴시를 보이기 위한 기본 아키텍쳐입니다.
네트워크 (트래픽 매니저와 DNS 관리) -Traffic Manager 는 공통 리소스라서 네트워크 리소스 그룹에 선택 하며 한개의 지역에 리소스를 적용시키면 Failover시 한번에 컨트롤이 어려움
가상네트워크 - 각 지역은 다른 가상 네트워크를 독자적으로 한개 씩 사용하며 다른 지역과 글로벌 피어링 연결
데이터베이스 - ASync 비동기식으로 복제 유지
배포된 지역
한국 중부(주 지역)
미국 동부(주 지역)
서부 유럽(주 지역)
윗 그림은 왜 빨간색 빈칸으로 블로 처리를 했나?
단순한 3Tier 구조이므로 굳이 복잡한 그림을 단순화 시켰다.
왜 그럼 3개의 지역에 배포를 했나?
만약 한국 중부만 리소스를 만든다면 브라질에 있는 유저는 접속을 하기 위해서 유럽 돌아 아프리카 돌아 아시아 돌아 한국으로 오게 된다.
스피드테스트 그림
위에 스피드 테스트 그림을 보자. 한국 지역에서 내가 한국 데이터센터에서 파일을 받는다면 레이턴시가 13ms 이나 브라질 데이터센터에서 가져오면 313ms 이다. 이야..! 이거는 파일이 작은거고 만약 조금 큰파일을 받는다면 엄청나게 느리다. 그래서 각 지역에 배포를 하면 그 지역에서는 매우 빠른 레이턴시를 가져오게 되므로 이런 아키텍쳐가 필요한 이유이다. 쉽게 말하면 내가 브라질에 여행을 하는 상황에 한국만 서버가 배포되있는 한국 로컬 정부서비스를 이용한다고 생각해보자. 로딩하는데 엄청난 오랜 시간때문에 한국정부 서비스를 사용하기는 정말 힘들수 있다. 그러나 만약 위와 같은 그림으로 다양한 지역에 서비스를 배포한다면 그 근처에서 가까운 위치는 빠른 반응속도를 자랑할것이다.
장점만 있나?
듣고 보니 무조건 좋다. 하지만 그건 고객중심 생각이며 서버를 저렇게 3군대에 배포한다면 1군대 배포하는것보다 3배 비용이 증가한다. 세상은 비용이 들지 않으면 좋아지지 않는것은 당연하며 만약 전세계 모든 사람이 한국 로컬 정부 서비스를 이용하지 않는다면 굳이 3군대 이상 지역에 배포할 이유가 있을까? 그래서 비지니스 니즈와 서비스의 영역은 항상 결합되어 있어야 한다. 물론 CDN을 쓰면 더 좋은 결과를 얻는다. 정적 오브젝트 스토리지와 CDN 결합으로 정적파일과 DSA(Dynamic Site Acceleration)으로 위에 아키텍쳐보다 더 빠른 서비스도 가능하긴 하지만 여기서 가장 포인트는 CDN이 아니므로 이부분은 스킵하겠다.
빨간색 화살표가 핵심이다
빨간색 화살표의 Azure Traffic Manager가 Azure DNS의 뒤에 위치해서 도메인 기반으로 다양한 시나리오에 맞춰 분기가 되어 전세계로 퍼지게 해주는 역활을 하기 때문이다. 배포는 쉬워서 굳이 만들지 않았다. 그러나 가장 중요한 이해가 필요한 부분은 시나리오이다. 어떤 시나리오를 어떻게 조합해서 내가 원하는 분기를 정확하게 만드는지가 가장 핵심이다.
트래픽 매니저의 동작 이론 방법
1번
유저는 Recursive DNS 서비스 들로 DNS를 전송해서 www.example.com 이라는 이름을 확인 하게 됩니다. Recursive DNS 서비스들은 DNS를 직접 호스팅 하지 않으며 클라이언트에서 DNS 이름을 확인하는데 필요한 작업을 오프로드 합니다.
2번
DNS 이름을 확인하기 위해서 Recursive DNS 는 example.com을 찾게 되고 Root NS,TLD NS, Authoritative Name Server(Azure DNS or Route 53) 를 통해서 www.example.com 은 example.trafficmanager.net을 CNAME record 를 보내줍니다
3번
Recursive DNS 서비스는 trafficmanager.net의 DNS 이름을 찾게 되고 example.trafficmanager.net.의 DNS record를 보내줍니다
4번
Traffic Manager 가 요청을 받으면 여러가지 라우팅 메소드에 따라 엔드포인트를 선택합니다
5번
선택된 엔드포인트는 DNS CName record를 반환합니다 (example.eu.cloudapp.net)
6번
Recursive DNS가 cloudapp.net이라는 NS를 찾고 example.eu.cloudapp.net 의 DNS 레코드를 요청하고 유럽지역에 엔드포인트의 IP 주소를 포함하는 A record가 반환됩니다
7번
Recursive DNS들이 모든 결과를 합체 시켜 클라이언트 유저에게 단일 DNS 응답을 반환합니다
8번
클라이언트 유저는 단일 DNS의 결과를 받고 지정 IP주소를 연결합니다.클라이언트는 Traffic Manager를 통해서 아니라 직접 엔드포인트로 연결됩니다.
시나리오
유저 (한국유저,일본유저,미국유저,캐나다유저,스페인 유저,독일 유저)
6명의 유저가 각각 자신의 지역에 살고 있습니다. 단순한 Traffic Manager 프로필 한개가 퍼포먼스 라우팅으로 되어 있으며 3개의지역(한국 중부, 미국 동부, 서부 유럽) 데이터센터에 서버들이 존재 합니다.
시나리오 1 - 퍼포먼스 위주의 가장 빠른 반응 속도에 따라 라우팅 하는 방법 (Performance)
퍼포먼스라우팅은 한국 유저가 한국에 있다면 Traffic Manager가 가 여러위치에서 검색해서 가장 빠른 반응 속도을 보이는 데이터 센터를 상태 확인 하고 있다가 이 대기시간이 가장 빠른 위치에 트래픽을 보내주는 역활을 합니다. 만약 일본 유저가 있다면 한국 서버가 가장 빠른 퍼포먼스를 보여주기 때문에 한국서버로 보내고 미국 유저는 미국 서버가 가장 빠른 대기 시간을 보내기 때문에 미국 서버로 보냅니다. 일반적으로는 대기 시간이 가장 짧은 데이터 센터는 지리적으로 가장 가까운 센터입니다.
그러나 Performance 라우팅이 지리적으로 기준을 가지고 가깝게 지정되는 것이 아니라 Traffic Manager 내부에 IP 주소 범위와 Azure 데이터 센터와 반응 하는 왕복 시간을 체크하는 레이턴시 테이블이 있습니다. 밑에 테이블을 보면 아이피 주소 범위를 DNS 쿼리해서 레이턴시를 관리하는 테이블이 존재하며, Traffic Manager가 DNS 요청의 Recursive DNS 원본 IP 주소를 찾아서 가장 빠른 지역대를 테이블에서 확인한 후에 가장 빠른 Endpoint에 트래픽을 보내줍니다.
Traffic Manager는 클라이언트에서 직접 DNS 쿼리를 수신하지 않으며 DNS 쿼리는 Recursive DNS 서비스에서 제공됩니다. 그러므로 가장 가까운 엔드포인트가 무엇인지 결정하는 데 사용되는 IP주소는 클라이언트 IP 주소가 아니라 Recursive DNS 서비스의 IP 주소입니다.
Traffic Manager는 인터넷 대기 시간 테이블을 정기적으로 업데이트 합니다.
시나리오 2 - 엔드포인트의 지리적 위치(가장 가까운 지역으로 보냄)로 라우팅 하는 방법(Geographic)
만약 지리적 위치에 따라 데이터의 독립성과 콘텐츠 및 사용자 환경의 지역화를 준수한다면 이 시나리오가 적합합니다. 한국 미국 일본 모두 다른 룰이나 지역 법에 따라 다른 서비스를 해야 할 경우에 지리적으로 세분화 할수 있으며 지역을 세분화 시킨 그룹도 사용할 수 있습니다.. 한마디로 일본 지역에 접속해야 하는 일본 사람은 일본 서버에만 접속 하도록 보내고 미국서버에 접속해야 하는 사람은 미국 서버에 보내고 한국 사람은 한국 서버로 접속하도록 해줄수 있습니다.
시나리오 3 - 가중치 적용 트래픽(1-1000으로 가중치를 주어서 우선순위 정함) 라우팅 방법(Weight)
가중치 테이블을 가지고 가중치를 1에서 1000으로 가중치를 주어서 우선 순위를 정합니다. 테스트 서버를 두고 본서버와 스왑할때 점진적으로 가중치를 주고 트래픽을 줄수 있습니다.
시나리오 4 - 우선 순위 트래픽(순서를 미리 정함) 라우팅 방법 (Priority)
예를 들어 우선순위를 서울 일본 미국으로 정해 놓는다면 기본적으로 우선순위가 서울이라면 모든트래픽을 서울 로 보내고 서울이 사용할수 없는 경우 일본으로 보내며 일본도 사용할 수 없다면 미국으로 보내는 시나리오에 적합합니다.
시나리오 5 - 서브넷 기반 으로 라우팅 (Subnet)
서브넷 라우팅을 사용하면 특정 IP 주소 범위를 엔드 포인트에 매핑할 수 있습니다.
시나리오 6 - 다중값 라우팅 (Multi-Values) - 여러개의 엔드포인트를 단일 쿼리 응답에 반응하게 함
다중값 트래픽 라우팅은 여러개의 정상 엔드포인트를 반환할 수 있으며 DNS 조회 하지 않고 다시 시도 할수 있는 옵션이 클라이언트에 주어지므로 에플리케이션 안정성이 좀더 높아지는 시나리오에 사용할 수 있습니다. IPv4 IPv6를 사용하여 사용하는 시나리오 입니다.
시나리오 7 - 중첩 프로필로 1-6번 기능을 혼합하여 사용하는 방법
https://docs.microsoft.com/ko-kr/azure/traffic-manager/traffic-manager-nested-profiles
7-1 성능 + 가중치 결합 사용 라우팅
7-2 성능 + 우선순위 결합 사용 라우팅
7-3 성능 + 지리적 결합 사용 라우팅
7-4 지리적 + 성능 결합 사용 라우팅
7-5 가중치 + 성능 결합 사용 라우팅
이런 시나리오와 더 많은 시나리오가 존재할 수 있으며 중첩은 10개까지 가능하며 루프로 개속 돌게 만드는 시나리오는 가능하지 않습니다. 중첩을 사용한다고 해서 추가 비용이 필요한것은 아닙니다. 맨 위에 상위의 프로필을 부모 프로필라고 하며 그 밑에 자식 프로필을 놓을수 있으며
이런 방식으로 중첩으로 구성하면 다양한 시나리오가 가능합니다.