大規模Node.jsを支える ロードバランスとオートスケールの独自実装

大規模Node.jsを支える ロードバランスとオートスケールの独自実装

1. 1. 大規模Node.jsを支える ロードバランスとオートスケールの独自実装 2015/11/7 DaikiTaniguchi (@kidach1) Akatsuki inc. #nodefest2015
2. 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
3. 3. http://qiita.com/kidach1/items/b75882edd4f715ebc213 事前資料
4. 4. アジェンダ ・作ったもの ・アーキテクチャ  ・経緯  ・ロードバランス  ・オートスケール ・負荷試験 ・その他  ・FRP  ・可用性  ・監視
5. 5. 作ったもの ・2D横スクロールアクション ・マルチプレイ  ・4人同時対戦  ・座標同期型  ・プレイヤーマッチング (Rating / Keyword)
6. 6. 作ったもの • リアルタイム非同期4人同時プレイ 奪い合いアクションゲーム • 動きやモーション、ダメージ、アイ テム取得/使用などのイベントを4人 で連携しあう
7. 7. Client：  Cocos2d-x (c++) Server：  API Server：Rails  Websocket Server：Node.js 詳しくは スマホアプリにおけるマルチプレイアクションゲーム開発の実例紹介 http://www.slideshare.net/aktsk/ss-52126411/1 システム概要
8. 8. ・同時一万接続を想定  → 常時数十∼百数十台規模の軽量インスタンスが稼働 ・柔軟なオートスケール  → 負荷に応じて柔軟に自律的に伸縮してくれるような インフラにしたい システム規模 / 要件
9. 9. Architecture Realtime Cluster LB Cluster API Cluster Redis Cluster
10. 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. 11. 本構成に至った経緯
12. 12. 立ちはだかる壁 Websocket / Socket.ioは(E)LBと相性悪いらしい ※ 正確には、「LBがクライアントからのリクエストを受け 付け、配下のサーバ群へ振り分ける形式」との相性
13. 13. ・Websocketと(E)LBの相性 ✕  Websocketは一度接続するとサーバー/クライアント 間のセッションを張りっぱなしにするため、コネクショ ン確立時以外LBを挟むメリットがない。むしろコネク ション数が肥大化し、ボトルネックになり得る 立ちはだかる壁
14. 14. ・Socket.ioとELBの相性 ✕ ✕  ELBのTCP Listenerを使った場合StickySessionがサポー トされていないため、Socket.ioのhandshakingが通らず コネクションが確立できない 立ちはだかる壁
15. 15. 今回はNodeやwsに乗る場面じゃなかったか・・？ しかし最近のNode・JavaScript界隈の目覚ましい進化や、 npmの資産は魅力的 →もう少し過去事例を調べる
16. 16.  ・ELBの下にNginxやHAProxyを立ててip-hashでバランスし stickinessを担保する     過去事例１  Load-balancing Websockets on EC2 — Medium  https://medium.com/@Philmod/load-balancing- websockets-on-ec2-1da94584a5e9 →しかし、ELBの下にさらにproxy立てて、はどうみ ても辛い
17. 17. ・運用コスト増大（LBとProxy） ・そもそもupstreamの動的変更が出来ない(※)ため、ぶら下が るec2インスタンスの変更には手動対応が必要   → オートスケール実現不可  ※ 実際はNGINX Plusの購入をすれば可能だが、多数のインスタンスを柔軟に追 加削除するには、結局追加モジュールを書く必要がありそう 過去事例１
18. 18.  ・ELBはセッション確立時のみ、もしくはELBなしでロード バランスするケース     過去事例２ WebSocket on AWS (ロードバランサと Socket接続を使用したイベント通知サー バの負荷分散) http://www.slideshare.net/ AmazonWebServicesJapan/socket-15753751 TV連動サービスのリアルタイム通知を支 える技術 http://www.slideshare.net/tsuyoshitorii5/ public-43549341
19. 19. ・なるほど！これだ  やはりクライアントとsocket.ioクラスタの間にはLB置かないべき ・AutoScalingは想定していないようだったので、その仕組みを追 加するように拡張していく方向で決定 過去事例２
20. 20. LoadBalance
21. 21. ・EC2のtagをもとに、各クラスタ（lobby/game server）の各 ノードごとのコネクション数を毎秒取得 ・RedisのSortedSetで保管/更新 ・APIサーバーからリアルタイムで最も接続数の少ないノー ドを読み出し、クライアントにendpointを返却 LoadBalance
22. 22. LB visualization
23. 23. ・インスタンスはコア数が少ないものを大量に横に並べる方針  ・SingleThreadで動くNodeとは相性が良い  ・コア数を増やしてClusterModuleを利用する方法もあるが、 （同一コアへのバランスなど）実装が複雑化するので避ける Point
24. 24. ・CPU使用率やLoadAverageといった指標ではなく、socket.ioプロセス （アプリケーションレイヤー）でのコネクション数を見てバランス  →サーバー自体はhealtyなのにプロセスは死んでいた、等を排除  ※ websocket/socket.ioを用いる場合、httpと比べて「OSレイヤーの指標と アプリケーションのプロセスの生死」が直結していない印象だった（正確 には、その部分に対する勘所がなかった）ため Point
25. 25. Autoscaling
26. 26. ・Game/Lobby各Clusterの状態を毎秒監視 ・設定した閾値に応じてサーバーを自動で追加/縮小 ・スケールアウトは最短で3分に一度、スケールインはよりシビ アに1時間に一度のスパンに制限（任意の値を設定可能） Autoscaling
27. 27. ・ゼロダウンタイム  ・サーバープロセスが立ち上がり接続が確認できるまでLB 側で有効なノードとして認識しない  ・縮小時は、ノードへの接続がない状態でしかトリガーさ れない Autoscaling
28. 28. ・Clusterの状態変化をシームレスにスケーリングイベントに 繋げるため、FRPのパラダイムを利用  ・Reactive-Extensions/RxJS  ・詳細後述（時間の限り） Point
29. 29. ・スケーリングのツールはCloudFormation  ・だが、次の課題を吸収するためRubyラッパーである kumogataを利用 Point
30. 30. ・socket.ioプロセスベースでコネクション数を監視、閾値に応じて 柔軟に増減台数を決定したい → 監視と増減台数決定部分はNode（前述のFRPの箇所）で、台数 に応じたスケーリングはCloudFormationで実現したい → CloudFormation単体（JSON）では力不足 Cloudformation
31. 31. ・kumogata  winebarrel/kumogata  https://github.com/winebarrel/kumogata ・cloudformationをRubyで。  →任意のインスタンス数   指定ロジックの記述 kumogata
32. 32. ・インスタンス50台同時起動 $ INSTANCE_NUM=50 kumogata create cloudformation/kumogata.rb prod- realtime → LobbyServer / GameServer 25台ずつのクラスタが生成される kumogata
33. 33. ・同時1万Connectionをシミュレートしたい ・攻撃サーバー1台ではマシンパワー不足 LoadTesting
34. 34. LoadTesting newsapps/beeswithmachineguns https://github.com/newsapps/beeswithmachineguns jmeter内包 ＝ httpのみ・・
35. 35. ・結局自分で作る socketio/socket.io-clientベース https://github.com/socketio/socket.io-client LoadTesting
36. 36. ・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
37. 37. LoadTesting
38. 38. ・Websocket/Socket.ioとELBの相性の問題  → 消滅 実装してみて
39. 39. ・LBが直接ユーザーからのコネクションを受けることがない ため、単一障害点になるリスクが低い。 実運用において、  ・直接的な障害無し  ・緊急対応的な手動オペレーション無し  （事前に必要とわかっているデプロイ/メンテ等を除く） 実装してみて
40. 40. ・本質的な部分（※）の実装は薄く、モジュール化可能  ※各ノードの任意の状態（コネクション数やCPU使用率など）を常時監視 し、設定した閾値に応じて任意のスクリプトをトリガー ・今回のsocket.ioのようなニッチなケースに限らず、http以外 のプロトコルでAutoscaleさせたい時にも使えるかもしれない  ・SPDY/HTTP2やwebRTC etc.. 実装してみて
41. 41. Appendix
42. 42. ・4人同時対戦  → GameServerはマッチした4人を同一ノードに送り込む仕組み  → ノード間の協調が不要、実装がシンプルに ・全国マッチング  → LobbyServerは全ノード間でユーザーのセッション情報の協調 が必要  → socketio/socket.io-redisを利用 LB Point
43. 43. Availability
44. 44. Lobby & Game Cluster ・Multi-AZ ・擬似FailOver  ・各クラスタ最低構成台数を持っておき、この閾値を下回る とAutoscaleが発火   ・AutoscaleでFOの機能をざっくり吸収   ・状態を持たないdisposableな設計のため実現しやすかった Availability
45. 45. LoadBalancer & Autoscaling Server  → SPOFになるとしたらこちら（直接リクエストを受け付けること がないのでリスクは少ないが、稼働台数が少ないため） ・Multi-AZ ・FailOver  ・Lobbyクラスタ用LB、Gameクラスタ用LB それぞれがお互いを Socket.ioプロセスベースで監視し合う  ・障害発生時に一方が片方の機能を吸収する形で自動でFailOver  ・インスタンスが復旧した時点で自動でFailBack Availability
46. 46.  ・監視   ・CloudWatch   ・Slack連携    ・破壊的なイベント発生時やサーバーの状態を定期的 にSlackで通知 Monitoring
47. 47. Autoscaling
48. 48. Redis内で刻々と更新されていくインスタンス毎のコネク ション数をもとに、オートスケールの発火を管理する Point
49. 49. ＿人人人人人＿ ＞ F R P ＜ ￣Y^Y^Y^Y￣
50. 50. ・Redisから取得したデータを基軸とした一本のストリーム ・ストリームに対して様々な制御（オペレーション） ・スケーリングイベントの発火 Design
51. 51. Autoscaling
52. 52. オートスケールの発火条件 ・負荷（※今回は接続数）に応じてトリガー ・指定時刻にトリガー ・事前に設定したクラスタごとの最低稼働台数を下回った際トリガー Design
53. 53. Implementation
54. 54. Implementation
55. 55. Implementation
56. 56. Implementation
57. 57. Anti Pattern 冗長なストリーム Redundant Stream
58. 58. Anti Pattern ・ Not DRY ・ Fat I/O
59. 59. Observable Hot / Cold
60. 60. Hot / Cold ・Cold -> Observable : Observer ＝ 1 : 1 ・Hot -> Observable : Observer ＝ 1 : n ・特定のオペレータ（publish等）を使うと  Cold→Hotに変換可能 ・特定のオペレータ（connect等）を使うと  HotObservableの値がObserver達に一斉通知
61. 61. Autoscaling
62. 62. ・mainStreamをHotObservableに変換（publish） ・各observer（checkByXXX）に分岐した後にconnect
63. 63. Hot Observable
64. 64. 手続き型との比較
65. 65. FRP比： ・プリミティブな制御構造（今回は主に条件分岐）が 随所に登場し、全体の流れを俯瞰しにくい
66. 66. FRP ver
67. 67. FRPによって ・リストとして扱うことでオペレータ（filterやmapなど） を適用でき、制御構造が抽象化/隠 される ・非同期処理もストリームの一部として違和感なく扱える 結果として「コード全体の見通し向上」 つまり「本質的な処理に集中」できる
68. 68. ・FPR→コードの見通し↑でなかなか良い ・インフラの制御はだいたいイベント駆動なので相性◎ ・まずはRx眺めてみると良いかも 結論
69. 69. http://qiita.com/kidach1/items/5fd764c18de7cdae24ca
70. 70. WE ARE HIRING! http://aktsk.jp/recruit/ or @kidach1
71. 71. Thank you !
72. 72. Questions