이번 포스팅은 지난 AWS Live Stream 예제 따라해 보기(http://mystouswp.cafe24.com/?p=478)에서 사용된 AWS Service Component를 하나씩 살펴 보고 S3에 m3u8을 올려만 놓고도 서비스가 가능한 pipeline을 왜 이렇게 복잡하게 만들어 놨는지에 대해서 알아 보도록 하겠음
※ 우선 그림을 그대로 가져오면 저작권 위반의 소지가 있으므로 AWS에서 Cloud Architecture 설계를 위해서 제공해 주는 아이콘을 사용하여 다시 그려서 사용해야 함. AWS Icon은 아래 링크에서 PPT 형태로 제공하고 있으니 참고하시기 바람.
https://aws.amazon.com/ko/architecture/icons/
AWS Live Stream 예제의 Service Component 구성이다.
뭔가 복잡하지만 있어 보인다. 그런데 문득 궁금증이 생것이다. 이렇게 복잡한 구성이 아니더라도 단순하게 S3에 업로드된 동영상에 대한 링크를 제공해도 웹브라우져들이 잘 보여줄 텐데…. 아래 그림의 구성처럼 말이지.
당연히 두 번째 그림 처럼 구성하여도 서비스를 사용할 수 있다. 하지만 저런 구성은 개인대 개인이 동영상을 주고 받거나 소규모 그룹을 대상으로 서비스 할 때 문제 없이 진행할 수 있는 방식이지 대규모 서비스를 위한 구성은 아닐 것이다. AWS 예제에서 제공하는 것은 다른 다양한 상황들을 극복할 수 있는 형태이다.
첫 번째 그림처럼 구성한다면 다음과 같은 것들을 해결 할 수 있다.
- Access Control
- World wide distribution
- Busting Traffic control
- Monitoring / Metering
- Multi-Resolution Service
- Live Stream QoS
와우… 참 많은 것들이 추가가 되었군! 이제 Service Component를 하나씩 살펴 보면서 어떤 Component가 이런 일들을 가능하게 하는지 살펴 보도록 하자.
AWS Elemental MediaLive
https://aws.amazon.com/ko/medialive/
사이트에 훌륭하게 설명이 적혀 있지만 간략이 요약해 보도록 하겠음, 공식 사이트의 내용은 범용성이 강조되어 있어서 부분을 이해하기가 어려울때가 있는 법이니… -_-;; AWS Elemental MediaLive는 원본 동영상을 방송이 가능한 다양한 형태로 변환을 해주는 Service Component이다. 동영상 변환외에도 많은 기능을 담당하고 있는데 홈페이지 내용을 그대로 가져와서 필자가 중요하다고 여기는 부분을 빨간색 테두리로 표시해 보았다.
다양한 방송 포맷으로 변환시켜주는 것은 대충(?) 짐작이 갔었다. 그런데 중요한건 이런 변환을 위해서는 반드시 Computing Resource가 필요하다는 것! S3에 파일을 올려 두고 Endpoint를 공유할때는 필요 없지만 다양한 포맷과 해상도로 변환을 하기 위해서는 반드시 변환(Trans-coding)이 필요한데 이를 위한 Code나 Computing Resource를 딱 필요한 만큼만 사용해서 변환해 준다.
오!!!!! 이런 귀찮고 어려운일을 돈으로 해결해 주다니! 역시 자본주의! ㅋㅋㅋ 각설하고 아무튼 변환에 필요한 모든 장치를 Element MediaLive에서 제공해주고 Pay-as-go로 지불만 하면 된다. 만약 변환을 위한 파일이 일정 수준 이상이 넘어 간다면 Pay-as-go가 문제가 되는 시점이 올 것이고 그전에 On-premise로 전환을 해야겠지만 초기 PoC를 위해서는 오히려 좋은 방식일 것이다.
그리고 다른 AWS Media Service들과의 Interface가 맞춰져 있다. 이 부분은 매우 중요한 부분인데 Interface가 맞지 않는다는것은 연결을 위해서 많은 노력이 들어 간다는 것이다. 해본 사람은 안다. 저게 어떤 지옥의 문을 여는 것인지를…
AWS Element MediaStore
Element Media Store는 Element MediaLive에서 변환 한 동영상들을 저장하는 Storage 이다. S3에 바로 저장하지 않고 중간을 거치는 것으로 봤을 때 분명히 쓰임새가 있음에 분명하다!
MediaStore는 MediaLive에서 변환된 동영상을 저장하면서 Access Control과 Caching Server 역할을 한다. 제어 관리의 경우 AWS의 IAM과 연동되고(이는 End User의 접근이 아니라 Client의 접근 제어이다. 테넌트 관리는 별도로 해야 한다.) Client를 식별하여 스트리밍을 제어 할 수 있다. Caching은 주기관리등의 복잡한 메카니즘을 AWS에서 대신 진행해 주는 것이다.
Amazon CloudFront
다음으로 살펴볼 Service Component는 CloudFront이다. 이 Component는 Media에 특화되어 있다기 보다는 AWS 전반적으로 사용되는 Edge Solution이라고 생각하면 된다. 그리고 우리가 잘 알고 있는 아주 유명한 단어의 AWS 버전이다. 바로 CDN(Contents Delivery Network)이다. 전세계에 원하는 Contents를 제공하기 위해서는 원거리에 있는 서버를 이용하게 되면 꽤나 큰 지연이 발생하게 되는데 CDN을 사용하면 근거리에 있는 CDN 서버로 부터 데이터를 받아 오게 되어 Client에서 빠르게 처리 할 수 있다.
지금까지 설명한 Service Component만으로도 사용자의 네트워크 상황에 맞는 해상도와 Busting time에 대한 대비도 되면서 세계 어디에서나 빠르게 접근할 수 있는 실시간 동영상 서비스를 제공할 수 있다.
Amazon CloudWatch
이렇게 서비스가 제공이 되면 궁금할 것이다. 어떤 동영상이 얼마나 많은 사람들에게 전달이 되고 있고 어디에서 많이 보고 있는지, 그역할을 해주는 것이 바로 CloudWatch 이다. AWS Console에서 CloudWatch를 확인해 보면 아래와 같은 화면을 만날 수 있다. 지금은 막 만든 예제여서 기록이 전혀 없지만(놔두면 돈이 많이 나가니… 바로 없애겠지만) 서비스를 운영하면 차곡 차곡 데이터가 쌓일 것이다.
마지막으로 S3에는 bucket이 새로 생성되고 전체 진행 중 발생하는 이벤트 로그가 Dump 된다.
위에서 설명한 내용들을 모두 종합해서 그려보면 다음과 같다. 전체를 모두 다 표시한 것은 아니고 필자가 중요하다고 생각하는 부분을 표시한 것이라서 빠진 부분이 있을 수 있으니 감안하고 보시기 바람
마치며
4~5번 정도 CloudFormation으로 만들었다가 없애기를 반복했더니 5천원 정도 과금이 되었다. MediaLive는 매번 Transcoding을 하니 이 Component가 가장 비용이 많이 나왔다. 확실히 개인이 테스트 해보기에는 부담이 되는 요금일 수 있다.
