大規模Node.jsを支える ロードバランスとオートスケールの独自実装
56 likes25,443 views
大規模Node.jsを支える ロードバランスとオートスケールの独自実装
- 1. 大規模Node.jsを支える ロードバランスとオートスケールの独自実装 2015/11/7 DaikiTaniguchi (@kidach1) Akatsuki inc. #nodefest2015
- 2. ・Github https://github.com/kidach1 ・Twitter https://twitter.com/kidach1 ・Qiita http://qiita.com/kidach1 ・Akatsuki Inc. ・Node / JavaScript /TypeScript Ruby / Rails / Android Dvorak Keyboard kidach1
- 7. Client： Cocos2d-x (c++) Server： API Server：Rails Websocket Server：Node.js 詳しくは スマホアプリにおけるマルチプレイアクションゲーム開発の実例紹介 http://www.slideshare.net/aktsk/ss-52126411/1 システム概要
- 10. A. 各Cluster/各Nodeの状態を毎秒監視 B. Node毎の重み付けを毎秒更新 C. Clusterの状態に応じてオートスケール D. LB間でのプロセス監視&自動FailOver ①② LobbyNode取得 ③ Lobby接続 ④ マッチングとroom_idの決定 ⑤ room_id返却 ⑥⑦ start(REST API)（GameNode取得） ⑧ GameNodeとroomを指定の上 GameServer接続 ⑨ finish(REST API) Architecture
- 11. 本構成に至った経緯
- 12. 立ちはだかる壁 Websocket / Socket.ioは(E)LBと相性悪いらしい ※ 正確には、「LBがクライアントからのリクエストを受け 付け、配下のサーバ群へ振り分ける形式」との相性
- 14. ・Socket.ioとELBの相性 ✕ ✕ ELBのTCP Listenerを使った場合StickySessionがサポー トされていないため、Socket.ioのhandshakingが通らず コネクションが確立できない 立ちはだかる壁
- 17. ・ELBの下にNginxやHAProxyを立ててip-hashでバランスし stickinessを担保する 過去事例１ Load-balancing Websockets on EC2 — Medium https://medium.com/@Philmod/load-balancing- websockets-on-ec2-1da94584a5e9 →しかし、ELBの下にさらにproxy立てて、はどうみ ても辛い
- 18. ・運用コスト増大（LBとProxy） ・そもそもupstreamの動的変更が出来ない(※)ため、ぶら下が るec2インスタンスの変更には手動対応が必要 → オートスケール実現不可 ※ 実際はNGINX Plusの購入をすれば可能だが、多数のインスタンスを柔軟に追 加削除するには、結局追加モジュールを書く必要がありそう 過去事例１
- 19. ・ELBはセッション確立時のみ、もしくはELBなしでロード バランスするケース 過去事例２ WebSocket on AWS (ロードバランサと Socket接続を使用したイベント通知サー バの負荷分散) http://www.slideshare.net/ AmazonWebServicesJapan/socket-15753751 TV連動サービスのリアルタイム通知を支 える技術 http://www.slideshare.net/tsuyoshitorii5/ public-43549341
- 21. LoadBalance
- 23. LB visualization
- 26. Autoscaling
- 28. ・ゼロダウンタイム ・サーバープロセスが立ち上がり接続が確認できるまでLB 側で有効なノードとして認識しない ・縮小時は、ノードへの接続がない状態でしかトリガーさ れない Autoscaling
- 33. ・インスタンス50台同時起動 $ INSTANCE_NUM=50 kumogata create cloudformation/kumogata.rb prod- realtime → LobbyServer / GameServer 25台ずつのクラスタが生成される kumogata
- 35. LoadTesting newsapps/beeswithmachineguns https://github.com/newsapps/beeswithmachineguns jmeter内包 ＝ httpのみ・・
- 37. ・kumogataで複数攻撃サーバー同時立ち上げ $ kumogata create cloudformation/bees-kumogata.rb bees ・ansibleでsocke.io-clientの攻撃スクリプトを複数台同時実行 $ ansible-playbook -i ./hosts/develop/ec2.py bees.yml —private- key=<key_path> LoadTesting
- 38. LoadTesting
- 42. Appendix
- 43. ・4人同時対戦 → GameServerはマッチした4人を同一ノードに送り込む仕組み → ノード間の協調が不要、実装がシンプルに ・全国マッチング → LobbyServerは全ノード間でユーザーのセッション情報の協調 が必要 → socketio/socket.io-redisを利用 LB Point
- 44. Availability
- 45. Lobby & Game Cluster ・Multi-AZ ・擬似FailOver ・各クラスタ最低構成台数を持っておき、この閾値を下回る とAutoscaleが発火 ・AutoscaleでFOの機能をざっくり吸収 ・状態を持たないdisposableな設計のため実現しやすかった Availability
- 46. LoadBalancer & Autoscaling Server → SPOFになるとしたらこちら（直接リクエストを受け付けること がないのでリスクは少ないが、稼働台数が少ないため） ・Multi-AZ ・FailOver ・Lobbyクラスタ用LB、Gameクラスタ用LB それぞれがお互いを Socket.ioプロセスベースで監視し合う ・障害発生時に一方が片方の機能を吸収する形で自動でFailOver ・インスタンスが復旧した時点で自動でFailBack Availability
- 48. Autoscaling
- 52. Autoscaling
- 54. Implementation
- 55. Implementation
- 56. Implementation
- 57. Implementation
- 61. Anti Pattern ・ Not DRY ・ Fat I/O
- 63. Hot / Cold ・Cold -> Observable : Observer ＝ 1 : 1 ・Hot -> Observable : Observer ＝ 1 : n ・特定のオペレータ（publish等）を使うと Cold→Hotに変換可能 ・特定のオペレータ（connect等）を使うと HotObservableの値がObserver達に一斉通知
- 64. Autoscaling
- 66. Hot Observable
- 67. 手続き型との比較
- 71. FRP ver
- 76. Thank you !
- 77. Questions