マーケティングテクノロジーの最先端を支える技術を大公開！に行ってきた

勉強会

  • 2014/12/16 19:30-21:00
  • 株式会社FreakOut

講演

  • 対談 アドテクが見据える未来のはなし
  • アドテクエンジニアによる技術勉強会 大規模データを支える技術
    • フリークアウトにおける大規模データの取り扱いの歴史と今後
    • BrandSafe はてなのアドベリフィケーションのしくみ
    • ゼロから始めたGunosyのアドサーバ開発運用記
    • M.T.Burnを支える技術

感想

「50ms or Die」は普段作ってるWebアプリの世界とはまるで違う世界だなーと思った。確かにその世界だとCPU以外も使ってみたくなるかもしれない。 あとは広告配信側もできるだけうざくない広告を出そうと、試行錯誤してるんだなと思った。まあとはいえ稼がなくてはいけないわけで。今後も広告なのかコンテンツなのかみたいな話は、常に揺り戻しが起きるんだろうな。

発表

対談 アドテクが見据える未来のはなし

  • 短時間で出す
  • 広告が嫌われないように出す
  • 回帰してる
    • バナー
    • Eメールマーケティング
    • 検索連動型広告
    • アドネットワーク
      • いろんなサイトを束ねる
      • 透明性が無くなった
    • DSP
      • 枠売から人売り
        • インプレッション毎に最適化
    • プレイヤーが変わった
      • 再びアドネットワーク
      • 再度DSPが出るといいな
  • IoT
  • いかにユーザーに受け入れやすい広告を出すか
    • バナーは広告っぽい
      • 自分でやりながら、嫌われるだろうなと思ってやっている
    • 広告はコンテンツにできる
      • ネイティブアド
        • 広告とコンテンツの境が曖昧になっていく
  • デジタルマーケティングは言葉としてなくなるといいな
    • マーケティングといえば絶対にアドテク使うようになる
  • トラフィックエクスチェンジ
    • アメリカで流行った
  • DSP自体もまだまだ新しい
  • インティメートマージャ
    • パブリックDMP
  • ネイティブアドは激戦区になってきている
  • 特徴は3つある
    • 聞き漏れ
    • アルゴリズムによる最適化
    • 高速化
      • 100ms以内で応答しないといない
        • 社内だと50ms or Die
        • 50msでどれだけ最適な計算を行えるか
          • 計算量のチューニングをしている
            • ちょっと足すと50msを超えてしまう
      • CPUがハードウェア的に頭打ち
        • GPU
        • FPGA
        • より低レイヤーで最適化
          • Freak out まだまだ踏み込めていない
            • 他の部分でまだやることがある
          • はてな まだまだ踏み込めていない
          • MicroAdはやり始めた
          • Bingは検索エンジンが全部FPGA
  • Freak outのプライベートDMPはシンプル
    • 正規化するところまでは至ってない
    • はことしてはKVS
      • Tokyo Tyrant TT
        • はてなでもTT使っていた
          • 限界値での挙動でくろうした
    • データ処理としてはHadoop
    • 最近はElasticsearch
  • 実装言語
    • はてなもFreak outもPerl
      • Perlは計算処理のライブラリが弱い
      • 計算量があがった時にPerlが最適かどうか
    • 管理画面はRuby
    • Goを見始めている

フリークアウトにおける大規模データの取り扱いの歴史と今後

  • オーディエンスデータ
    • クリック履歴
    • 属性情報
    • Freak outの総発行ID数: 数十億
      • IDをどうシンクするかは今後の課題
    • アクセスが誰か
    • AudienceDBの構成
      • memcached
        • キャッシュサーバー
      • KVS
        • マスターとして使う
        • 現状
          • 3TB
          • get/setレスポンス: 0.1ms
          • 15,000get/sec
        • Tokyo Tyrant使ってる
          • Expireできない
            • データが増え続ける
          • サーバー追加が難しい
            • データロストが発生する
            • 世代交代でクラスタごと徐々に移行
        • Riakの検証
          • 徐々にwriteがしんどくなる
            • 断念
        • HBaseの検証
          • 書き込み性能が高い
          • スケーラビリティがいい
  • ログ
    • 配信実績の分析
    • 入札のA/Bテスト
    • 当初はMySQL

BrandSafe はてなのアドベリフィケーションのしくみ

  • 事足りるなら人力でもいい
  • はてなブックマークでたまってるデータがサイト分類に役立ってる
  • アルゴリズム

ゼロから始めたGunosyのアドサーバ開発運用記

  • 入稿から配信まで全部自前
    • 入稿システムはRails
    • 以外はPython
  • 最初は経験者0
    • 1年やってなんとなく分かってきた
    • 稼ぐためにはギリギリを狙う
      • 収益最大化してもお客さん離れる
      • うざい広告いれてもユーザー離れる
    • Gunosyでも50ms or Die
  • 全体
    • 配信システム
      • API
    • CV計測システム
      • API
    • ログ
      • S3
    • MySQL
  • 最初
    • 配信システム
      • Python
    • Redisに配信データすべて投入
      • オーディエンスデータも
    • MongoDBで集計 ユーザーがあって条件があって、その部分はバッチ処理にやらせる CM後 Redisが詰まり始める MongoのCapped Collectionに1日分すらのらない 集計DBをRedshiftに データ増で断念 Push通知改善後 Redisを捨てる方向 アクティブユーザーはファイルDBで全台に配布 BigQueryに期待

M.T.Burnを支える技術

  • ネイティブアプリ向けの広告