LT at Node School Festival(http://nodefest.jp/2014/) with @jimisky

1. ド初心者が
5000QPSの広告配信APIを
Node.jsで構築したおはな死

2. 自己紹介
＠zuqqhi2
• EC系企業広告エンジニア(3年目)
• 好きなこと：観葉植物を愛でる
@Jimisky
• EC系企業広告エンジニア(2年目)
• 好きなこと：食べること

3. 未だにドが取れたぐらいの初心者です
間違ったことを言ったら、遠慮無くマサカリを！
ちなみにLTもド初心者です
注意事項

4. 背景

5. 背景
上司
「この広告の表示、一ヶ月で３倍速くできない？」
「！？」

7. スピード改善前の広告パーツ
複数のAPIを叩く
↓
データの加工
↓
Viewの動的生成
ほぼ全てブラウザ側のJavascriptで処理

8. スピード改善前の広告パーツ
• CSS:約4000行
• JavaScript:いっぱい
• リクエスト数：34 / 1 display
• データ転送量:1MB / 1 display
• MAX5000QPSくらい
え、私の広告リッチすぎ・・・？

9. 表示スピード改善計画
1. 直列で呼んでいる複数APIの一本化
2. APIのレスポンスをKVSにキャッシュ
3. ロジック部分をバックエンド化
4. PaaS化してスケール可能に
Browser
← →
API
API
API
API
Browser
← →
API
API
K
V
S
API
API
API

10. 表示スピード改善計画
1. 直列で呼んでいる複数APIの一本化
2. APIのレスポンスをKVSにキャッシュ
3. ロジック部分をバックエンド化
4. PaaS化してスケール可能に
Browser
← →
API
API
API
API
Browser
← →
API
API
K
V
S
API
API
API
ここをNode.jsで！

11. But…
しかし…

12. 当時の私たち
Node.js経験
５日
０日

13. しかも
広告の仕様をほぼ把握していない

14. さらに
[悲報]実質の開発期間は２週間
になりました

15. 本当にいろいろあったものの
かろうじて動くレベルになり
初回リリースの日がやってきた！
(クライアントのJSをほぼ機械的にコピペ)

16. 結果

17. 結果
• PaaSのインスタンス1台で7QPS

18. 結果
• PaaSのインスタンス1台で7QPS
• 絶えず自壊するインスタンス

19. 結果
• PaaSのインスタンス1台で7QPS
• 絶えず自壊するインスタンス
• ユーザー間でレスポンスが混線…？
（グローバル変数の削除漏れ）

20. ぎゃああああ
※撮影前日水道が止まり、お風呂に入れていません

21. これはアカン！と速攻ロールバック
バグ潰しとQPS改善の長い戦いが始まった…

22. バトンタッチ

23. 得られた教訓（一部）
1. child_process.exec以外の方法を使うべし
2. C/C++ベースのライブラリを積極的に使うべし
3. よく使用するデータはローカルメモリにのせて使うべし
4. チューニングは勘に頼らずダンプを使うべし

24. 1.child_process.exec
広告配信サーバ APIサーバ

25. 1.child_process.exec
広告配信サーバ APIサーバ
httpモジュール

26. 1.child_process.exec
広告配信サーバ APIサーバ
httpモジュール

27. 1.child_process.exec
広告配信サーバ APIサーバ
httpモジュール
+ proxy

28. 1.child_process.exec
広告配信サーバ APIサーバ
httpモジュール
+ proxy A

29. 1.child_process.exec
広告配信サーバ APIサーバ
child_process.exec(‘curl’)

30. 1.child_process.exec
広告配信サーバ APIサーバ
child_process.exec(‘curl’)

31. 1.child_process.exec
広告配信サーバ APIサーバ
child_process.exec(‘curl’)
通信方法 1通信あたりの速度(ms)
child_process.exec(‘curl’) 50ms
httpモジュール 30ms

32. 1.child_process.exec
広告配信サーバ APIサーバ
httpモジュール
+ proxy
教訓1：child_process.exec以外の方法を使うべし

33. 2.ライブラリ
• 巨大オブジェクトのclone
– node-clone
• 巨大XMLの解析
– Jquery
• Redisクライアント
– node_redis

34. 2.ライブラリ
• 巨大オブジェクトのclone
– node-clone 10ms
– node-v8-clone 1ms
• 巨大XMLの解析
– jquery 250ms
– node-expat 1ms
• Redisクライアント
– node_redis 10ms
– hiredis-node 7ms

35. 2.ライブラリ
• 巨大オブジェクトのclone
– node-clone 10ms
– node-v8-clone 1ms
• 巨大XMLの解析
– jquery 250ms
– node-expat 1ms
• Redisクライアント
– node_redis 10ms
– hiredis-node 7ms
教訓2：C/C++ベースのライブラリを積極的に使うべし

36. 3.ローカルオンメモリ
広告配信サーバ Redis Cluster
加工済み
広告情報

37. 3.ローカルオンメモリ
広告配信サーバ Redis Cluster
②加工済み
広告情報
メモリ
①加工済み
広告情報

38. 3.ローカルオンメモリ
広告配信サーバ Redis Cluster
②加工済み
広告情報
メモリ
①加工済み
広告情報
メモリ使用量が一定値を超えたら
利用回数が少ないデータを削除

39. 3.ローカルオンメモリ
広告配信サーバ Redis Cluster
②加工済み
広告情報
メモリ
①加工済み
広告情報
メモリ使用量が一定値を超えたら
利用回数が少ないデータを削除
ストレージ 1通信あたりの速度(ms)
Redis 7ms
ローカルオンメモリ 1ms

40. 3.ローカルオンメモリ
広告配信サーバ Redis Cluster
②加工済み
広告情報
メモリ
①加工済み
広告情報
メモリ使用量が一定値を超えたら
利用回数が少ないデータを削除
教訓3：よく使用するデータはローカルメモリにのせて使うべし

41. 4.CPU/Heapダンプ
• CPUダンプ
– nodegrind
• 指定した期間内のCPUの状態をダンプする
• Chromeの開発者ツールで結果を確認できる
• Heapダンプ
– heapdump
• ダンプ取得関数を実行した時点でのHeap状態をダンプする
• Chromeの開発者ツールで結果を確認できる

42. 4.CPU/Heapダンプ
• CPUダンプ
– nodegrind

43. 4.CPU/Heapダンプ
• Heapダンプ
– heapdump

44. 4.CPU/Heapダンプ
• CPUダンプ
– nodegrind
• 指定した期間内のCPUの状態をダンプする
• Chromeの開発者ツールで結果を確認できる
• Heapダンプ
– heapdump
• ダンプ取得関数を実行した時点でのHeap状態をダンプする
• Chromeの開発者ツールで結果を確認できる
教訓4：チューニングは勘に頼らずダンプを使うべし

45. 得られた教訓再掲
1. child_process.exec以外の方法を使うべし
2. C/C++ベースのライブラリを積極的に使うべし
3. よく使用するデータはローカルメモリにのせて使うべし
4. チューニングは勘に頼らずダンプを使うべし

46. 得られた教訓再掲
1. child_process.exec以外の方法を使うべし
2. C/C++ベースのライブラリを積極的に使うべし
3. よく使用するデータはローカルメモリにのせて使うべし
4. チューニングは勘に頼らずダンプを使うべし
５．安請け合いしないようにしよう！！

47. 成果
• １インスタンスごとのQPS
– 初期バージョン 7
– 最終バージョン 350
• 広告表示速度
– 約30～60% UP
• 広告のクリック率
– 約15% UP

48. Node.jsいいね！
※撮影前日水道が止まり、お風呂に入れていません

49. ご静聴ありがとうございました