안녕하세요. 김대우입니다. 이제 Windows Azure 트래픽 관리자 마지막 포스팅이네요.

지금까지 포스팅을 통해 클라우드 환경에서의 트래픽 분산의 필요성과 서비스 시나리오를 알아 보았습니다.

 

클라우드 트래픽 부하 분산 - (1) Windows Azure 트래픽 관리자(Traffic Manager)

클라우드 트래픽 부하 분산 - (2) Windows Azure 트래픽 관리자 서비스 시나리오

클라우드 트래픽 부하 분산 - (3) Windows Azure 트래픽 관리자 서비스 구축


당연히 실제 서비스 구축 과정을 살펴 보도록 하겠습니다. 비록, 테스트 도메인이 없어 아쉽지만 아래 캡처한 강좌 화면만 보셔도 감이 오실거에요. 트래픽 관리자는 Windows Azure 관리 포털 좌측 하단의 Traffic Manager를 선택하고 “새로만들기” 하시면 됩니다.

 

image_2.png


익숙하신 화면이지요.(대쉬보드를 보시면 한글화 되어 있습니다.) “DNS 접두사(Prefix)”는 꼭, 이미 구성된 CNAME으로 링크해 주시면 됩니다.


CNAME에 대한 소개는 이전에 제가 작성한 포스팅인

Windows Azure Website와 클라우드 서비스에 나의 도메인을 연결 - CNAME만 기억하세요!

내용을 참조 하시면 됩니다.


만약, AWS의 Route 53에 익숙하다면 이 과정은 관리할 도메인인 "Hosted Zone"을 만드는 과정과 유사합니다.


만약, 클라우드 트래픽 부하 분산 - (2) Windows Azure 트래픽 관리자 서비스 시나리오 을 차근차근 보셨다면 이제 원하시는 서비스의 선택이 가능하실 거에요. 먼저, 자 첫 시나리오인 "(1) 높은 성능을 제공하는 클라우드 어플리케이션을 구성 - 성능(Performance) 정책"을 구현하기 위해 “성능(Performance)”를 선택 후 생성합니다.

 

image_4.png


만드는데 시간이 오래 걸리지 않습니다. 말 그대로 몇 초 만에 후닥닥 만들어지죠.  이 화면은 만들어진 대쉬보드 화면입니다.

상태 모니터링이나 DNS 요청 수 등을 이 대쉬보드에서 보실 수 있어요.


image_6.png


그럼 바로 끝점(End Point)을 구성하도록 하겠습니다. - 끝점 구성 역시 간단해요, 어느 클라우드 서비스에 분산해 라우팅 시킬지 골라서 선택하는 과정입니다. 만약, AWS의 Route 53에 익숙하다면 이 과정은 "Record Set"을 만드는 과정과 유사합니다.

 

image_8.png


끝점 추가(Add Endpoint)를 선택하면 이미 내가 만들어 서비스되고 있는 다양한 지역의 클라우드 서비스가 나옵니다.

느낌이 오시죠? 각 데이터센터 지역에 구성된 서비스 중, 묶고 싶은 서비스를 선택하면 끝!

위의 화면에서는 북유럽과 미국 동부 지역을 묶었습니다. – 원하는 만큼 묶으시면 됩니다.


 

image_10.png



잠시 후 이렇게 서비스가 묶어지고 온라인 상태가 되죠. 이제 테스트를 해 보시면 됩니다. 여러 방법의 테스트가 가능한데요, 간단하게 하시는 방법은 각 지역에 Windows Azure 가상머신을 만들고 원격 데스크톱으로 접속해 브라우저로 요청을 해 보는 방법입니다.


대쉬보드의 구성(Configure)에서 DNS TTL 시간을 30초 정도로 줄이고 테스트하면 더 빨리 테스트 가능하겠지요.(기본 DNS TTL 세팅은 300초)  


성능 시나리오를 살펴 보셨으면 이제 두 번째 시나리오를 살펴 보도록 할게요. "(2) 장애복구 계획을 목표로 트래픽 관리자를 구성 - 장애조치(Failover) 정책" 시나리오 입니다.


image_12.png


이 시나리오 역시 간단합니다. 이전 포스팅에서 소개해 드린 것처럼, 장애 조치(Failover)로 처리할 경우는 주 서비스(Primary)를 구성하는 절차가 선행되어야 합니다. 이렇게 주 서비스를 선택해 구성하고, 주 서비스를 강제로 중지 시켜서 테스트 해 보시면 Failover가 잘 처리되는 것을 확인 가능합니다.

 


마지막으로 살펴볼 시나리오는 "(3) 서비스 중인 클라우드 어플리케이션에 대해 서비스 중지(유지보수 시간) 없이 업그레이드를 제공"하는 시나리오 입니다. 간단히 처리해 보실 수 있어요.


image_14.png


유지보수 시간 없이 어플리케이션을 업데이트 하는 시나리오의 경우에는 이렇게 해당 끝점을 잠시 중지시키고 서비스 업데이트/테스트 하시면 됩니다. 테스트가 다 되면 다시 온라인 시키면 부하 분산이 이루어지지요.


클라우드 기반 부하 분산 서비스, Windows Azure 트래픽 관리자의 내일

클라우드의 미래는 IaaS가 아니라 PaaS다 라고 늘상 말씀 드렸습니다.(Windows Azure는 IaaS와 PaaS를 모두 제공하죠) 그리고, 앞으로의 클라우드는 On-premise에 더해지는 Private Cloud, Public Cloud를 아우르는 하이브리드 클라우드가 주도하게 될 것입니다. 내일의 트래픽 관리자 모습도 쉽게 예측 가능할 것 같아요. 클라우드 대상 서비스 뿐만 아니라, On-premise와 하이브리드 클라우드 전체에 대한 트래픽 관리에, 클라우드의 내일인 PaaS기반 서비스와 더 유기적으로 동작해 PaaS 기반 서비스의 일부로 분명 자리잡게 될겁니다.


이렇게 해서 Windows Azure Traffic Manager에 대해 알아 보았습니다. 클라우드 기반 트래픽 부하 분산 서비스로 고민하시는 많은 개발자 분들께 도움 되시면 좋겠습니다. 감사합니다.

 

 

참고링크

클라우드 트래픽 부하 분산 - (1) Windows Azure 트래픽 관리자(Traffic Manager)

클라우드 트래픽 부하 분산 - (2) Windows Azure 트래픽 관리자 서비스 시나리오

클라우드 트래픽 부하 분산 - (3) Windows Azure 트래픽 관리자 서비스 구축 

Windows Azure Traffic Manager 서비스 소개 - 공식 한글 사이트
Windows Azure Website와 클라우드 서비스에 나의 도메인을 연결 - CNAME만 기억하세요!
Traffic Manager Overview
Edge Show 86 - Windows Azure Traffic Manager Demos - 동영상
About Traffic Manager Load Balancing Methods
Traffic Manager Configuration Tasks
트래픽 관리자 가격 정보
About Traffic Manager Monitoring






profile

부족하지만, SQLER의 누군가와 함께한 나눔을 통해 제가 더 많이 즐거웠습니다.
SQLER와 함께 즐거워 할수록, 그 나눔을 통해 더 많은 기회와 가치를 발견하게 되었습니다.
나눔의 생각이 앞으로도 계속, SQLER를 움직일 것입니다.

코난, 김대우 / SQLER 운영자 / 골라먹는 SQLER RSS 정보 구독 / 실시간 SQLER 소식 uxkorea 트위터