호스팅2008. 11. 17. 11:36

 웹에서 비디오를 서비스하는 것은 가장 일반적인 시나리오 중의 하나가 되었습니다. 상품에 대한 설명 비디오, 동영상 교육 비디오, 광고, UCC 동영상, 뮤지비디오 등 정말 다양합니다.

그런데 한가지 이슈가 있죠. 네트웍 대역폭은 IT에서 가장 비용이 많이 드는 항목 입니다. 또한, 고화질을 원한다면 그 비용은 훨씬 더 비싸지죠.

그렇다면, 위와 같은 동영상을 호스팅 하는 방법과 그 비용을 줄일 수 있는 방법에 관심이 갈 수 밖에 없을텐데요, 그 부분을 오늘 설명드리도록 하겠습니다.

1. 무료 미디어 호스팅 서비스를 사용하는 방법
    - YouTube, 마이크로소프트 Silverlight 스트리밍 서비스, NHN의 블로그에 연계하는 방법 등 다양하죠. 즉, 비디오 컨텐츠를 다른 회사의 네트웍을 이용해서, 그 회사가 대역폭 비용을 내도록 하는 방법이죠. 그 회사는 광고등으로 수익을 얻게 되는 방식 입니다. 마이크로소프트의 Silverlight 스트리밍 서비스는 10G의 컨텐츠까지 업로드할 수 있고, 한달에 5TB까지는 무료로 다운로드 가능하도록 제공 되는 서비스 입니다. (최대 1.4 Mbps Bit-rate 제공)

2. 자체 서버에서 미디어를 호스팅 하는 방법
  
- 미디어에 인증을 부여하고 싶거나, 큰 동영상을 서비스하는 경우, 또는 비디오에 광고를 넣고 싶은 경우에는 직접 호스팅을 하고 싶어질 겁니다. 컨트롤을 해야 하기 때문이죠.

이때는 두가지 옵션이 있습니다.
    1) 스트리밍 서버 시나리오
       . 스트리밍 시나리오에서는 클라이언트 (Silverlight, 윈도우 미디어 플레이어, 플래쉬 등)가 스트리밍 서버에 연결을 하게 됩니다. 스트리밍 서버가 비디오 스트림을 내려 보내고, 사용자는 앞으로 가거나 뒤로 돌려보기, 정지, 멈춤 등을 자유롭게 할 수 있습니다. 사용자가 브라우저를 닫거나, 다른 페이지로 이동하면 비디오 스트림이 자동적으로 데이터 보내는 것을 멈추게 되죠.
Windows Media Services (WMS)는 윈도우에서 무료로 다운받아 사용할 수 있는 스트리밍 서버이고, 윈도우 미디어 플레이어나 크로스 플랫폼 기능이 제공되는 Silverlight 등의 클라이언트를 사용할 수 있습니다. 웹에서 비디오 스트리밍을 제공할 때 가장 확장성이 뛰어나고 비용 효율적인 방식이며, 온디맨드 스트리밍, 또는 실시간 스트리밍 등의 방식으로도 사용될 수 있습니다. 또한, Windows Server 2008 Web Server 에디션에서도 구동 가능합니다.

   2) 프로그레시브 다운로드 시나리오
       . 프로그레시브 다운로드 시나리오에서 클라이언트 (플래쉬, Silverlight)는 웹서버에 직접 연결되어 비디오를 다운로드 받기 시작하며, 충분한 양이 다운로드 되면 바로 플레이가 가능합니다. 이 방식의 장점은 웹서버에 설정하는 것이 정말 쉽습니다. 웹서버에 해당 미디어를 복사한 후, URL 주소만 정해지면 클라이언트 비디오 플레이어가 플래이 합니다. 웹서버에 설정이 필요없고, 스트리밍 서버 셋업등의 과정이 불필요합니다.

프로그레시브 방식의 단점은 웹서버가 최대한 빨리 파일이 다운로드 한다는 것입니다. 사용자가 사이트에서 비디오 보기를 클릭하면 웹서버가 클라이언트로 해당 파일을 최대한 빠르게 보내기 시작합니다. 사용자가 처음부터 끝까지 비디오를 본다면 별 문제가 없지만, 비디오를 보다가 중간에 멈추거나, 다른 페이지로 옮겨 가면 보지도 않는 파일이 다운로드가 된다는 불합리한 부분이 있습니다. 보지도 않는데 다운로드 되는 내용이 수 메가바이트나 된다면, 그 만큼의 돈을 낭비하고 있는 셈이 되는거죠.

3. 그래서, IIS7.0 비트 레이트 Throttling 모듈 (Bit Rate Throttling Module)이 있습니다.
     - 해당 모듈은 미디어 유형에 관계없이 Bandwidth, 즉 대역폭의 낭비를 막아줍니다. 최초로 마임타입 확인 후, 파일에 대해 Bit-rate 인코딩을 한 후 최초 20초간 플레이 할 수 있는 양의 미디어를 최대한 빠르게 전송합니다. 일단 20초 만큼의 미디어가 다운된 이후 부터는 Bit Rate Throttling 모듈이 전송되는 양을 제어하기 시작합니다. 그러면서, 클라이언트가 플레이어를 멈추거나 다른 페이지로 옮겨가는 것을 모니터링 하다가 사용자가 시청을 멈추는 순간 자동적으로 파일 보내기를 멈추게 하는 역할을 합니다.

예를들면, 35MB짜리 비디오 파일이 500Kbps의 속도로 인코딩되어 상영되면, IIS는 20초에 해당하는 만큼의 파일을 즉시 내려보낸 후 (20초 * 500Kbps, 1.25MB), 이후에는 초당 500Kbps의 컨텐츠를 내려보냅니다. (20초 만큼의 버퍼만 갖도록 유지, 사용자가 보다가 버퍼링이 일어나지 않도록 하기 위함)

만약, 1분 후에 사용자가 비디오 보기를 멈추거나 다른 페이지로 옮겨 가면, IIS가 상황을 인지하고 컨텐츠 전송을 멈추게 됩니다. IIS는 단지 80초에 해당하는 비디오만 다운로드 했기 때문에 전체 35MB 중 (5M, 즉 80초 * 500kbps)의 대역폭만 사용한 셈이 되는 것이죠. 이 30MB가 수백번 반복 된다면 대역폭, 즉 비용을 엄청나게 절약할 수 있게 되는 것입니다.


  • Bit Rate Throttling Module Setup
  • Bit Rate Throttling Configuration Walkthrough
  • Bit Rate Throttling Extensibility
  • ScottGu's의 블로그를 참고하여 글을 정리하였습니다.

    Posted by 조이트리
    아키텍트2008. 11. 7. 14:55

    온실가스, 탄소배출량 절감 등의 그린 IT 개념이 등장한지 벌써 꽤 많은 시간이 지난 것 같습니다. 지금까지 그린 IT하면 서버, 네트웍 장비, 스토리지 등의 저전력 하드웨어를 통해서만 가능한 것처럼 인식되었습니다. 하지만, 마이크로소프트는 소프트웨어를 활용한 그린 IT가 가능한 전략을 가지고 있고, 내부적으로 적용하여 효과를 얻고 있습니다. 이름하여, 그린 컴퓨팅 전략 입니다.

    대한민국의 총 전기 생산량이 100이라고 가정하면, 화력발전을 통해 얻어지는 전기가 몇 정도 될까요? 놀랍게도 63.1 정도, 즉 63%에 육박합니다. 화력발전은 석탄, 석유, 천연가스를 태워서 물을 끊인 다음 터빈을 돌려서 전기를 생산합니다. 국내 보령화력발전소의 경우 하루 약 3만톤의 석탄을 사용하고, 24시간에 7만3천톤의 이산화탄소를 배출합니다. 이 정도의 이산화탄소를 분해하려면 하루에 잣나무 2,238만 9400그루를 심어야 한다고 하죠. 엄청나지 않습니까? 결국 나무로는 해결이 불가능 합니다. 우리가 할 수 있는 건 전기 사용을 줄이는 방법이 최선이라고 할 수 있죠. 마이크로소프트가 사용하는 전략은 크게 3가지 입니다.

    줄이고, 관리하고, 다시 생각하자

    1. 줄이고
        - Windows Server 2008은 Windows Server 2003에 비해 10% 에너지 효율성 ↑
        - 가상화를 통한 자원 최적화
           . 가상화 ROI 계산 도구 (무료)
        - 가이드 및 교육
           . Assessment & Planning Toolkit (무료) : 도구를 통해 전원관련 설정 가이드 제공
           . 데이터센터 베스트 프랙티스 제공

    2. 관리하고
        - 에너지 낭비요인 줄이기 "측정할 수 없으면 개선할 수 없다"
        - 10~30% 서버는 아무일도 하지 않고 전원을 공급받는 상태 (미국, Uptime Institute 조사) 
        - System Center Configuration Manager, Virtual Machine Manager, Operation Manager등

    3. 다시 생각
        - 환경 오염을 줄이고, 생산성 향상 시키는 방안을 늘 고민하고 적용하려고 해야 함

    마이크로소프트가 위의 전략에 의해 실제 운영환경의 물리적인 서버, 477대를 16대의 서버로 줄여 약 2백만불 (24억)의 비용 절감 효과, 19TB의 디스크 공간을 8TB로 줄여 11TB의 절감 효과, 30개의 Rack을 단 2개로 줄였으며, 525 암페어의 전력 사용량을 8 암페어로 줄이는 효과를 직접 체험하였음

    위와 같은 노력이 실제로 어느 정도의 탄소배출량을 절감하는지에 대한 수치를 산출하여 대외에 알리는 노력이 그린 활동의 중요한 실행, 집행 이라고 생각합니다.

    Posted by 조이트리
    아키텍트2008. 11. 4. 17:52
    안녕하세요, 까만돌 입니다. 오늘 2008년 11월 4일에 코엑스 인터콘티넨탈에서 "클라우드 컴퓨팅의 현황과 비전" 이라는 주제로 Keynote 발표를 하였습니다.

    한국과학기술정보연구원(KISTI) 주관으로 진행된 간담회에 지식경제부, 방송통신위원회, KISTI 등 정부기관을 비롯하여 삼성SDS, SK텔레콤, KT 등의 국내 대기업, 한국마이크로소프트, 한국Sun, 한국IBM, 한국HP 등의 업체들이 참여하여 간담회를 진행하였습니다.

    목적은
    1. 국내 클라우드 컴퓨팅 관련 정부, 학계 및 산업체간의 정보 공유
    2. 클라우드 컴퓨팅 연구 사업 및 실용 사업 추진 주도
    3. 공공분야(과학기술분야) 클라우드 컴퓨팅 기술방향 및 정책 협의
    4. 기술교류, 운영관련 정보교류 등 상호 협력 체계를 마련
    5. 클라우드 컴퓨팅 서비스 활성화 및 IT 응용 산업 발전에 기여 하는 것입니다.

    제가 진행한 발표의 핵심은 아래와 같습니다. 클라우드 컴퓨팅 플랫폼 제공자, 현재 마이크로소프트의 Windows Azure가 대표적 입니다. (www.azure.com)
    국내에서도 비슷한 형태로 클라우드 컴퓨팅 플랫폼을 제공하는 업체가 등장해야 한다고 생각합니다.
     

    클라우드 컴퓨팅은 애플리케이션을 개발하거나 서비스할 때 서버나 스토리지 등 컴퓨팅 자원등을 자체적으로 보유하기 보다 이 같은 자원을 갖고 있는 클라우드 컴퓨팅 플랫폼 제공자를 통해 운용하는 것을 의미합니다.” , 우리 나라의 천재 개발자가 마이크로소프트의 메일 서비스인 핫메일에 대응하는, 즉 전 세계인을 상대로 한 메일 서비스를 개발하고자 할 때, 장애 요인은 수억 명의 사용자를 대상으로 메일을 서비스 하기 위해 필요한 네트웍 장비, 웹서버, 데이터베이스 서버, 막대한 양의 스토리지를 확보하기 어렵기 때문입니다. 동시에 메일 시스템을 사용하는 사용자가 100, 200명 일 때는 큰 문제 없이 서비스가 가능하겠지만 10만명, 100만명, 1,000만명으로 늘어나면 하드웨어 시스템을 감당하기가 어려울 것 입니다. 하지만, 클라우드 컴퓨팅 플랫폼 제공자는 아무리 많은 사용자라도 서비스할 수 있는 인프라를 보유하고 있기에 개발 능력만 보유하고 있다면 전 세계를 상대로 서비스를 판매할 수 있는 새로운 돌파구가 열리는 것을 가능하게 합니다.

    클라우드 컴퓨팅이 적용된 실제 사례는 바로 이 사진 사이트, Smugmug (www.smugmug.com) 가 대표적입니다. 이 사이트는 클라우드 컴퓨팅 인프라를 이용해 개발되었습니다. 사이트 개발 시 사용한 만큼만 비용을 지불하는 방식이었기에 인프라 비용, 즉 서버, 스토리지, 네트웍 장비 등의 하드웨어 구입 비용이 전혀 들지 않았고, 즉 투자 비용이 없이도 사이트를 개설할 수 있었고 전세계의 사용자를 대상으로 서비스를 하고 있으며 현재 315,000명의 유료 사용자를 확보하여 큰 수익을 올리고 있습니다. 클라우드 컴퓨팅을 이용하면, 국내의 개발자가 인프라 투자 비용 없이도 아이디어 및 개발 능력만 보유하고 전세계를 상대로 비즈니스를 할 수 있게 되는 것 입니다.


    메릴린치 보고서에 의하면 2020년 클라우드 컴퓨팅은 약 1,000억불, 100조원의 시장이 될 것이라고 예측되고 있습니다. 이 중의 10%, 아니 1%만 확보할 수 있어도 1조원이나 되는 방대한 시장입니다. 클라우드 컴퓨팅에 대한 정부, 산업계, 학계의 집중적인 관심과 투자가 필요하다고 생각합니다.


    감사합니다.

    Posted by 조이트리
    아키텍트2008. 10. 31. 23:20
    "클라우드 컴퓨팅의 진화 및 이슈"라는 주제로 강의를 진행하였습니다. 

    클라우드 컴퓨팅의 비즈니스 모델은 크게 4가지 정도가 있습니다.
    1. Storage as a Service, 스토리지 서비스 사업자
    2. Infrastructure as a Service, 컴퓨팅/스토리지 서비스 사업자
    3. Platform as a Service (PaaS), 플랫폼 서비스 사업자
    4. Software as a Service, 애플리케이션 사업자

    PaaS를 통해 플랫폼을 장악하는 업체가 SaaS 영역의 주도권을 잡을 것이라고 보여지던 시기가 있었지만 지금 마이크로소프트의 Windows Azure 플랫폼, Azure Services 플랫폼이 발표되면서 클라우드 플랫폼을 통해 국내 애플리케이션 개발 업체가 얼마든지 글로벌 서비스를 개발할 수 있게 됨에 따라, PaaS가 아닌 클라우드 플랫폼 사업자가 훨씬 우위를 차지하는 시대가 도래했습니다. 앞으로 국내의 애플리케이션 개발자, 개발업체가 진행할 수 있는 다양한 비즈니스 모델에 대해 언급해 보도록 하겠습니다.

    해외의 업체가 한글을 지원하면서 국내에 서비스를 하듯, 국내 업체가 영어를 지원하면서 해외에 서비스를 하는 것도 어렵지 않게 가능해지는 시대가 왔습니다.
    Posted by 조이트리
    아키텍트2008. 10. 28. 19:53

    윈도우 애저는 굉장히 유연한 플랫폼으로 윈도우 런타임 환경에 전체 애플리케이션을 구동할 수도 있고, 개별 서비스만 활용할 수도 있습니다.

    PDC에서 발표된 버전에서는 마이크로소프트 .NET 프레임웍과 비쥬얼 스튜디오(Visual Studio)를 이용해 Windows Azure(애저) 애플리케이션을 개발할 수 있고, 가까운 시일에 PHP, Ruby 등의 언어를 이용해서도 애플리케이션 개발이 가능해집니다.


    1. 윈도우 애저에 애플리케이션 개발
      - 일단 애플리케이션을 개발한 후 윈도우 애저, 즉 클라우드 상에 배포합니다.
      - 컴퓨팅 파워 및 트래픽이 많든 적든 안정적인 애플리케이션을 최종 사용자가 사용 합니다.

    굉장히 간단하죠?
    How Does It work Diagram


    2. 구름에 있는 애플리케이션에 애저 서비스 추가 및 On-Premise 애플리케이션에 기능 추가

    지금 여러분이 개발한 클라우드 애플리케이션에 Windows Azure에서 제공하는 다른 서비스를 추가하고 싶습니다. Messenger 등의 Live Services (전 세계 4.6억명)이 쓰도록 할 수 있고, 워크플로우, 접근제어, 서비스 버스등을 이용하기 위해 .NET Services를 쓰거나 SQL Services를 사용할 수도 있겠죠. 물론 비즈니스 파트너 또는 업무용으로 사용될 어플리케이션을 개발할 수도 있습니다.

    How Does It work Diagram

    3. 모두 모아서

    또한, 가장 중요한 내용은 Azure (애저) 서비스 플랫폼은 클라우드 운영체제이며 서비스들의 집합이므로 웹, 모바일, 소프트웨어 및 서비스, 즉 하이브리드 하게 어느 유형에도 사용할 수 있다는 장점이 있습니다.

    현재 있는 소프트웨어에 클라우드 컴퓨팅이 가지고 있는 부가적인 기능을 추가할 수도 있고, 다른 어플리케이션에서 사용할 서비스를 만드는 것 등이 가능합니다.

    How Does It work Diagram
    Posted by 조이트리
    아키텍트2008. 10. 28. 18:56
    안녕하세요, 이전 글에 마이크로소프트의 클라우드 컴퓨팅 Platform에 대한 이야기를 했었는데요
    어제 날자로 드디어 발표되었습니다. 이름이 Windows Strata 일지, 아니면 새로운 이름일지에 대해 의문을 제기했었는데요, 결국은 새로운 이름이네요. 윈도우 애저, Windows Azure 입니다.


    Windows Azure (윈도우 애저)는 컴퓨팅, 스토리지, 매니지먼트 관련된 핵심 기반 인프라를 의미하고, 거기에 올라가는 애플리케이션은 Azure (애저) 서비스 플랫폼을 이용하여 개발할 수 있습니다.

    윈도우 애저는 기존의 On-Premise를 대체하는 개념이 아닙니다. 고객은 상황에 맞는 것을 선택하게 되는데 선택의 폭이 넓어졌다, 라고 보시는 것이 좋습니다. 바로 소프트웨어 플러스 서비스의 핵심인 선택, 클라우드 컴퓨팅이 추가된 개념으로 이해하셔야 합니다.
    Posted by 조이트리
    아키텍트2008. 10. 24. 10:28
    블로터닷넷 도안구 기자님이 아래와 같이 써 주셨습니다.

    http://bloter.net/archives/7561

    mmshsshin신현석 한국마이크로소프트 개발자와 플랫폼 사업총괄 부장은 “아마존의 아마존 웹서비스(Amazon Web Service)가 대표적이며 마이크로소프트의 버추얼어스를 부동산 정보와 결합해 제공하는 메시업, 다음커뮤니케이션과 NHN이 진행하고 있는 메시업, 오픈마루의 다양한 서비스 시도들이 WOA의 초기 모델이라고 볼 수 있습니다”라고 밝혔다.

    야후의 교통정보라는 서비스를 마이크로소프트의 버추얼어스나 구글어스와 결합하거나 부동산 전문 업체들이 전세계 지도 서비스 업체들의 인프라를 활용해 3차원적인 정보 서비스를 별도로 만들어 내면서 이전과는 전혀 다른 서비스들이 속속 출현하고 있다. 이런 서비스를 제공하기 위해 자사의 서비스 아키텍처를 좀더 유연하게 만들어 내는 것이 WOA이다.

    그렇다면 왜 WOA가 주목을 받을까?

    신현석 부장은 “웹이 하나의 플랫폼이 됐기 때문입니다”라고 설명한다. 수 많은 웹 서비스 업체들은 자신들의 서비스를 네티즌들에게 제공하고 있지만 이와는 별개로 수많은 개발자들이 웹서비스 업체의 인프라를 활용해 또 다른 서비스를 만들어 낼 수 있도록 돕고 있다. 이런 서비스 인프라를 만들어 제공하지 않으면 경쟁 업체들이 선점하면서 생태계를 이끌어가기 때문에 웹서비스 업체들이 주목을 하고 있다.

    그렇다고 해서 웹서비스 업체들만 관심을 가지는 것은 아니다. 일반 기업들도 인터넷뱅킹 서비스와 같은 다양한 인터넷 서비스를 제공하고 있는데 이런 사이트 구축을 할 때 WOA 형태로 진행할 수 있다. 다만 그동안 기업 내부적으로 SOA의 표준들이 다양하게 사용돼 왔기 때문에 웹 서비스 분야에서도 SOA 표준 중 하나인 SOAP를 사용할지 아니면 WOA의 REST를 사용할지의 선택을 해야 한다. 일장일단이 있기 때문에 어떤 아키텍처로 가져갈지에 대한 다각도의 검토 작업이 필수적이다.

    공공 기관들의 경우, 통계정보나 지리정보, 기상정보 등 원천 데이터들을 보유하고 있고, 지속적으로 이를 담는 그릇을 서비스 형태로 만들어가기 위해 노력하고 있는만큼 WOA를 검토할 필요성은 기업이나 웹서비스 업체에 뒤쳐지지 않을 것으로 보인다.

    신현석 부장은 “WOA가 SOA를 모두 대체할 수 있다고 보지는 않습니다. 어떤 서비스를 제공하기 위해 최적의 아키텍처는 무엇인지 검토가 필요한 상황이죠”라고 전하고 “SOA가 소개된지 오래됐지만 꾸준히 변화하고 있듯이 이제 막 소개되고 있는 WOA도 적용 가능한 분야를 찾아 진화, 진보해 나갈 것으로 봅니다”라고 밝혔다.

    Posted by 조이트리
    아키텍트2008. 10. 17. 10:19
    2008년 10월 15일자 디지털타임즈에 위와 같은 제목의 기사가 게재되었습니다.
    그 내용 중 제가 밝힌 내용도 나와서 참고로 올려 놓습니다.
    http://www.dt.co.kr/contents.html?article_no=2008101602010560744002

    SOA의 ROI에 의문이 제기 되고 있다.

    "이런 가운데 기존 SOA의 단점을 보완하기 위한 대안찾기 움직임도 활발하다. 웹지향아키텍처(WOA)가 바로 그것으로 `단순함'이라는 웹의 근본적 장점을 충분히 살려 부동산 회사가 외부 지도정보 위에 매물정보를 함께 보여주는 등 기존의 웹 서비스를 차용해 빠르게 새로운 서비스를 개발하는 개념이다.

    신현석 한국MS 개발자플랫폼 사업총괄 부장은 "WOA를 SOA와 같은 형태로 기업 환경에 적용하기 위해서는 데이터 암호화나 서비스 단위의 재사용 등 해결해야 할 기술적 과제가 아직 많이 남아있다"며 "그러나 일반 소비자 대상 서비스 영역에서 SOA의 단점을 보완해 활용할 수 있는 가능성은 충분할 것"이라고 말했다."

    제일 중요한 것은 "고객이 얼마나 Benefit, 즉 혜택을 느낄 수 있는가" 라고 생각합니다. 그것이 SOA를 기반으로 개발되었든, 아니면 전통적 개발 방식으로 개발되었든 최종 사용자는 차이를 느끼기 어렵기 때문입니다. 그렇다면 비즈니스적으로 비용, 시간 등의 가시적인 효과가 없다면 무슨 이유로? 이런 질문을 해보게 됩니다.


    Posted by 조이트리
    아키텍트2008. 10. 15. 13:10

    "WOA는 웹을 이루는 검증된 기술인 HTTP 프로토콜을 그대로 사용하고, SOAP 보다 간단한 REST 아키텍처 스타일을 사용하여 URI 형태로 참조되면서 웹 서비스를 구현할 수 있다." 마이크로소프트의 Virtual Earth를 이용하여 부동산 중개업소가 활용하는 경우 아주 획기적인 서비스를 제공할 수 있습니다.
    아래 그림에서 보듯, 해당 지도에 나타나는 매물을 보실 수 있죠. 집 모양의 아이콘을 클릭하면 상세 가격, 정보가 나타납니다. 이런 형태로 중개업소 사이트를 구축하는 것이 어려울까요? 어렵지 않습니다. Virtual Earth API가 제공되기 때문에 그대로 가져다가 쓰면 된다는 거죠. 이것이 WOA의 장점 입니다.


    위와 같이 WOA를 활용하면 누구나 거대한 서비스 공급망의 일원이 될 수 있습니다.

    SOAP vs REST 비교 자료를 올려 보겠습니다.

    SOAP(Simple Object Access Protocol) vs REST(Representational State Transfer)

     

    새로 웹서비스를 시작하려는 개발자는 많은 기술 및 개념에 압도되곤 합니다. SOAP, REST, WSDL, XML Schema, UDDI, WS-I, WS-Security, WS-* 등 정말 많고 계속 생겨나고 있죠. 그 중 웹서비스 개발에서 가장 대표적인 SOAP REST 중에서 한가지를 선택하게 됩니다.

     

    SOAP

    SOAP 1998 CORBA DCOM 같은 미들웨어 기술에 대한 대안으로 마이크로소프트에 의해 언어 및 플랫폼 중립적으로 선보였습니다. 이후 수정을 거쳐 1999 12 SOAP 1.0, 2000 5월에 1.1 버전이 W3C에 제출되었고 웹서비스의 핵심으로 부각되었습니다. 현재는 1.2버전이 사용되고 있습니다. SOAP과 함께 WSDL, XML Schema XML 기반의 메시지를 교환하는 표준이며 디자인 개념에 확장이 가능하도록 설계되어 다른 표준이 통합되기 쉽습니다. 현재도 계속 추가되고 있고, WS-*로 표현할 수 있습니다. 쉽게 말하면 점점 복잡해지고 있는 거죠. 하지만 필요한 것만 선택해서 사용할 수 있기에 걱정할 필요는 없습니다. SOAP의 기본 구조는 <Header>, <Body>로 구성되어 있습니다. <Header>는 선택, <Body>는 필수적으로 있어야 합니다. SOAP <Body>는 메시지를 보낼 때 에러가 발생하면 전송자에게 알려주는데 <Fault> element <Body> element의 자식으로 포함되어 보내지는데, 분산 컴퓨팅에서는 아주 중요한 개념 입니다.

    SOAP을 이용하여 개별 종목의 주가를 가져오는 웹 서비스 예제를 살펴보겠습니다.

    The request:

    GET /StockPrice HTTP/1.1
    Host: cooolguy.net
    Content-Type: application/soap+xml; charset=utf-8
    Content-Length: nnn
     
    <?xml version="1.0"?>
    <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
       xmlns:s="http://www.cooolguy.net/stock-service">
       <env:Body>
         <s:GetStockQuote>
              <s:TickerSymbol>MSFT</s:TickerSymbol>
         </s:GetStockQuote>
       </env:Body>
    </env:Envelope>

    The response:

    HTTP/1.1 200 OK
    Content-Type: application/soap+xml; charset=utf-8
    Content-Length: nnn
     
    <?xml version="1.0"?>
    <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
       xmlns:s="http://www.cooolguy.net/stock-service">
       <env:Body>
         <s:GetStockQuoteResponse>
              <s:StockPrice>30.08</s:StockPrice>
         </s:GetStockQuoteResponse>
       </env:Body>
    </env:Envelope>

     

    REST

    HTTP/1.0 Spec, HTTP/1.1, URI(Uniform Resource Identifiers) 등 인터넷의 표준을 수립하던 ROY T.FIELDING 교수가 웹 어플리케이션간 상호작용을 위한 이상적인 모델을 만들었는데, 그것이 바로 REST(Representational State Transfer) 아키텍처 스타일이며 최초 버전은 1995년에 만들어졌고, 현재 존재하는 웹 아키텍처의 근간을 이루고 있습니다. REST를 정의하기에 앞서 잘 디자인된 웹 어플리케이션이 동작하는 방식을 살펴보면 왜 이런 이름이 붙여졌는지 이해할 수 있습니다. 네트웍 상의 웹 페이지를 상태(State)를 가진 객체로 본다면 사용자가 링크를 클릭하거나 간단한 입력 값을 넣은 후 버튼을 클릭하면 해당 상태(State)가 특정한 형태(Representation)로 전송되고, 이 상태(State) 역시 다른 형태로 전송되는 과정을 갖게 됩니다. 결국 현재 우리가 매일 사용하는 Web REST를 가장 잘 표현한 아키텍처의 예가 됩니다. REST는 자원(Resource)에 대한 정의를 제공하는데 웹페이지, 이미지, 텍스트, 비디오, MP3, 슬라이드쇼, 지도 등 어떤 것도 자원이 될 수 있습니다. 자원을 명사라고 하면, 이 자원에 어떤 동작을 취하도록 하는 동사(Verb)가 필요하게 되는데 HTTP에서는 ‘GET’, ‘PUT’, ‘DELETE’, ‘POST’ 4개를 사용하고 있습니다.

    HTTP

    동작

    GET

    읽기

    PUT

    생성, 수정

    POST

    생성, 수정, 삭제

    DELETE

    삭제

    RESTful 웹 서비스는 Plain old XML(POX) HTTP 프로토콜을 이용하여 사용하는 방식 입니다. 위의 4개의 동사를 이용하여 네트웍 상에 위치하는 자원에 원하는 조작을 하게 됩니다.‘신현석이라는 사용자의 상세한 정보를 가져오는 웹서비스를 만든다고 했을 때 HTTP GET 방식으로 “http://www.cooolguy.net/users/신현석과 같이 사용할 수 있는 겁니다.

     

    주가 정보를 가져오는 서비스를 RESTful 웹서비스로 구현하면 아래와 같습니다. SOAP 방식과 비교하면 훨씬 간단한 것을 느끼실 수 있습니다.

     

    The request:

    GET /StockPrice/MSFT HTTP/1.1

    Host: coooguy.net

    Accept: text/xml

    Accept-Charset: utf-8

    The response:

    HTTP/1.1 200 OK

    Content-Type: text/xml; charset=utf-8

    Content-Length: nnn

     

    <?xml version="1.0"?>

    <s:Quote xmlns:s="http://cooolguy.net/stock-service">

         <s:TickerSymbol>MSFT</s:TickerSymbol>

         <s:StockPrice>32.08</s:StockPrice>

    </s:Quote>

     

    SOAP XML 기반의 분산 컴퓨팅을 위한 프로토콜이라면, REST는 웹기반의 아키텍처 스타일 입니다. 이렇게 역사가 오래된 REST가 지금 부각되고 있는 이유는 웹은 간단함을 통해 성장 발전했는데, SOAP을 이용한 웹서비스는 복잡하다는 겁니다. HTTP, XML, URI만 가지고 웹서비스에 생명력을 불어넣고 싶어졌다는 거죠. 한가지 잊지 말아야 할 것은 RESTful 웹서비스를 가지고 SOAP이 할 수 있는 모든 것을 구현할 수는 없겠지만, “간단함”, “매시업같은 형태를 통해 웹의 서비스화가 가속화되고 있다는 사실 입니다.

     

    SOAP의 장점

    1.     언어, 플랫폼, 전송(Transport) 중립

    2.     분산컴퓨팅 환경에서 사용하기 위한 디자인

    3.     웹서비스를 위해 널리 사용되는 표준이며, 다른 표준과 통합을 통한 확장성이 뛰어나고 다양한 Vendor를 통한 지원이 이루어지고 있음

    4.     에러처리 기능이 포함되어 있음

    SOAP의 단점

    1.     개념적으로 REST보다 더 어렵고, 무거움

    2.     개발이 REST 보다 어렵고 Tool이 필요한 경우가 많음

     

    REST의 장점

    1.     언어, 플랫폼 중립

    2.     일반적으로 SOAP보다 웹서비스 개발이 더 쉬움

    3.     매시업을 통한 새로운 형태의 웹서비스 개발을 쉽게 할 수 있음
    . Virtual Earth API
    와 연계하여 교통정보 제공 웹사이트를 개발하는 등

    REST의 단점

    1.     분산환경에서 메시지가 중간 경유지를 여러 번 통과하는 경우 사용하기 어려움

    2.     보안, 정책, 안정적인 메시지 전달을 지원하기 위한 표준이 부족함
    , 복잡한 요구사항을 표현하기 위해 직접 구현해야 함

    Posted by 조이트리
    아키텍트2008. 10. 15. 10:22

    한국 시간으로 2008년 10월 15일, http://www.microsoft.com/silverlight/ 을 통해 다운로드 받으실 수 있습니다.

    주목할 만한 내용은 Eclipse Foundation과 함께 Eclipse 개발 환경에서 Silverlight 컨트록 팩을 이용하여 개발할 수 있게 되었다는 것입니다. 지금까지 Eclipse 툴을 사용하는 Java 개발자들은 Adobe flash를 de-facto 스탠다르 같이 사용해 왔지만, Silverlight도 함께 이용할 수 있게 됨으로 상호운영성 측면에서 획기적인 진전을 이루었다고 할 수 있습니다.

    Silverlight의 채택율은 급격히 증가하고 있습니다. 일본 같은 경우 이미 50%를 넘어섰고, 약 150여개의 파트너와 수만개의 어플리케이션이 Silverlight을 이용하여 개발되었습니다. 지난 베이징 올림픽의 경우 NBCOlympics.com을 통해 약 5천만명의 사용자가 사용하였고 13억건의 페이지 뷰, 7천만개의 비디오가 Silverlight을 통해 전달되어졌습니다. 우리나라에서도 KBS가 Silverlight을 이용해 올림픽을 중계하여, 온 국민을 감동의 도가니로 몰아넣었던 야구 한일전, 결승전의 경우 엄청난 양의 트래픽이 발생했다고 합니다.

    Silverlight을 이용했을 때의 장점은 사이트에 체류하는 시간을 길게 해준다는 건데, 평균 3분 정도 체류하던 고객이 27분 이상 머물른다는 통계 데이터가 발표되기도 했습니다. MNet의 TVDeep을 보시면 아시겠지만 미디어를 지속적으로 소비하도록 하는 구조로 개발되고, 사용자의 시선을 끌기 때문이죠.

    한 번 보세요. 매력적인 모습을 확인할 수 있습니다.

    Posted by 조이트리