Submit Search
Upload
大規模Node.jsを支える ロードバランスとオートスケールの独自実装
•
56 likes
•
25,346 views
kidach1
Follow
東京Node学園祭2015 http://nodefest.jp/2015/#!/schedule
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 77
Download Now
Download to read offline
Recommended
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
dcubeio
Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方
Taku Miyakawa
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Masahito Zembutsu
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Hitachi, Ltd. OSS Solution Center.
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
メタプログラミングって何だろう
メタプログラミングって何だろう
Kota Mizushima
backlogsでもCI/CDする夢を見る
backlogsでもCI/CDする夢を見る
Takeru Maehara
Sparkをノートブックにまとめちゃおう。Zeppelinでね!(Hadoopソースコードリーディング 第19回 発表資料)
Sparkをノートブックにまとめちゃおう。Zeppelinでね!(Hadoopソースコードリーディング 第19回 発表資料)
NTT DATA OSS Professional Services
More Related Content
What's hot
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
Takuto Wada
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Recruit Lifestyle Co., Ltd.
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
Yuta Shimada
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
Keycloakの最近のトピック
Keycloakの最近のトピック
Hitachi, Ltd. OSS Solution Center.
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
Hironobu Isoda
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
WebSocketのキホン
WebSocketのキホン
You_Kinjoh
マイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦い
ota42y
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
Akihiro Kuwano
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
NTT DATA Technology & Innovation
インフラCICDの勘所
インフラCICDの勘所
Toru Makabe
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
Kotlinアンチパターン
Kotlinアンチパターン
Recruit Lifestyle Co., Ltd.
What's hot
(20)
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
テストコードの DRY と DAMP
テストコードの DRY と DAMP
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Keycloakの最近のトピック
Keycloakの最近のトピック
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
DockerとPodmanの比較
DockerとPodmanの比較
Redisの特徴と活用方法について
Redisの特徴と活用方法について
WebSocketのキホン
WebSocketのキホン
マイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦い
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
インフラCICDの勘所
インフラCICDの勘所
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Kotlinアンチパターン
Kotlinアンチパターン
Viewers also liked
[Tokyo NodeFest 2015] Hardware Hacking for Javascript Developers
[Tokyo NodeFest 2015] Hardware Hacking for Javascript Developers
Tomomi Imura
The State of JavaScript (2015)
The State of JavaScript (2015)
Domenic Denicola
unassert - encourage reliable programming by writing assertions in production
unassert - encourage reliable programming by writing assertions in production
Takuto Wada
Node.jsv0.8からv4.xへのバージョンアップ ~大規模Push通知基盤の運用事例~
Node.jsv0.8からv4.xへのバージョンアップ ~大規模Push通知基盤の運用事例~
Recruit Technologies
スマホアプリにおけるマルチプレイアクションゲーム開発の実例紹介
スマホアプリにおけるマルチプレイアクションゲーム開発の実例紹介
aktsk
TV連動サービスのリアルタイム通知を支える技術
TV連動サービスのリアルタイム通知を支える技術
Tsuyoshi Torii
【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発&運営技法
【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発&運営技法
モノビット エンジン
마이크로소프트 앱 플랫폼을 이용한 어플리케이션 개발과 배포
마이크로소프트 앱 플랫폼을 이용한 어플리케이션 개발과 배포
Dae Kim
Node.jsのオートスケールをFRPで管理する
Node.jsのオートスケールをFRPで管理する
kidach1
Va tutorial
Va tutorial
yg0808
Android nodejs binary-transfer_130531ss
Android nodejs binary-transfer_130531ss
ts170
THE OPEN
THE OPEN
Yoshihiro Furukawa
Aws 2014 lt
Aws 2014 lt
Yoshihiro Furukawa
OSC2010 TOKYO/Spring Asterisk Seminar
OSC2010 TOKYO/Spring Asterisk Seminar
Kenichi 深海
World Cup Marketing 2014
World Cup Marketing 2014
Viddyad
冗長構成で定価100万以下バラクーダ ロードバランサー
冗長構成で定価100万以下バラクーダ ロードバランサー
BarracudaJapan
Wakamonog6 “ISPのネットワーク”って どんなネットワーク?
Wakamonog6 “ISPのネットワーク”って どんなネットワーク?
Satoshi Matsumoto
Layer 4 Load Balancer (NAT, IP Tunnelling, DR)
Layer 4 Load Balancer (NAT, IP Tunnelling, DR)
Kota Uchida
Node.jsで対戦ゲーム作ったよ
Node.jsで対戦ゲーム作ったよ
Yuusuke Takeuchi
What Teens Want Beinggirl Pres
What Teens Want Beinggirl Pres
Dave Knox
Viewers also liked
(20)
[Tokyo NodeFest 2015] Hardware Hacking for Javascript Developers
[Tokyo NodeFest 2015] Hardware Hacking for Javascript Developers
The State of JavaScript (2015)
The State of JavaScript (2015)
unassert - encourage reliable programming by writing assertions in production
unassert - encourage reliable programming by writing assertions in production
Node.jsv0.8からv4.xへのバージョンアップ ~大規模Push通知基盤の運用事例~
Node.jsv0.8からv4.xへのバージョンアップ ~大規模Push通知基盤の運用事例~
スマホアプリにおけるマルチプレイアクションゲーム開発の実例紹介
スマホアプリにおけるマルチプレイアクションゲーム開発の実例紹介
TV連動サービスのリアルタイム通知を支える技術
TV連動サービスのリアルタイム通知を支える技術
【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発&運営技法
【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発&運営技法
마이크로소프트 앱 플랫폼을 이용한 어플리케이션 개발과 배포
마이크로소프트 앱 플랫폼을 이용한 어플리케이션 개발과 배포
Node.jsのオートスケールをFRPで管理する
Node.jsのオートスケールをFRPで管理する
Va tutorial
Va tutorial
Android nodejs binary-transfer_130531ss
Android nodejs binary-transfer_130531ss
THE OPEN
THE OPEN
Aws 2014 lt
Aws 2014 lt
OSC2010 TOKYO/Spring Asterisk Seminar
OSC2010 TOKYO/Spring Asterisk Seminar
World Cup Marketing 2014
World Cup Marketing 2014
冗長構成で定価100万以下バラクーダ ロードバランサー
冗長構成で定価100万以下バラクーダ ロードバランサー
Wakamonog6 “ISPのネットワーク”って どんなネットワーク?
Wakamonog6 “ISPのネットワーク”って どんなネットワーク?
Layer 4 Load Balancer (NAT, IP Tunnelling, DR)
Layer 4 Load Balancer (NAT, IP Tunnelling, DR)
Node.jsで対戦ゲーム作ったよ
Node.jsで対戦ゲーム作ったよ
What Teens Want Beinggirl Pres
What Teens Want Beinggirl Pres
Similar to 大規模Node.jsを支える ロードバランスとオートスケールの独自実装
Type scriptmemo
Type scriptmemo
ytanno
0831 node学園lt
0831 node学園lt
Kazuya Fukumoto
javascript を Xcode でテスト
javascript を Xcode でテスト
Yoichiro Sakurai
いまさら触るAwt
いまさら触るAwt
Keiichi Kobayashi
ちょっとGoogle Analyticsの話しようぜ
ちょっとGoogle Analyticsの話しようぜ
Shinobu Okano
Unreal engine4を使ったVRコンテンツ製作で 120%役に立つtips集+GDC情報をご紹介
Unreal engine4を使ったVRコンテンツ製作で 120%役に立つtips集+GDC情報をご紹介
エピック・ゲームズ・ジャパン Epic Games Japan
Draft: Observability, Service Mesh and Microservices
Draft: Observability, Service Mesh and Microservices
Taiki
コーディング入門以前
コーディング入門以前
Yutaka Kinjyo
GitHub ActionsでiOSのCIを実現しよう
GitHub ActionsでiOSのCIを実現しよう
Shinya Nakajima
Building Static Website With Github And Jekyll
Building Static Website With Github And Jekyll
Yoji Shidara
node.js koとhtml5とwebsocketsと
node.js koとhtml5とwebsocketsと
scdn
VSCodeで始めるAzure Static Web Apps開発
VSCodeで始めるAzure Static Web Apps開発
Yuta Matsumura
Pyramid + socket.io 人狼を作ってみた
Pyramid + socket.io 人狼を作ってみた
Junya Hayashi
【Unity道場京都スペシャル4】Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
【Unity道場京都スペシャル4】Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
UnityTechnologiesJapan002
Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
Yoshifumi Kawai
Android studio で行ってみよう!!
Android studio で行ってみよう!!
Kazuaki Ueda
スマホアプリディレクターが考えていること
スマホアプリディレクターが考えていること
Kazuaki KURIU
PlayFramework 2.0 Javaと WebSocketでつくる リアルタイムMVC Webアプリケーション
PlayFramework 2.0 Javaと WebSocketでつくる リアルタイムMVC Webアプリケーション
Kazuhiro Hara
ソーシャルゲーム開発における運用とそのツール
ソーシャルゲーム開発における運用とそのツール
Yoshiaki Sugimoto
SwiftとReactNativeで似たようなUIを作った際の記録
SwiftとReactNativeで似たようなUIを作った際の記録
Fumiya Sakai
Similar to 大規模Node.jsを支える ロードバランスとオートスケールの独自実装
(20)
Type scriptmemo
Type scriptmemo
0831 node学園lt
0831 node学園lt
javascript を Xcode でテスト
javascript を Xcode でテスト
いまさら触るAwt
いまさら触るAwt
ちょっとGoogle Analyticsの話しようぜ
ちょっとGoogle Analyticsの話しようぜ
Unreal engine4を使ったVRコンテンツ製作で 120%役に立つtips集+GDC情報をご紹介
Unreal engine4を使ったVRコンテンツ製作で 120%役に立つtips集+GDC情報をご紹介
Draft: Observability, Service Mesh and Microservices
Draft: Observability, Service Mesh and Microservices
コーディング入門以前
コーディング入門以前
GitHub ActionsでiOSのCIを実現しよう
GitHub ActionsでiOSのCIを実現しよう
Building Static Website With Github And Jekyll
Building Static Website With Github And Jekyll
node.js koとhtml5とwebsocketsと
node.js koとhtml5とwebsocketsと
VSCodeで始めるAzure Static Web Apps開発
VSCodeで始めるAzure Static Web Apps開発
Pyramid + socket.io 人狼を作ってみた
Pyramid + socket.io 人狼を作ってみた
【Unity道場京都スペシャル4】Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
【Unity道場京都スペシャル4】Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
Unityによるリアルタイム通信とMagicOnionによるC#大統一理論の実現
Android studio で行ってみよう!!
Android studio で行ってみよう!!
スマホアプリディレクターが考えていること
スマホアプリディレクターが考えていること
PlayFramework 2.0 Javaと WebSocketでつくる リアルタイムMVC Webアプリケーション
PlayFramework 2.0 Javaと WebSocketでつくる リアルタイムMVC Webアプリケーション
ソーシャルゲーム開発における運用とそのツール
ソーシャルゲーム開発における運用とそのツール
SwiftとReactNativeで似たようなUIを作った際の記録
SwiftとReactNativeで似たようなUIを作った際の記録
大規模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
3.
http://qiita.com/kidach1/items/b75882edd4f715ebc213 事前資料
4.
アジェンダ ・作ったもの ・アーキテクチャ ・経緯 ・ロードバランス ・オートスケール ・負荷試験 ・その他 ・FRP ・可用性 ・監視
5.
作ったもの ・2D横スクロールアクション ・マルチプレイ ・4人同時対戦 ・座標同期型 ・プレイヤーマッチング (Rating /
Keyword)
6.
作ったもの • リアルタイム非同期4人同時プレイ 奪い合いアクションゲーム • 動きやモーション、ダメージ、アイ テム取得/使用などのイベントを4人 で連携しあう
7.
Client: Cocos2d-x (c++) Server: API Server:Rails Websocket
Server:Node.js 詳しくは スマホアプリにおけるマルチプレイアクションゲーム開発の実例紹介 http://www.slideshare.net/aktsk/ss-52126411/1 システム概要
8.
・同時一万接続を想定 → 常時数十∼百数十台規模の軽量インスタンスが稼働 ・柔軟なオートスケール → 負荷に応じて柔軟に自律的に伸縮してくれるような インフラにしたい システム規模
/ 要件
9.
Architecture Realtime Cluster LB Cluster API Cluster Redis Cluster
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.
・Websocketと(E)LBの相性 ✕ Websocketは一度接続するとサーバー/クライアント 間のセッションを張りっぱなしにするため、コネクショ ン確立時以外LBを挟むメリットがない。むしろコネク ション数が肥大化し、ボトルネックになり得る 立ちはだかる壁
14.
・Socket.ioとELBの相性 ✕ ✕ ELBのTCP
Listenerを使った場合StickySessionがサポー トされていないため、Socket.ioのhandshakingが通らず コネクションが確立できない 立ちはだかる壁
16.
今回はNodeやwsに乗る場面じゃなかったか・・? しかし最近のNode・JavaScript界隈の目覚ましい進化や、 npmの資産は魅力的 →もう少し過去事例を調べる
17.
・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立てて、はどうみ ても辛い
18.
・運用コスト増大(LBとProxy) ・そもそもupstreamの動的変更が出来ない(※)ため、ぶら下が るec2インスタンスの変更には手動対応が必要 → オートスケール実現不可 ※
実際はNGINX Plusの購入をすれば可能だが、多数のインスタンスを柔軟に追 加削除するには、結局追加モジュールを書く必要がありそう 過去事例1
19.
・ELBはセッション確立時のみ、もしくはELBなしでロード バランスするケース 過去事例2 WebSocket on AWS
(ロードバランサと Socket接続を使用したイベント通知サー バの負荷分散) http://www.slideshare.net/ AmazonWebServicesJapan/socket-15753751 TV連動サービスのリアルタイム通知を支 える技術 http://www.slideshare.net/tsuyoshitorii5/ public-43549341
20.
・なるほど!これだ やはりクライアントとsocket.ioクラスタの間にはLB置かないべき ・AutoScalingは想定していないようだったので、その仕組みを追 加するように拡張していく方向で決定 過去事例2
21.
LoadBalance
22.
・EC2のtagをもとに、各クラスタ(lobby/game server)の各 ノードごとのコネクション数を毎秒取得 ・RedisのSortedSetで保管/更新 ・APIサーバーからリアルタイムで最も接続数の少ないノー ドを読み出し、クライアントにendpointを返却 LoadBalance
23.
LB visualization
24.
・インスタンスはコア数が少ないものを大量に横に並べる方針 ・SingleThreadで動くNodeとは相性が良い ・コア数を増やしてClusterModuleを利用する方法もあるが、 (同一コアへのバランスなど)実装が複雑化するので避ける Point
25.
・CPU使用率やLoadAverageといった指標ではなく、socket.ioプロセス (アプリケーションレイヤー)でのコネクション数を見てバランス →サーバー自体はhealtyなのにプロセスは死んでいた、等を排除 ※ websocket/socket.ioを用いる場合、httpと比べて「OSレイヤーの指標と アプリケーションのプロセスの生死」が直結していない印象だった(正確 には、その部分に対する勘所がなかった)ため Point
26.
Autoscaling
27.
・Game/Lobby各Clusterの状態を毎秒監視 ・設定した閾値に応じてサーバーを自動で追加/縮小 ・スケールアウトは最短で3分に一度、スケールインはよりシビ アに1時間に一度のスパンに制限(任意の値を設定可能) Autoscaling
28.
・ゼロダウンタイム ・サーバープロセスが立ち上がり接続が確認できるまでLB 側で有効なノードとして認識しない ・縮小時は、ノードへの接続がない状態でしかトリガーさ れない Autoscaling
29.
・Clusterの状態変化をシームレスにスケーリングイベントに 繋げるため、FRPのパラダイムを利用 ・Reactive-Extensions/RxJS ・詳細後述(時間の限り) Point
30.
・スケーリングのツールはCloudFormation ・だが、次の課題を吸収するためRubyラッパーである kumogataを利用 Point
31.
・socket.ioプロセスベースでコネクション数を監視、閾値に応じて 柔軟に増減台数を決定したい → 監視と増減台数決定部分はNode(前述のFRPの箇所)で、台数 に応じたスケーリングはCloudFormationで実現したい → CloudFormation単体(JSON)では力不足 Cloudformation
32.
・kumogata winebarrel/kumogata https://github.com/winebarrel/kumogata ・cloudformationをRubyで。 →任意のインスタンス数 指定ロジックの記述 kumogata
33.
・インスタンス50台同時起動 $ INSTANCE_NUM=50 kumogata
create cloudformation/kumogata.rb prod- realtime → LobbyServer / GameServer 25台ずつのクラスタが生成される kumogata
34.
・同時1万Connectionをシミュレートしたい ・攻撃サーバー1台ではマシンパワー不足 LoadTesting
35.
LoadTesting newsapps/beeswithmachineguns https://github.com/newsapps/beeswithmachineguns jmeter内包 =
httpのみ・・
36.
・結局自分で作る socketio/socket.io-clientベース https://github.com/socketio/socket.io-client LoadTesting
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
39.
・Websocket/Socket.ioとELBの相性の問題 → 消滅 実装してみて
40.
・LBが直接ユーザーからのコネクションを受けることがない ため、単一障害点になるリスクが低い。 実運用において、 ・直接的な障害無し ・緊急対応的な手動オペレーション無し (事前に必要とわかっているデプロイ/メンテ等を除く) 実装してみて
41.
・本質的な部分(※)の実装は薄く、モジュール化可能 ※各ノードの任意の状態(コネクション数やCPU使用率など)を常時監視 し、設定した閾値に応じて任意のスクリプトをトリガー ・今回のsocket.ioのようなニッチなケースに限らず、http以外 のプロトコルでAutoscaleさせたい時にも使えるかもしれない ・SPDY/HTTP2やwebRTC etc.. 実装してみて
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
47.
・監視 ・CloudWatch ・Slack連携 ・破壊的なイベント発生時やサーバーの状態を定期的 にSlackで通知 Monitoring
48.
Autoscaling
49.
Redis内で刻々と更新されていくインスタンス毎のコネク ション数をもとに、オートスケールの発火を管理する Point
50.
_人人人人人_ > F R P <  ̄Y^Y^Y^Y ̄
51.
・Redisから取得したデータを基軸とした一本のストリーム ・ストリームに対して様々な制御(オペレーション) ・スケーリングイベントの発火 Design
52.
Autoscaling
53.
オートスケールの発火条件 ・負荷(※今回は接続数)に応じてトリガー ・指定時刻にトリガー ・事前に設定したクラスタごとの最低稼働台数を下回った際トリガー Design
54.
Implementation
55.
Implementation
56.
Implementation
57.
Implementation
58.
Anti Pattern 冗長なストリーム Redundant Stream
61.
Anti Pattern ・ Not
DRY ・ Fat I/O
62.
Observable Hot / Cold
63.
Hot / Cold ・Cold
-> Observable : Observer = 1 : 1 ・Hot -> Observable : Observer = 1 : n ・特定のオペレータ(publish等)を使うと Cold→Hotに変換可能 ・特定のオペレータ(connect等)を使うと HotObservableの値がObserver達に一斉通知
64.
Autoscaling
65.
・mainStreamをHotObservableに変換(publish) ・各observer(checkByXXX)に分岐した後にconnect
66.
Hot Observable
67.
手続き型との比較
70.
FRP比: ・プリミティブな制御構造(今回は主に条件分岐)が 随所に登場し、全体の流れを俯瞰しにくい
71.
FRP ver
72.
FRPによって ・リストとして扱うことでオペレータ(filterやmapなど) を適用でき、制御構造が抽象化/隠 される ・非同期処理もストリームの一部として違和感なく扱える 結果として「コード全体の見通し向上」 つまり「本質的な処理に集中」できる
73.
・FPR→コードの見通し↑でなかなか良い ・インフラの制御はだいたいイベント駆動なので相性◎ ・まずはRx眺めてみると良いかも 結論
74.
http://qiita.com/kidach1/items/5fd764c18de7cdae24ca
75.
WE ARE HIRING! http://aktsk.jp/recruit/ or
@kidach1
76.
Thank you !
77.
Questions
Download Now