Links

今日は「マーケティングテクノロジーの最先端を支える技術を大公開！」の日です

Posted on December 16, 2014

マーケティングテクノロジーの最先端を支える技術を大公開！に参加しています。適当に内容をメモします。

あいさつ

  • えむてぃー“ぶれいん”さま

対談『アドテクが見据える未来のはなし』 / 田中さん、明石さん

  • 田中さんより
    • B2Bも最近やろうとしている
    • BrandSafeはてな : 広告枠が2ch系か、アダルトか判断
  • 明石さんより
    • 関連会社について
    • 「えむてぃーばーん」です
  • 明: 広告の未来はどうなる？これがわかれば苦労しない
  • 田: ターゲティングの精度の向上。データを加工してアルゴリズムに加工
    • 嫌われないような最適な広告を出せるようになるといい
  • 明: はてなはなにを？
  • 田: BrandSafeはてな。今まではB2C向けサービス。
    • スパム判定アルゴリズムを応用
    • はてなブックマーク関連のデータが利用できると面白い
    • プライバシーへの配慮は必要
  • 明: はてなでプライバシーデータ使ってはてなで炎上？
  • 田: よくある。炎上しても受け入れるようにしている
  • 明: アドテクは回帰している。
    • バナー、email、検索連動、アドネットワーク、DSP、
    • DSPにて枠売りからimpression売りに変化
    • またアドネットワークに移りつつある
    • IoTにおいてコミュニケーションがまた変わる
  • 田: はてなはアドテクもやってる
    • 自社のメディアへの広告の出し方。枠を持ってる
    • 枠の進化には興味がある
    • いかにいいアドを出すか。ネイティブアドとか
    • ユーザに受け入れられる広告を出すところを大事
    • どう考える？
  • 明: バナーは広告っぽい。嫌われるだろうと思ってやってる
    • ネイティブアドは受け入れられやすい
    • IoT。演算装置を持たなかったものが演算装置を持つように
    • 街の広告とかがテクノロジーで置き換えられる
    • 「マーケティング」＝デジタル、の時代を目指す
  • 田: はてなブックマークのトップに何を出すかやってる(広告ではない話)
    • ネイティブアドとかやると、広告とコンテンツがあいまいになる
    • アドテクがカバーしてくれると面白い
  • 明: 海外ではそのような動きが始まっている
  • 田: 広告も含めたWEBメディアの設計
  • 明: テクノロジーは現在どのような進化を遂げているか
  • 田: フリークアウトさんで熱いのは？
  • 明: DSP。プライベートDMP。パブリックDMP。ネイティブアド
    • まだ新しいし、取り組んでいる。
    • ネイティブアドは激戦区に
    • DSPの配信のエンジンはどこまでも進化させられる
  • 田: 1. DMPの取り組みを増やしてインプットを増やす
      1. 集めてきたデータの最適化
      1. ロジックの高速化
    • はてなで熱いのは、 3. の部分
  • 明: フリークアウトでは 2. に力を入れている
    • 100ms縛りはある。「50ms or die」
    • 50ms でどこまで高度な計算の近似値を出せるか
  • 田: CPUの改善の頭打ち
    • FPGAとかで改善があつかったり。やってらっしゃいます？
  • 明: まだそこに踏み切れてない
    • 踏み切った次点で一番最適な技術を選択するのがよい
  • 田: 計算量のチューニングはしている？
  • 明: している。50msはすぐ過ぎてしまう
    • アドベリの精度を上げるためにやっていることは？
  • 田: クラス分け問題のアルゴリズムを色々試している
    • モダンなアルゴリズムを探っている
  • 明: FPGAとかはどう？
  • 田: はてなは今はバッチ処理している
    • FPGAでガリガリチューニングするよりアルゴリズムを
    • チューニングすることは多いけど、さすがにFPGAは持ち出してない
  • 明: 他にも使い切るべき技術はあるので、FPGAにはまだフラットな立場
    • 他社の話を聞くとやってみたいなとは思う
    • 原則は現場に任せている
  • 田: プライベートDMPとか、大規模データはけっこう大変では？
  • 明: 仕組みがシンプルなので正規化とかはしてない
    • クラスタリング的な手法は多少使っている
    • KVSを箱としては利用している
    • TTを使っているが、限界を感じて他を考えている
    • Hadoop、 elastic search など
  • 田: TokyoTyrantのこと？ いろいろな思いがある
  • 明: なぜ苦笑い？
  • 田: 昔使い潰した。限界近いときの挙動に問題があって苦労した
  • 田: 実装言語は考えていきたい。Perlでアルゴリズムを実装するのにはいいのか
    • WEB向けのライブラリは多い。アルゴリズム系のライブラリはどう？
    • 計算機科学とか。PythonとかRも使っていきたい
  • 明: うちもPerlがメイン。
    • データマイニングではPython、Hadoopも使っている
    • 今後計算量が増えた時にPerlが最適化
  • 田: どこに注目？
  • 明: Perl系の人はgo。UIを作ってる人はRubyを見たり
  • 田: 今はPerl？
  • 明: 表に出しているところは全部Perl
    • Perlに苦手な処理からは逃げているので、まだ大丈夫a
  • 田: Perlは採用は大変では
  • 明: 言語はツールなのでなんでもよい。テクノロジに興味を持ってもらうように話す
  • 田: 基本、採用の時はPerl書くよという。Scalaとかは採用している
    • B2Bだと静的片付けはデグレが少なかったりいい
    • 言語を増やしすぎるとカオスになるのは避けたい
  • 明: 人事には「Perl変わらない？」と言われる
    • 人事に言われる筋合いではない
    • 現段階ではPerlの生産性が高い
  • Q. 欲しいエンジニア像は？
  • 田: B2Bに手を出して、求める幅が広がっている
    • アプリを作ったり
    • より幅広い人を求めている
    • 時代の要請にあった技術を身につけられる人
  • 明: アドテクの業界に興味がある人
    • 勉強を惜しまない人。日々変わっていく
    • ある領域にとんがっている人。追求できる人
    • アイデアを人に伝えることができる人。文系と理系の人を取り持つ人
    • データを扱える人たちは貴重。力を入れている。
  • Q. 機械学習でアドテクの未来が変わっていく。どう関わっていくか
  • 明: 今はバッチ的な機械学習が多い
    • リアルタイムになっていく
    • ムーアの法則の崩壊。近似値を出すような特殊な取り組みが求められる
    • より高度なアルゴリズムの簡略化
  • 田: 教師付きの機械学習には限界がある
    • コンテキストを理解するようなアルゴリズムを探りたい
    • 人間と似たような判断ができるような
    • 現在の広告の価値を変えるようなアルゴリズム
  • 明: 教師なしアルゴリズムは結構トライされている。方向性はある？
  • 田: 論文はサーベイしているけど、まだ時間は掛かりそう
    • 取り組む価値は出てくる
  • Q. AWSのサービスをどうつかう？kinesisとか使ってる？
  • 田: 全部オンプレ。はてなブックマーク(古い)と蜜結合なので
    • kinesisとかredshiftをがりがりは使ってない
    • はてなブログなどで使ったりはしている
    • mackerel使おう！
  • 明: 規模が大きくなるとコスト高になる
    • 事業規模が大きくなった次点でオンプレにしている
    • 海外サービスではネットワーク距離の問題もあってAWSを利用
    • AWSの様々な機能を使っているかといえば、そうでもない

フリークアウトにおける大規模データの取り扱いのこれまでとこれから / 加藤さん

  • RTBの仕組みについて
    • ユーザ → SSP → 応札！ → 最高値が勝
    • アプリの中は 50ms or die
  • 大規模データは２つ
    • オーディエンスデータ
    • 配信ログ
  • オーディエンス = 広告を見ている人
    • 広告の接触、セグメント、クリック履歴など
    • 数十億データ
    • 日本の人口を超えているが、1人 1 IDではないので
  • オーディエンスデータを使うところ
    • 最適な広告をオーディエンスデータから判断する(50ms)
    • memcached + KVSの二重構成
    • KVSは0.1ms〜数ms。3TBくらい
    • 15000 get/s
  • Tokyo Tyrant使ってる。速い
    • Expireできない
    • consistent hashingはしているがサーバ追加するとロストが出る
  • OKAWARI作戦
    • 新しいTTを前段に用意
    • 旧から新に徐々に書き換えていく
    • 旧を外す
    • サーバ台数がすごいかかるので効率悪
    • 退役できるのは以降がすんでから
  • riak → 断念
    • writeが厳しいため断念
    • OKAWARIに戻った
  • HBASEを使うことを検討中
    • 書き込み性能が高い。スケーラビリティ
    • もう火山じゃなくなってる（ほんと？）
    • HBase 0.98.6を検証中
    • 手前にラッパーAPIを準備。APIはmessage packで
    • うまくいったらまた別途報告を！
  • 配信ログ
    • クリック、コンバージョンなど
    • 配信実績の分析。ABテストの実施
    • オーディエンスデータのデモグラ分析
    • 開発側で使う指標の測定など
  • 大昔 → MySQL
    • 2013年半ばからHive
    • Elastic search + KIBANA体制
    • Impara導入、fluentdの監視でNorikra
  • CDH4 →CDH5
    • Yarn対応。Cloudera Manager
    • Hadoopエコシステムの進歩の速さについていくため採用
  • Hivemall → 機械学習
  • Impara → バク速Hive
  • Norikra → metricsの収集
  • Elasticsearch + Kibana → サマリの可視化
    • kibanaじゃない別UIも作ってある
  • Spark使いたい(MLlibも)
    • HBaseも
    • 日次バッチから分次バッチへ
    • 開発側に訴えかける可視化
      • パフォーマンスや使ってるリソースなど
      • あなたのコミットが何の役に立ったか

『BrandSafe はてな』のアドベリフィケーションのしくみ / 伊奈さん

  • インターンの時にはてなブックマークをやってた
  • 検索技術を多くやってた → 専門はtyp theory
  • brandsafe はてな
    • 広告主の希望で、リクエストを出すべき、出さないべきを判断
    • 2chまとめサイトに出さない、の機能は人気がある
    • 違法ダウンロードサイトに出さない、など
  • Webページの分類問題
    • 2chまとめかつアダルト、もある → 各属性について2値分類
  • 判定方法の候補
    • 人間が手動で →十分 高速にできるのであれば、これでもいい
    • ルールベース、機械学習
    • 工数を抑える。計算量を抑える。保守性をキープ
  • はてなブックマークの仕組み
    • ブックマーク→本部う抽出→メタ情報抽出→カテゴリ判定、アドべり判定
    • トリガをはてなブックマーク以外でもできるようにする
  • 素朴なフィルタの例
    • NGワードがあれば、という判定
    • メンテナンスが簡単(単語をリストに追加していくだけ)
    • リンク数を見る、とか
    • 精度は低い
    • 「カブトムシの交尾」「やまもとい“ちろう”」問題
  • 素朴なフィルタをたくさん重ねる
    • 一つのフィルタだと誤認識が
    • 2次元にすると、綺麗に分かれる可能性もある
    • 直線 ax+by+c を引く
    • aとbを設定
  • 直線を手でチューニングするのはちょっと
    • 可能であればそれでもいい(地域別エントリはそうしてる)
  • AdaBoost
    • 弱分類気を複数合わせる
    • 2個目以降のフィルタの学習は、それまでの判定が誤っていたもののデータを重くする
  • BSはてなの弱分類器
    • カテゴリの偏り、タグの頻度、特定タグ、コメント率
    • 他、ブックマークしてなくてもできるもの → URL、キーワードの出現
  • キーワードの出現傾向、の精度を上げる
    • Perceptron 教科書に載ってる。枯れてる
    • 単語の出現ベクトルと作って、それで学習
    • 誤った場合は、ウェイトを入力データで学習
    • Perlで20行程度のコードで精度がかなり出た
  • 教師データを集めるのが大変
    • URLを人の目で判断
    • 人なのでぶれが出る
  • AdaBoost
    • スパムフィルタ用途だった
    • AdaGrad + RDA・・・はいいはずなのに、検証したらよくなかった
  • Perceptronはすごくうまくいった
    • キーワードを増やすときつい
    • 特徴語に絞っているのがGood
  • 今後
    • 判定できる属性を増やす、画像対応、フィルタリング以外に使う(積極的に広告を出すとか)、次元をふやす(100億くらい)
  • 東京でも京都でも勤務可能!

ゼロから始めたGunosyのアドサーバ開発運用記 /  粟飯原 さん

  • 「本当に怖いこの一年で踏みぬいたアドサーバ地雷の話」
    • Gnosy Ads
    • 完全自社製。Python製。Scalaとgoも
    • End to EndのRTB
    • アドネットワークも
  • アドサーバは総合格闘技
    • アルゴリズム、大規模データ、安定、高速
  • 配信エンジニア2名(入稿システムは別)
    • AWSを活用。自動化。プロビジョニング。
    • サーバふやすよりチューニング
    • KPI Tool (数値は神より正しい)
  • ユーザ数が10倍、配信料は数千倍
    • エンジニア数は5倍
  • 最初はTornado性の数台のサーバ
    • オンライン学習＋バンディット (思い計算)
    • RDBは一切見ず、redis
    • hっログはagentでMongo DBへ
  • スパイキーなアクセスが捌けない
    • サーバと同時にエンジニアも死ぬ
    • CPUバインド。サーバを横にふやす
    • APIサーバで計算するのが間違い→バッチ系へ
    • トラブルが楽しい時期→比較的カジュアルにサービスをいじる
  • ウルトラマンのCMで広告枠増
    • 収益も増えた→止められないサービスへ
    • redisに載り切らない。詰まる。
    • S3経由で全サーバにデータをばらまく対策
    • 垂直分散
    • riakはコスト面で不採用
  • Redshiftへ以降。楽できる・・・はずだった
    • データの爆発でRedshiftが死亡
    • バッチはPythonのCeleryで分散処理
  • Redshiftはテーブルがメモリに乗らないと使い物にならない
    • お金持ち以外は厳しい
    • メモリに乗らないビッグデータは諦める。データマートとしての利用
    • 定時バッチに必要なものだけ載せる
    • アドホックな分析、回帰モデル構築はSparkを利用
    • 全ログ集計はImparaへ
  • Pushのアルゴリズム改良で開封率が上がりすぎた
    • 1分以内に大量アクセスが来るように。20倍！
    • ELBから外されるレベルで配信が死ぬ
    • Redisと完全にサヨナラしたいけど厳しい
  • 夢の技術なんてない
    • BigQueryに期待
    • インフラは全部自動化したい
    • いろいろな経験がつめてよい

The technology behind M.T.Burn / 久森さん

  • M.T.Burn → AppDaviを作ってる
  • 言語
    • Objective-C
    • Java, roboletric
    • Perl → 経験者が多い
    • JS 一択
  • サーバサイド
    • AWS。AutoScaling 自分たちでは運用しない
    • EC2インスタンスだけを面倒見るように
    • Ubuntu 14.04ベース → 新しいパッケージを使いたい
    • PackerでAMI Imageを
    • Docker → ワークロードがそこまで上がらないサーバにはいい
      • デベロッパが出元でDocker build
      • S3へ。インスタンスがpull
    • Fluentd : Norikra, mackerel
  • Mackerel → サービスの監視。サービスメトリクスとして任意のものも
    • サーバインスタンスが増えたり減ったりする環境だといい
    • AutoScalingしてもグラフが途切れない
  • Norikra → Docker image あるよ
    • 例: imp, click, conversionを分単位で
  • BigQueryを採用
    • UIの操作ログも。バッチの実行ログも
    • とにかく何でも
    • ストレージが安い、運用しなくていい。開発速度が上がる
  • Development Tool
    • github : コードとissue。PR駆動
    • TravisCI の有料プラン iOS, Android, Perl, JS
    • Qiita Team → 日報や技術情報
    • Slack → チャット。アラートとかも
      • Mackerel - Slack 連携
      • メールには頼らない
  • 利用者、メディアが急激に伸びている
  • 3回作り直している
    • オンプレ→クラウド、セルフ→マネージド
  • 使わなくなったもの
    • オンプレ → 調達が大変。スケールを破壊的にしたいので。
    • 内部DNS →Route53
    • CentOS → 古い
    • Cobbler。Cloud-init + AMI
    • rsync → S3へ。syncさせる。Auto scalingの際にも安全
    • Puppet→Ansible→shellへ。ロールあたりのやることが少なくなったので
    • Nagios, CloudForecast → サーバリストが多く、管理につかれた
    • HipChat → クラッシュ、API連携がきつい
    • Hive, MapReduce → 開発者がコントロールできることをふやす。BigQueryはredshiftより手間が少なくて安い
  • 重要なこと
    • マーケット、テクノロジーについてキャッチアップ
    • トレンドの変化に強い構成が重要
    • スケーラブルで、かつ、オペレーションを減らすこと
  • 常にアップストリームを追う姿勢が大切