この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは！おおはしりきたけです。今日は、TECH PLAY Conference 2017の急成長する動画市場に参加して来ましたので、セッション3のコーナーのレポートです。
今までのレポートは以下になります。
- VRが創り出す世界 - TECH PLAY Conference 2017 -
- 日常化されていくIoT - TECH PLAY Conference 2017 -
- デジタルマーケティング - TECH PLAY Conference 2017 -
イベント概要
TECH PLAY Conference 2017 - 急成長する動画市場のイベント概要は以下になります。
スマートフォンの急速な普及に伴って加速する動画市場。国内のインターネット動画広告市場は、2013年には132億円、2017年には約5倍の640億円にまで拡大しています。 そんなマーケットで、今まさにサービスを急成長させている企業をお招きし、ビジネス・UIUX・技術 の面から各社がどのような取り組みをしているかお話し頂きます。
kurashiru リリース当時の裏側と動画アプリのグロース戦略
登壇者：dely株式会社 大竹 雅登 氏
kurashiruサービス紹介
- kurashiruは2016年2月頃リリース
- 2つの「作りたい」に答えるレシピ動画サービス
- 3月にテレビ番組で紹介されトラフィックが増え、その後テレビCMをうって更にトラフィックが増えてきた
- レシピ動画数が世界でNo1(2017/8月24日時点)
分散型メディア時代のkurashiru
- 主要SNSに動画を直接投稿
- Webサイトやアプリを持たない
- 動画リーチ数の最大化が目的
動画サービスをゼロから3週間で作る方法
- kurashiruアプリの開発着手
- 開発メンバーは1人
- 動画は自社でホスティングして配信したい
- 3週間位でリリースしたい
- 仕様は「いい感じ」
- HTTP Live Streaming(HLS)配信
- ダウンロード再生
- ダウンロードが終わってから再生させるため重い
- プログレッシブダウンロード再生
- 途中まで読み込んんだら再生される
- 1分の動画があれば10秒くらいで分割する
- HLSフォーマット
- 自社のトランスコーダーを作ると時間がかかるため、AWSの Elastic Transcoderを使った
- ダウンロード再生
- AWS Elastic Transcoder
- AWSのクラウドのメディア変換サービス
- スケーラブル、安定稼働、従量課金、簡単に導入可能
- MP4ファイルをHLS形式に変換してS3に配置
- AWSのクラウドのメディア変換サービス
- その他もろもろを最速で実装
- 管理画面のviewはtypusを使って時短
- APIのフォーマットはJSON APIに則ることで時短
- PaperclipでS3アップロードとElastic Transcoder変換
- デザインは、Sketchで最小のコンポーネントを作って使いまわす
- iOSの実装は、とにかく集中して頑張る
- 結果
- 1週目：アーキテクチャ設計とインフラ構築
- 2週目：動画入稿用のAdminとAPIサーバー実装
- 3週目：Sketchデザイン作成とiOSの実装
- 4週目：リリース！
コンテンツ内製型のAdmin機能
- 内製型の動画サービス運営の難しさ
- 業務フローが複雑
- 企画→テキスト情報入力→撮影→編集→入稿
- 撮影者と編集者の密なコミュニケーションが必須
- 撮影者の意図を汲み取って、動画内のシーンを作っていく
- 効率化して短い時間で多くの動画を制作できる体制づくり
- 制作のボトルネックを見つけ出し改善をしていく
- 業務フローが複雑
- ボトルネックを見つけるために、スタッフさんごとのデータを計測
- Admin内のコンテンツ検索機能
- 編集待ちとかステータスの状態を分かるようにする
- 目標を3ヶ月毎に設定して、分析できるようにしている
- チームとして生産体制が見えるようにしていく
アプリのグロース戦略
- サービスドリブンで考える文化
- データをしっかり分析するし、ヒアリングもする
- 根拠に基づく意思決定を積み重ねる
- なんとなくで意思決定する怖さ
- 施策の成功確率が低い
- 成功しても失敗しても再現性がない
- 組織的に成功率を高める仕組みが作れない
- 根拠をつくるための情報源を増やす
- ユーザーの行動ログを基にしたデータ分析基盤
- 稼いつ検証を高速に回すためのABテスト基盤
- なんとなくで意思決定する怖さ
- リテンションとユーザーの積み重なり
- 良いリテンションレートは積み重なっている
- 積み重なるリテンションカーブ
- 良いリテンションは最初落ちるけど、最終的にフラットになる
- キーワードごとの直近1週間の検索回数と離脱率
- 検索したけど1件も動画見ない人を離脱したとみなす
- 「なす」が今の季節は人気で検索の場合、「なす」のレシピが少ないのか、「なす」の表記ゆれがあるか？
まとめ
- 動画サービスを開発するのは難しいが、便利なサービスを組み合わせれば1人でも作れる
- 動画を内製するタイプの場合、開発と同じくらい制作体制の効率化が事業インパクトが大きい
- 動画というだけで流行るほどあまくない。しっかりとしたグロース戦略がやっぱり重要
1周年を迎えたAbemaTVの動画配信の裏側
登壇者：株式会社サイバーエージェント 山中 勇成 氏
AbemaTVとは？
- 24時間365日のリニア型放送を行う、インターネットテレビ局
- ニュースやアニメ、スポーツなど約25チャンネルを視聴できる
- PC、タブレット、スマホ、テレビデバイスなど様々なデバイスで楽しめる
- 2015年4月11日に開局した
- アプリ2000万DL
- 今まで29万番組
- 1日30億のリクエスト
AbemaTVを支える技術
- AbemaTV（サーバサイド）で仕様している主な技術は、Google Cloud Platform（GCP）＋Kubernetes（k8s）+ Golang
- Google Cloud Platform（GCP）
- AbemaTVの殆どのインフラはGCP
- CloudStrage：動画ファイル、セグメント、サムネイル等
- ComputeEngine：varnish、redis、mongo,wowza
- BigQuery：アクセスログ
- BigTable：視聴履歴データ
- Pub/Sub：アクセスログ、行動ログ、通知等
- Network：DNS、GLB等
- AbemaTVの殆どのインフラはGCP
- Kubernetes(k8s)
- Googleのエンジニアによって作られたコンテナ管理プラットフォーム
- デプロイ、ローリングアップデート、スケーリングのスケジューリングを行ない、適切にpodの台数やリソースを管理してnodeに配置する
- 自分で組むと大変だが、GCPでは、Google Container Engine（GKE)としてマネージドなKubernetesクラスタが提供されている
- 840instance、230nodes
- 半分は本番、半分は負荷テスト用
- Microservices
- AbemaTVでは、マイクロサービスアーキテクチャを取り入れており、約40のサービスが稼働している
- サービス間の通信が必要な場合はgRPCを仕様している
- Deploykun
- AbemaTVのChatOpsボット
- Slackでサービスのリリース作成、デプロイ、スケールなどが可能
- Golang
- サーバーサイドはGolang
- 社内でいくつか運用実績
- 新しいもの好き
- シンプルな言語仕様
- Codeship(CI)
- 以前はCircleCiを利用していた
- Golangのユニットテストを並列で実行している
- Codeshipはコンテナを並列で動かすことができるので、インテグレーションテストの環境が比較的楽にできる
- まとめ
- AbemaTVのサーバーサイドの構成は、GCP+k8s+Golangの構成
- サービスのデプロイでは、ChatOpsを採用し、基本的にPRからデプロイを1人のエンジニアが行う
AbemaTVの生放送が視聴できるまで
- AbemaTVの配信種別
- 収録と生放送がある
- 配信種別は以下
- リニア
- タイムシフト：リニアの過去のアーカイブ
- ビデオ：自由な好きな時に見れる
- 今日はリニアの生放送の話で、AbemaTVの生放送が視聴できるまでの流れは以下
- 現場から送出
- 現場の映像は、Wirecastを通してエンコードし、GCP上のWowzaへストリーミング
- プロトコルとして、RTMPやRTMP over Zixiが使われる
- エンコード＆パッケージング
- Wowzaでは、ストリーミングされてきた映像をAbemaTVで仕様している各種解像度毎に再エンコードし、HLSへのパッケージングも行う
- 生放送管理画面で行ったCMの送信、投票の開始などの操作もHLSのメタ情報に埋め込む
- これを実現するために、独自の拡張を導入している
- 監視＆保存
- Watchmanは、HLSを監視してセグメントを保存するサービス
- Watchmanでは、プロセスごとの担当番組を決め、該当番組のWowzaが出力するプレイリストを取得し、セグメント情報をmongoDBへ、TSをRedisとGCSへ書き込む
- 開局当初は、GCSへの書き込みだけだったが、冗長化のためにRedisを利用している
- 配信＆広告挿入
- ユーザーが映像を再生するためのプレイリストやTSのエンドポイントを持つサービス
- プレイリストのアクセスに対して、DBを参照して現在のチャンネルの放送すべきセグメントを計算して、収録や生放送、SSAI広告のTSパスをまとめたm3u8プレイリストを生成する
- TSのアクセスに対して、RedisがGCSを参照して返す
- 配信からユーザーまで
- Clientは、MediaProxyのプレイリストを取得して再生する
- TSファイルは、Akamai（CDN)を通して取得する
- まとめ
- AbemaTVでは、リニア型の配信やSSAIのために独自システムのレイヤーを挟んで動画配信を行っている
- 独自のシステムでは、HLSをベースに動画の取得と配信を行っている
- CM挿入や投票機能を映像と同期して行うため、パッケージャーの時点でHLSにそれらの情報を埋め込んでいる
MPEG-DASH対応
- DRM技術に対応したコンテンツの配信を行う必要があった。
- DRMはデバイスごとの対応が異なり、DRMによって必要な配信形式も異なる
- MPEG-DASHのマニフェスト
- MPEG-DASHには、MPDと呼ばれるマニフェストファイルとMP4を数秒の細かいチャンクに区切ったfMP4(fragmented MP4)が必要
- HLSのリスト型とは異なり、MPEG-DASHはテンプレートを書いているような感覚
- MPEG-DASHには、MPDと呼ばれるマニフェストファイルとMP4を数秒の細かいチャンクに区切ったfMP4(fragmented MP4)が必要
HLSとMPEG-DASHのファイル取得
AbemaTVでfMP4を生成する
- fMP4は、ffmepeg、Bento4、MP4Boxなど様々なツールで作成できる
- 収録されたコンテンツは予め予測できるが、生放送のコンテンツはリアルタイムで変換する必要がある
- AbemaTVでは、予め区切られたTSファイルをMP4に変換し、Initial SegmentとMedia Segmentに分ける
まとめ
- 生放送の番組では、リアルタイムにTSからfMP4へトランスコードして、MPEG-DASHに対応している
- MPEG-DASHのMulti-Periodで広告やコンテンツを区切っている
Q&A
- Q：セグメントファイルをRedisに保存しているのはなぜか？
- A：GCSだけでもいいが、冗長化と高速化のためにRedisを使った
- Q：Live配信の遅延はどの位あって、対策などしているか？
- A：様々なレイヤーを挟んでいるため、遅延は30秒程度ある
- A：コメントの同期などは、デバイスごとに違うが対応は特にしていない
Hulu の取組み
登壇者：HJホールディングス株式会社 須加 知也 氏
Hulu紹介
- 2008年：米国にて動画配信サービスをスタート
- 2011年：日本国内でサービス開始
- 2014年：日本国内のサービス事業をHJホールディングスが承継し、日本テレビのグループ会社になった
- 2017年：配信プラットフォームを移行
- 現在40000万本以上のコンテンツを配信、VODのみではなくリアルタイム配信も実施している
Huluのサービス概要
- 配信は40000本（VOD
- 国内バラエティの視聴も多い
- 圧倒的に高いアクティブ率
- アクティブ率を高めることを重視している
- リアルタイムの配信も行っている
- 日本のプラットフォームに移行してからアグレッシブに取り組めるようになった
- 昨年はNFLやコンサートなど
- 最近では、映画「HiGH&LOW THE MOVIE 2」の舞台挨拶も配信
- オリジナルコンテンツの開発
- ドラマ、バラエティなど色々やっている
- マルチデバイス
- テレビ
- ブルーレイレコーダー
- ゲーム機
- コネクテッドデバイス
- 150万会員（2017年4月時点
- 使われているデバイスの変化
- 2011年はPCが多かった
- 2017年はMobileが増えてきた
- ユーザー数としては同じだが、比率としてはPCが少ない
- デバイスの使われ方の違い
- Mobileは比率は高いが、短時間の視聴が多い
- Livingは比率自体はMobileより低いが、長時間の視聴が多い
配信の仕組み
- コンテンツ受入から配信まで
- コンテンツ入稿：高速ファイル転送の仕組みを利用しセキュアに
- メタ情報、アート、字幕
- トランスコード：複数の解像度、ビットレードを運用
- 解像度的には7〜8パターンで運用 一番上はフルHD
- パッケージング
- 複数の配信フォーマット、を使っている
- SmoothStreamingは古い仕組みだが、デバイスによっては対応が必要
- VODをやる上でDRMは必須
- アナログ出力は行っていない
- アナログ出力は今後認めにくくなっていく
- 良いコンテンツを出すためにはセキュアにする必要がある
- 配信システム
- ユーザーまで動画を届ける
- ユーザーリクエスト；ユーザー判定、同時再生の判定
- CDN：キャッシュヒット率の向上→オリジン側の負荷を軽減
- 地理制御：国内サービスなので判定を実施
- リアルタイム配信：Akamaiのリアルタイムサービスを使っている
- ユーザーまで動画を届ける
UI/UX、プレイヤ、アプリ
- ユーザーが動画を楽しめるように
- UI/UX
- デバイスごとの特性を考慮したデザイン
- エディトリアル、リコメンド→常に改善を実施していく
- プレイヤ開発
- 通信状況に応じて最適な動画再生
- DRMパラメータに応じた再生、トリックプレイ、字幕（日本語字幕は独特
- クオリティ状況のフィードバック機能
- 各種アプリ開発
- iOS、Android、FireTVなど
- UI/UX
- ユーザー情報の管理と運用
- サインアップ
- ユーザー情報、決済情報の管理（各種決済システムとの連携）
- 以前のユーザーであるかの判定
- プロフィール
- マルチプロフィール設計 → 履歴などの管理ができる
- データ分析とレポーティング
- グロースにも使う
- コンテンツパートナーへのレポート
- カスタマーサポート・システム
- 限られたアクセスを実現している
- サインアップ
- 今後の取組
- 4K、HDR、VR、サラウンドなど
- 技術面での検討は行っているが、その問題解決とサービスでの対応は別の問題
- ユーザーの皆さんの望むかたちは何かをイメージすることが肝心
- しかし、保守的な訳ではなく、時にチャレンジをする事は重要
テレビ×インタラクティブ 新たな価値を創出するソリューション
登壇者：HAROiD inc. 小野寺 正実 氏
HAROiD紹介
- 日本テレビとバスキュールで立ち上げた会社
- テレビとネットを融合させて新しい視聴体験を提供
- Platform
- LiveCM
- TV-DMP
- O2O2O
- CHARiN
LiVE CM
- 通常のCMの効果に加えて視聴者がCMに参加するサービス
O2O2O
- リアルなウリに直結させるためのソリューション
テレビはのコンテンツとしての力
- 全世帯がテレビを持っていると仮定すると1%でも575,000世帯に一瞬でリーチできる
- バルス祭り
- 秒間14万ツイート
- テレビをみんなで見ているから盛り上がる
- テレビは誰かと同時に楽しめるエンターテインメント
- テレビの圧倒的なリーチ力と、ネットを融合させると新しい何かが生まれる
- テレビを起点とする新しいソリューションの提供
- コンテンツの価値を上げる
- 新しい価値を生み出す
- ユーザーにも新しい視聴体験
O2O2O
- テレビ試聴→クーポンゲット→リアル店舗
- LiveCMはO2O2Oの一部
LiVE CM
- 商品体験機会の創出
- ブランド好意度のリフトアップ
- 新しい試聴体験とオトクを提供する
トラフィック
- 10,000rps以上
- 数百万のアクション数
- 6万本のクーポンコードを20分で配布
何が必要か？
- スケーラブルでアクセスに対応できるインフラ
- 大量のユーザーアクションを集計するアプリケーション
- 殺到するクーポン応募に対応するアプリケーション
- リアルタイムな放送(CM)に集計結果をフィードバック
- 構成はシンプルだが高負荷でやるのは大変
- テレビの告知はスパイクアクセスが発生する。急激なトラフィック
- 秒単位で上がっていく
- 急激なスパイクと膨大な同時接続
- スパイクの程度が予測しにくい
- どのくらいスケーラブルにするかが重要
- リアルタイム性
- ミッションクリティカル
- 失敗はできない
- 結果として開発難易度は上がる
- アクセスへの対応
- 一発勝負
- 瞬時に勝負が決する
- 60秒のCMだと、障害の対応する時間はない
- アクセスを予測する
- 視聴率などからフェルミ推定を行う
- 最大参加ユーザー数
- 最大アクセス数
- 最大リクエスト数
- アクセスの推移
- アクションの推移
- など実データを積み重ねて、推定値と実測値のギャップを埋めていく
- アクセスによる影響範囲の影響を検証する
- コンテンツアクセス
- コンテンツ配信
- 参加アクション
- 残クーポン数の表示
- クーポン応募
- 応募受付
- クーポン発行
- メール配信
- コンテンツアクセス
- 関連プロアクトをすべて洗い出し、検証
- CDN帯域
- アプリ、DB
- サーバーはリニア
- ユニークなクーポン
- クーポン数を数万クライアントが参照しても大丈夫か？
- メール配信は大丈夫か？
- 各サービスへどの位のアクセスあるか？
- 負荷試験
- 状況を完全に再現したい
- 既存の攻撃ツール
- 状況を再現しにくい
- シナリオごとのデータを保持できないあ
- 手間がかかる（コストや設定）
- HAROiD謹製負荷テストツール
- Punisher
- 想定されるスパイクを再現
- 柔軟なシナリオ設定
- 千手観音
- アクセスパターンの再現
- 低コスト
- Punisher
- 上記のツールを用途によって使い分け事前に負荷によるリスクを回避しオンエアに対する安心感を得る
- 高負荷状態でUX検証なども行う
- 視聴率などからフェルミ推定を行う
リアルタイムCG
- アクションデータをリアルタイムにCG生成して合成
- テレビ局の副調整室からそのまま放送波へ
- 集計→Fll信号、Key信号→CG合成
- Fill信号：塗り
- Key信号：抜き
- リアルタイムにパーティクルも塗りと抜きを配信
- アクセスに備えて安全にミッションを終える
- これを日々やる
まとめ
- テレビの視聴データやメタデータを使ってCM見たら商品がレコメンドされるような取り組みも今後は可能になってくるのではないか
- テレビをアップグレードしていきたい
- インタラクティブでは無いものをインタラクティブにするのはソリューションがないから大変だけど楽しい
- マスメディアがメインフィールドなので拾えてなかったデータが拾えるようになった
- 一発勝負なので、エキサイティング
- テレビは古い領域に見えるけど新しい領域
まとめ
今、勢いのある動画ビジネスで利用されているテクノロジーがどのようなものなのか聞くことができ、非常に参考になりました。膨大なトラフィックを捌くための工夫や、サービスを成長させるために事業として工夫していること、テレビというコンテンツと融合してユーザーに新しい体験を提供していくなど面白い話を沢山聞けました。次世代移動通信「5G」がでることにより、動画ビジネスは益々拡大していく流れだと思いますので、やるなら「今」かなと思いました。
35
