HUで6000万PVのトラフィックを捌くまでに起ったことを

ありのままに話すぜCMT

SAITO

1.自己紹介

斎藤です。ビールが好きです。最近は焼酎を飲んでいます。

3. 某クライアント向けのサーバー構成

3.解析サーバー構成（EC2）解析サーバー（c3.xlarge）

=> 解析用のRubyプロセス10個 x 2台

集計サーバー（c3.xlarge）

=> fluentdの集計用 out_exec_filterプロセス6個 x 2台

データベース（c3.2xlarge）

=> MongoDB ReplicaSet構成 primary, slave, arbiter（t2.small）

トラッキング（m3.medium）

=> Nginx, td-agent

3.解析サーバー構成（DynamoDB）

2. HUの解析インフラ

2. HUの解析インフラ

・Nginx で、トラッキングのアクセスを ltsv形式で出力・td-agentのinput-tail で拾って fluent-masterへ送信・fluent-materでセッション単位の集計を行う・analyzer で解析処理

4.トラフィック

5.導入手順 1. CloudFormationで環境構築

4000万 PVくらいのサイトにHUの解析タグを埋めて計測したい

↓

プロダクション環境のタグを渡したら既存クライアント全滅する

↓

専用環境が必要 => CloudFormation で環境構築できるようにした

5.導入手順 2. トラッキングサーバーで計測

「トラッキングサーバーはビーコン用の1pxの GIF画像を配信するだけだし、

Nginxは優秀だからいけるはず！！」

↓

ぜんぜん余裕、なんなら t2.microでも問題ない

↓

この時点では fluent-master へはトラフィック送らずに実測値を計測

access_log => td-agent（input_tail）×=> fluent-master

5.導入手順 3. fluent-masterで集計

nginx でトラフィックみたら6000万PV くらいだった（聞いていた話の 1.5倍）

↓

まずはプロダクション環境と同じ構成でトラフィックを受けてみる

（c3.large 1台、multi process 3）

↓

CPU使用率、ロードアベレージ、ともに全然上らず、MongoDBも余裕の状態

しかし、集計は全然できていない

5.導入手順 3. fluent-masterで集計

DynamoDBがボトルネックになっていた。

=> 書き込みスループットを 50 => 400くらいに変更

↓

無事、MongoDB氏死亡

=> Index の張り方に問題があったので修正 & スケールアップ c3.xlarge=>c3.2xlarge

↓

それでも集計に遅延発生

=> プロセス数を3 => 6へ、それに伴いスケールアップ & スケールアウト

5.導入手順 4. analyzerで解析

処理が遅延しているので解析プロセス数を 6 => 10へ

それにともないスケールアップ & スケールアウト

↓

無事、MongoDB氏死亡

やはり、Index に問題あり、修正することで安定稼動

※ 1セッションの解析で 7Secくらい掛っていたのが、数ミリSecへ

6.まとめ

ボトルネックになるのはデータベースであることがほとんど

トラフィックが小さいうちはインデックスの問題は露見しない

CPU使用率、ロードアベレージが低いと不安になる（この感覚が正しい）

DynamoDBは優れたソリューション、今後はフルマネージドなインフラをどれ

だけ選定できるかが鍵になる

HUは、Fluentd を捨てて Kinesiss に移行すると思う

営業の持ってくる数字を信じてはいけない