AWS Summit 2014 〜 Media & Entertainment 〜

  • 7
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

AWS Summit に行ってきたので、参加したセッションについてまとめてみました。
アドテク屋さんなので Media & Entertainment のセッションです。

AWSが支える動画広告の舞台裏

cci

工藤 達之様(株式会社サイバー・コミュニケーションズ Project Designer, Strategy Division)

ネットにおける動画市場について

過去2回動画広告元年があった。いずれも通信環境のイノベーションがトリガー。

→ 今年はどう違うのか??

動き出したソリューション・プロバイダー

  • 米国の動画DSP・SSPの相次ぐ参入
  • TV局の無料動画配信の開始

コンテンツについて

  • マネタイズ可能な動画媒体は少ない
  • ニコニコ動画、Youtubeの寡占状態
  • 平均滞在時間では、 ニコニコ動画 > YouTube (約2倍)

動画配信のモデル

タイプ (略称) 説明
TVOD Transactional Video on Demand 都度課金制動画配信
SVOD Subscription Video on Demand サブスクリプション(定額課金)
ADVOD Advertising Video on Demand 広告課金

広告在庫について

In-Stream在庫の8割がYouTube(一極集中)
広告代理店が扱うべき領域が4割

正直、ここまでYouTubeに集中しているとは思っていなかった・・・。

dennoo

上野 武史様(Dennoo Inc. Senior Product Director)

Viewable時のみ動画再生が行われるのが特徴な動画広告配信プラットフォーム

視聴時間を動画広告の価値に とのこと

動画広告の過去の課題

  • 端末の処理能力

    • グラフィックメモリ
    • ガラケー
  • 回線が細かった

    • ブロードバンドが家庭になかった
    • 3Gも貧弱(パケ死)
  • 動画は容量が大きい → 転送量がすごくかかる

    • 2chが閉鎖しかけた原因
    • ニコニコが長い間赤字の理由
  • 集計項目が多い → サーバ台数がかかる → お金もかかる

    • 再生開始、再生完了、マウスオーバー etc...
    • 広告配信のバッチを高速に回す必要がある
  • 高すぎるインフラコストが広告費に反映される

    • 静止画広告の10〜100倍とか

結果、動画広告市場が立ち上がらない・・・

そして今

  • 再生余裕のハイスペック!

    • PCのグラフィック性能の向上
    • スマートフォン、タブレット
  • 回線が太い!

    • LTE
    • NURO
  • CDNにより転送量が安価に!

    • CloudFront(CKがあればすぐに使える)
  • 大量のログをリアルタイムに集計可能に!

    • S3, EMR, Redshift
  • 対費用効果が妥当に!

    • ターゲティング制度
    • リーチの大きさ
    • 接触頻度のコントロール(フリークエンシーコントロール)

dennooの開発体制

八子 武司様(Dennoo Inc. Software Engineer)

超少人数なので、出来るだけインフラ運用コストを下げ、効率化したい。。 → ということで AWS を採用

使用サービス

EC2

  • RTBサーバ
  • アドサーバ
  • コンソールサーバ
  • バッチサーバ

CloudFlont

  • 全体の料金の50%を占める

S3

  • 大量のログを保存

Redshift

  • FlyData社の支援により導入
  • 2週間でRedshiftに移行
  • Hadoopで5時間かかっていた処理 → 1〜2分に
  • 短い間隔でのバッチ処理が可能に(ほぼリアルタイム)

諸々含めて2週間での移行が可能になるのであれば、支援を受けるメリットは大きいかと。

Redshift選定基準(使ったほうがいいケース)

  • 1TB〜数PB
  • 短い間隔(数分〜1時間)に何回も分析する場合
  • SQLで分析可能な形式

今度動画広告が発展していくために必要なこと

経済上の理由に基づいて行動する(八子さん)
→ じゃないと割に合わないビジネスモデルになってしまう・・・。

2兆円市場規模をつくる気概(上野さん)
→ まだまだ未成熟な領域。熱意が大事。

権利処理、配信コスト、収益、優良コンテンツ 4つがしっかり回ること(工藤さん)
→ どれか一つだけではなく各要素が噛みあうことが重要。

広告配信システムDynalystができるまで

~ Ad Tech STUDIO でのAWS活用戦略 ~

dynalyst.jpg

オンライン広告の今

現在のアドテク

より細かいターゲティングが可能な時代

  • 5W1Hの中でwhoが特に重要視される
  • ユーザ行動に基づく配信
  • 予算の適切な分配とROIの向上

広告出稿の意思決定がリアルタイム化

  • RTBは当たり前
  • 集計、分析も出来るだけリアルタイムに

Dynalystって?

ユーザ行動をベースにエンゲージメントレベルを解析。
見込み客かどうかをリアルタイムに判別し、ターゲティング広告を展開する。

  • RealTime(配信 & 分析)
  • Personalized Ad(レコメンド機能)

Dynalystができるまで

環境

  • 少人数 × 短時間(サービス企画、アプリ、インフラで6人くらい)
  • とにかくRealTime
    • RTB
    • 計測から配信までをとにかく短く
  • 日次で数億impを裁く

計測結果を即時に配信ロジックに反映させるサービスってあまり他に無いような気がします。

構成

  • EC2
  • ElasticCache : ユーザの行動ログからユーザ識別を瞬時に行うため
  • DynamoDB : ユーザの行動ログ
  • Redshift : ログの集計
  • SQS : 各イベントのキック

この構成で秒間1万リクエストを捌いている。

なぜDynamoDB?

  • 典型的なデータ構造
  • 広告主ごとのカスタマイズ可能(スキーマレス)
  • 高スループット、低レイテンシ
  • 高い拡張性

なぜElasticCache?

  • まず判定したいのはユーザがターゲティング対象か否か?
  • ターゲティング対象である確立は一般に20%以下
  • 80%はDynamoDB参照以前に振り落としたい

キャッシュヒット率を把握していることは重要

なぜRedshift?

  • 配信ロジックを変更した時に出来るだけ早く察知したい
  • アドホックな分析クエリーを低コストで発行したい(色んなロジックを簡単に試したい:SQLが使える)
  • レポーティング基板×分析器版

通常、すごく時間がかかる検証をライトに何回もやりたいってことらしい。

Ad Tech Studio でのAWSの使い方

リザーブドインスタンスをどう買うか?

全社で親アカウントを統一、各サービスで子アカウントを作成。

  • 親アカウントでRIを購入
  • 子アカウントはRIのメリットを享受
  • RI適用率が65-70%になるように調整してRIを購入する(親アカウントの管理者がコントロール)

各サービスで購入したRIをどれくらい消化しているかはわからなくなるけど、全体でみると確かに最も効率がいい。ただ、経営陣がそれを許容するかどうかが一番のハードルになりそう。

所感

集計・分析から配信までがリアルタイムに行われているサービスはあまり無かったように思う。
また、DynamoDBやRedshiftなどのみでRDBMSを使っていないことも興味深かった。