Live配信のワークフロー takusuta tech conf #1
•Télécharger en tant que PPTX, PDF•
2 j'aime•9,162 vues
takusuta tech conf #1 でプレゼンしたスライドです。 Live配信とアーカイブ化について触れています。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Live配信のワークフロー takusuta tech conf #1
Similaire à Live配信のワークフロー takusuta tech conf #1 (20)
Live配信のワークフロー takusuta tech conf #1
- 2. INTRODUCTION 自己紹介 > 2011年 CyberAgent 中途入社 > PC ピグゲーム(ピグ/ピグワールド/ピグライフ)の開発・運用 > 現在、ライブ配信動画サービス「Takusuta」を立ち上げ、運用中 杉山 仁則 (Yoshinori Sugiyama) ENGINEER 株式会社 タクスタ 従業員代表 @ syama666 #python #js #aws #node.js #mongodb ...
- 4. 動画基盤 HTTPS HTTPS Amazon SNS(HTTPS) HLS downstream(AWS Cloud Front) RTMP upstream(wowza) サービスと動画基盤の概要
- 6. 動画基盤 create stream RTMP url & key の発効 配信準備 live_ready
- 8. 動画基盤 live_end RTMP upstream disconnect destroy stream RTMP url & key の無効化 配信終了
- 9. 動画基盤 RTMP upstream disconnect destroy stream RTMP url & key の無効化 配信終了(時間切れパターン)
- 11. What’s Amazon Elastic Transcoder? MP4をHLS(playlist + ts files)に変換 参考URL http://www.slideshare.net/AmazonWebServicesJapan/20131120-aws- medisterregeneratecloudfrontetspublic
- 13. What’s AWS SNS? SQS, HTTP(S)と連携可能 参考URL http://docs.aws.amazon.com/ja_jp/sns/latest/dg/SendMessageToHttp.html
- 14. attribute name example of attribute value 備考 applicationID takusuta サービス毎にユ ニークな値 streamName 8aed684929914b0a9edec26afefa1e0e@1436750704941 番組のキー SQS Attributes format
- 15. プロセス キュー名 処理の内容 transcode_ready queue_transcode_ready_[host ip] エンコードの準備 wowzaが出力したmp4をs3に uploadする wowzaとworkerのhostが一致する 必要があるのでキュー名のsuffix にipをつけている transcode_doing queue_transcode_doing エンコード実行 Elastic TranscoderのAPIを実行す る transcode_end queue_transcode_end Elastic Transcodrからの通知を受 け取る transcode_end_notify queue_transcode_end_notify サービスにSNS経由で通知する SQS queue & worker process
- 19. 配信サーバ transcode_end_notifyの処理 dequeue: queue_transcode_end_notify notification to HTTPS endpoint
- 21. ご静聴ありがとうございました
Notes de l'éditeur
- 配信サーバ。Wowzaのことです。RTMP配信したり、視聴側のためにHLSに変換したりするコアなところです。 Python製のWorkerプロセスがあります。live開始・終了、トランスコードの準備・開始・終了・終了の通知と、それぞれ個別の役割をもち、別々のキューをポーリングしています。 配信サーバに同居する形で、複数のプロセスが起動しています。 APIサーバは番組のステータス管理や配信URLの払い出し等行います。とても役割として小さい部分なので、この後の説明にはほとんど登場しません。 Golangで作った意味も今となってはほとんど無いです。いい思い出です。
- 各サービス、ここでは宅スタと動画基盤との連携の全体的な概要を説明します。ラジ生やアメスタについてもこれとほぼ同様であると思っていただいて大丈夫です。 iOS/Android/Webのクライアントサイドとやりとりするのはほとんど宅スタのサーバです。 RTMPの配信とHLSでの視聴については動画基盤のサーバ、もしくはCloudFrontにアクセスします。 それ以外でクライアントから直接動画基盤と通信することはありません。
- LiveとVODについて、配信と視聴の関係がどうなっているか簡単に図でしめしました。 LiveはWowzaでHLS変換を行い、Cloud Frontにのせて配信します。 VODはWowzaがレコーディングしたMP4をAWS TranscoderにかけてS3に保存し、Cloud Frontにのせて配信します。
- ここからは配信者の視点で説明いたします。視聴者はCloud Front経由で配信されたHLSの動画を再生されるだけなので特に説明はしません。 配信するにはまず宅スタの live_ready APIを叩きます。宅スタサーバーから動画基盤のcreate stream APIを実行し、RTMPのURL（どのWowzaから配信するか）と、配信サーバでRTMPするためのアクセスキーが発行されます。 アクセスキーには有効期限がついていて、その有効期限は任意の値にすることが可能です。 宅スタは30分を一枠としているので有効期限も30分です。
- 次に配信開始について。クライアントから宅スタサーバのlive_doing APIが実行されます。 配信準備の時点で動画基盤的に配信可能な状態になっているので、あとはクライアントからRTMP通信がされればCloud Front経由で番組が配信されます。
- 次に配信終了について。こちらには2つのパターンがあります。まず配信者が30分の期限を待たずに任意のタイミングで終了させた場合です。 宅スタの live_end APIを実行します。宅スタサーバから動画基盤に向けて destory stream APIが実行されます。これにより該当の番組のURLやキーが無効化されます。 クライアント側からRTMPを切断します。
- 次に時間切れで番組が終わる場合です。配信サーバのWowzaには自作プラグインでワーカスレッドを立てており、それぞれの配信サーバのstreamの有効期限を監視しています。 有効期限が過ぎた番組はWowza側からRTMPのセッションを切断されます。
- Liveが終わり、番組がアーカイブ化されるまでのフローを説明します。 登場人物は配信サーバ(WowzaとPythonワーカープロセス)とサービス（宅スタ）と、AWS（SQS/SNS/S3/TransCoder）です。 ここでのワーカープロセスの役割は非常に大きい物になっています。個別の小さな役割のプロセスをたくさん立てて、シンプルでスケーラビリティに強い仕組みにしています。
- Elastic Transcoderはクラウド上で動画のエンコーディングを行ってくれるサービスです。 ソースとなるデジタルコンテンツをS3のバケットに配置して、指定した形式での動画ファイルを指定したバケットに出力してくれます。 mp4をソースコンテンツとし、HLS形式でのファイル郡を出力してもらってます。 またSNSと連携することで、ジョブ完了時通知を受け取ることができます。
- SQS。シンプルでマネージドなメッセージキューサービスです。詳しくは公式ドキュメントか、参考URLを御覧ください。
- Amazon SNSはプッシュ通知してくれるサービスです。 SQS, HTTP(S), emailなど、多くのサービスやプロトコルと連携できます。 宅スタではHTTP(S)連携を使用しており、アーカイブ化完了した際に通知を送ってもらっています。
- SQS で扱うメッセージのフォーマットについて SQSのメッセージには本文とは別にアトリビュートという領域が使えます。 各サービス、例えば宅スタならtakusutaといったような個別のユニークなapplicationIDと、番組のIDを入れてメッセージを飛ばします。 これで、各workerはどのサービスのどの番組を処理するのか判断します。 全てのキューがこのフォーマットを使用しています。
- transcodeに関わるworkerプロセスとそれぞれの内容についてです。 それぞれのプロセスはそれぞれのキューだけをポーリングして、メッセージを受け取り、最小限の処理だけ実行して次のキューにメッセージを投げます。
- transcode_readyを図と一緒に説明します。 配信が終わった番組を管理してるWowzaからSQSにキューが投げられます。これは先程説明したように配信サーバ毎にキューが作られているので、Wowzaと同じインスタンス内にあるtranscode_ready workerだけがこのメッセージを受け取れます。 メッセージを受け取ったworkerは、mp4をs3バケットにuploadして、次のtranscode_doingのキューに向けてメッセージを投げます。
- 続いて、実際にElastic TranscoderへJOBをPOSTするworkerについて 先ほどキューイングされたtranscode_doingへのメッセージを受け取ったworkerがElastic TranscoderへJOBをPOSTします。 次のworkerが受け取るキューはTranscoderがSNS経由でenqueueするので、JOBをPOSTして処理終了です。
- 続いて、エンコードが終了すると、TranscoderがSNSから通知します。予めSNSをtranscode_endのキューと連携させる設定をいれています。 transcode_endキューをポーリングしているworkerは次のtranscode_end_notifyへ向けてenqueueするだけして処理終了です。
- 最後にtranscode_end_notifyのworkerはSNS経由して各サービスへ動画のエンコードが終了した旨を通知します。
- 質問タイム