狠狠撸

DSP「ScaleOut」の
成長と負荷対策
TECH VALLEY #6
2015/11/18
Supership 石桥稔章

自己紹介
? 石橋稔章(いしばしとしあき)
? アドテク系エンジニア
? DSP「ScaleOut」とSSP「AdGeneration」の
技術部門のリーダーをやってます。
? 趣味でスマホアプリ作り。6,000 DL突破！

会社が「Supership」になり
ました。
* 11月1日よりスケールアウト、nanapi、ビット
セラーの3社が合併。できたてほやほや。
* 強い広告事業には、強いサービスが必要。

今日話すこと。
4年前位に当時海外で流行りつつあった
DSP(Demand Side Platform)のaspサービス
をメイン事業に転換して、1から国内有数の
プロダクトにまで成長させた途中で起こった
苦労話をします。

個人的な裏目標
へー、アドテクって面白そうじゃん。
おれもやってみたいな！
っと少しでも思ってもらうこと。

前提として
広告システムに詳しくない人
も多いと思うので。

DSPとは？
ざっくり言うと様々な広告枠をオークション形式で購入す
る広告配信プラットフォーム。大量にリクエストを受けて、
買いたい広告枠を選りすぐって買う。
図はサイバーエリアリサーチさんのサイトからお借りしました。
http://www.arearesearch.co.jp/learn/ind/27.html

DSPのシステム特性①
リクエスト回数がとんでもな
く多い
具体的な数は後述。

DSPのシステム特性②
リスポンス速度の制約が厳しい
(0.1秒以内にレスポンスを返
さないといけない)

DSPのシステム特性③
ピークタイムは、インターネッ
トのトレンドと同じ。20時～
24時くらい

使用している技術
配信系: c++、js
nginx、apache、kvs
画面系: rails、postgresql
集計系: ruby、python
hive、presto
解析系: python、R、hivemall
など

ちなみに
広告配信システムでは、配信にRDB
は基本的に使わない。
なんらかのKVSを利用するのが一般
的。

インフラの変化
(全てオンプレ)

2012年サービス開始時
配信サーバ48台でサービス開
始

2015年現在
配信サーバ500台強
集計サーバ150台強
10倍に増加！

2012年サービス開始時
8億/month

2015年現在
2000億強/month
250倍に増加!！

システム構成
集計基盤構築後(結構初期)
nginx
adsvr
adsvr バッチ
転送
サーバ
HDFS
DB

現在の構成
細かい部分は変わっているが、基本
的な部分はほとんど変わっていない。
ひたすらスケールアウトしてきた。
社名が株式会社スケールアウトでしたしね。

初期設計大事。
社長が元yahooのエンジニアで高トラ
フィックをさばいていた経験が生きて
いる。

全て顺风満帆だったの？

そんなに世の中は甘くない。

例えば、サーバの熱問題
初期の頃に起こった問題。
サーバを安く調達するため、自作していた。
排熱性が悪く、cpuのクロック数が下がって
想定より性能が出ないサーバが多発した問題。

サーバをどうやって冷やすか
とか初めて議論した。。

教訓としては、自作は極力し
ないほうがいい。

サーバは急に足せない問題
オンプレだとクラウドより安く調達できるが、
急にはサーバを追加出来ない。
(当たり前だけどね。)

リクエストが急に増えてきて
もシステムを落とすわけには
行かないので、色々工夫して
きた。

基本的な戦略は、優先順位を
付けて、売上に効果が薄い処
理から順に削る。

ある程度自由に制御できるト
ラフィックの確保する。
何らかの不測の事態が発生した場合に、自
分たちでサーバ負荷を減らす方法を用意をし
ておく。SSPによっては、管理画面からリク
エストを止めることが出来る。
本当の緊急事態に使う

オークションに参加する枠や
人には優先順位を付けておく。
負荷が高くなってきたら優先順位が低い枠か
らオークションに参加する確率を下げるよう
にする。
ほぼ買えない枠や買っても広告効果を期待で
きない枠などは、cpu時間の無駄遣いなの
で。

60msを超えたら処理を打ち切
る。
100ms以内に返さないと負けなので、超えそ
うな場合、cpuの無駄なので諦めて、レスポ
ンスを返す。

ほとんど配信されない案件に
はペナルティを与える。
1日で数回しか配信されないものに毎リクエ
ストでcpuリソースを使うのはもったいない
ので、処理対象となる回数を制限をかける。
負荷に応じて、ペナルティ率を変化させる。

案件を無駄に登録出来ないよ
うにする。
案件数は、配信の負荷に影響を与えるので、
管理画面で登録出来る件数を制限する。

事前に案件は足切りを行う。
広告システムは、ざっくり言うと、案件を高い順に並
べて、上から配信できるかチェックする。そのため、
案件数に応じて、負荷が高くなる。
無駄な案件を処理しないように事前に足切りを行う。
例えば、iOSにしか配信しない案件は、Androidから
の広告枠については、事前に処理対象から外すように
する。

特定のユーザは、極力同じサー
バで処理する。
キャッシュヒット率が上がるので、nginx
などで極力同じadserverに割り振る。

配信時の価格決定に必要な計
算はシンプルにする。
オークションの価格決定は、再重要だが、
シンプルにしないと100msで返せない。
速度と精度のバランスが重要。

負荷がかかるのは、配信系だ
けではない。
集計系も負荷がかかる。

サーバリソースは、有限なの
で、無駄に負荷をかけない仕
組みが必要。

Resource Managerで優先度
に応じて、queueを分ける。
Hadoopを150台位のサーバでクラスタを組
んでいても、一律で処理をさせると遅れると
サービス的にcriticalになるものが後回し
になってしまうことがある。

集計基盤に、サンプリングされた
データが入るテーブルも用意する。
概算だけわかればいいケースも多いので、素
早く処理するための少量のテーブルを用意す
る。

uu数を計算するためのサンプ
リングを用意する。
広告系ではよくあるuu数の集計。
uu数の集計は、ユーザをn個の集合に分割し
たサンプリングテーブルを用意して集計する。

最後に、なぜ負荷対策が重要
なのか？

重要というか必須でやらない
といけない作業。

怠るとサービスが止まってし
まう。

利用者が増えると負荷は勝手
に上がっていくので、定期的
に対策が必要になる。

重要なのは、対策に開発リソー
スの一定量以上を取られない
ようにすること。

広告業界は競争が激しい。
googleやfacebookなどとも
戦わなくてはいけない。
競争力のないプロダクトは、簡
単に淘汰されてしまう。

淘汰されないために、開発リ
ソースは、極力新たな機能の
追加などに充てられるように
することが重要。

狠狠撸

顿厂笔「厂肠补濒别翱耻迟」の成长と负荷対策

More Related Content

顿厂笔「厂肠补濒别翱耻迟」の成长と负荷対策