[VNet] Traffic Manager 도메인 기반 로드벨런서
VNet
작성자
Roronoa
작성일
2019-05-25 10:39
조회
3288
300회 이상 배포 해본 사용기 입니다. 또한 실제 운영서버를 사용중입니다.
수학으로 말하면 집합(정석의 1장)인 Azure DNS 와 Traffic Manager .. 이름이 솔직히 MS는 파격적이지 못해서 재미없다. 물론 개발단계에서는 독특한 이름이었겠지만 윗형들은 이런이름을 좋아하니깐 ... 어쩔수 없는듯 하다. 집합이라 표현한것은 모든 트레픽 모든 프로덕트의 가장 앞단에 있기 때문이다. 사실 Azure DNS 가 가장 앞이긴 하지만... 가격은 100만 DNS 쿼리당 648원이정도면 꽁짜나 다름없지 않을까 생각된다. 물론 꽁짜는 아니지만. 알다시피 DNS 기반 서비스 이므로 도메인과 아이피를 연결 해주는 서비스이다. 예를 들어 naver.com이 있다면 naver.com 이 가지고 있는 xxx.xxx.xxx.xxx 숫자 IP주소와 naver.com 도메인이 연결되어 VM으로 분산되어 접속 할수 있다. 일반적으로 잘나가시는 Akamai, Azure Traffic Manager, Dyn 등등 이 비슷한 서비스라 할 수 있다. 항상 이런 서비스에서는 DDoS 를 막는 솔루션이 제공된다고 하나 아직 검증을 해보지 못했으며 DDoS의 종류가 다양하고 대규모 아니면 전혀 막아주지도 않을뿐더러 어떻게 막아준다는 내용과 정확한 SLA 도 없고 아무것도 보장된것이 없다. 갑자기 비관적으로 바뀌었지만 아무튼 이 서비스에 대해서 알아보자
기본 시나리오
naver.com이란 도메인이있다고 가정하자.
주소창에 naver.com 를 치면 -> 네임서버로 가고 -> 네임서버에서 369.369.369.369 라는 주소는 -> Traffic Manager에 있고 전달된다. 그후 Traffic Manager는 다양한 서브도메인이나 서비스로 가장 빠르거나 가장 가까운 지역으로 보내준다.
이거 저거 생각할것 없이 위에 한줄이 바로 Traffic Manager의 역할이며 "DNS 기반" 만 생각하면 된다.
장점
다른 비슷한 제품 중 DNS로 되는거만 되고 "중첩" Traffic Manager 프로필이 된다.
애플리케이션의 가용성, 성능 향상, 무중단 서비스 가능, 하이브리드 결합 가능 하다.
끝점에 대한 모니터링 가능
실제 사용자 측정 가능
단점
DNS 이외에 문제는 다른 서비스와 결합하여 해결해야한다. 예를들어 WAF 와 같은 방화벽은 Application Gateway와 결합해야한다.
DNS가 아닌 내부 엔드포인트(Private IP)로 연결은 불가능
고정 세션은 불가능하며 다른 로드벨런서로 가능
DNS 가 어떤 시나리오로 분기될수 있나?
자 위 그림은 Microsoft 공식 문서에서 퍼온 그림이다. www.contoso.com 이라는 도메인을 소유했다고 가정하자. 그리고 유럽지역, 아시아, 미국 3군대에 서비스를 하기 위한 3개의 서브도메인 (contoso-us.cloudapp.net, contoso-eu.cloudapp.net, contoso-asia.cloudapp.net) 으로 나누어 만약 유저가 유럽에 있다면 유럽으로 아사아에 있다면 아시아로 보내고 싶다는 가정하에 www.contoso.com에 접속한 유저는 자동으로 각각 위치에서 가까운 쪽으로 보내게 된다. 자 여기서 www.contoso.com은 naked 도메인이 아니다.이런 도메인을 Vanity Domain(가짜 도메인)이라고 하는데 . 실제적으로 트레픽 관리자에서는 naked 도메인(contoso.com(www가 빠진)을 CNAME 을 만들수 없으므로 Vanity Domain(www.contoso.com) 을 CNAME으로 만든후 리디렉션을 사용하여 Vanity Domain으로 nake 도메인으로 보낸다. 이는 DNS 표준이다.
라우팅 방법
DNS 성능 측정 도구
중첩 트래픽 관리 (이부분이 가장 중요)
1번 시나리오 : Traffic Manager의 가장 중요한 부분은 이 중첩 Nested Profile 이 가장 중요하며 부모가 되는 Parent Profile 이 입구이며 가장 처음 부분이다. 이 부분은 성능 트래픽 라우팅으로 3개의 지역 서부 미국서부, 서부유럽, 동아시아 에서 유저가 가장 가까운 또는 성능이 가장 잘나오는 지역으로 보낸다. 일반 로드 벨런서처럼 성능을 측정하기 위해서 Probe가 개속 체크를 하며 접속한 유저의 IP를 기반으로 트래픽을 보낸다.
2번 시나리오: 한개의 트래픽 매니저 프로파일로는 원하는 시나리오를 구축 할수 없기 때문에 밑와 같은 중첩된 트래픽 매니저로 원하는 방식대로 입맛에 맞게 사용할수 있다. 그래서 그 두번째 Child Profile은 프로덕션과 스테이징(테스트환경) 에 99퍼센트의 트래픽을 프로덕션으로 보내고 1프로만 테스트 환경으로 보내는 중첩 프로파일로 다양한 시나리오를 커버가 가능하다.
3번 시나리오 : 성능 트래픽 라우팅에서 서부 유럽으로 가는 트래픽이 실패했을때 이 모든 트래픽은 미국 서부로 보내는 시나리오 를 위한 방법이다. 우선순위를 두어서 기본적으로는 서부 유럽으로 가지만 서부유럽이 실패했을때 전부 미국 서부로 보내는 시나리오를 만들수 있다.
4번 시나리오 :동일한 지역 서부 유럽에 두개의 엔드포인트를 생성하고 두개를 똑같이 나눠가게 한다. 이런 시나리오는 서부유럽이 메인 프로덕트일때 사용되게 하는 방법이다.
5번 시나리오 : 퍼포먼스 기반 라우팅에서 서부 유럽에 두개의 Active- Active 구성을 만들어 이며 더 파워풀하고 컴퓨팅 파워가 큰 부분으로 전체 트래픽의 99퍼센트를 보내고 아주 라이트하게 1프로만 서부유럽2 지역으로 보낸다. 이 시나리오가 일반적인 DR 구성에서 가장 이상적인 방법이며 한개의 데이터센터가 장애가 낳을때 가장 빠르게 복구할수 있는 시나리오이다. 물론 최소 비용으로..
끝점의 유형( Endpoint)
트래픽 매니져 만들어보자
Azure 포털 접속
새로만들기 -> 네트워킹 -> 모두보기 -> "트래픽 관리자 프로필(Traffic Manager profile)" 선택 후 만들기 누름
트래픽 매니저의 이름(소문자로만- 서브도메인이므로)
성능 방법 (성능, 가중, 우선순위 지리적) 을 선택
참고 글
https://docs.microsoft.com/ko-kr/azure/traffic-manager/traffic-manager-overview
수학으로 말하면 집합(정석의 1장)인 Azure DNS 와 Traffic Manager .. 이름이 솔직히 MS는 파격적이지 못해서 재미없다. 물론 개발단계에서는 독특한 이름이었겠지만 윗형들은 이런이름을 좋아하니깐 ... 어쩔수 없는듯 하다. 집합이라 표현한것은 모든 트레픽 모든 프로덕트의 가장 앞단에 있기 때문이다. 사실 Azure DNS 가 가장 앞이긴 하지만... 가격은 100만 DNS 쿼리당 648원이정도면 꽁짜나 다름없지 않을까 생각된다. 물론 꽁짜는 아니지만. 알다시피 DNS 기반 서비스 이므로 도메인과 아이피를 연결 해주는 서비스이다. 예를 들어 naver.com이 있다면 naver.com 이 가지고 있는 xxx.xxx.xxx.xxx 숫자 IP주소와 naver.com 도메인이 연결되어 VM으로 분산되어 접속 할수 있다. 일반적으로 잘나가시는 Akamai, Azure Traffic Manager, Dyn 등등 이 비슷한 서비스라 할 수 있다. 항상 이런 서비스에서는 DDoS 를 막는 솔루션이 제공된다고 하나 아직 검증을 해보지 못했으며 DDoS의 종류가 다양하고 대규모 아니면 전혀 막아주지도 않을뿐더러 어떻게 막아준다는 내용과 정확한 SLA 도 없고 아무것도 보장된것이 없다. 갑자기 비관적으로 바뀌었지만 아무튼 이 서비스에 대해서 알아보자
기본 시나리오
naver.com이란 도메인이있다고 가정하자.
주소창에 naver.com 를 치면 -> 네임서버로 가고 -> 네임서버에서 369.369.369.369 라는 주소는 -> Traffic Manager에 있고 전달된다. 그후 Traffic Manager는 다양한 서브도메인이나 서비스로 가장 빠르거나 가장 가까운 지역으로 보내준다.
이거 저거 생각할것 없이 위에 한줄이 바로 Traffic Manager의 역할이며 "DNS 기반" 만 생각하면 된다.
장점
다른 비슷한 제품 중 DNS로 되는거만 되고 "중첩" Traffic Manager 프로필이 된다.
애플리케이션의 가용성, 성능 향상, 무중단 서비스 가능, 하이브리드 결합 가능 하다.
끝점에 대한 모니터링 가능
실제 사용자 측정 가능
단점
DNS 이외에 문제는 다른 서비스와 결합하여 해결해야한다. 예를들어 WAF 와 같은 방화벽은 Application Gateway와 결합해야한다.
DNS가 아닌 내부 엔드포인트(Private IP)로 연결은 불가능
고정 세션은 불가능하며 다른 로드벨런서로 가능
DNS 가 어떤 시나리오로 분기될수 있나?
자 위 그림은 Microsoft 공식 문서에서 퍼온 그림이다. www.contoso.com 이라는 도메인을 소유했다고 가정하자. 그리고 유럽지역, 아시아, 미국 3군대에 서비스를 하기 위한 3개의 서브도메인 (contoso-us.cloudapp.net, contoso-eu.cloudapp.net, contoso-asia.cloudapp.net) 으로 나누어 만약 유저가 유럽에 있다면 유럽으로 아사아에 있다면 아시아로 보내고 싶다는 가정하에 www.contoso.com에 접속한 유저는 자동으로 각각 위치에서 가까운 쪽으로 보내게 된다. 자 여기서 www.contoso.com은 naked 도메인이 아니다.이런 도메인을 Vanity Domain(가짜 도메인)이라고 하는데 . 실제적으로 트레픽 관리자에서는 naked 도메인(contoso.com(www가 빠진)을 CNAME 을 만들수 없으므로 Vanity Domain(www.contoso.com) 을 CNAME으로 만든후 리디렉션을 사용하여 Vanity Domain으로 nake 도메인으로 보낸다. 이는 DNS 표준이다.
라우팅 방법
- 지리적 라우팅 방법(Geographic) - 지리적 기반으로 end point에 트래픽을 보낸다. 예를들어 한국 미국에 서버가 있다면 미국에 있다면 미국서버로 한국에 있다면 한국 서버로 라우팅 시킨다.
- 우선순위 라우팅 방법(Priority) - 우선순위를 정하여 트래픽을 보냄
- 가중 라우팅 방법(Weighted) - 가중치를 주어서 트래픽 보냄 - 예를들어
- 성능 라우팅 방법 (Performance) - 네트워크 대기시간을 측정한후 가장 빠른 지역으로 트래픽 보냄 -
- 사용자의 서브넷 기반 (Subnet) - 서브넷 기반으로 트래픽 라우팅
DNS 성능 측정 도구
- SolveDNS http://www.solvedns.com/dns-comparison/
- WebSitePulse https://www.websitepulse.com/help/tools.php
- Watchmouse Check Website https://asm.ca.com/en/checkit.php
- Pingdom https://asm.ca.com/en/checkit.php
- Whatsmydns.net https://asm.ca.com/en/checkit.php
- Digweb http://www.digwebinterface.com/
중첩 트래픽 관리 (이부분이 가장 중요)
1번 시나리오 : Traffic Manager의 가장 중요한 부분은 이 중첩 Nested Profile 이 가장 중요하며 부모가 되는 Parent Profile 이 입구이며 가장 처음 부분이다. 이 부분은 성능 트래픽 라우팅으로 3개의 지역 서부 미국서부, 서부유럽, 동아시아 에서 유저가 가장 가까운 또는 성능이 가장 잘나오는 지역으로 보낸다. 일반 로드 벨런서처럼 성능을 측정하기 위해서 Probe가 개속 체크를 하며 접속한 유저의 IP를 기반으로 트래픽을 보낸다.
2번 시나리오: 한개의 트래픽 매니저 프로파일로는 원하는 시나리오를 구축 할수 없기 때문에 밑와 같은 중첩된 트래픽 매니저로 원하는 방식대로 입맛에 맞게 사용할수 있다. 그래서 그 두번째 Child Profile은 프로덕션과 스테이징(테스트환경) 에 99퍼센트의 트래픽을 프로덕션으로 보내고 1프로만 테스트 환경으로 보내는 중첩 프로파일로 다양한 시나리오를 커버가 가능하다.
3번 시나리오 : 성능 트래픽 라우팅에서 서부 유럽으로 가는 트래픽이 실패했을때 이 모든 트래픽은 미국 서부로 보내는 시나리오 를 위한 방법이다. 우선순위를 두어서 기본적으로는 서부 유럽으로 가지만 서부유럽이 실패했을때 전부 미국 서부로 보내는 시나리오를 만들수 있다.
4번 시나리오 :동일한 지역 서부 유럽에 두개의 엔드포인트를 생성하고 두개를 똑같이 나눠가게 한다. 이런 시나리오는 서부유럽이 메인 프로덕트일때 사용되게 하는 방법이다.
5번 시나리오 : 퍼포먼스 기반 라우팅에서 서부 유럽에 두개의 Active- Active 구성을 만들어 이며 더 파워풀하고 컴퓨팅 파워가 큰 부분으로 전체 트래픽의 99퍼센트를 보내고 아주 라이트하게 1프로만 서부유럽2 지역으로 보낸다. 이 시나리오가 일반적인 DR 구성에서 가장 이상적인 방법이며 한개의 데이터센터가 장애가 낳을때 가장 빠르게 복구할수 있는 시나리오이다. 물론 최소 비용으로..
끝점의 유형( Endpoint)
- Azure 끝점 - IaaS VM, PaaS 클라우드서비스, 웹앱, LoadBalancer, Application Gateway (이건 머 당연히 되야되며)
- 외부 끝점 - 온프레미스의 끝점, 그이외에 AWS(아마존) 조차 연결 가능하다. (AWS와 하이브리드로 구성가능)
- 중첩 끝점 - 중첩으로 여러개의 트래픽 매니저의 프로파일이 트리구조로 자식 부모 관계로 끝점이 추가 가능하다.
트래픽 매니져 만들어보자
Azure 포털 접속
새로만들기 -> 네트워킹 -> 모두보기 -> "트래픽 관리자 프로필(Traffic Manager profile)" 선택 후 만들기 누름
트래픽 매니저의 이름(소문자로만- 서브도메인이므로)
성능 방법 (성능, 가중, 우선순위 지리적) 을 선택
참고 글
https://docs.microsoft.com/ko-kr/azure/traffic-manager/traffic-manager-overview