株式会社ベーシックで毎月末開催しているTGIFの発表資料です。 https://basicinc.jp/

1. HUで6000万PVのトラフィッ
クを捌くまでに起ったことを
ありのままに話すぜ
CMT
SAITO

2. 1.自己紹介
斎藤です。ビールが好きです。最近は焼酎を飲んでいます。

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

4. 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

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

6. 2. HUの解析インフラ

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

8. 4.トラフィック

9. 5.導入手順 1. CloudFormationで環境構築
4000万 PVくらいのサイトにHUの解析タグを埋めて計測したい
↓
プロダクション環境のタグを渡したら既存クライアント全滅する
↓
専用環境が必要 => CloudFormation で環境構築できるようにした

10. 5.導入手順 2. トラッキングサーバーで計測
「トラッキングサーバーはビーコン用の1pxの GIF画像を配信するだけだし、
Nginxは優秀だからいけるはず！！」
↓
ぜんぜん余裕、なんなら t2.microでも問題ない
↓
この時点では fluent-master へはトラフィック送らずに実測値を計測
access_log => td-agent（input_tail）×=> fluent-master

11. 5.導入手順 3. fluent-masterで集計
nginx でトラフィックみたら6000万PV くらいだった（聞いていた話の 1.5倍）
↓
まずはプロダクション環境と同じ構成でトラフィックを受けてみる
（c3.large 1台、multi process 3）
↓
CPU使用率、ロードアベレージ、ともに全然上らず、MongoDBも余裕の状態
しかし、集計は全然できていない

12. 5.導入手順 3. fluent-masterで集計
DynamoDBがボトルネックになっていた。
=> 書き込みスループットを 50 => 400くらいに変更
↓
無事、MongoDB氏 死亡
=> Index の張り方に問題があったので修正 & スケールアップ c3.xlarge=>c3.2xlarge
↓
それでも集計に遅延発生
=> プロセス数 を3 => 6へ、それに伴いスケールアップ & スケールアウト

13. 5.導入手順 4. analyzerで解析
処理が遅延しているので解析プロセス数を 6 => 10へ
それにともないスケールアップ & スケールアウト
↓
無事、MongoDB氏 死亡
やはり、Index に問題あり、修正することで安定稼動
※ 1セッションの解析で 7Secくらい掛っていたのが、数ミリSecへ

14. 6.まとめ
ボトルネックになるのはデータベースであることがほとんど
トラフィックが小さいうちはインデックスの問題は露見しない
CPU使用率、ロードアベレージが低いと不安になる（この感覚が正しい）
DynamoDBは優れたソリューション、今後はフルマネージドなインフラをどれ
だけ選定できるかが鍵になる
HUは、Fluentd を捨てて Kinesiss に移行すると思う
営業の持ってくる数字を信じてはいけない