More Related Content
Next GAE Heroku を使って 3分でRailsアプリをリリース ConoHa VPSの コマンドラインツールを作った ConoHaにおける オブジェクトストレージの 利用動向 What's hot (11)
Text editor anywhereでtextareaもsublime text 2 Web Worker +α - HTML5/JavaScript and Service Worker API Closure CompilerのES6対応 あるいはES6時代のAltJS生存戦略 The state of sbt 0.13, sbt server, and sbt 1.0 (ScalaMatsuri ver) Similar to inside 2012新卒説明会 (20)
Shinjuku.rb #29 ActiveJobでSQS使ったのとその永続化についての話 Lineにおけるspring frameworkの活用 サーバ擬人化ユーザ会キックオフ資料 Slideshare ver インフラエンジニアがk8sでアプリを作って見えた今後のインフラ レガシーなアプリにWeb apiを実装してなみだ目になったのでちょっといろいろ教えてください 2015年GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクション 20140131 万葉帰社日発表 チーム積み重ね 公開版 RESTful API (JAX-RS) 書くだけで仕様書も 自動で作られていく話 with MicroProfile Open API Riot.jsを用いたweb開発 takusuta tech conf #1 inside 2012新卒説明会
- 5. 状況の配信はリアルタイムで
• APIコールによる
Apache+PHPのプロセス生成コストを減らす
• リアルタイム配信は、からあげクンサイトにて
Tatsumaki(Perl)での構築経験アリ
• リアルタイムシステム構築の実績がとにかく
もっと欲しい
- 7. リハ終了
• この時点ではAPIを合わせただけ
• 負荷対策等は全くやってない
• 数人がやってみて、割と好評だったらしい
• 「これ、１０００人接続して落ちないの？」
– by CEO
– 一番リーチしたい人
- 8. 徹夜一日目
• スケーリングも考慮したシステム構築
→ マスタ・スレーブ方式
• 【急募】リバースプロキシサーバ
– １時間以上繋いでいてもタイムアウトにならない
• nginxのタイムアウトは75秒が最大。使えない＞＜
– ロードバランサ付き
– URLに応じたルーティングも
• つまりL7対応が必要
• HAProxyを発見！期待通りの動作
- 10. HAProxyの設定（２）
• 各種設定はブロックごとに適用可能
• 例えば、staticブロックだけtimeoutを
もっと短くすることもできる
- 11. マスタ・スレーブの方針
• マスタプロセス
– こちらがメイン
– マスタだけで動ける体制にしておく
• スレーブプロセス
– 特定のURLのみに対応するように
– スレーブの起動と同時にマスタへアクセス
そのソケットハンドラをどこかに紐付けて管理
→ 管理クラスを作成してそこに格納しておいた
- 13. 冗長化できた！
• 負荷試験をしてみる
→ JMeterで1000コネクション作成
• 閲覧者がアクションを起こしたときの
APIをバシバシ叩かせる
• 超重い。。。
／(^o^)＼ナンテコッタイ
- 17. マスタとスレーブの関係
• マスタ同士、スレーブ同士は独立の関係
• スレーブから全てのマスタを参照する
• 更新APIはいずれかのマスタで受け、
全スレーブに通知後、閲覧者にプッシュされる
- 18. ふと、天の声が聞こえた
• Luke, use the “node.js”
（ルークよ、node.jsを使うのだ）
• 嘘です
• でも、マスタプロセスなら実装は複雑ではな
いので、node.jsで書き直せると思った。
• １時間後、
node.js（マスタ）+Tatsumaki（スレーブ）完成
• 動いた☺
- 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!）
