먼저 미디어의 사전적 의미를 알아보자. “어떤 작용을 한쪽에서 다른 쪽으로 전달하는 역할을 하는 것.” 그럼 IT에서 미디어란 무엇일까? 연속된 사진을 압축하고 네트워크를 통해 사용자에게 전달하는 일련의 작업이라고 말할 수 있다. 그럼 IT 트래픽에서 미디어가 차지하는 비중은 얼마나 될까?
과학기술정보통신부에 의하면 국내 분야별 모바일 트래픽 추이에서 동영상(미디어)이 차지하는 비율은 압도적으로 높다.
앞으로도 4K 등의 보급으로 미디어 트래픽이 급격하게 성장하리라 누구나 예상할 수 있다. IT 시장에서 트래픽은 곧 회사의 가치로 평가되기 때문에 미디어 플랫폼 회사의 가치는 시간이 지날수록 더욱 높아질 것이다.
화질
그럼 본론으로 IT 미디어의 워크플로를 알아보자.
<그림2>처럼 IT 미디어의 워크플로를 보면, 각 해상도(Resolution)의 연속된 초당 사진의 수(Frame, 프레임)를 적당한 데이터 크기(Bitrate, 비트레이트)로 정한다. 여기서 영상의 품질, 즉 화질이 결정된다. 그리고 약속한 코덱(H.264 등)으로 압축하고 긴 영상 파일을 작은 파일로 분할(Packetizing)해 사용자에게 전달한다.
그 중간에는 GOP, CBR/VBR, Profile(Baseline, Main) 등 미디어 자체에 대한 많은 개념이 있다. 대부분 영상 효율성에 관한 내용이다. 어떻게 작은 자원으로 높은 화질의 영상을 만들고, 볼 수 있을지에 대한 고민으로 나온 결과물이다.
코덱(Codec)
- 디지털 영상의 인코딩과 디코딩을 담당(e.g H.264, HEVC 등)
GOP
- 프레임을 그룹화하고, 앞뒤 프레임 등을 이용해 부분 압축하는 방식
CBR/VBR
- 순간 데이터에 따라 비트레이트를 고정(CBR)시키거나 변경(VBR)하는 방식
Profile
- 타겟팅 기기에 따른 규격(Baseline, Main 등)
Level
- 비트율, 프레임, 해상도에 따른 정의(1 ~ 5.2)
이렇게 다양한 미디어 설정값에서 최적값은 어떻게 찾아야 할까? 가장 쉽고 안정적인 방법은 실제 대규모 미디어 서비스를 운영하는 기업을 따르는 것이다. 유튜브, 트위치 등 미디어 플랫폼 사의 미디어 설정을 확인해보자.
물론 프레임이 급변하는 스포츠 영상이나 변화가 거의 없는 CCTV 영상과 같이 다양한 영상 특성별로 최적화된 미디어 구성은 다를 수 있다. 그러나 <그림3>과 같이 미디어 플랫폼 사의 구성을 참조하면 일반적인 수준으로 안정적인 서비스를 꾸릴 수 있다.
미디어 프로토콜
미디어 프로토콜은 RTMP, RTSP, MSS(Microsoft Smooth Streaming) 등이 있다. 이 프로토콜은 실시간성이 좋고, 콘텐츠 다운로드가 불가능해 많이 사용됐었다. 그러나 제조사마다 규약이 달라 호환되지 않는 문제가 있었으며, FMS(Flash Media Server), WMS(Windows Media Server), 와우자(Wowza) 같은 유료 소프트웨어가 필요했다.
또한 플래시 기반 플레이어에 의존해야 하는 문제점도 있었다. 그래서 최근에는 이 단점을 보완한 HTTP 기반의 HLS, MPEG-DASH 등 형태가 주류를 이룬다. 이제 Nginx 등 웹서버를 통해서도 사용자에게 미디어 콘텐츠를 제공할 수 있으며, 기본적으로 80포트를 사용해 방화벽 등의 문제에서도 자유로워졌다. 또한 기존 어댑티브(Adaptive) 스트리밍 방식을 이어받아 대역폭 낭비도 줄일 수 있다.
미디어 운영
미디어는 라이브(LIVE, 생방송)와 VOD(Video on Demand, 주문형 비디오)로 분류할 수 있다.
라이브는 SDI 등 무거운 영상 신호를 엘리멘탈(Elemental) 인코더 같은 물리 장비를 이용해 전달받고, 각 프로파일에 맞게 인코딩 한다. 그리고 와우자 같은 상용 미디어 플랫폼 혹은 FFmpeg 라이브러리 등을 이용해서 트랜스코딩(Transcoding) 및 패킷타이징(Packetizing) 하고 HTTP 기반의 웹서버를 통해 사용자에게 전달한다. 개인 방송 플랫폼의 경우 영상 신호가 가볍기 때문에 물리 장비가 필요하지 않은 경우도 있다.
VOD는 각 해상도 별로 파일을 NAS 같은 스토리지에 저장하고, 웹서버를 이용해 서비스 한다. 테이프 등 오래된 자료는 디지털라이징을 거쳐 스토리지에 저장한다.
운영상 어려움
미디어 서비스를 운영하면서 느꼈던 개인적으로 어려움을 몇 가지를 소개한다.
첫째, 유지보수가 힘들다. 미디어 서비스를 위해 다양한 플랫폼을 구성했기 때문에, 엔드포인트에서 발생한 장애의 발현점을 찾는 게 쉽지 않았다.
둘째, 유연성 확보가 힘들다. 미디어 서비스의 경우, 올림픽이나 대선 등 이벤트로 트래픽 변동성이 크다. 그래서 유연성을 확보해야하지만, 한정된 리소스로 이벤트 대응시 서비스에 어려움이 있었다.
셋째, 미디어 기술 변화에 쉽게 대응할 수 없다. 대부분 방송사는 콘텐츠에 집중하기 때문에 미디어 프로세싱, CDN 영역은 외주 업체를 이용한다. 이 때, 미디어 신기술 도입에 어려움을 겪을 수 있다. 4K 방송, DRM 도입, 광고 플랫폼 변경 등 새로운 요구사항을 적용하기 위해서는 외주 업체와 요구사항에 따른 재계약이나 추가계약이 필요할 수 있으며, 협업에 따른 테스트에도 오랜 시간이 소요된다. 이건 기존 SI 시장 문제와 대동소이하다.
넷째, VOD 서비스 운영을 위한 스토리지 확장이나 축소 관리가 어렵다. 지상파나 종편의 방송편성표만 봐도, 매순간 새로운 콘텐츠가 추가된다.
클라우드 활용
그렇다면 기존 미디어 구성을 클라우드로 옮기면 어떤 장점이 있을까?
첫째, 미디어 플랫폼의 유지보수가 수월하다. PaaS로 이뤄진 클라우드 미디어 서비스는 최초 구성만 하면 그 외 유지보수 업무가 많이 줄어든다. 물론 어느 클라우드도 장애는 발생한다. 하지만 기존 레거시 환경보다 장애를 줄일 수 있으며 유지보수에 대한 전문 엔지니어 리소스 또한 줄일 수 있다. 엔지니어는 단순 유지보수보다 가치 있는 다른 일을 할 수 있다.
둘째, 유연성이 확보된다. PaaS의 경우, 사용자의 개입 없이 리소스를 확장할 수 있다. 트래픽 변동성이 큰 미디어 서비스에 매우 적합하다. 사용한만큼만 비용을 지불하기 때문에 미리 이벤트에 대비해 과다한 컴퓨팅 리소스를 구매할 필요가 없다. 물론 ‘대규모 이벤트’ 시에는 클라우드 벤더사에 내용을 미리 공유하는 것이 좋다. 그러나 레거시 환경 대비 유연성에 많은 장점이 있다.
셋째, 미디어 기술 변화에 쉽게 대응할 수 있다. 대부분 클라우드 벤더사는 자신의 서비스를 먼저 직접 사용하고 검증한 뒤에 신뢰할 수 있는 기능을 PaaS 상품으로 추가한다. 따라서 대부분 신기술은 PaaS에도 있으며, 기존보다 수월하게 새로운 기술을 도입할 수 있다.
넷째, VOD용 스토리지는 오브젝트(Object) 스토리지를 활용해 스토리지의 확장이나 축소에 대한 고민을 줄일 수 있다. 또한 IOPS 등 스토리지 성능 병목에 대해서도 신경 쓸 필요가 없다.
언급한 내용은 개인적인 경험을 토대로 생각한 클라우드 미디어 PaaS의 이점이다. 만약 AWS 미디어 PaaS를 사용하면, AWS의 CDN 서비스인 클라우드프론트(CloudFront)와 호환성도 높일 수 있다.
AWS 미디어 서비스
그럼, 클라우드 벤더사 중 한 곳인 AWS가 공식적으로 설명하는 AWS 미디어 서비스의 이점을 알아보자.
AWS 미디어 서비스는 브로드캐스트와 OTT(Over-The-Top)용 미디어(라이브와 VOD)를 쉽고 빠르게 이동하고, 준비하고, 처리하고, 전송할 수 있게 지원한다. 사용량에 따라 요금을 지불하는 체계이므로 기술 구입이나 통합에도 많은 시간이나 비용을 들이지 않고 테스트와 배포를 이어갈 수 있다.
출력을 추가하거나 시청자가 늘어날 경우, 필요에 따라 서비스를 확장하고 일관적인 고품질 콘텐츠 전송을 유지할 수 있다. 전체 지역에서 사용할 수 있는 자동화 모니터링 및 복구를 통해 기본적으로 안정성을 유지할 수 있다. 신뢰할 수 있는 인프라를 통해 가장 많은 인기를 끄는 콘텐츠도 안심하고 지원할 수 있다. AWS의 및 타 서비스와 상호 운용성이 높아, 라이브와 VOD 워크플로를 위한 완전한 도구 세트를 완성할 수 있다.
- 콘텐츠 중심
클라우드의 가장 큰 장점은 인프라 관리 리소소의 최소화다. 미디어 서비스에 가장 큰 영향을 주는 영역인 콘텐츠에 직원 리소스를 집중할 수 있다. 인프라 관련 작업(비디오 이동, 처리 및 전송 하드웨어 구입 및 유지 관리)은 AWS에 맡기고, 콘텐츠 제작과 엔드유저를 위한 서비스에 전념할 수 있다.
- 변화에 맞춘 대처
미디어 서비스를 운영하면 스토리지 증가, 장애 처리, 전송 요구 사항 등 예측하기 힘든 리소스 수요가 생긴다. 확장성 확보로 나날이 증가하는 대규모 비디오 스트림과 파일 크기 증가를 충족할 수 있습니다. 아마존 S3나 아마존 글래시어(Amazon Glacier) 같은 AWS 스토리지 서비스를 활용하면 스토리지 요구 사항에 맞춰 간편하고 경제적인 과금 체계를 만들 수 있다.
- 구축 사례
AWS 미디어 서비스 사례에는 Pac-12 Networks(미국의 스포츠 케이블 방송사), FOX SPORTS(미국의 스포츠 케이블 방송사), BT(영국의 통신사), 아마존 프라임 비디오(Amazon Prime Video)가 대표적이다. 국내 몇몇 방송사에서도 AWS 미디어 서비스를 사용 중인 것으로 알고 있다.
각 클라우드 벤더사는 각자 자사 미디어 PaaS가 손쉽게 쓸 수 있다고 한다. 사실 여러 기능을 사용한다면, 클라우드마다 러닝커브가 조금 있는 편이다.
AWS 미디어 PaaS
그럼 클라우드 벤더사 중 1위 업체인 AWS의 미디어 서비스를 소개한다.
미디어 서비스를 위해서는 앞서 말했듯이 여러 계층이 있어야 한다. 웹 서비스를 할 때도 프론트엔드, 백엔드, 데이터베이스, 메일, 데이터 분석 등 각 모듈별로 플랫폼이 필요하다. 미디어 역시 기존 IT 서비스와 동일하다. AWS 미디어 PaaS를 기준으로 필요한 내용만 간결하게 알아보자. (feat. 쪽집게 과외)
라이브
먼저 미디어 LIVE 스트리밍을 위한 AWS 미디어 서비스다.
미디어커넥트(MediaConnect)
미디어커넥트는 미디어 서비스를 위한 앞단 인게스트(Ingest) 부분 커넥트(Connect)다. 직시(Zixi)나 RTP 등 미디어를 위한 안정적인 프로토콜를 지원한다. 네트워크가 불안정할 경우, 스트리밍 품질이 떨어져 흐트러짐이 발생한다. 직시 프로토콜은 네트워크 손실에도 최대한 안정적인 미디어 스트리밍을 도와준다.
미디어커넥트는 라이브에 사용하는 엘리멘탈 인코더(Elemental Encoder) 물리 장비에서 AWS 엘리멘탈 미디어라이브(AWS Elemental MediaLive)로 미디어 스트리밍을 연결하는 역할을 한다. 그러나 라이브 미디어 스트리밍에서 꼭 필요한 서비스는 아니다. 2019년 9월 기준 아직은 보편적으로 미디어 인게스트 단계에서 RTMP 프로토콜을 사용하고 있다. 또한 서울 리전에는 오픈하지 않았다.
미디어라이브(MediaLive)
미디어라이브는 기존 미디어 인코더와 같다고 볼 수 있다. 미디어 소스의 인코딩과 패킷타이징을 지원한다. 당연히 <그림6>과 같이 다중 AZ 배포(Multi-AZ)를 이용해 인풋과 아웃풋 모두 이중화를 지원한다.
미디어라이브는 인코딩된 미디어 데이터를 보내주는 역할(PUSH)만 하기 때문에, 데이터를 받을 수 있는 플랫폼인 미디어패키지(MediaPackage)나 미디어스토리지(MediaStorage)와 함께 사용해야 한다. 미디어커넥트와 달리, 라이브 서비스에서 꼭 필요한 서비스다. 또한 품질 기반 가변 비트레이트(QVBR)를 지원한다.
AWS가 말하는 QVBR의 이점은 비디오 출력 비트레이트를 최대 50% 감소할 수 있다는 점이다. 미디어 서비스에서 네트워크 비용은 가장 큰 비용 중 하나다. 동일한 영상에 대해 네트워크 트래픽을 감소시킬 수 있다면, 미디어 서비스의 운영 비용을 매우 절감할 수 있다.
그 외에도 AWS에서 내세우는 이점은 많으나, 중점은 비트레이트 감소다.
미디어스토어(MediaStore)
미디어스토어는 메모리 기반 미디어 전용 S3 스토리지로 이해하면 된다.
메모리 기반이므로 실시간성에서 좋은 성능을 보여준다. CORS 설정을 기능으로 언급하지만, 그 외 특별한 기능은 없다. 미디어라이브에서 스트리밍을 HTTP(S) 프로토콜을 통해 받는다. 클라우드프론트 등 CDN의 원본 역할을 수행한다.
미디어패키지(MediaPackage)
미디어패키지는 트랜스코딩, 패킷타이징 같이 미디어를 재가공할 수 있는 서비스다. 현재 패키지 타입으로 HLS, DASH-ISO, MS 스무스(Microsoft Smooth), CMAF(Common Media Application Format)을 지원한다. 또한 DVR(Time Shift)과 DRM 기능도 지원한다.
미디어패키지 역시 HTTP(S) 프로토콜을 지원해, 클라우드프론트 등 CDN의 원본 역할을 할 수 있다. AWS를 이용해서 미디어 서비스를 구성할 때 혼돈하는 부분이 미디어스토어와 미디어패키지다.둘 다 미디어라이브와 클라우드프론트 중간에 위치하기 때문에 차이를 알아야 한다.
앞서 말했듯이, 미디어스토어는 특별한 기능이 없다. 단순한 콘텐츠 서비스만을 목적으로 한다면 미디어스토어만 사용해도 충분하다.
반면 미디어패키지는 트랜스코딩, 패킷타이징, DRM 기능으로 미디어 데이터를 재가공할 수 있다. 또한 DVR(Time Shift) 기능도 사용할 수 있다. 이런 기능이 필요하거나 콘텐츠 제공 업체에서 통일되지 않은 규격으로 미디어 소스를 받는다면, 미디어패키지를 사용해 미디어 규격을 통일시켜 사용자에게 제공할 수 있다.
미디어테일러(MediaTailor)
미디어테일러는 미디어에 광고 삽입 서비스로 광고에 대한 자동화 보고서를 제공한다.
미디어테일러는 클라우드프론트 및 광고 서버(ADS)와 통신해 사용자에게 맞춤 광고 환경을 제공할 수 있다. 매니페스트(manifests)를 제어해 서버 영역에 광고를 게재할 수 있다. 또한 SCTE-35 마커를 통해, 사용자 영역(엔드포인트)에 동적 광고도 삽입할 수 있다.
여기까지가 미디어 라이브 스트리밍을 위한 AWS 미디어 서비스다. 이들을 조합하면 대부분의 미디어 라이브 스트리밍 서비스를 할 수 있다.
VOD
이제 VOD 서비스인 경우에 사용할 AWS 미디어 서비스를 소개한다.
미디어컨버트(MediaConvert)
미디어컨버트는 VOD를 위한 AWS의 인코더/트랜스코더다. 현재 HLS, DASH, MSS, CMAF를 지원한다. (소스 저장은 현재 S3만 지원한다.)
미디어 소스 파일을 업로드 하면, 미디어컨버트를 거쳐서 지정한 S3 버킷에 트랜스코딩이 완료된 미디어 파일을 업로드 한다. 각 구간별로 제공되는 API를 이용할 수 있고, 람다(Lambda)를 활용하면 자동화 형태로 구현할 수 있다.
기존에는 엘라스틱 트랜스코더(Elastic Transcoder)라는 VOD 전용 서비스가 있었다. 그러나 AWS에서 엘리멘탈(Elemental)을 인수한 후, 업데이트가 이뤄지지 않고 있다. 더 이상 업데이트가 되지 않는 플랫폼은 무시하자.
운영과 관리
이제까지 설명한 AWS 미디어 서비스를 이용하면 라이브와 VOD 서비스 모두를 구성할 수 있다. 그럼 모든 것을 위임하고 클라우드에 맡겨도 될까? 이전 언급했듯이 클라우드도 장애는 발생한다. 서비스 관제는 클라우드를 사용해도 엔지니어에겐 피할 수는 숙명이다.
AWS의 대부분 미디어 서비스는 클라우드워치(CloudWatch)라는 모니터링 서비스를 활용할 수 있다. 클라우드워치를 통해 각 서비스에 할당한 CPU와 메모리 같은 메트릭을 파악하고 모니터링해야 한다. 또한 장애가 발생하면 추적을 위한 로그 파악도 잊지 말아야 한다.
클라우드는 장애 발생에 대해 불친절하다. PaaS, SaaS를 활용하는 엔지니어라면 해당 서버에 접근할 수가 없다. 따라서 장애를 입증할 수 있는 모든 내역을 보관해야 하며 분석할 수 있어야 한다.
그러나 채널이 많을 경우 클라우드워치와 클라우드워치 로그(CloudWatch logs)를 이용해서 모니터링 시스템을 구축하기엔 어려움이 있을 수 있다.
각 채널의 CloudWatch Log 파이프라인을 구축하고, 원하는 방식으로 그루핑하여 로그를 S3로 옮기고, Atheana 등을 통해 장애 확인을 위한 쿼리를 만들고, SNS Topic을 통해 알람을 받을 수 있다.
또는 데이터독(DataDog)과 같은 AWS나 Azure 등 클라우드와 통합된 서드파티 솔루션을 사용하면 좀 더 손쉽게 구성이 가능하다.
서드파티 모니터링 솔루션은 로그 매니지먼트, 대시보드, 임계치, 알람 등 여러 기능을 제공한다.
미디어 시스템을 클라우드로
이 글은 실제 기존 레거시 시스템을 클라우드로 이관하며 느꼈던 경험 위주로 작성했다. 라이브 서비스를 이관하며 사용했던 시스템은 미디어라이브, 미디어컨버트, 미디어스토어, 미디어패키지였다. QVBR을 적용해 인코딩 이점을 가져갔다. 그러나 인게스트 단계에서 네트워크 문제로 가끔 원인을 파악하기 힘든 장애가 단발적으로 발생하기도 했다. 그래서 데이터독 등을 이용해 모니터링 체계를 잡았으며, 앞으로도 잡아갈 것이다. 또한 전용선을 통해 인게스트 단계의 네트워크 문제를 해결하려고 한다.
VOD 서비스 이관에서는 300TB 데이터를 옮겼다. 레거시 환경의 제약과 복잡성으로 심플하게 EC2(S3 API)를 통해 이관했으며, 검증까지 약 3주 정도 걸렸다.
전면 미디어 시스템, CDN 이관임을 고려하면 성공적으로 클라우드 미디어 시스템을 이관했다고 평가할 수 있다. 또한 새로운 기술을 도입해 실시간성을 높이고, 네트워크 사용을 줄일 수 있는 방편을 계속 찾을 것이다.
위기와 기회
IT 미디어 그리고 클라우드에 대한 소개를 해봤다. 나는 미디어의 본질에 대한 지식은 부족하다. 따라서 부족한 내용이 있었더라도 너그러운 마음으로 이해를 부탁한다. 부족한 경험과 글이더라도, 도움이 됐기를 바라며 글을 마친다.
마이크로소프트웨어 398호: 클라우드의 어떤 것(Something Cloud)
방송 시스템을 위한 PaaS 활용 - AWS 미디어 서비스를 알아보자 편
'잡부생활' 카테고리의 다른 글
| Python locust load test tool (0) | 2021.10.12 |
|---|---|
| CORS (simple, preflight request) (0) | 2020.03.27 |
| 알리바바 클라우드(Alibaba cloud) CDN 분석 (0) | 2019.12.24 |
| AD FS 이용해서 AWS SAML 2.0 연동하기 (0) | 2019.12.24 |
| XGBoost 파라미터 정리 (0) | 2019.11.06 |
