Korea Evangelist

Developer & Platform Evangelism, Microsoft Korea

  • 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

  • Korea Evangelist

    기다림은 오직 40ms - Windows Azure의 더 빨라진 네트워크 응답속도와 넓어진 대역폭! - 일본 데이터센터 공식 발표

    • 2 Comments

    안녕하세요, 김대우입니다.
    이번에 소개해 드릴 내용은 Windows Azure를 사용하는 분들께 희소식일 것 같아요. 바로 더 빨라진 응답속도와 쾌적한 서비스를 제공하는 일본 데이터센터 공식발표 소식입니다.

    지난 2013년 12월 공식 발표된 남미지역 - 브라질 데이터센터에 이어 2014년 2월 25일, 일본 데이터센터 공식 서비스 발표 소식인데요. 일본 쪽 서비스는 물론 국내에서 사용할 경우에도 쾌적하게 사용하실 수 있을 것 같아요.

    먼저, 2014년 2월 25일 공식 발표된 내용부터 살펴 볼게요.
    Windows Azure services now generally available in new Japan cloud region
    일본 지역은 두 개의 센터가 제공되고 있으며, 토쿄 북쪽 지역인 시타마(Japan East-일본 동부)와 오사카 지역(Japan West-일본 서부)에 데이터 센터가 있습니다. 사실 우리에게 어디에 센터가 있는지는 중요하지 않지요.

    우리의 관심사는 오직 네트워크 응답속도(Latency)와 대역폭(Bandwidth)!!!

    바로 일본 데이터센터를 사용해 보기 위해 Windows Azure 대쉬보드에서 확인부터 들어가 보겠습니다.    
    azure_japan_select01.jpg

    만만한 Windows Azure 웹 사이트,  지역 정보를 봐 보시면~ 넵~ 일본 동부와 일본 서부가 보입니다. – 다른 클라우드 서비스에서 역시 선택 가능합니다.
    (곧 들어온다는 한국 데이터센터! 어서 빨리 한국이 리스트에 보이면 좋겠습니다.)    
    azure_japan_select02.jpg
    바로 두 개의 웹사이트를 생성해 보았구요. 이어서 바로 Latency 체크를 진행해 보도록 할게요. – 만만한 녀석부터 시작!   

    먼저 테스트한 곳은 일본 서부 데이터센터의 Azure 웹 사이트입니다. 

    azure_japan_center01.jpg

    회사인지라 전반적인 모니터링을 위한 PRTG를 해 보기는 어렵네요. PRTG나 Apache JMeter 를 사용하면 조금 더 전문적인 환경에 대한 체크도 가능하다고 합니다.  저는 sysinternal의 PsPing을 이용해 현재 서비스 중인 웹사이트 - 80포트로 테스트를 해 봤습니다. 익숙하시다면  wget등을 쓰셔도 되겠지요. 
    Sysinternals – PsTools의 PsPing
    넵! 이렇게 일본 서부 데이터 센터가 40ms 정도의 쾌적한 안정적인 응답속도를 보여 주네요.

    이 정도면 천천히 동아시아나 동남아시아 데이터센터에서 가상머신이나 서비스들을 하나씩 옮겨와도 나쁘지 않을 것 같아요.

    바로 이어서, 동부 데이터센터 역시 테스트해 보았습니다.

    azure_japan_center02.jpg
    마찬가지로, 일본 동부 데이터 센터도 40ms 정도의 쾌적한 안정적인 응답속도를 보여 주네요.

    위의 일본 지역 Windows Azure website들은 저도 응답속도 테스트 차원에서 계속 유지하려고 합니다. psping으로 바로 테스트 해 보실 수 있을 거에요.

    가끔식 응답속도가 순간적으로 내려가긴 하지만, 40ms 정도면 국내에서 서비스해도 무리가 없을 정도로 쾌적할 듯 합니다.
    일본 서비스를 계획하시는 분들은 더욱 빠른 일본내 서비스가 가능하겠지요. – 정확한 추가 테스트는 자사에서 테스트하시는 네트워크 모니터링 도구로 다양한 지역과 구축된 망에서 테스트 해 보시면 되실거에요.

    대역폭의 경우도 테스트를 해 보았는데요, 국내 서비스를 사용하는 정도의 빠른 전송 속도를 확인해 보실 수 있습니다.

    클라우드의 장점인 확장성과 가용성에 빠른 응답속도까지! 더 빠른 Windows Azure 서비스를 기다렸던 분들께 희소식이 되실 것 같아요.
    혹시, 일본 데이터센터 자체에 대한 자연재해 등 여러 걱정이 되실 수도 있으실 것 같아요.

    Windows Azure는 저장소에 대해 Geo-Replication(지역 복제)를 제공 합니다. Windows Azure는 저장소의 안정성을 위해 하나의 데이터센터 내에 3중화된 저장소를 제공하고, 데이터를 같은 지역(Region)의 다른 데이터센터로 복제하는 설정을 제공합니다.

    다른 데이터센터로 복제하는 기능이 바로 Geo-Replication 입니다. 이런 경우라면 일본에서 서비스 하더라도 마음 놓으셔도 좋을 것 같아요. – 물론, 우리에게 최선은 어서 빨리 국내에도 Windows Azure를 마음껏 사용 가능한 데이터센터가 들어오는 것이겠지요!!!

     

    지역 복제 관련 참고 자료 :
    Geo Replication for Windows Azure Storage
    Introducing Geo-replication for Windows Azure Storage - 스크린샷은 조금 오래 되었지만, 내용 참고 하시면 좋을 것 같아요.

    많은 도움 되시길 바랍니다.
    [참고링크]
    Windows Azure services now generally available in new Japan cloud region
    Expanding Windows Azure Capacity – Brazil

    Apache JMeter
    PRTG
    Sysinternals – PsTools의 PsPing
    Geo Replication for Windows Azure Storage
    Introducing Geo-replication for Windows Azure Storage

  • Korea Evangelist

    테크데이즈 미니 토요세미나 발표자이신 마이크로소프트 GBS 엔지니어분들을 미리 만나 보았습니다

    • 0 Comments

    오늘은 한국마이크로소프트 내의 기술의 메카라고 할 수 있는 GBS(Global Business Service)의 Developer Support Engineer 분들과 함께 이야기를 나누어 보았습니다.

    김명신: 안녕하십니까? 김순근, 이진헌, 이정철님. 오늘은 만나 뵙기가 어렵지 않아서 같이 모셨습니다. 거의 매일 얼굴을 뵙는 분들과 인터뷰를 하려니 참 어색하긴 하네요. 먼저 GBS(Global Business Service) 라는 부서가 어떤 업무를 하는지 간략히 소개 해 주실 수 있을까요?

    clip_image002김순근: 저희 부서는 마이크로소프트의 제품과 플랫폼에 대하여 기술 지원을 하는 부서라고 간단히 말씀 드릴 수 있겠습니다. 마이크로소프트의 다양한 소프트웨어 제품에 대한 전문성을 갖춘 100여명의 엔지니어들이 주로 기업 고객을 대상으로 기술 지원을 합니다. 마이크로소프트의 GBS가 다른 회사의 기술 지원부서와 확연히 차이를 보이는 것은 지원의 범위를 단순히 저희가 개발한 제품으로 한정 짓지 않고 개발 플랫폼도 지원 한다는 점일 것입니다. 즉, 기업 내에서 저희 플랫폼을 근간으로 개발한 응용 프로그램에 문제가 있거나 자문이 필요한 경우에도 저희가 도움을 드릴 수 있습니다. 이는 마이크로소프트가 가지고 있는 개발자 중심의 기업문화와도 맥이 닿아 있다고 할 수 있겠습니다. 또한 기업 내에 특정 솔루션이나 기술 도입을 검토 하실 때에도, 저희 부서가 그 기업에 가장 적합한 제품, 기술, 개발 방법 등을 자문 하기도 합니다. 뿐만 아니라 마이크로소프트 제품의 문제가 있다면 본사와 협업하여 문제를 해결하기도 하고, 향후 제품의 방향성을 모색할 때 한국의 다양한 상황을 전달하여 제품의 완성도를 높이기 위한 역할을 담당하고 있습니다. 아무래도 업무의 성격상 실제 국내 기업이 겪고 있는 기술적인 문제를 몸소 체험하는 부서이기도 합니다.

    김명신: 실제로 개발 현업의 목소리를 가장 크게 들으실 수 있는 부서이니만큼 실제 기업들의 IT 현황이나 애로사항을 가장 잘 아실 거라 생각이 듭니다. 수년간 근무해 오시면서 기업 고객들의 변화들을 느끼신 부분이 있을지요?

    이정철: 실제로 IT분야의 특성상 하루가 다르게 빠른 속도로 개발 환경, 개발 플랫폼, 개발 방법론 등이 변화에 변화를 거듭하고 있는 것이 사실입니다. 서버 측은 가상화 기술로 큰 변화를 맞이 하였고요, 클라이언트 측도 Rich 클라이언트, Thin 클라이언트를 오가는 형태로 변화/발전하고 있습니다. 하지만 이러한 변화를 적시에 도입하기는 상당히 어려운 것이 사실인데요, 기업 내에 유기적으로 결합된 다양한 솔루션들로 인해 운영과 개발의 복잡도가 계속 증가하고, 기존에 개발/운영 중인 시스템과의 상호 운용성도 배제할 수 없기 때문일 것입니다.

    이진헌: 실제로 웹 기술을 중심으로 살펴 보아도 변화의 양상이 얼마나 빠른지 몸소 체험할 수 있는데요. 정적 페이지만을 서비스하던 시대를 돌이켜 보지 않더라도, 동적으로 페이지를 생성하는 서버 측 기술이 중심이 되었다가, 플래시나 실버라이트와 같은 RIA 기술에서 다시 순수 웹 표준을 지향하는 HTML5로 변화에 변화를 거듭하고 있지요. 이 과정에서 혼돈스러울 만큼 많은 버즈워드(Buzz Word)들이 양산된 것도 사실입니다. 하지만 최근에는 HTML/CSS와 JavaScript에 대한 기술들이 구현기술의 중심으로 빠르게 재편되어 가는 느낌을 받습니다. 실제로 이와 관련된 기술의 발전과 변화를 지켜 보는 것만으로도 흥미롭습니다.

    김명신: 다양한 디바이스의 출현과 모바일 환경의 도래 그리고 다양한 운영체제와 플랫폼의 등장으로 인해 이러한 기술 변화가 가속화된 면이 있지 않나 싶습니다. 하지만 실제로 기업 고객들은 이러한 웹 기반 기술을 도입하는데 상당히 어려움을 겪는 것으로 알고 있습니다.

    김순근: 기술적인 배경과 발전과정을 돌이켜 보면 쉽게 이해가 되는 부분이기도 합니다. 가장 큰 문제점은 기업 내의 요구사항을 완벽히 해결 해 주는 단일 기술은 존재하지 않는다는 원칙적인 문제입니다. 저마다의 기술은 나름의 활용 용도와 방향성을 가지고 있는데 이를 정확히 파악하여 적재적소에 올바른 기술을 사용하기가 매우 어렵다는 것이지요. 예를 들어 웹 페이지 구축 붐이 한창 불던 시기에 고객의 요구사항은 기존에 사용하고 있던 설치형 응용 프로그램과 동일한 형태의 웹 페이지를 구축해 달라는 것이었습니다. 이는 사실 웹이라는 기술의 활용 용도나 방향성과 그 한계를 사전에 충분히 파악하고 기술을 도입하였다기 보다는, 웹이라는 유행에 편승하였다고 볼 수 있습니다. 고객 요구사항에 맞추다 보니 웹 브라우저만으로 구현할 수 없는 부분을 ActiveX와 같은 플러그인 모듈에 의존할 수 밖에 없었죠. 웹 기술이 가져다 주는 장점들, 예를 들면 설치가 필요하지 않다거나 버전 업그레이드가 편리하다는 것과 같은 부분이 외부 플러그인 모듈에 의존적이 되다 보니 의미가 많이 퇴색되지 않았나 생각합니다. 보안 문제로 최근 트렌드는 플러그인 모듈에 대한 자원 접근을 제한하는 방향으로 가고 있는데 기존에 개발된 모듈들이 호환성 이슈를 발생시키고 최신 웹 기반 기술을 도입하는데 장애 요인이 되는 경우가 많습니다.

    이진헌: 사실 이러한 관점에서 브라우저 플러그인 기술을 이야기 하지 않을 수 없는데요. 최근 들어 많은 기업들이 겪고 있는 브라우저 호환성 문제라던지 운영체제 업그레이드의 문제들이 인터넷 익스플로러의 브라우저 플러그인 기술인 ActiveX와 직간접적인 연관성이 있습니다. 인터넷 익스플로러뿐 아니라 크롬, 사파리, 파이어폭스와 같은 웹 클라이언트들은 사실 기술적인 한계와 방향성이 매우 명확합니다. 그럼에도 많은 기업들이 웹 기술을 도입할 때, 그러한 한계를 간과한 면이 없지 않다고 생각하고 있습니다. 실제 기업체의 요구사항들이 표준 웹 기술로는 구현이 어렵거나 불가능하기 때문에, ActiveX와 같은 기술을 사용하지 않을 수 없었던 것입니다. 그런데 이제는 이러한 비표준 브라우저 플러그인 기술로 인해 기업체 내에 신규 기술의 도입과 확산을 심각하게 저해하고 있다고 볼 수 있겠습니다. 사실 ActiveX 라는 기술을 그 자체로 좋고 나쁨을 판단하는 것은 우려스럽습니다. 단지 ActiveX와 같은 기술로 무엇을 만들었느냐 하는 것이 문제라면 문제일 것입니다.

    이정철: 인터넷 익스플로러의 이전 버전들이 비표준 기술을 사용하고 있다거나 웹 표준 규격을 준수하지 않는다고 하여 끊임없이 논란이 되고 있는데요. 이 부분은 전후 관계가 바뀐 면�� 없지 않습니다. 인터넷 익스플로러가 많이 사용되던 시기에는 HTML4나 XHTML 정도가 마크업 언어로 많이 사용되었던 시기였고, 브라우저가 좀 더 많은 기능을 수행해줄 것을 요구하는 목소리가 높았습니다. 이러한 요구사항을 브라우저에 반영하였던 것이 비표준 규격 기술을 도입한 이유 중 하나인 것도 사실입니다. 하지만 인터넷 익스플로러 9버젼 이후부터는 빠른 속도로 신규 표준을 준수하는 방향으로 버전업이 이루어지고 있고, 최근 출시된 IE11은 거의 대부분의 표준 규격을 준수하고 있습니다. 게다가 F12 개발자 도구는 꼭 한번 써보시라고 말씀 드리고 싶습니다.

    김명신: 앞서 말씀해 주신 것처럼 시장은 빠른 속도로 HTML5와 기술을 널리 활용하는 쪽으로 방향을 잡고 있는 것 같습니다. 스티브 잡스가 HTML5를 외쳤기 때문이다라는 우스갯 소리도 있는데요. 이처럼 빠르게 HTML5가 자리매김 할 수 있었던 이유가 무엇일까요?

    김순근: 네! 스티브 잡스가 외쳤기 때문이죠. 하하. 하지만 사실 그 보다 다양한 폼팩터와 다양한 디바이스의 출현이 HTML5의 사용을 가속화 시켰다고 보는 측면이 좀 더 올바른 답이 아닐까 싶습니다. 각 플랫폼별로 앱을 만들기보다는 표준화된 단일 웹 애플리케이션으로 다양한 디바이스와 운영체제의 차별성을 지원하는 것이 최적의 방법이라는 생각을 하게 되었고, 결국 HTML5/JavaScript 등에 대한 기술에 관심이 높아질 수 밖에 없었던 것이겠지요.

    이진헌: 하지만 HTML5가 브라우저 플러그인 기술을 완전히 대체할 수는 없습니다. HTML5은 브라우저 외부의 시스템과 상호운용해야 하는 작업을 극히 제한하고 있기 때문에 브라우저로 할 수 있는 일의 범위가 엄청나게 확장되지는 않습니다. 단지 표준을 근간으로 여러 브라우저에서 공통적으로 사용할 수 있도록 잘 정리되었다는 측면이 더욱 강하지 않을까 싶습니다. 약간 다른 관점으로 이처럼 웹 기술이 각광 받는 이유가 JavaScript 수행엔진의 성능 향상과도 관련이 있다고 생각합니다. Internet Explorer의 Chakra, Chrome의 V8, Safari의 Nitro 등의 최신 스크립트 수행 엔진들은 성능이 이전에 비해 괄목상대하였다고 말할 수 있을 정도 입니다. 스크립트 성능을 기반으로 한 다양한 시도들의 결과가 지금과 같은 클라이언트측 웹 기술의 비약적인 발전을 가져왔다고 생각합니다. JavaScript 라이브러리나 프레임워크들이 폭 넓게 사용될 수 있는 기반이 되었고, 이를 통해 웹 클라이언트에서 수행하는 기능과 업무의 내용이 비약적으로 늘고 있습니다. 예전에는 웹 서버에서만 처리하던 작업의 상당 부분을 웹 클라이언트로도 처리할 수 있게 된 것이지요. 또한 웹 서버는 그 구조상 중앙 집중식으로 구성될 수 밖에 없는데, 이처럼 업무를 클라이언트 측으로 내려 보내면, 컴퓨팅 리소스를 균형적으로 쓸 수 있는 장점도 얻게 됩니다.

    김명신: 이번 2월15일에 있을 세션이야기도 해보았으면 합니다. 웹 클라이언트 기술을 중심으로 주제와 세션을 구성해 주셨는데요. 각 세션에서 어떤 내용들을 말씀해 주실지 살짝 이야기해 주실 수 있을런지요?

    김순근: 제가 맡은 세션의 주요 테마는 HTML5와 JavaScript가 될 것 같습니다. 모던 웹 애플리케이션 개발의 중심에 있는 HTML5와 JavaScript의 발전과 활용분야와 더불어 주요 개발 언어로서 Visual Studio가 지원하는 기능들을 같이 살펴볼 생각입니다. 웹 클라이언트 개발을 위해서 다양한 도구들을 사용하실 수 있겠지만, Visual Studio에 신규로 추가된 기능들을 살펴보면 어느 IDE 보다 훌륭한 기능들이 많이 포함되어 있습니다.

    이진헌: 저는 주로 JavaScript의 최적화 기법에 대해서 말씀 드리려고 하는데요. JavaScript의 수행엔진이 엄청난 개선을 이루었음에도 우리가 계속해서 성능문제에 직면할 수 밖에 없는 문제에 대해서 말씀 드리고, JavaScript 프로그래머들이 반드시 알아야 할 코드 패턴이나 코딩 스타일 등을 실제 사례와 Demo 중심으로 알아보려고 합니다.

    김명신: 저는 개인적으로 이정철 님께서 발표해 주실 Internet Explorer 11 호환성과 웹 표준이라는 주제에 관심이 많이 가는 것이 사실입니다.clip_image004

    이정철: Internet Explorer 11에서 올바르게 동작하는 웹 응용 프로그램을 개발하는 방법과 기존에 개발되어 있는 웹 응용 프로그램들을 Internet Explorer 11에서 올바르게 수행할 수 있는 방법들을 다룰 생각입니다. 다양한 호환성 문제들이 발생할 가능성이 있고, 그 각각에 대해서 어떻게 대응하는 것이 좋은지를 실 사례와 엮어서 말씀 드리려고 합니다. 또한 Internet Explorer 11에서 무엇이 어떻게 바뀌었으며, 변경된 내용이 어떤 영향을 줄 수 있는가에 대해서 이야기를 드리려고 준비하고 있습니다.

    김명신: 장시간 인터뷰에 응해 주셔서 감사 드립니다. 2월 15일 현장에서 뵙겠습니다.

    김순근, 이진헌, 이정철: 감사합니다.

     

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

Page 7 of 122 (606 items) «56789»