【レポート】AWS Summit Tokyo 2017: [CyberZ] OPENREC.tvにおけるライブ動画およびメッセージ配信基盤のリプレース全貌 #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年06月1日に行われた『[CyberZ] OPENREC.tvにおけるライブ動画およびメッセージ配信基盤のリプレース全貌 』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

セッションレポート

以下、セッションのレポートです。

発表資料はこちらに公開されています。

今回の発表のポイント

• 「ライブ」を支えるアーキクティングの紹介
• OPENREC.tvのアーキテクチャの経緯

OPENREC.tvの紹介

ゲームに特化した動画配信メディア e-sports大会やオリジナル番組など MAU 110万人

「ライブ」配信に重要な要素

• live streaming
• realtime messaging

動画配信の種類

• オンデマンド配信
  • 見たいとき
• ライブ配信
  • リアルタイム

配信方針

• progressive download
  • 一つのまとまったデータをDL
• streaming
  • メディアデータを細かく分割
  • ライブ配信に対応可能
• VOD / LIVEともにstreamingが主流

配信サイド

• RTMP w/ H.264の組み合わせが主流
• エンコードはクライアント側で行う
  • 様々なフォーマットがある

受信サイド

• ストリーミング型
  • 専用プレイヤーが必要
• HTTPストリーミング型
  • webクライアントで動く
  • ブラウザで再生可能
  • 一般的なcache技術を利用しやすい
• HTTPストリーミングが現在の主流
• Adaptive Bitrate Streaming
  • ユーザの回線状況によって画質を自動調整する技術
  • 配信メディアを帯域に応じて複数用意
    • live transcodingを使う
      • WOWZA STREAMING ENGINE など
• Live Streamingのアーキテクチャ
  • Media ServerでTranscode / CDNで配信
  • 最近ではwebRTCでの配信も
• Time Shifting
  • 視聴者がライブ動画を後から見返したい
  • 配信停止 -> アーカイブをアップロード -> CDNから配信
• 動画サービスはお金がかかる...

Openrecでの事例

• 要件
  • 高画質・低遅延
  • 配信はユーザドリブン
    • 集客力は配信者次第
      • 負荷が読みづらい
  • 同時視聴者数: 無制限
• 構成 c4, g2を並行 - GPUアクセラレータでtranscodingを効率化 - 「同時配信数」に応じてEC2を拡張/縮退
  • elastic trancecoderでVOD/アーカイブの変換

配信環境の歴史

• 2014 - 2015
  • スマホ特化のプレイ動画共有サービスとしてスタート
  • iOS, Androidから録画
    • SDKの開発に注力
• 2015-2016
  • live配信開始
    • 小さく始める : zencoder liveを活用
    • 大きく進める : 2016年からLIVEに注力。
• 2016 Mid - Later
  • アーカイブ機能の課題
    • VOD化に要するリードタイム
      • ライブ終了後にETSで再TranscodeしてS3に永続化
        • 24時間配信だと変換にかかる時間が...
• 2016 Later
  • Wowza MPEG-TS Ingestion Listener API
    • 配信時にメモリにあるHLSを抽出し、S3バケットに保管
      • 即時アーカイブ
• 2017 Early
  • ローリング デプロイ/メンテナンスの煩わしさ
    • 配信中のサーバはライブ終了まで落とせない
      • ユーザ手動のため、いつ終わるかわからない
  • wowza を揮発化
    • コンテナに寿命を設定
      • 寿命がきたら、新規配信は受け付けない
        • 全ての配信が終わったらコンテナをローリング
      • EC2/ECS Auto Scalingはメディアサーバと相性が悪い
        • 負荷が低くても縮退できない
        • 「配信状況」というメトリクスに基づいてスケジュールする必要
          • CloudWatch Events + AWS Lambda
            • これから

メッセージングの歴史

• 要件
  • リアルタイム性
  • スケーラビリティ
• 2015
  • node.js + redis + API
  • WebSocketを自作APIで分散
    • ELBが(当時)WebSocket非対応のため 煩わしさ
    • Not AutoScaling
    • EIP + DNS
• 2016
  • ALBがリリース
    • Websocket対応
    • Content Based Routing対応
  • ALBを活用して
    • Content Based Routingを活用したSharding
    • AutoScalingを導入

WebSocket w/ AutoScalingのポイント

• 早めにスケールアウトさせる
  • 接続が持続型なので、接続数が増えてからだと遅い
    • 接続が飽和したインスタンスはそのまま
• 重要な指標
  • 同時接続数
  • メッセージ流量
  • メッセージサイズ
• Scaling Policy
  • CPU Utilizationがおすすめ
    • Increaseは敏感、Decreaseは緩く
    • ピーク帯に合わせてScheduled Policyが有効

OPENREC.tvの成長

• スタートアップの各ステージに従って成長してきた
  • 検証による学習
  • 実験による方針変更
  • 成長への集中
• アーキテクチャをなぜ4度も作り直したか
  • 最善にこだわって検証サイクルを遅くするのは本末転倒
  • 小さく初めて、大きく育てる

感想

配信という分野でのAWSに関するアーキテクチャや知見がとても新鮮で面白かったです。また、スタートアップでのビジネスの考え方についても最後にまとめられていて興味深かったです。