Korea Evangelist

Developer & Platform Evangelism, Microsoft Korea

  • 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일 현장에서 뵙겠습니다.

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

     

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

  • Korea Evangelist

    테크데이즈 미니 토요세미나 발표자이신 박용준님을 미리 만나 보았습니다.

    • 0 Comments

    오늘은 마이크로소프트 MVP 이면서 MCT(마이크로소프트 공인강사)이신 DevLec의 박용준 전임 강사님을 모시고 이야기를 나누어 보았습니다.

    김명신: 안녕하십니까? 박용준 님. 호칭은 어떻게 하는 것이 좋을지요?

    박용준: 강사라고 불러주시면 좋겠습니다. 저는 이 호칭이 참 좋습니다.

    김명신: 특별한 이유가 있으신지요?

    박용준: 네. 이건 아주 개인적인 이야기이긴 합니다만, 제가 어린 시절에 쑥스러움이 많아서 누구 앞에 나서는걸 잘 하지 못했어요. 남들 앞에 나서면 말도 잘 하지 못하고 얼굴만 붉어지는 수줍고 내성적인 성격이었습니다. 성격이 그렇다 보니 학창시절에는 누가 저를 반장으로 추천했음에도 손사래를 치고 거절한 적도 여러 번 있고, 군 시절에는 누구나 한다는 선임 견장도 한번 못 달고 제대하였습니다. 그런데 그러던 제가 대학교 졸업 즈음에 어쩔 수 없이 강의를 한번 하게 되었습니다. 거절할 수 있는 상황이 아니었거든요. 나름 열심히 준비를 하였고, 나름 성공적으로 마무리를 할 수 있었습니다. 큰 경험은 아닐지 모르지만 그 일 이후로 많은 부분이 바뀌었습니다. 여러 사람을 대상으로 저의 의견을 피clip_image002[4]력하거나, 제가 알고 있는 지식을 전달하는 것에 대한 희열의 보람을 맛 보았다고 해도 틀리지 않을 것 같습니다. 대략 13~4년 동안의 사회 생활에서, 한 회사에 소속되어 업무를 한 기간이 약1년여 정도이고, 대부분의 기간 동안 프리랜서 개발과 더불어 교육, 강의, 컨설팅 등으로 일을 하고 있던 계기가 되기도 하였습니다. 그렇다 보니 강사라는 호칭이 동경의 대상이었고 동시에 지금도 강사라고 불러주시는 것이 편하고 좋습니다.

    김명신: 지금은 오프라인으로 학원에서 강의하시는 것 보다는 온라인으로 강의를 더 많이 제작하고 서비스 하시는 것으로 알고 있습니다. 처음부터 그러셨던가요? 아니면 어떤 계기가 있으셨는지요?

    박용준: 처음에는 학원 강의를 주로 많이 하였습니다. 주로 컴퓨터 프로그래밍 전문가 과정과 같이 6개월 혹은 1년과 같이 장기간 학생들과 같이 하는 강의가 많았습니다. 전산전공 대학생들이 실무 개발을 익히기 위해서 오는 경우도 많았지요. 그렇게 긴 기간 동안 학생들과 함께하다가 졸업 즈음에 대기업이나 유수 기업에 취직하는 것을 보면 보람도 많이 느꼈습니다. 최근에도 간혹 기술 세미나를 하곤 하는데요 그럴 때 마다 그 때 학생이었던 분들을 자주 뵙곤 합니다. 인사를 미리 하시고 하는걸 보면 나쁜 강사는 아니었나 봅니다. 최근에는 오프라인 강의는 거의 하지 않고 온라인 강의를 제작하고 서비스하는 것에 중점을 두고 있습니다. 강의라는 것이 기록되지 않으면 사라져 버리는 것이고, 동일한 내용을 필요로clip_image004[4] 하시는 다른 분들이 많음에도 재사용될 수 없음이 가장 안타까웠고요. 온라인으로 강의를 한번 제작해 두면, 좀 더 많은 분들이 제 강의를 접하실 수도 있고, 저 또한 같은 내용을 계속 반복할 필요가 없으니 좋은 방법이라고 생각합니다. 저는 이를 약간 우스운 말로 생활이 시스템이고 가상화다라고 이야기 하곤 합니다. 온라인 강의가 실제 저를 대신해 주니까 말이죠. 게다가 온라인을 통한 강의 제작 서비스가 제 개인적인 성향과도 잘 부합하고, 특별히 원거리로 출근을 하지 않아도 되다 보니 가족과 함께 하는 시간도 많이 가질 수 있어 매우 만족하고 있습니다. 회사에 다니시는 분들께서는 느끼지 못하시겠지만, 아이들을 직접 학교에 등/하교 시키는 것이 동경의 대상이기도 하였고, 지금은 제 인생에 큰 보람 중에 한 부분이기도 합니다.

    김명신: 최근에 페이스북에 올리신 글을 보고 깜짝 놀랐습니다. 지금까지 작성하신 동영상의 수가 상당하던데, 총 몇 편이었지요?

    박용준: 제가 지난 10년간 꾸준히 강의 동영상을 제작하다 보니 그 수와 내용이 많은 것은 사실입니다. 2013년을 정리하면서 확인을 해 보았는데, 총 3665개 이더군요. 1년에 365개씩은 만들자라고 계획하였었는데 그 목표는 달성한 것 같습니다.

    clip_image005[4]

    김명신: 그럼 매일 매일 작업을 하시는 건가요?

    박용준: 그렇지는 않고, 하루에 5~6개씩 촬영을 할 때도 있고, 일주일 내내 하나도 촬영하지 않는 경우도 많이 있습니다. 벽보고 강의는 제가 국내 일인자임에 분명한 것 같습니다.

    김명신: 개수도 개수지만 그 내용도 상당히 방대할 것 같습니다.

    박용준: 아주 오래 전에 촬영하였던 C# 1.0이나 ASP관련 내용도 있고요, Windows Server, SQL Server, ASP.NET 그외 HTML5, jQuery, AngularJS 등등 그 주제와 내용이 매우 다양합니다. 국내의 경우 하나의 주제로 전문성을 가져가면서 강의하기가 쉽지 않기 때문에, 다양한 주제의 강의를 하게 되고, 이 때문에 깊이나 전문성이 결여되는 문제가 발생하기도 하는데요, 저 같은 경우에는 특별히 ASP.NET과 같은 마이크로소프트 웹 개발 기술에 대한 전문성을 놓치지 않기 위해서 특별히 더 신경 쓰고 노력하는 편입니다.

    김명신: 그렇게 많이 작성하신 동영상들은 어디서 살펴볼 수 있을까요?

    박용준: 제가 지인과 함께 운영하고 있는 http://www.devlec.com/ 이라는 온라인 프로그래밍 전문교육 사이트가 있습니다. 여기서 모두 살펴보실 수 있습니다. 국내에 온라인으로 프로그래밍이나 OA과정을 다루는 사이트가 꽤 있는 것으로 알고 있는데요. 저희는 프로그래밍 전문 사이트이기 때문에 그 넓이와 깊이가 다른 곳과는 확연히 차이가 있습니다.

    김명신: 저도 며칠 전에 살펴보았는데, 첫 페이지에 SignalR에 대한 강의가 올라가 있더군요.

    박용준: 네, 최근에 SignalR에 대한 촬영을 했습니다. ASP.NET SignalR은 상당히 놀랍고도 실용적인 기술입니다. 제가 봐도 신기할 정도입니다. 먼저 SignalR은 굉장히 쉽습니다. 실제로 web 기술을 기반으로 chatting 서버를 작성하기 위해서 4~5줄의 코드면 핵심 코드를 작성할 수 있을 정도입니다. 뿐만 아니라 기존에 양방향 통신을 수행하기 위해서 사용하고 있는 WebSocket, Server Sent Events, 영구 프레임(Forever Frame), Ajax 롱 폴링(long polling)등을 모두 아우르는 기술입니다. 특정 기술 하나만을 사용하는 것이 아니라, 클라이언트의 지원 내용을 확인하여 최초 협상 시에 가장 효과적인 기법을 선택하도록 되어 있습니다. 기존 기술들이 브라우저의 지원 여부, 클라이언트 개발 환경의 특성 등으로 인해 좋은 기술이 나와도 쓰기가 어려웠는데, SignalR을 사용하면 각각의 환경에 부합하는 최적화된 방법이 자동으로 선택됩니다. 개발자가 그 각각을 다루어야 할 일이 없죠. 이는 다양한 형태의 Web 기반 기술을 이용한 양방향 통신 메커니즘을 말 그대로 통합하는 효과가 있습니다. 이는 마이크로소프트의 이전 기술 중에 WCF가 Unified Communication 메커니즘으로 다양한 통신 규격을 하나의 방식으로 프로그래밍 하게 만들었다는 장점에서 진일보 하여서 Web 기술을 근간으로 하는 Unified Communication 메커니즘이라고 정리해 볼 수 있겠습니다.

    김명신: SingalR의 이 같은 장점에 대해서는 저도 상당히 고무적이라고 생각하고 있습니다. 게다가 다양한 브라우저를 지원하고, 다양한 개발 언어를 지원하기 때문에 더더욱이나 활용성이 높은 것 같습니다. 예전에 mms, RTCP/RTSP 등의 미디어 자체적인 미디어 전송 기술들이 최근에는 http를 이용하는 웹 기술로 발전/진화한 것은, 웹 기반 기술을 지원하는 다양한 장치와 인프라들을 그대로 사용하면서, 손쉬운 Scale Out이 가능한 것으로 알려져 있습니다. SignalR 또한 Web 기술을 근간으로 하기 때문에, 단일 서버뿐 아니라 다중 서버로의 확장이 용이할 것으로 예상되는데요

    박용준: SignalR은 단일 서버에서 수행될 때에도 상당히 고성능으로 동작하기 때문에, 한대의 서버만을 이용해도 상당한 성능을 유지할 수 있습니다. 외부자료 중에는 초당 10만건의 메시징을 수행하였다는 보고도 있습니다. 하지만 그 이상을 지원하기 위해서는 말씀하신데로 Scale Out이 중요한 요소입니다. SignalR은 개발시부터 이에 대한 고려가 있었기 때문에 다중 웹서버로 구성한다 해도 기존 코드를 변경해야 할 내용이 극히 적고, 실제 그에 대한 대응을 수행하기 위해서도 코드 한두 줄로 구성 설정을 변경할 수 있습니다.

    김명신: 그 정도까지 극단적으로 업무를 단순화 할 수 있는지는 저도 처음 알았네요. 최근 마이크로소프트의 웹 기술들이 플랫폼 기술로 거듭나고 있는 것으로 보입니다. 이에 대해서 말씀 해 주실만한 내용이 있으실까요?

    박용준: 그렇습니다. 최근 ASP.NET을 중심으로 한 마이크로소프트의 웹 기술은 기존의 웹페이지 제작기술을 모던하게 변화 발전시키는 것과 더불어 웹 서비스 플랫clip_image007[4]폼으로 그 영역을 확장해 나가고 있습니다. 최근에 가장 눈에 띄는 기술이라고 하면 역시 ASP.NET WebAPI와 SignalR 등을 꼽을 수 있을 텐데요. 두 가지 모두 이 범주에 속하는 기술이라고 볼 수 있고, 이러한 기술들이 시장에 미칠 파급효과는 상당하다고 생각하고 있습니다. SignalR과 새로운 기술은 처음부터 기존 방식을 바꾸는 게 아닌 레고 블록 맞추는 것처럼, 기존에 구축해 놓은 시스템에 추가적으로 필요한 부분만을 적용하여 개선해 나가는 방식으로 좀 더 쉽게 접근하실 수 있으리라 봅니다.

    김명신: 이번 미니테크데이즈 토요세미나가 바로 WebAPI와 SignalR 뿐 아니라 ASP.NET 성능 최적화 까지를 다루고 있습니다.

    박용준: 최근 SignalR과 WebAPI가 버전 업데이트가 되었고, 상당히 많은 부분들이 개선되었습니다. 이 기술들을 살펴볼 수 있는 가장 적기가 아닌가 생각됩니다.

    김명신: 이번 미니테크데이즈를 통해서 SignalR의 장점을 유감없이 보여주실 것 같이 기대가 큽니다.

    박용준: 네, 최선을 다해서 준비하도록 하겠습니다. 감사합니다.

Page 7 of 121 (605 items) «56789»