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

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

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

4.
背景

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

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

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

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

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

10.
But…
しかし…

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

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

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

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

15.
結果

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

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

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

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

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

21.
バトンタッチ

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

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

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

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

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

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

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

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

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

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

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

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

34.
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++ベースのライブラリを積極的に使うべし

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

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

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

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

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

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

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

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

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

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

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

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

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

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