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