1. ElasticsearchとKibanaで実現する
30億req/dayのリアルタイム分析
2015年2月13日 第8回Elasticsearch勉強会
株式会社サイバーエージェント 山田 直行

2. 目次
• 自己紹介
• ディスプレイ広告配信DSP「Smalgo」について
• インフラ全体の構成とElasticsearchの位置づけ
• Kibanaを使った実際の分析項目とパネルの紹介
- Bid率 / Win率 / Unhandled Exception数 / NoBidの理由の内訳
- レスポンスタイムの時系列分布 / Worstレスポンスタイム
- BidType別Bid数・Imp数 / Click数, CV数 / BidType別のWin価格の平均と標準偏差
- Bid価格・Win価格の時系列分布 / SSP毎のRequest数・Bid数 / 生ログの調査

3. 自己紹介
• 山田 直行（やまだ なおゆき）
@satully / blog.kirishikistudios.com / www.facebook.com/yamadanaoyuki
• 株式会社サイバーエージェント アドテク本部 Smalgoカンパニー ソフトウェアエンジニ
ア
• アドネットワーク・DSPに携わって2年
• 担当分野：インフラ・DevOps・サーバーサイドアプリケーション全般
• 好きなキーワード：自動化・大量トラフィック・イミュータブル
• AWS認定ソリューションアーキテクト アソシエイト
• データの活用について、インフラ構築から分析、実サービスへの適用までを通してできる
エンジニアを目指しています

4. ディスプレイ広告配信DSP「Smalgo」
• ディスプレイ広告（ バナー広告）の配信プラットフォーム
• 2014年5月から提供（前身となるプロダクトを含めると2014年2月から）
• サイバーエージェント アドテクスタジオ内の1プロダクト（1事業部）
• RTB & 第三者配信、CPA/CPC課金に対応。コンバージョン獲得に特化した
配信ロジックを持つ
• さまざまな配信手法と広告フォーマットに対応、多くの接続先と在庫量を持つ
• 開発・運用に携わるエンジニアは計6人

5. インフラ全体の構成とElasticsearchの位置づけ
• 2014年9月に発表した資料
ElasticSearch勉強会 第6回
http://www.slideshare.net/Satully/elasticsearch-
study6threaltime20140916
• 今回は、このときからの変遷も交えてお話します

6. サーバーインフラ全体の構成
配信
サーバー
ログサーバー
(Fluentd)
S3
Redshift
MySQLRedis Elasticsearch
Kibana
Tableau

7. Elasticsearch部分の詳細
ElasticSearch
Data Nodes
ElasticSearch
Coordinate Nodes
ElasticSearch
Data Nodes
ElasticSearch
Data Nodes
ElasticSearch
Data Nodes
Elasticsearch
Data Nodes
ELB
Elasticsearch
Coordinate Nodes
master: true/ data: false
EC2: c3.2xlarge
+ 80GBのInstanceStore x 2
2ノード
master: false / data: true
EC2: c3.2xlarge
+ 80GBのInstanceStore x 2
14ノード
12シャード & 1レプリカ
ログサーバー
(Fluentd)
EC2: c3.largeインスタンス
+ EBS(GP2)200GBを横に並べる
td-agent1.1系
独自のプラグインで
ElasticsearchへBulkInsert
Kibana
Kibana3の最新版
EC2: m1.small
+ ElasticIP
フロントにapache
VPC内の
Internal ELB
ElasticSearchバージョン：1.4.2

8. 半年前と比べて構成を変更したところ
• レポーティングと分析の基盤はバッチ処理形式のRedshiftで構築。
ElasticsearchはKibanaを使った数時間以内のリアルタイムな調査・モニタリ
ングに役割を特化
• 以前は30日分データを保持していたが、現在では最大3日分程度のみ保持
• Elasticsearchに使うインスタンスはEBSをやめ、InstanceStoreを2つアタッ
チしてデータディレクトリを2つ指定してIOを分散
• データノードの台数は28台→14台に減らせた
（秒間書き込みレコード数は3万→6万に増加したが捌けた）
• サーチノードを廃止し、コーディネートノードに一本化

9. Kibanaを使った実際の分析項目

10. • Bid率
Bidした量とNoBidで返した量の比率を
円グラフで表示。
そもそもBidしないとImpressionも出
ないので、一定以上に保てるようにする
• Win率(Bidの勝率)
Imp数 Bid数＝Win率。
これも基本的には高くしていきたい指標

11. • UnhandledException数
想定外の例外を投げた際にカウントされ
る。エラーログが出ているはずなので、
調査する
• NoBidの理由の内訳
オークションに参加できなかった理由
をID別に円グラフで表示。
原則としてBid率は高めていきたいの
で、なぜBidしなかったかの内訳を把
握しておく

12. • Bidレスポンスタイムの時系列分布
50msec or die なので、ほとんど全
面をブルーの状態(50msec以内)に保つ
赤い部分が出てきたら、それは障害
• Bidレスポンスタイムのうち、最も
遅かったレスポンスタイムを表示
全てのリクエストに対して100%を
50msecで返すことは不可能だが、数
秒以上かかっているレスポンスがあれば
異常のサイン

13. • BidType別Bid/Imp数
Bidロジック(配信方法)別にどれくら
いのボリュームが出ているか
• Click/Conversion数
コンバージョン数は数日以上さかの
ぼってカウントする場合もあるので、
ここに出てくる値とは一致しない。
なので参考程度だが、計測連携のテ
ストをするときなどは便利

14. • CPMの基礎統計
配信方法ごとに、いまいくらでBidし
ているかの俯瞰を表示。最小値・最
大値・平均値・標準偏差の4つ
• CPMの時系列分布
価格帯ごとにクエリを分け、それを
積み重ねグラフとして表示。
リリース直後・設定変更直後などの
急激な価格変動を見ている

15. • SSPごとの時系列での
Request数、Bid数
特に新しいSSP(配信先パートナー)をつ
なぐときに使うことが多い。1秒あたり
の数で表示しているので、配信サーバー
の台数と性能の比較でキャパシティを把
握できる。
また、接続後も大きく変動したりすると
実はSSP側が障害になっていることもあっ
た。

16. • 生ログの調査
フィルタを使って任意のリクエストの詳細をみる
※この用途には、Kibana4はかなり動作が速く使いやすくてオススメ

17. まとめ
• 少人数で比較的大きなシステムを見ているのでElasticsearchもそれほど深く使えているわ
けではありませんが、逆に手がかからず安定して動作しています（特にver1.2以降安定し
たイメージがあります）
• リアルタイムのモニタリング用途に特化した使い方をしていますが、役割をしぼったことで
かえって上手く使えている気がします。Kibanaのダッシュボードはチームの席の近くにあ
る大きなテレビに映していて、誰でも見られるようになっています
• 24時間365日動かし続けなければいけないシステムなので、監視システムのアラートが鳴
る前でも、異常な徴候があれば気づきたい。また、配信ロジックも複雑かつリリース頻度も
多いので、特にデプロイ直後、監視システムだけでは捉えられないサービスレベルの変化に
気づくには、こうしたサービスの数値をモニタリングするシステムは有用だと思います
• ElasticsearchとKibanaの活用方法の一つとして、参考になれば幸いです