Korea Evangelist

Developer & Platform Evangelism, Microsoft Korea

  • Korea Evangelist

    테크데이즈 미니 토요세미나 발표자이신 김경균님을 미리 만나 보았습니다

    • 0 Comments

    오늘은 유비베이스의1 김경균 님을 만나 뵈었습니다.

    김명신: 안녕하세요 김경균님. 최근에 하시고 계신 일에 대해서 간단히 소개 부탁드립니다.

    김경균: 네, 최근에 유비베이스라는 회사에서 주로 마이크로소프트에서 개발한 Lync라는 기업용 메신저 소프트웨어를 교환기나 외부 시스템과 연동하는 일을 수개월간 진행하고 있습니다. 이러한 메시징 소프트웨어는 단순한 TCP/IP 통신 외에도 VoIP(Voice Over IP)기반의 통신이나, CSTA(Computer-Supported Telecommunication Application) 관련 프로토콜, Telephone API 등과 같이 일반 기업용 응용 프로그램 개발 시에 사용하는 기술과는 조금 다른 기술에 대한 이해를 필요로 합니다. 외부 시스템이나 장비 연동을 하려면 아무래도 잘 작성된 문서나 스펙에 의존할 수 밖에 없는데요, 최근 프로젝트는 전임자의 퇴사와 부실한 문서화 등으로 상당히 고전하고 있는 것이 사실입니다. 물론 잘못된 문서보다는 나을 수 있을지 모르겠으나, 연동을 위해서 응용 프로그램을 디버깅해야 하는 유쾌하지 못한 상황에 처해 있는 것은 사실입니다.

    김명신: 사실 국내 개발 프로젝트들을 살펴보면 너무나 과도한 문서화를 요구해서, 개발보다 문서작성에 시간이 더 많이 걸린다고 불만을 토로하시는 개발자도 있고, 김경균님처럼 부실하게 문서를 만들어 놓은 탓에 차기 프로젝트를 진행하는 데 걸림돌이 되는 경우도 있는 것 같습니다. 개발 프로젝트에 있어 문서화의 정도는 어느 수준이 적합할지요?

    김경균: 저도 문서화에 대한 다양한 시각이 있음을 알고 있습니다. 어떤 개발자들은 소스 그 자체가 이미 완벽한 문서이므로 추가적인 문서는 필요하지 않으며, 소스가 문제를 정확히 설명할 수 있도록 작성하라는 극단적인 주장도 있고, 일부 국내 대기업에서와 같이 소프트웨어 공학의 연구 과정이나 CMMI 등을 기준으로 자체 개발한 거의 100여종에 이르는 산출물 리스트를 접한 적도 있습니다. 개인적인 생각으로는 문서화는 가능한 최소화 하는 것이 좋지 않을까 합니다. 개발 진행 과정의 편의를 돕기 위한 문서라면 모를까 대부분의 문서들이 프로젝트 완료 이후에는 그 가치가 현저히 떨어지거나 쓸모 없게 되는 경우가 많은데, 이런 문서들의 작성은 최소한으로 하는 것이 좋을 것 같습니다. 물론 외부 시스템과의 연동 규격서나, 운영 매뉴얼 등은 반드시 있어야 하는 문서 중에 하나일 것으로 생각됩니다. 또한 업무 처리 로직이 너무 복잡한 경우에도 반드시 문서화가 필요한 부분일 수는 있겠습니다. 물론 소스 코드는 그와 상관 없이 깔끔하게 작성할 필요가 있겠지요.

    김명신: 지금 진행하시고 계신 프로젝트 이외에도 국내 대기업과 상당히 다양한 개발 프로젝트를 진행하신 것으로 알고 있습니다. 현업에서 그러한 프로젝트를 진행하시면서 겪으셨던 어려움이나 에피소드 같은 것이 있을까요?

    김경균: 실제 현업에서 개발을 담당하다 보면 여러 가지 형태의 제약이나 어려움이 없을 수 없습니다. 그 중에 가장 큰 것이 무엇이냐 라고 물어보신다면 역시 사람의 문제라 말씀드릴 수 있을 것 같습니다. 개발 프로젝트의 진행 중에는 특별한 경우가 아니라면 다양한 업무와 역할을 담당하는 개발자 분들과 같이 일을 하는 것이 보통이겠지요. 저 같은 경우는 주로 프로젝트의 핵심 공통 모듈 개발을 많이 진행하곤 하였는데, 다른 개발자 분들과의 협업 시에 역할 분담과 기술 지원에 애를 많이 먹었던 기억이 있습니다. 공통 모듈은 보통의 경우 프로젝트의 주요 기능을 다루거나 혹은 다른 개발자분들께서 자주 사용하시는 부분들에 대한 추상화 계층을 제공하기 위한 경우가 많은데요, 이 모듈은 왜 이렇게 만들었느냐는 긍정적인 비판 외에도, 이것은 왜 만들어 주지 않느냐 혹은 이 모듈은 사용할 수 없다라는 식의 이야기도 간혹 듣곤 했습니다. 사실 공통 모듈 개발이라는 것이 외부에서 보면 뭔가 하는 일이 없어 보이기도 하고, 뭔가 잘못되면 공통 모듈의 문제인 것만 같고 그런 것 같습니다. 프로젝트의 성공이 공통 모듈을 잘 개발해서라고 평가되는 경우는 별로 없지만 실패의 원인을 공통 모듈로부터 찾으려는 시도는 사뭇 비일비재 합니다. 또 다른 관점에서는 기술이 문제일 경우도 있더군요. 정확히는 기술 그 자체의 문제라기 보다는 기술을 이해하지 못하는 개발자의 문제라고 보는 편이 좀 더 정확한 것 같습니다. 개발자의 업무와 역할은 사실 요구되는 일과 그 결과가 다른 업종에 비해서 명확하기 때문에, 같이 일을 해보고 그 결과를 드려다 보면 개발자의 성향이나 능력치가 드러날 수 밖에 없는 것 같습니다. 수년 전에 외부의 커뮤니티에서 꽤나 이름이 알려진 개발자분과 함께 일할 기회가 있었습니다. 하지만 수개월 후에 그분이 만들어 내신 결과물은 명성에는 걸맞지 않은 수준이었고요, 그 분도 그걸 아셨는지 더 이상 일을 하지 못하시고 떠나시더라고요. 개발자는 명성 보다는 능력과 결과로 본인을 증명할 수 있어야 한다고 생각합니다.

    김명신: 그렇다면 개발자가 반드시 가져야 하는 역량이라는 것이 있을까요? 제 주위의 일부 학생들은 개발 그 자체가 좋긴 하지만, 업종 자체가 3D이고, 젊었을 때 잠시 잠깐 밖에 할 수 없는 일이기 때문에 개발자로서의 수명이 너무 짧은 것 같다고 토로하는 분이 있는 것 같습니다. 이 점에 대해서는 어떻게 생각하시는지요?

    김경균: 제 주위에 훌륭한 개발자라고 생각되는 몇몇 분들을 보면 나름의 특징들이 조금 있기는 합니다. 대부분이 어떤 문제 상황에 봉착했을 때, 문제 해결을 위해서 과도하리만큼 놀라운 집중력을 보이는 분들이 많은 것 같아요. 정보통신업이라는 것이 고도의 지식집약적 산업이고, 육체적인 노동 보다는 지적 노동을 필요로 한다는 점에서 이는 사실 특별한 것은 아니라고 할 수도 있겠습니다만 다른 업종에 종사하시는 분들에게는 이러한 특징으로 인해 개발자들은 조금 이상하거나 다르다고 생각하실 수도 있을 것 같다는 생각을 해보았습니다. 그리고 정보통신 산업이 3D 산업인 나라는 아마 한국밖에 없지 않을까 합니다. 소프트웨어 개발과 관련된 다양한 직업들 예를 들면 컨설팅 업무나, 소프트웨어 아키텍트, 개발자 등에 이르기 까지 정보통신 관련업은 많은 나라에서 가장 각광 받는 직업이자 최고의 부가가치를 생산하는 산업으로 인정 받고 있는 분야입니다. 이러한 분야가 3D 산업으로 분류되는 것은 그 분야에 있는 분들에게도 좋지 않겠지만 국가적으로도 불행한 일이 아닐 수 없다고 생각합니다. 게다가 개발자가 수명이 정해져 있다는 것에도 동의하기 어렵습니다. 개발은 젊어서만 할 수 있다고 생각하는 것은 편견에 가깝고요, 자기계발을 꾸준히 하여 개발 역량을 보전할 수만 있다면 나이와 상관없이 개발은 계속하실 수 있으리라 생각합니다. 하지만 이는 개인의 역량의 문제로만 볼 수는 없고 사회적인 통념이나 보수의 문제와 연관 지어 고민해볼 부분인 것 같습니다. 실제로 많은 SI업체들이 경력이 많고 개발을 잘 하는 고급 개발자 한명보다 적당한 중급 혹은 초급 개발자 여러명을 선호합니다. 이는 개발업종을 사람의 머리수로 계산하는 어처구니 없는 사고방식일 뿐입니다. 응용 프로그램의 본수로 프로젝트의 규모를 측정하고, 그것을 근간으로 개발자 수를 산정하기 때문인데요, 제 개인적인 생각으로는 아무리 단순한 개발이라도 고급개발자 한 명이 중급 개발자 여러 명보다 훨씬 낫다고 생각합니다. 이런 비유가 어떨지 모르겠지만 중급 개발자가 삽이라면 고급 개발자는 포크레인인 것이지요. 그럼에도 기술적인 사리판단이 정확하지 않은 매니저들이 고급 개발자들 보다는 중급 혹은 초급 개발자들을 선호함에 따라 실제로 능력과 경험을 겸비한 개발자들이 설자리가 점점 좁아지는 것이 사실입니다. 이는 안타까운 현실임에는 분명한 것 같습니다.

    김명신: 기술 그 자체에 대한 이야기를 조금 나누어 보면 어떨까요? 최근에 공부하시면서 가장 재미있었던 부분이나 혹은 가능성을 발견하신 부분이 있으시다면 어떤 부분일까요?

    김경균: 대학교 다닐 때 C++와 같은 언어를 배우기는 했지만, 사회생활을 시작하면서 본격적으로 접한 언어가 C#이었습니다. 그런데 C#에서는 델리게이트라는 요소가 있습니다. 처음 C# 언어를 공부할 때는 제가 이 부분을 잘 알지를 못했어요, 게다가 이벤트 드리븐 아키텍쳐(event driven architecture)나 최근 JavaScript에서 문제점이라고 지적하는 콜백을 근간으로 한 비동기 모형 등은 사실 별로 관심사가 아니었어요. 그런데 어느날 이벤트를 근간으로 한다는 것에 대한 호기심이 생겼고, 그것이 델리게이트로 무명 메서드(anonymous method)로 다시 람다 표현식(lambda expression)으로 그리고 LINQ로 발전하고, 그 적용영역이 확장되는 것을 보면서 즐거웠던 기억이 있습니다.

    김명신: 수년간 ASP.NET MVP로 활동을 하신 것으로 알고 있습니다. 마이크로소프트의 웹 개발 기술은 사실 ASP로부터 시작해서 이미 상당히 오랫동안 거의 정점에 이를 만큼 그 완성도가 높다고 평가 받고 있습니다. 이에 대해서 의견이 있으실까요?

    김경균: 그렇습니다. 말씀하신 바와 같이 마이크로소프트의 ASP와 ASP.NET이라는 이름으로 상당히 오랫동안 웹 개발 기술을 계승 발전시켜 왔습니다. 하지만 그 내면을 드려다 보면 상당한 자기 혁신과 변혁의 노력들을 살펴볼 수가 있습니다. ASP에서 ASP.NET으로의 전환이 그 한 단면일 수 있습니다. 스크립트와 마크업을 교묘히 섞어 사용하던 ASP의 시대에서 서버 사이드 컴포넌트와 이벤트 드리븐 방식의 ASP.NET으로의 변화는 진일보한 발전임에 분명하였습니다. 그 이후에는 다시 MVC 모형을 전폭적으로 수용한 ASP.NET MVC 모형이 최근 버전 5.1까지 출시가 되었지요. 게다가 WebPage나 SPA와 같은 웹 페이지 개발 기술과 더불어 WebAPI, SignalR 과 같은 웹 서비스 개발 기술, IIS와 같은 웹 애플리케이션 호스팅 기술, 최근에는 트렌드에 맞추어 경량화 웹서버, 경량화 웹 플랫폼 기술, 웹 호스팅 환경과 웹 어플리케이션의 분리를 도모하는 등 끊임없이 발전하고 진화하는 모습을 보여주고 있습니다. 사실 정점에 이르는 완성도보다는 현실의 변화를 즉각적으로 반영하고 따라가 주기를 많은 개발자들이 희망한다고 생각합니다. 물론 그 다음은 기술적 리더쉽이겠지요. 부족한 부분이 많이 있다고 생각은 듭니다만, 마이크로소프트가 최근에 웹 개발 프레임워크를 전격적으로 .NET Framework과 분리하여 1~2년만에 한번씩 업데이트가 나오던 이전과 다르게 수주에서 수개월에 한번씩 최신의 업데이트가 나오는 것은 상당히 고무적이라고 생각이 듭니다.

    김명신: 아 그렇군요. 변화 무쌍한 웹 개발 트렌드를 따라가는 것이 쉽지는 않을 것 같다는 생각이 많이 드네요. 그럼에도 불구하고 이번 세션에서 발표하실 내용은 ASP.NET의 고전이라 할 수 있는 웹폼에 대한 내용인 것으로 알고 있습니다.7824_clip_image004_thumb_55AC0446

    김경균: 그렇습니다. 현재까지 ASP.NET을 이용하여 웹 사이트를 개발하시는 분들의 대다수가 여전히 웹폼을 즐겨 쓰시는 것으로 알고 있습니다. 최신 기술 변화의 흐름을 놓치지 않는 것만큼이나 중요한 것이 기존 기술에 대한 계승 발전일터인데요, 이런 관점에서 웹폼은 여전히 현재 진행형인 기술입니다. 최근에는 와우! 하는 새로운 기술은 덜 도입되었지만 개발자들의 피드백을 중심으로 정말 필요한 기술들이 제법 추가되었습니다. 개인적으로는 가려운 부분만을 정확히 찍어서 긁어주는 듯한 느낌을 많이 받았습니다. 아주 많은 부분에서 획기적인 변화가 있었던 것은 아니기 때문에, 제가 이번 테크데이즈 미니 토요 세미나에서 정리해 드리는 부분만 잘 이해하신다면 그것만으로도 충분하지 않을까 생각하고 있습니다.

    김명신: 그렇게 말씀 해 주시니까 그 세션은 꼭 들어가야겠다는 생각이 드는군요. 그럼 토요일 행사장에서 뵙겠습니다. 감사합니다.

    김경균: 감사합니다.

    테크데이즈 미니 토요세미나 안내

  • Korea Evangelist

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

    • 0 Comments

    안녕하세요. 김대우입니다. 이제 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

  • Korea Evangelist

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

    • 0 Comments

    Windows Azure 트래픽 관리자 두번째 포스팅이 이어집니다.

    이번 시간에는 앞에서 소개해 드린 것처럼, 어떤 형태의 서비스가 가능한지, 시나리오를 통해 살펴보는 시간을 가지도록 하겠습니다.

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

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

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

    Windows Azure 트래픽 관리자 – 구축 시나리오

    azure_traffic_manager02_thumb1_thumb.jpg

    (1) 높은 성능을 제공하는 클라우드 어플리케이션을 구성

    (2) 장애복구 계획을 목표로 트래픽 관리자를 구성

    (3) 서비스 중인 클라우드 어플리케이션에 대해 서비스 중지(유지보수 시간) 없이 업그레이드를 제공

    구축 가능한 솔루션은 이렇게 세가지의 시나리오를 생각해 볼 수 있습니다. 그럼 하나씩 하나씩 살펴 보도록 하지요.

    (1) 높은 성능을 제공하는 클라우드 어플리케이션을 구성 - 성능(Performance) 정책

    azure_traffic_manager04_thumb1_thumb.jpg

    가장 많이 일반적으로 사용되는 서비스로 응답속도(Latency) 및 최적화 기반 서비스 입니다.

    일반적인 경우는 위의 그림처럼, "서비스도메인"에 전세계에서 사용자가 접속하지만 매우 느린 속도로 서비스가 되는 부분이지요. 아래의 클라우드 서비스의 장점을 살려 트래픽 관리자를 사용하는 화면을 보면 각 지역에 위치한 데이터센터로 요청이 라우팅되어 최적화된 서비스를 받게 됩니다.

    이 성능 정책이 가장 많이 제가 문의 받고 실제로 사용되는 부분입니다. 사실 쉽게 말씀 드렸지만, 라우팅 정책에는 여러 숨은 기술들이 포함되어 있어요. 상세한 라우팅 방식은 맨 아래의 참고링크 부분에서 더 살펴 보실 수 있습니다.

    (2) 장애복구 계획을 목표로 트래픽 관리자를 구성 - 장애조치(Failover) 정책

    azure_traffic_manager05_1.jpg

    클라우드를 이용할 경우 가능성은 매우 낮지만, 위에서 보시는 것처럼 지역내 서버에 장애가 발생할 경우 사용자가 서비스를 제공받지 못하는 상황이 발생할 수 있지요. Windows Azure 트래픽 관리자는 보시는 것처럼 서비스 상태를 모니터링 하다가 해당 지역내 서버에 장애가 있을 경우 다른 지역으로 트래픽을 라우팅 시킬 수 있습니다. Failover 구성 역시 트래픽 관리자에서 설정이 비교적 단순합니다. 다음 포스팅인 구현 부분에서 상세히 다로도록 할게요.

    (3) 서비스 중인 클라우드 어플리케이션에 대해 서비스 중지(유지보수 시간) 없이 업그레이드를 제공

    지속적인 서비스 유지라는 거창한 이름입니다. 트래픽 관리자는 이렇게 트래픽을 마음대로 주물럭~ 주물럭~ 라우팅 가능한게 특징인데요. 끝점 노드를 개별로 제어가 가능하기 때문에 이런 시나리오도 고려해 보실 수 있습니다.

    image_thumb1_2.png

    예를 들어, 북미와 아시아권에서 서비스 중인 모바일 게임에서 업그레이드가 필요합니다. api.mydomain.com 으로 서비스 되고 있지요. 이제 북미 서버를 업그레이드 하려면 어떻게 할까요?

    image_thumb3_2.png

    이렇게, 북미 지역 서버로의 라우팅을 잠시 중지시키고, 해당 서버에 대해 직접 업그레이드와 테스트를 원하는 형태로 진행합니다.

    물론 서비스는 아시아 지역으로 라우팅되어 계속되고 있지요. 북미 지역 업그레이드 후 노드를 올려 활성화시키고, 아시아 지역 서비스를 업그레이드를 하시면 됩니다.

    image_thumb4_2.png

    업그레이드가 끝나면? 다시 모든 노드를 올려서 서비스를 처리하시면 되지요.

    자 이렇게 간단히, Windows Azure 트래픽 관리자의 서비스 시나리오를 살펴 보았습니다.

    이제 실제로 적용해 볼 시간이네요. Windows Azure의 트래픽 관리자 화면, 어떻게 생겼을까요?

    azure_traffic_manager_thumb1_2.jpg

    Windows Azure 대쉬보드에서 제공되며 보시는 것처럼

    성능, 라운드 로빈, 장애조치(Fail Over) 부하 분산 방법이 제공됩니다. 참고로, 라운드 로빈은 단순 부하 분산으로 요청을 순차적으로 분산하는 방법입니다.

    그럼, 이어지는 포스팅에서 실제 구현 과정을 살펴 보고 마무리 하도록 하겠습니다. 감사합니다.

    클라우드 트래픽 부하 분산 - (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

  • Korea Evangelist

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

    • 0 Comments

    시작하기 전에,

    이 포스팅을 Windows Azure 기반 모바일/온라인 게임 퍼블리싱 사업을 국내외에서 하시는 손대표님께 바칩니다.

    제발 트래픽 때문에 서버가 터질 정도로 우리 서비스가 많이 인기를 끌면 좋겠어요.

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

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

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

    Windows Azure 트래픽 관리자는 왜, 누가 사용하나요?

    기하급수로 폭증하는 사용자-트래픽에 제발 한번이라도 맞아보는게 소원! - 이신 파트너사와 고객사 분들과 이야기 하다 보면 꼭 나오는 이야기가 바로 클라우드/트래픽 관리자 입니다.  클라우드 서비스라면 반드시 전체 아키텍처 스택의 맨 앞에서 고려되어야 하는, 트래픽 분산 / 부하 분산 기술이죠.

    국내의 온라인 게임이나 모바일 게임과 같은 서비스는 물론, 대규모 트래픽 분산부터 현지에 최적화된 글로벌 서비스를 제공하기 원하는 사업자라면 사용이 필수인 서비스입니다.

    국내의 경우도 카카오 플랫폼 기반 모바일 게임은 물론,  해외 론칭을 준비 중인 온라인/모바일 게임사 & 퍼블리셔와 대한민국 대표 기업이자 글로벌 비즈니스를 하는 1위 기업까지 이 트래픽 관리자를 사용하고 있습니다.

    Windows Azure의 트래픽 관리자에 대한 조금 더 깊은 이야기, 이제 시작합니다.

    대규모 트래픽 서비스를 위한 좀더 똑똑해진 DNS들 이야기

    DNS 서비스는 우리가 익히 알고 있는 도메인과 IP를 연결해주는 기술입니다. 하지만, 요즘의 대세는 조금 더 똑똑해진 DNS들이지요. 아시는 분들도 계시겠지만, CDN으로 더 유명한 아카마이의 Terra - Enhanced DNS기업용 솔루션계의 Level 3 커뮤니케이션즈, Dyn의 Managed DNS가 대표적이며, 이 서비스를 클라우드로 제공하고 있는 마이크로소프트의 Windows Azure 트래픽 관리자와 아마존 AWS의 Route 53과 같은 서비스가 바로 이러한 기술입니다.

    DNS 따위에 이런 비즈니스가? 하면서 생소한 분들도 많이 계시겠지만, 이 분야에서의 현재 글로벌 업계는 CDN과 마찬가지로, 기업용 솔루션은 아카마이가 가장 많이 점유하고 있습니다. 하지만, 클라우드의 장점인 "종량제"로 쓴만큼 돈을 내는 형태가 앞으로 더 많아질겁니다. 참고로, 이 기술들의 근간은 모두 LDNS(Local DNS)이지만, 기술이 적용되는 비즈니스 시나리오에 따라 다양하고 유용한 솔루션 형태로 제공이 가능해요.

    Windows Azure 트래픽 관리자 가격 정보

    2014년 3월 기준 가격정보를 살펴 보자면 Windows Azure 트래픽 관리자는 최초 10억개의 DNS 쿼리에 대해서는 100만 쿼리당 900원을, 10억개 초과 DNS 쿼리에 대해서는 100만개당 450원의 월별 과금 정책을 제공하고 있습니다. 트래픽 관리자로 돈 벌 생각 없어 보이죠?

    DNS의 캐싱 기능 등을 고려할 때 일반적으로 100만개 초과하기도 쉽지 않은 대부분의 상황을 고려한다면, 거의 무료로 사용이 가능한 서비스입니다.상세한 내용은 아래 가격정보를 참고하세요.

    Windows Azure 트래픽 관리자 가격정보

    넵. 분명 시장이 있고 수요가 있으며, 조금 더 똑똑한 DNS로 치부하기에는 여러 이야기가 많이 있지요.

    차근차근 살펴 보도록 하겠습니다.

    azure_traffic_manager01_2.png

    Windows Azure 트래픽 관리자 – Traffic Manager – 어디에 쓰는 물건인고?

    마이크로소프트의 Windows Azure 트래픽 관리자는 우리의 서비스에 들어오는 트래픽을 여러 Windows Azure 서비스로 전달해 높은 성능과 가용성, 탄력적인 어플리케이션 서비스를 제공하도록 돕는 서비스 입니다.

    azure_traffic_manager03_2.jpg

    이렇게 보시면 간단하죠. “서비스도메인”에 대해 Trafiic Manage가 Azure 서비스 등으로 라우팅을 시켜 주는게 핵심인 부분이에요.

    사용자의 요청에 대한 트래픽 관리자의 라우팅 처리 절차

    1) 사용자가 클라이언트에서 www.서비스도메인.com 요청

    2) 사용자의 DNS 서버가 등록된 네임서버인 ns.서비스도메인.com에 www 어디냐고 요청

    3) ns.서비스도메인.com 은 CNAME으로 서비스도메인.trafficmanager.net에 있다고 요청전달

    4) trafficmanager서비스는 서비스 정책에 따라 어느 클라우드 서비스가 살아있는지 확인

    5) 여러 Azure 클라우드 서비스의 지역을 확인하고, 어떤 서비스가 사용자의 LDNS 대상 최적의/가장빠른 서비스인지 확인 후 해당 Azure 서비스의 IP 주소를 최종 전달

    자, 이렇게 간략히 Windows Azure 트래픽 관리자에 대해서 살펴 보았습니다.

    이제 조금 더 내려가 보도록 할게요. 시나리오에 따라 어떻게 활용 가능한지 살펴 보도록 하겠습니다.

    LDNS에 대한 추가적인 단상

    LDNS는 지역 기반 서비스에 유용하지만 사용자의 DNS 설정에 따라 좌우될 수 있습니다.

    예를 들어, 구글DNSOpenDNS 등등의 global LDNS를 사용하는 경우, 라우팅에 이슈가 있을 수 있지요. 특정 LDNS 기반 서비스의 지역 제한을 회피하는데 일부 사용자가 설정하기도 합니다. 사용자의 특수성을 고려해 본다면 이슈 꺼리는 아니겠지만, 이런 경우도 있구나 하고 참고 정도 하시면 좋을 듯 합니다.

    클라우드 트래픽 부하 분산 - (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

  • Korea Evangelist

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

    • 0 Comments

    안녕하세요. 김대우입니다.

    이번에 소개해 드릴 내용은 여러번 필드에서 Windows Azure Website를 적용하려는 고객사와 파트너사 분들께 받았던 질문 내용인데요, 간단히 정리해 보도록 하겠습니다.

    Windows Azure Website와 클라우드 서비스는 물론, 가상머신으로 서비스 하실 경우에도 도메인 연결(Custom Domain) 방식은 동일합니다.

    이번 포스팅 내용에 이어지는 포스팅은,  대용량 트래픽 분산 처리 및 응답속도(Network Latency) 기반 DNS 라우팅을 처리하는 Windows Azure Traffic Manager – 트래픽 관리자 – 로 이어지는 내용으로 정리만 간단히 하고 마무리 지을게요.

    나의 도메인을 Windows Azure 서비스에 연결하는 방법 - CNAME
    국내 실정을 그대로 말씀 드리자면, 대부분 국내외 도메인 등록 대행 업체(도메인 레지스트라)나 호스팅사 이용하실 거에요.

    도메인 등록 대행업체나 호스팅사의 도메인 관리 메뉴에 찾아 보시면 네임 서비스 항목에 CNAME 추가 메뉴가 있습니다. 여기에서 www.mydomain.com 을 mydomain.azurewebsites.net  으로 CNAME을 걸어 주시면 됩니다.

    azure_cname_05_2.jpg

    이 화면은 국내 도메인 등록 대행업체인 아이네임* 라는 업체의 메뉴 입니다. 네임서버 메뉴에 보시면 대부분 업체가 이렇게 CNAME 셀프 구성을 제공합니다.

    자체 DNS를 운영하실 경우도 물론, 관리 메뉴에서 CNAME 레코드를 추가해 주시면 됩니다.

    IT 전문가시면서 DNS 서버를 구성한 경험이 있으시고, DNS의 A레코드, CNAME, MX 등에 익숙하시면, CNAME만 보시고도 충분히 처리 가능하실 거에요. 혹시 잘 모르시더라도 A레코드와 CNAME등에 대해서는 간략히 네이버 등에서 검색만 해 보셔도 여러 자료를 보실 수 있을 겁니다. (추억의 nslookup... - MX 레코드를 몰라서 메일서버 구성에 고생하던 그 시절이 생각납니다.)

    참 쉽죠잉~ 이렇게 해서 포스팅 하나를 날로 먹고 끝내고 싶지만 그러면 안되겠죠. 몇 가지 고려 사항이 있습니다.

    왜 Windows Azure는 CNAME을 사용하는가?
    클라우드 환경은 가상환경이고, 서비스의 배포와 변경이 즉각적이며, IP는 물론 네트워크 리소스를 공유합니다.

    - A레코드는 정적 IP 주소에 매핑되나, 클라우드 환경에서는 여러 이유로 IP 주소가 변경될 수 있습니다.

    - Windows Azure Website의 경우 web site를 재생성, 크기 조정에서 “웹 사이트 모드”를 무료(Free)로 바꿀 경우 IP 주소가 변경될 수 있습니다.

    - Windows Azure 클라우드 서비스의 경우 패키지를 배포 제거 하실 경우 등에서 IP 주소가 변경될 수 있습니다. (아래 링크 참조)

    azure_cname_5.jpg

    - Windows Azure Website는 크기 조정 메뉴의 웹 사이트 모드가 공유(Shared), 표준(Standard) 모드일 경우에만 “도메인 관리(Custom Domain)” 설정이 가능합니다.

    azure_cname_02_2.jpg

    - 만약, (저는 권장해 드리고 싶지 않지만) A 레코드를 추가하실 경우에는 먼저, 에서 “awverify.사이트이름.azurewebsites.net”로 포인팅 하는 CNAME을 만들고 이어서 A 레코드를 만들면 됩니다.   

    azure_cname_03_5.jpg

    azure_cname_04_2.jpg

    이렇게, Windows Azure 서비스에 DNS 를 미리 검증시켜 주는 역할을 하게 됩니다.

    마지막 조언을 드리자면, 꼭 CNAME을 활용하세요. - 이후 이어질 클라우드 기반 트래픽 분산 처리 서비스인 Windows Azure Traffic Manager - 트래픽 관리자 - 에서도 활용됩니다.

    서브도메인만 가능한 CNAME, 루트 도메인도 적용하고 싶다면?

    CNAME의 기술적인 제약 사항으로 루트 도메인에 적용이 불가할 수 있습니다.

    예를 들면, ”abc.com” 으로 별칭을 걸 수 없고, “www.abc.com” 서브 도메인만 설정 가능합니다.

    만약 abc.com 의 경우도 www.abc.com으로 보내기 원하신다면 이럴 경우에도 걱정 마시고, 루트 도메인인 abc.com 대해서 HTTP 요청을 www.abc.com 으로 포워드 해 달라고 도메인 등록 대행사나 호스팅사에 요청 하시면 됩니다.

     

    참고링크

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

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

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

    Windows Azure website 과금 관련 정보

    Windows Azure Website에서 custom domain 설정 – 영문

    Custom Domain Names in Windows Azure 호스팅사일 경우 - 영문

    Windows Azure 클라우드 서비스에서 도메인 설정 - Configuring a custom domain name for a Windows Azure cloud service

Page 4 of 119 (593 items) «23456»