소프트웨어/SliverLight

웹 서버를 쓸까? 스트리밍 서버를 쓸까? 도대체 뭐가 좋은거야~~!

falconer 2008. 6. 4. 19:15

요즘 어느 웹 사이트나 동영상이 빠져있는 사이트를 보는 것은 이제 매우 어려운 일이 되어버렸습니다. 어떤 형태로든 동영상을 서비스하고 있고, 이러한 동영상은 웹 페이지를 더욱 미려하고, 직관적으로 해주는 또하나의 백미중에 하나가 되고 있죠. IT 관리자는 조직의 솔루션 or 웹 서비스등에 동영상을 서비스해달라는 요청을 심심치 않게 받으실 수 있습니다.

동영상을 서비스할 수 있는 방법론은 크게 두가지를 꼽을 수 있습니다. 바로 웹 서버를 이용한 전통적인 서비스 방식과 Windows Media Service와 같은 스트리밍 방식의 서비스를 이용하는 방법입니다. 어떤 것을 사용하고 계신가요?

image

두가지중에 어느 한가지가 좋다고 선택하기가 매우 어렵습니다. IIS를 사용하는 전통적인 다운로드 방식의 동영상 서비스와 스트리밍 방식의 동영상 서비스는 각기 방향성과 사용 방법론이 조금은 틀리기 때문이죠.

2002~2003년즈음에 화상 회의와 관련된 회사를 다녔던 저입장에서는 이러한 미디어에 대한 네트워크 전송은 단순하게 서비스의 종류도 종류였지만, 네트워크에서 어떠한 프로토콜을 사용하느냐도 매우 중요했습니다. 바로 TCP냐 UDP냐는 것에 대한 선택이죠. Multicast도 있었고요.

TCP는 신뢰성있는 프로토콜입니다. 여기서 길게 언급하기는 그렇지만.. 전송에 대해서 확인을 거친 후, 어떠한 문제가 발생하면 그 문제점에 대해서는 재전송해주는 방식을 사용합니다만, 동영상과 같은 실시간 스트리밍에서는 이러한 재전송이 오히려 딜레이와 같은 역효과를 낼수도 있습니다. 다만, TCP를 사용하는 경우 NAT라던가, Firewall과 같은 네트워크에서의 접근 문제점을 해결할 수 있다는 장점은 있습니다.

UDP는 신뢰성이 없는 프로토콜입니다. 전송하면 받던가 말던가 크게 신경쓰지 않죠. 또한 네트워크 장비에서 TCP보다 처리되는 프로세스가 더 빠릅니다. 이에 실시간의 빠른 전송을 요구하는 오디오/비디오 스트리밍 환경에서는 TCP보단 적절할 수 있습니다. 네트워크 인프라에 영향을 많이 받았고, NAT와 Firewall과 같은 네트워크에서 다소 문제를 야기했었습니다.

Multicast는 네트워크 장비 레벨에서 패킷 처리를 멀티미디어에 적절하게 해주는.. 결국, 서버에는 하나의 멀티미디어 패킷만 전송하면, Multicast 그룹에 들어가 있는 클라이언트들은 스위치 레벨에서 이를 나누어서 보내주는 것이죠. Unicast 방식보다 서버의 부하, 그리고 네트워크 대역폭을 훨씬 작게 쓴다는 장점이 있습니다만, 장비가 지원해야 한다는 약점이 있습니다.

웹 서버는 HTTP 프로토콜로 서비스를 하게 되고, 이 HTTP는 바로 TCP를 사용합니다. 이렇기 때문에 동영상을 서비스하는 경우에 TCP에 의한 문제점을 고스란히 가지고 있는 것은 사실입니다, 스트리밍 서버는 TCP or UDP를 선택할 수가 있죠. 물론 Multicast도 사용이 가능합니다.

Silverlight이 대중화가 되가면서, Silverlight을 이용한 개발자나 디자이너 분들께서 많이들 궁금해하시는 사항인데요. 어떤 것을 선택할까? 라는 것이죠.

간단하게 살펴보죠.

웹 서버

장점

  1. 쉬운 관리와 설정 - 현재 사용하는 웹 서버에서 바로 서비스 가능
  2. 낮은 서버 사용량
  3. SSL을 이용한 보안
  4. 일반 웹 클라이언트의 지원
  5. 방화벽, 캐쉬, 프록시등을 지원

단점

  1. 콘텐츠의 Bit Rate에 상관없이 한번에 왕창 전송 - 네트워크 대역폭의 일시적 폭주
  2. 고급 스트리밍 기술에 대한 지원 없음 - Intelligent Streaming, Advanced FF/RW, Live Broadcast 등
  3. 재생 목록에 대한 지원 없음
  4. DRM을 사용하지 않을 경우, 동영상 콘텐츠가 클라이언트 캐쉬에 남음

스트리밍 서버

장점

  1. 동영상 서비스에 적합한 많은 스트리밍 기술 제공
  2. 서버 기반 재생 목록
  3. 대역폭 최적화
  4. 다양한 프로토콜 지원

단점

  1. 추가적인 인프라 구축에 따른 관리
  2. 지원 포맷의 한정 및 클라이언트 제한

웹 서버의 경우에는 첫번째 문제점이 단점 1번 사항입니다. 128K로 인코딩된 콘텐츠는 128K로만 서비스하면 사용자는 무리없이 서비스를 받을 수 있지만, 웹 서버 자체가 콘텐츠의 Bit Rate을 알지 못하므로, 무조건 왕창 전송하고 끝내버린다는 것이죠. 이는 다수의 사용자가 동시에 서비스를 요청하면 네트워크 대역폭이 첫번째 문제점이 될 수 있습니다. 그리고 동영상 서비스를 위한 비즈니스 구조인 광고를 넣고, 이에 대해 시청한 후, 서비스를 받는 등의 비즈니스 연관 관계를 설정하는 것도 어렵습니다.

그렇다고 스트리밍 서버를 추가적으로 설치하자니.. 인프라적인 요소 및 서비스가 가능한 동영상 포맷이 제한적이 되어버리죠.

이를 해결하기 위해서 바로 Windows Server 2008의 IIS 7에서는 두가지 모듈을 추가적으로 제공합니다. 물론 IIS 7을 사용하시면 언제든지 사용하실 수 있습니다.

IIS 7 Bit Rate Throtting Module

  • 32 bit - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1640

  • 64 bit - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1641

    IIS 7 Web Playlist Module

  • 32 bit - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1623

  • 64 bit - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1631

    Bit Rate Throtting Module에 대해 간단히 말씀드리면.. 12Mbps로 인코딩된 동영상을 IIS 7을 통해서 제공할 때, IIS 7의 경우 해당 동영상이 12Mbps로 서비스해야 한다는 사실을 알지 못합니다. 그러므로, 대역폭이 허락하는한, 최대로 파일을 전송하게 되고, 사용자는 빠르게 전송받은 콘텐츠는 말 그대로 캐쉬에 가지게 되는 것이죠. 그렇지만, Bit Rate Throtting Module을 사용하게 되면, IIS가 해당 콘텐츠의 Bit Rate를 알게 되서, 최초의 Fast Start, Fast Cache를 위해서만 일시적으로 전송 속도를 올리고, 남은 시간에는 해당 Bit Rate로만 전송하는 모듈입니다. 간단하죠?

    image image

    위의 그림에서 보시면 확연히 차이를 아시겠죠?

    image

    설정은 매우 간단합니다. IIS 7에 해당 모듈을 설치하시고, 이에 대해 설정만 해주시면 되고, 필요하시다면 추가적으로 얼마든지 콘텐츠 유형을 추가할 수 있습니다. 콘텐츠 입장이 아닌, 데이터 입장에서 설정을 할 수 있기 때문에, 엔지니어 시각에서 데이터 처리를 원하는 경우, 다시 말해, 최초의 Fast Start를 위한 대역폭, 이후 대역폭을 네트워크 입장에서 명시할 수 있죠.

    image

    이를 사용했을 경우의 그림이 밑의 왼쪽 - 대역폭과 Bit Rate가 거의 일치합니다. 쓰지 않았을 경우의 그림이 밑에 오른쪽입니다. 대역폭을 허가량만큼 다 쓰고 있죠.

    image image

    물론 IIS 7 + Bit Rate Throtting이 만사 해결은 아닙니다. IIS 7에서 콘텐츠를 서비스하기 위한 최소한의 모듈을 제공하고 있고, 고급적인 모듈은 WMS를 이용하셔야 합니다.

    동일한 동영상을 WMS를 통해서 서비스를 하게 되면, 대역폭도 훨씬 최적화하여 사용하며, 클라이언트와 서버사이의 네트워크 상태를 파악하기 때문에, 네트워크의 변화에 따라 품질 조정 및 오디오/비디오 서비스를 조절하는 Intelligent Streaming이 가능해집니다. 물론 Windows Media Player와의 궁합도 생각하긴 해야죠

    image image

    내용이 길어지네요.. 그래도 다 써야죠~ WMS의 Playlist(.asx)는 비즈니스적으로 필요한 기능이 많습니다. 광고를 보고~ 동영상을 보게 하거나, 되돌리기, 앞으로 가기 금지.. 재생 위치 조절 금지등... 이 기능도 동영상을 서비스하는 서버입장에선 꼭 필요합니다. 바로 IIS 7의 Web Playlist(.isx)가 이를 할 수 있습니다.

    image

    만약 IIS로 동영상을 서비스한다면, 사용자가 직접 URL을 치고 들어갈 수도 있다는 문제점도 있고.. 광고를 보지 않고, 동영상을 서비스받을 수도 있습니다. 또한 동영상 콘텐츠가 반드시 서버에 같이 있어야 한다는 문제점이 있지만.. Web Playlist를 사용하시면, 구지 콘텐츠가 가상 디렉터리, 같은 서버내에 있지 않고도 서비스를 할 수 있게 해줍니다.

    image image

    훌륭하죠? 사용자는 http://주소/Playlist.isx 또는 이 XML 정보를 ASPX를 통해서 제공받을수도 있습니다.

    image

    첫번째 질문에 대해 이제 답변이 생기셨나요? 웹 서버는 뭔가 아쉽고, WMS 쓰기엔 뭔가 지나친거 같고... 이를 Windows Server 2008의 IIS 7이 속시원하게 해결해드리며.. 이를 통해 Silverlight과의 멋진 만남을 만들어낼 수 있습니다.

    image

    아래의 표는 보너스입니다. 기능에 대한 비교표도 있어야겠죠 :)

    image

    Expression을 통한 콘텐츠 제작 및 인코딩, 이를 Windows Platform에서 서비스를 하고, 이러한 풍부한 기능 및 경험을 사용자는 Silverlight을 통해서 완벽하게 경험하실 수 있습니다. 역시나 사용자의 멋진 경험 뒤에는 이를 묵묵히 서비스하는 다양한 플랫폼 기술이 있어야 한다는 것을 다시금 느끼실 수 있을거라 생각합니다.

    출처 : 꼬알리의 하얀집