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

目次

• 自己紹介

• ディスプレイ広告配信DSP「Smalgo」について

• インフラ全体の構成とElasticsearchの位置づけ

• Kibanaを使った実際の分析項目とパネルの紹介- Bid率 / Win率 / Unhandled Exception数 / NoBidの理由の内訳 - レスポンスタイムの時系列分布 / Worstレスポンスタイム - BidType別Bid数・Imp数 / Click数, CV数 / BidType別のWin価格の平均と標準偏差 - Bid価格・Win価格の時系列分布 / SSP毎のRequest数・Bid数 / 生ログの調査

自己紹介

• 山田 直行（やまだ なおゆき）@satully / blog.kirishikistudios.com / www.facebook.com/yamadanaoyuki

• 株式会社サイバーエージェント アドテク本部 Smalgoカンパニー ソフトウェアエンジニア

• アドネットワーク・DSPに携わって2年

• 担当分野：インフラ・DevOps・サーバーサイドアプリケーション全般

• 好きなキーワード：自動化・大量トラフィック・イミュータブル

• AWS認定ソリューションアーキテクト アソシエイト

• データの活用について、インフラ構築から分析、実サービスへの適用までを通してできるエンジニアを目指しています

ディスプレイ広告配信DSP「Smalgo」• ディスプレイ広告（≒バナー広告）の配信プラットフォーム

• 2014年5月から提供（前身となるプロダクトを含めると2014年2月から）

• サイバーエージェント アドテクスタジオ内の1プロダクト（1事業部）

• RTB & 第三者配信、CPA/CPC課金に対応。コンバージョン獲得に特化した配信ロジックを持つ

• さまざまな配信手法と広告フォーマットに対応、多くの接続先と在庫量を持つ

• 開発・運用に携わるエンジニアは計6人

インフラ全体の構成とElasticsearchの位置づけ

• 2014年9月に発表した資料ElasticSearch勉強会 第6回http://www.slideshare.net/Satully/elasticsearch-study6threaltime20140916

• 今回は、このときからの変遷も交えてお話します

~サーバーインフラ全体の構成~

配信 サーバー

ログサーバー (Fluentd)

S3

Redshift

MySQLRedis Elasticsearch

Kibana

Tableau

~Elasticsearch部分の詳細~

ElasticSearch Data Nodes

ElasticSearch Coordinate Nodes

ElasticSearch Data NodesElasticSearch Data NodesElasticSearch Data NodesElasticsearch 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 214ノード

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

半年前と比べて構成を変更したところ

• レポーティングと分析の基盤はバッチ処理形式のRedshiftで構築。ElasticsearchはKibanaを使った数時間以内のリアルタイムな調査・モニタリングに役割を特化

• 以前は30日分データを保持していたが、現在では最大3日分程度のみ保持

• Elasticsearchに使うインスタンスはEBSをやめ、InstanceStoreを2つアタッチしてデータディレクトリを2つ指定してIOを分散

• データノードの台数は28台→14台に減らせた（秒間書き込みレコード数は3万→6万に増加したが捌けた）

• サーチノードを廃止し、コーディネートノードに一本化

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

• Bid率Bidした量とNoBidで返した量の比率を円グラフで表示。そもそもBidしないとImpressionも出ないので、一定以上に保てるようにする

• Win率(Bidの勝率) Imp数÷Bid数＝Win率。これも基本的には高くしていきたい指標

• UnhandledException数想定外の例外を投げた際にカウントされる。エラーログが出ているはずなので、調査する

• NoBidの理由の内訳オークションに参加できなかった理由をID別に円グラフで表示。原則としてBid率は高めていきたいので、なぜBidしなかったかの内訳を把握しておく

• Bidレスポンスタイムの時系列分布“50msec or die”なので、ほとんど全面をブルーの状態(50msec以内)に保つ赤い部分が出てきたら、それは障害

• Bidレスポンスタイムのうち、最も遅かったレスポンスタイムを表示全てのリクエストに対して100%を50msecで返すことは不可能だが、数秒以上かかっているレスポンスがあれば異常のサイン

• BidType別Bid/Imp数Bidロジック(配信方法)別にどれくらいのボリュームが出ているか

• Click/Conversion数コンバージョン数は数日以上さかのぼってカウントする場合もあるので、ここに出てくる値とは一致しない。なので参考程度だが、計測連携のテストをするときなどは便利

• CPMの基礎統計配信方法ごとに、いまいくらでBidしているかの俯瞰を表示。最小値・最大値・平均値・標準偏差の4つ

• CPMの時系列分布価格帯ごとにクエリを分け、それを積み重ねグラフとして表示。リリース直後・設定変更直後などの急激な価格変動を見ている

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

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

まとめ

• 少人数で比較的大きなシステムを見ているのでElasticsearchもそれほど深く使えているわけではありませんが、逆に手がかからず安定して動作しています（特にver1.2以降安定したイメージがあります）

• リアルタイムのモニタリング用途に特化した使い方をしていますが、役割をしぼったことでかえって上手く使えている気がします。Kibanaのダッシュボードはチームの席の近くにある大きなテレビに映していて、誰でも見られるようになっています

• 24時間365日動かし続けなければいけないシステムなので、監視システムのアラートが鳴る前でも、異常な徴候があれば気づきたい。また、配信ロジックも複雑かつリリース頻度も多いので、特にデプロイ直後、監視システムだけでは捉えられないサービスレベルの変化に気づくには、こうしたサービスの数値をモニタリングするシステムは有用だと思います

• ElasticsearchとKibanaの活用方法の一つとして、参考になれば幸いです