Download as PDF, PPTX
Uploaded bykidach1
PDF, PPTX25,453 views
大規模Node.jsを支える ロードバランスとオートスケールの独自実装
東京Node学園祭2015http://nodefest.jp/2015/#!/schedule
Related topics:
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2famazonauroratips-170307140000-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
![[Tokyo NodeFest 2015] Hardware Hacking for Javascript Developers](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fnodefesthardwarehackingforjavascriptdevelopers-151107050537-lva1-app6891-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
大規模Node.jsを支える ロードバランスとオートスケールの独自実装
- 1.
- 2.・Github https://github.com/kidach1・Twitter https://twitter.com/kidach1・Qiitahttp://qiita.com/kidach1・Akatsuki Inc.・Node / JavaScript /TypeScript Ruby / Rails / Android Dvorak Keyboardkidach1
- 3.
- 4.
- 5.
- 6.
- 7.Client： Cocos2d-x (c++)Server： API Server：Rails WebsocketServer：Node.js詳しくはスマホアプリにおけるマルチプレイアクションゲーム開発の実例紹介http://www.slideshare.net/aktsk/ss-52126411/1システム概要
- 8.
- 9.
- 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がクライアントからのリクエストを受け付け、配下のサーバ群へ振り分ける形式」との相性
- 13.
- 14.・Socket.ioとELBの相性 ✕ ✕ ELBのTCPListenerを使った場合StickySessionがサポートされていないため、Socket.ioのhandshakingが通らずコネクションが確立できない立ちはだかる壁
- 16.
- 17.・ELBの下にNginxやHAProxyを立ててip-hashでバランスしstickinessを担保する 過去事例１ Load-balancing Websockets onEC2 — 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-15753751TV連動サービスのリアルタイム通知を支える技術http://www.slideshare.net/tsuyoshitorii5/public-43549341
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.・インスタンス50台同時起動$ INSTANCE_NUM=50 kumogatacreate cloudformation/kumogata.rb prod-realtime→ LobbyServer / GameServer 25台ずつのクラスタが生成されるkumogata
- 34.
- 35.
- 36.
- 37.・kumogataで複数攻撃サーバー同時立ち上げ $ kumogata createcloudformation/bees-kumogata.rb bees・ansibleでsocke.io-clientの攻撃スクリプトを複数台同時実行 $ ansible-playbook -i ./hosts/develop/ec2.py bees.yml —private-key=<key_path>LoadTesting
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.・4人同時対戦 → GameServerはマッチした4人を同一ノードに送り込む仕組み → ノード間の協調が不要、実装がシンプルに・全国マッチング →LobbyServerは全ノード間でユーザーのセッション情報の協調が必要 → socketio/socket.io-redisを利用LB Point
- 44.
- 45.Lobby & GameCluster・Multi-AZ・擬似FailOver ・各クラスタ最低構成台数を持っておき、この閾値を下回るとAutoscaleが発火 ・AutoscaleでFOの機能をざっくり吸収 ・状態を持たないdisposableな設計のため実現しやすかったAvailability
- 46.LoadBalancer & AutoscalingServer → SPOFになるとしたらこちら（直接リクエストを受け付けることがないのでリスクは少ないが、稼働台数が少ないため）・Multi-AZ・FailOver ・Lobbyクラスタ用LB、Gameクラスタ用LB それぞれがお互いをSocket.ioプロセスベースで監視し合う ・障害発生時に一方が片方の機能を吸収する形で自動でFailOver ・インスタンスが復旧した時点で自動でFailBackAvailability
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 61.Anti Pattern・ NotDRY・ Fat I/O
- 62.
- 63.Hot / Cold・Cold-> Observable : Observer ＝ 1 : 1・Hot -> Observable : Observer ＝ 1 : n・特定のオペレータ（publish等）を使うと Cold→Hotに変換可能・特定のオペレータ（connect等）を使うと HotObservableの値がObserver達に一斉通知
- 64.
- 65.
- 66.
- 67.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.