오늘은 'Streaming Service' 라는 키워드를 가지고 국내의 스푼라디오의 사례와 이탈리아의 De Agostini의 사례를 살펴보겠습니다! ✨
1. 스푼라디오
소개
스푼라디오는 실시간 오디오 플랫폼입니다. 스마트폰만 있으면 누구나 언제 어디서든 DJ나 청취자가 될 수 있습니다. 스푼라디오의 고객은 DJ와 리스너로 구분이 됩니다.
아키텍쳐 다이어그램
아키텍쳐 설명
-
DJ가 ALB와 API Server로 라이브방 개설을 요청을 합니다. 라이브방 개설과 동시에 API Server에서는 Chatting Server로 채팅방 개설, Streaming server로는 라이브 스트리밍 서버 배정을 요청하게 됩니다. 이러한 모든 정보들은 RDS AURORA와 DOCUMENT DB에 동시에 저장이 됩니다.
-
리스너 입장에서는 실제 DJ가 생성한 라이브 정보의 개인피드를 받는 경우도 있고 실시간 랭킹 정보를 받는 경우도 있습니다. 이때 리스너는 API Server로 똑같이 어떤 방송을 들을 것인지 요청을 하게되면 API Server는 리스너가 원하는 라이브 채팅 정보와 스트리밍 정보를 전달하게 됩니다. 그러면 리스너는 Chatting Server에 접속해서 채팅을 보게 되고, CLOUDFRONT를 통해서 라이브 음원을 듣게 됩니다.
-
CLOUDFRONT의 백 단에는 NGINX가 있고, NGINX는 라이브 스트리밍 서비스를 바라보게 되는데 그 메타 정보는 ELASTICACHE redis를 통해서 확인을 하게 됩니다.
-
글로벌 서비스이기 때문에 네트워크 레이턴시가 가장 중요합니다. 그중에서도 dj와 스트리밍서버간의 네트워크 레이턴시가 가장 중요했습니다. 따라서 aws의 여러 리전에 스트리밍 서버를 구성하였고, ROUTE53의 레이턴시 기반 라우팅 정책을 사용해서 레이턴시 극복을 최소화하고 있습니다.
-
ELASTICACHE Redis를 3가지 용도로 사용하고 있는데 첫번째로는 리스너에게 실시간랭킹 정보를 전달하는데 사용하고 있습니다. dj가 API Server로 방을 개설하는 경우, 그리고 리스너가 실제 그 방에 참여하는 경우와 같은 모든 정보를 API Server에서는 ELASTICACHE Redis에 저장하여 실시간 랭킹 정보를 리스너에게 전달하고 있습니다.
-
두번째에는 채팅 서버에서 사용하고 있는데, 채팅서버의 pubsub을 ELASTICACHE Redis를 사용하여 처리하고있습니다. 마지막으로 스트리밍 서버의 다이나믹 라우팅에 대해서도 ELASTICACHE Redis를 사용하고 있습니다.
-
dj와 리스너간의 교류하는 모든 정보들은 기본적으로 RDS AURORA에 저장이 됩니다. 그와 동시에 사용자가 일으키는 모든 서비스 행태들은 DOCUMENT DB에 저장이 되고, RDS AURORA와 DOCUMENT DB를 통해 개인화된 피드를 구성하여 사용자에게 개인 맞춤형 추천 라이브 정보를 제공하고 있습니다.
-
dj중 일부 dj분들이 배경 이미지를 불건전한 이미지를 올리는 경우가 있기 때문에, 사용자가 올리는 모든 컨텐츠들을 S3에 저장하여 동시에 LAMBDA가 트리거가 되고, 이 LAMBDA에서는 RECOGNITION CONTENTS MODERATION 을 사용해서 그 이미지가 건전한 이미지인지 불건전한 이미지인지 판단하게 됩니다. 그 이미지가 불건전한 이미지인 경우 사용자에게 노출이 되지 않도록 처리하고 있습니다.
2. De Agostini
소개
De Agostini는 비디오 플랫폼으로 온디맨드 영상 콘텐츠와 라이브 스트리밍 영상 콘텐츠를 모두 가지고 있습니다. 1901년 설립된 De Agostini는 출판업과 미디어 산업에서 활발합니다. 미디어파트로는 특히 Digital De Agostini가 tv채널과 웹사이트, 모바일앱등을 관리하기 위해 10년 전에 설립되어 매달 수백만 건의 스트림 뷰를 배포합니다.
아키텍쳐 다이어그램
아키텍쳐 설명
-
크게 두개의 워크플로우로 나누어지는 De Agostini 비디오 플랫폼의 배포 아키텍쳐에 대해서 설명하려고 합니다. 하나는 컨텐츠의 업로드를 위한 것이고, 다른 하나는 배포를 위한 것입니다. author가 멀티미디어 콘텐츠의 업로드를 결심하였을 때 모든 work가 시작합니다. 그들은 EC2로 동작하는 중앙집중화된 플랫폼에 접근하여 콘텐츠와 관련 메타데이터를 업로드합니다. EC2에 의해서 처리되면, 오브젝트 스토리지인 S3 버킷으로 이동합니다.
-
그러고 나면, process function이라고 불리는 LAMBDA로 조정되는 첫번째 STEP FUNCTION이 시작됩니다. 이는 S3버킷에 업로드된 멀티미디어 콘텐츠들을 검증하는 역할입니다. 그리고 더 중요하게 Elastic Transcoder를 통하여 프로젝트 세팅 프로필을 전형적으로 low, medium, high 품질로 생성합니다. 이는 고객들마다 다른 포맷입니다.
-
다른 중요한 프로세싱 단계는 멀티미디어 콘텐츠의 음성을 텍스트로 바꾸는 TRANSCRIBE를 사용하여 이 콘텐츠의 메타데이터를 풍부하게 합니다. 이러한 음성-텍스트 작업을 통해 콘텐츠를 풍부하게 하고, 검색 엔진에서의 콘텐츠의 위치를 향상시킵니다.
-
LAMBDA와 함께 조정되는 두번째 STEP FUNCTION은 S3에서 S3로 다시 이동되지만 최종 대상 버킷에 포함되어 CLOUDFRONT로 전파되는 내용을 에 게재합니다. 이것은 온디맨드로 제공되는 영상 콘텐츠를 위한 것입니다.
-
De Agostini는 M3U8 형식의 텔레비전 방송으로부터 이 신호를 CDN으로 가져와 CDN에 연결된 수천 명의 사용자들에게 방송함으로써 사용자들을 라이브이벤트와 콘텐츠들로 분배합니다.
아키텍쳐 장점
- 이 아키텍쳐의 장점은 인프라 관리입니다. 배포 부분이 운영을 간소화하고 높은 수준의 사용자 경험을 줄 수 있는 확장 가능한 서버리스이기 때문입니다.
Amazon CloudFront란? 개발자 친화적 환경에서 짧은 지연 시간과 빠른 전송 속도로 데이터, 동영상, 애플리케이션 및 API를 전 세계 고객에게 안전하게 전송하는 고속 콘텐츠 전송 네트워크(CDN) 서비스입니다. CloudFront는 네트워크 및 애플리케이션 계층 DDoS 공격을 비롯해 여러 유형의 공격으로부터 보호하기 위해 AWS Shield, AWS Web Application Firewall 및 Route 53와 완벽하게 통합되어 필드 수준 암호화 및 HTTPS 지원을 포함한 대부분의 고급 보안 기능을 제공합니다. Amazon CloudFront는 고도로 확장 가능하며 전 세계에 분산되어 있습니다. CloudFront 네트워크에는 225개 이상의 PoP(Point of Presence)가 있습니다. 이는 AWS 백본으로 연결되어 최종 사용자에게 매우 짧은 지연 시간 성능과 높은 가용성을 제공합니다.
