1. inside 2012新卒説明会
技術部 田中太陽 2011/02/28

2. 全ては１本の電話から
• from 担当のW氏
• ログインしてみると、確かに重い。
• アタックらしきアクセスの形跡あり
→ 大人なのでdenyしてスルー
• とりあえず、I/O waitが結構かかってる

3. アプリケーションの構成を確認
• ひとまずapacheのアクセスログを見てみる
• ものすごい勢いでAPIがコールされてる
• しかも、APIの処理を読んでみると、
MySQLにログを書いてる

4. 説明会コンテンツの要件
• 金曜に、リクナビで登録した人が同時にアクセス
– 2000人だと！
– この電話を受けたのは月曜
• ページアクセスに合わせ、
どの言語を何人見ているかリアルタイムに示し
たい
• スピーカーが変わったら即時切り替えたい
（´-`）.｡oO（全部従来のAPIだけでやろうとし
たら、多分負荷で落ちるな。。。)

5. 状況の配信はリアルタイムで
• APIコールによる
Apache+PHPのプロセス生成コストを減らす
• リアルタイム配信は、からあげクンサイトにて
Tatsumaki(Perl)での構築経験アリ
• リアルタイムシステム構築の実績がとにかく
もっと欲しい

6. 水曜はリハ
• 月曜に電話を受けたのに、水曜までに
完全な状態にするのは無理
• ひとまず動くシステムを作りつつ、
何をしたいのかを把握してもらう
• Tatsumaki(Perl)でシステムを構築開始
• 水曜昼に何とか間に合う

7. リハ終了
• この時点ではAPIを合わせただけ
• 負荷対策等は全くやってない
• 数人がやってみて、割と好評だったらしい
• 「これ、１０００人接続して落ちないの？」
– by CEO
– 一番リーチしたい人

8. 徹夜一日目
• スケーリングも考慮したシステム構築
→ マスタ・スレーブ方式
• 【急募】リバースプロキシサーバ
– １時間以上繋いでいてもタイムアウトにならない
• nginxのタイムアウトは75秒が最大。使えない＞＜
– ロードバランサ付き
– URLに応じたルーティングも
• つまりL7対応が必要
• HAProxyを発見！期待通りの動作

9. HAProxyの設定（１）

10. HAProxyの設定（２）
• 各種設定はブロックごとに適用可能
• 例えば、staticブロックだけtimeoutを
もっと短くすることもできる

11. マスタ・スレーブの方針
• マスタプロセス
– こちらがメイン
– マスタだけで動ける体制にしておく
• スレーブプロセス
– 特定のURLのみに対応するように
– スレーブの起動と同時にマスタへアクセス
そのソケットハンドラをどこかに紐付けて管理
→ 管理クラスを作成してそこに格納しておいた

12. ストリーミングシステムの概要

13. 冗長化できた！
• 負荷試験をしてみる
→ JMeterで1000コネクション作成
• 閲覧者がアクションを起こしたときの
APIをバシバシ叩かせる
• 超重い。。。
／(^o^)＼ナンテコッタイ

14. 0.3req/secだと。。。
• １リクエストに３秒かかるのは絶対落ちる
• スレーブへのpush_writeが
シーケンシャルに書いてあるので、
全部終わるまでレスポンスを返さないのかも
→ AE::timerで逃げてみる
• APIレスポンスはすぐ返るようになった
• が、全体的には
思ったようなパフォーマンスは出ない

15. マスタの負荷を減らす
• マスタのプロセス増やせばいいんじゃない
• 対応はすぐにできた
– 複数のマスタに接続できるようにしただけ
– HAProxyでも、APIアクセスについては
ラウンドロビンするように設定
• が、それでも全体的には
思ったようなパフォーマンスは出ない

16. マスタとスレーブが同居してる
• マスタのパフォーマンスが
スレーブに引っ張られているのではないか
• いずれにせよ、両方コケるのはヤバい
• マスタサーバとスレーブサーバを
物理的に分割する
• が、それでも全体的には
思ったようなパフォーマンスは出ない

17. マスタとスレーブの関係
• マスタ同士、スレーブ同士は独立の関係
• スレーブから全てのマスタを参照する
• 更新APIはいずれかのマスタで受け、
全スレーブに通知後、閲覧者にプッシュされる

18. ふと、天の声が聞こえた
• Luke, use the “node.js”
（ルークよ、node.jsを使うのだ）
• 嘘です
• でも、マスタプロセスなら実装は複雑ではな
いので、node.jsで書き直せると思った。
• １時間後、
node.js（マスタ）+Tatsumaki（スレーブ）完成
• 動いた☺

19. パフォーマンス大幅アップ
• 当社比300%UP
• これって、スレーブもnode.jsにすれば、
もっと早くなるんじゃね？
→ 徹夜二日目へ（翌日が本番！）

20. スレーブの実装
だいたいあってる

21. マスタの実装（一部）
スレーブの実装に加え、
こんな感じで更新APIをつくっていく

22. 本番当日朝、ついに完成する
• ちゃんと動いた
• 出社後、スレーブプロセスを入れ替え、
負荷試験をする
• 2000コネクション。以前の２倍の負荷に
• それでも前より早い
– APIに連続1000回アクセスするテストスクリプトを作成
– 10req/sec近くは余裕だった
• これならいける。。。かも！
• 念のため、マスタ用サーバをもう１台手配
• 結果、３台体制に

23. そして本番
• 400,500,600と上がる接続数
• 常にtopで負荷を確認
– マスタは余裕、スレーブはLA0.3くらい
• 21:44 説明会終了！
• 最終的な接続数は合計1400前後

24. 振り返って
• （自分にとって）新技術投入しまくりの３日間
– node.js初の実戦投入
– マスタスレーブ独自構築
– HAProxy
– etc…
• node.jsで構築できた事で、
全体で技術共有しやすくなった
– 特に僕の所属しているクライアントワークチームは
PHPやAS3、JSがメインのため

25. 今後に向けた課題
• node.jsについての理解が足りてない
– proxyではなく、node.js側から接続が切れてしまう疑惑
• 現象レベルでの確認のみなので、調査中
– プロセスフォークでの省メモリ化
• 運用レベルでの連携の足りなさ
– プライオリティの設定
– 例外発生時の動作の確認
• 設計上の問題
– 異常時の接続数確認等々
– 無停止でのリソース追加方法
etc…

26. Tatsumaki? or node.js?
• Tatsumaki
– システム全体がよくテストされている
– 豊富なCPANリソースを使える
– 既存のPerlシステムとの連携
• node.js
– 省リソースかつハイパフォーマンス
– JS書ける人ならだれでもサーバサイドの
非同期プログラミングができる
– モテる（it’s just HOPE!）

27. FIN.
ご清聴
ありがとうございました！