1.
リアルタイムサーバー
Erlang/OTP で作る PubSub サーバー

2.
自己紹介
@yamionp
gumi ってところで R&D をしています
サーバーさわりはじめて 15 年
Python 5年
Erlang 6ヶ月

3.
関わったもの

4.
今日話す事

5.
リアルタイムサーバーを自作した話

6.
アジェンダ
なぜリアルタイムサーバーか
なぜ自作なのか
PubSubモデル
プロトコル

7.
アジェンダ
サーバー
なぜ Erlang/OTP なのか
負荷試験
実際のゲームでの使われ方

8.
なぜリアルタイムサーバーか

9.
これまでのソーシャルゲーム
非同期コミュニケーション
同時に遊んでいないのに一緒に遊んでいる感覚
ニコニコ動画
技術的制約（モバイルWeb・処理能力・バッテリー）

10.
より濃密なゲーム体験へ
より強い連携・一体感
本当の同時プレイ
ニコニコ生放送
アプリ化 / 端末性能・ネットワーク環境の向上

11.
リクエスト/レスポンス モデル
Request
ResponseClient Server

12.
リクエスト/レスポンス モデル
Request
ServerClient

13.
HTTPの問題
通信はユーザー側からしか開始できない（Serverから送れない）
無いわけではない (それで十分な場合も多い)
高頻度の通信が難しい（毎秒10回通信
オーバーヘッド
レインテンシ

14.
ServerClient
SYN
SYN+ACK
ACK
最初に Connection を確立する
TCP Connection を直接使う

15.
TCP Connection を直接使う
Connectionがある限り自由なタイミングで通信できる
ServerClient

16.
HTTPでもTCPは使っているが
Response を返したら Connection を破棄する
（ステートレス）
ServerClient

17.
リアルタイム通信のメリット
(準備さえできれば) どちらからでも送り始められる
一回あたりの通信コストが小さい
秒間15回とか送っても全然OK
遅延が少ない

18.
デメリット
負荷が高い・負荷分散しにくい
状態を持つので障害に弱い
エラーパターンが多くコードが複雑になりがち
端末のバッテリー消費が激しい (通信頻度が高い)

19.
なぜ自作なのか

20.
いろいろあるが・・・
Windows Server は (我々にとって) 運用コストが高い
機能過多
既存システムとの相性
ゲームでの通信に特有な仕様への対応
落としたくない。土日に寝ていられるシステムを

21.
ちなみに

22.
フルメッシュ

23.
スター
ここの話をします

24.
Pub/Subモデル

25.
Pub/Sub(出版/購読)モデルとは
非同期メッセージングモデルの一種
Subscribe (購読) しているユーザーにメッセージを Publish (出版) する
Sub側は Topic という単位で購読する
Pub側は Topic にメッセージを送る
Pub側は Sub側を意識する必要がなく、疎結合になる

26.
Subscribe
Broker
Topic A
Topic B
A
B
C
D

27.
Broker
Topic A
Topic B
A
B
C
D

28.
Broker
Topic A
Publish
Topic B
A
B
C
D

29.
Broker
Topic A
Topic B
A
B
C
Publish
D

30.
Room モデルとの違い
Room の作成/削除が必要ない
Roomの管理が必要ない
Sub側 が 0 の Topic にも Publish できる
Pub側が Topic を Subscribe している必要はない

31.
導入イメージ

32.
ELB
App
Job
MQ
Batch
log
PubSub
既存の仕組みと喧嘩しないシンプルなシステムが欲しい

33.
プロトコル

34.
目指したもの
数bitを切り詰めるよりシンプルであること
必要十分な拡張性
シリアライズ・パースがしやすい

35.
概要
TCP を採用
TLV ベースのプロトコル構造
最小限の固定ヘッダと拡張部分のTLV化
4 bytes 単位

36.
固定ヘッダ
1 bit
1
6
3
2
Type (メッセージの種類) Length (全体の長さ)
SenderTimestamp (送信者時間) ※後述
ReceiverTimesamp (受信者時間) ※後述
Payload (送信内容)

37.
Payload も連続した TLV の形をとる
1
1
6
3
2
SectionType SectionLength
Value

38.
つまり

39.
1
1
6
3
2
Type Length
SenderTimestamp
ReceiverTimesamp
SectionType SectionLength
Value
SectionType SectionLength
Value

40.
この構造によるメリット
拡張しやすい
実装が比較的容易
バリデーションが容易

41.
RTT計測
ユーザー サーバー の回線状態を把握していたい
強制切断など
通信時に自分のタイマーと処理時間を加算した相手のタイマーを送る

42.
固定ヘッダ
1 bit
1
6
3
2
Type (メッセージの種類) Length (全体の長さ)
SenderTimestamp (送信者時間) ※後述
ReceiverTimesamp (受信者時間) ※後述
Payload (送信内容)

43.
Client Server
Timer Timer
1
1000
Sender Receiver
1 0 ※
※初回は相手のTimerが
わからないので0
送信までに300msかかったので
受け取った1に300を足す
Sender Receiver
1300 301
1300
321
この時点で自分のタイマーが
321なのでRTTは20ms
421
送信までに100msかかったので
受け取った1300に100を足す
Sender Receiver
421 1400
1420
この時点で自分のタイマーが
1420なのでRTTは20ms521
1520
この時点で自分のタイマーが
1520なのでRTTは20ms
Sender Receiver
521 1500
受信から送信までに200msかかったので
受け取った1300に200を足す

44.
なぜTCPか？
NAT超え
到達保証
順序保証
輻輳制御
ゲームによってはTCPのみでも十分な場合も多い(ターン制など

45.
UDP拡張の試験中
あくまでTCPのサブとしてのUDP
到達保証なし・順序保証なし・輻輳制御なし
品質の良くない回線などでとにかく早く送りたい場合
重要なやりとりはTCPで行う

46.
サーバー

47.
コンセプト
土管としての役割に徹する
ステートフル、データレス
品質重視
安定して繋がり、そこそこ速く、落ちない。

48.
土管に徹する
コネクションを持つ＝状態が多くなる
ネットワークプログラミングの大半はエラーハンドリング
持つべき状態は極力減らす
アップデートの可能性を減らす

49.
ステートフル・データレス
状態（ステート）は持つが、データは持たない。
永続化はしない
必要なデータは外部に問い合わせ or 通知 (ex. 認証
起動したらすぐ使える状態

50.
認証 App
PubSub
1.game start
2.IP:Port, Token, Topic
3.Token
4.Token 5.OK
6.OK

51.
品質重視
ドキュメント
暗黙のルールを作らない
Sphinxを採用(& packetdiag)
負荷試験
性能を保証する
自動テスト
デグレさせない
End to End テスト
タイムアウト
同時処理

52.
なぜ Erlang/OTP なのか

53.
Erlang/OTP とは
エリクソン社製の関数型言語 (1986年生まれ)
1998年からオープンソース
動的型付け
優れた耐障害性
並行処理・分散処理に強い

54.
軽量プロセス
起動速度・使用メモリが超軽量なプロセス
OSのプロセス・スレッドとは違う
一瞬で立ち上がり、ごくわずかなメモリしか使用しない
インスタンスを作る感覚でプロセスを作る
数万、数十万のプロセス走る
プロセス間ではメッセージ通信ができる

55.
Let it crash
エラーが起こったプロセスは死ぬ
プロセスが死んだ事は監視している別のプロセスに対処させる
再起動や後始末をしたり、連携するほかのプロセスの処置をしたり
監視プロセスは別のマシンで動いていても問題ない
正常系と異常系の処理が分離される

56.
Erlang採用事例紹介
League of Legends
https://engineering.riotgames.com/news/chat-service-architecture-servers
Call of Duty
https://en.wikipedia.org/wiki/Demonware
http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-
PersonShooters.pdf
WhatsApp
http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf
Game of War
https://erlangcentral.org/senior-erlang-engineer-machine-zone/

57.
社内に導入実績あり
認証・課金・テキスト検証、それぞれのマイクロサービス
数年間の連続稼働実績
全アプリからのリクエストを数台で処理している

58.
プロセスデザイン
tcp session session_udp
ErlangVM
※ system process
link link

59.
tcp session
session_udp
※ system process
session_sup
sessions_sup
arkps_sup
session_udp_sup
ErlangVM
udp_sup
gen_udp
simple_one_for_one
one_for_all
one_for_one
one_for_one
one_for_one

60.
停止フロー

61.
tcp session
session_udp
※ system process
session_sup
sessions_sup
arkps_sup
session_udp_sup
ErlangVM
udp_sup
gen_udp
simple_one_for_one
one_for_all
one_for_one
one_for_one
one_for_one
session がなんらかの理由で Down

62.
tcp session
session_udp
※ system process
session_sup
sessions_sup
arkps_sup
session_udp_sup
ErlangVM
udp_sup
gen_udp
simple_one_for_one
one_for_all
one_for_one
one_for_one
one_for_one
検知した session_sup が session_udp_sup に停止を送り
session_udp_sup がそれを受けて session_udpを停止

63.
tcp session
session_udp
※ system process
session_sup
sessions_sup
arkps_sup
session_udp_sup
ErlangVM
udp_sup
gen_udp
simple_one_for_one
one_for_all
one_for_one
one_for_one
one_for_one
session_udp の停止を確認して session_udp_sup が停止

64.
tcp session
session_udp
※ system process
session_sup
sessions_sup
arkps_sup
session_udp_sup
ErlangVM
udp_sup
gen_udp
simple_one_for_one
one_for_all
one_for_one
one_for_one
one_for_one
監視下のすべてのプロセスの終了を確認して session_sup が停止

65.
tcp session
session_udp
※ system process
session_sup
sessions_sup
arkps_sup
session_udp_sup
ErlangVM
udp_sup
gen_udp
simple_one_for_one
one_for_all
one_for_one
one_for_one
one_for_one
link している tcp も停止

66.
負荷試験

67.
なぜ負荷試験を行うか
限界性能を知る
ボトルネックの発見
スケールすることの確認
必要容量の計算
コスト試算

68.
Locustを使いました
Python製分散負荷試験ツール
このためにフル機能の Python クライアントを開発
接続側はどんなに頑張っても限界がくるので数で解決
スポットインスタンス安い
m4.large のスポットインスタンスが t2.medium オンデマンドより安
い

69.
Locust Slaves
PubSub
Locust Master
m4.2xlargem4.xlarge
CPU: 8
RAM: 32GB
CPU: 4
RAM: 16GB
x8

70.
メッセージ数計測
PubSub
x71 msg
合計 8msg

71.
PubSub

72.
PubSub

73.
PubSub

74.
user/room 8
message/user/sec 0.2
waittime[
ms] 5000
rooms 100 1000 2000 3000 3500 3750
(想定) users 800 8000 16000 24000 28000 30000
(想定)
message/sec 1280 12800 25600 38400 44800 48000
(実測)
message/sec 1270 12783 25560 38328 44787 21054
(Server)CPU [%] 66.5 360.4 404.7 560.9 635.8 444.4
(Server)RAM [%] 0.6 2.4 3.7 6.2 7.2 16.5
RTT Med [ms] 1 2 5 12 19 34
RTT Avg [ms] 14 11 12 14 27 1260
RTT Max [ms] 44 49 75 356 536 62798
End to End Med
[ms] 1 3 8 18 39 460
End to End Avg
[ms] 2 12 13 21 50 3017
End to End Max
[ms] 747 738 754 1003 1315 100979

75.
user/room 8
message/user/sec 1
waittime[
ms] 1000
rooms 100 400 800 900 1000
(想定) users 800 3200 6400 7200 8000
(想定)
message/sec 6400 25600 51200 57600 64000
(実測)
message/sec 6360 25527 48195 53240 25154
(Server)CPU [%] 275.8 618.3 709.3 774.7 766.7
(Server)RAM [%] 0.5 1.1 2.7 3 11.2
RTT Med [ms] 1 1 5 12 5
RTT Avg [ms] 10 7 24 40 494
RTT Max [ms] 45 48 491 1100 34295
End to End Med
[ms] 2 11 36 80 310
End to End Avg
[ms] 10 13 54 120 970
End to End Max
[ms] 554 550 981 2923 44120

76.
user/room 8
message/user/sec 15
waittime[
ms]
66.66666
6666666
7
rooms 10 50 70 80 90 100
(想定) users 80 400 560 640 720 800
(想定)
message/sec 9600 48000 67200 76800 86400 96000
(実測)
message/sec 9096 46047 58600 60764 63539 26390
(Server)CPU [%] 229.8 694.7 776.6 775.6 787.9 786.2
(Server)RAM [%] 0.4 0.5 0.6 0.7 0.7 8
RTT Med [ms] 38 2 7 10 15 24
RTT Avg [ms] 30 14 15 17 23 194
RTT Max [ms] 45 67 93 122 522 20686
End to End Med
[ms] 19 19 24 33 46 73
End to End Avg
[ms] 18 21 27 37 50 293
End to End Max
[ms] 618 631 657 718 1231 39470

77.
UDPのスループットがTCPの1/5問題
V「5万/s はいける」
1万/s でない

78.
fprof でプロファイリング
sendが遅い
port_command で非同期にしたら解決
gen_udp/tcp:send がボトルネックなときにやること
http://qiita.com/mururu/items/9b77e49b5b8a2815ceb6
10万/s 出ました

79.
user/room 8
message/user/sec 0.2
waittime[
ms] 5000
rooms 100 2000 3750 6250 7500 8750
(想定) users 800 16000 30000 50000 60000 70000
(想定)
message/sec 1280 25600 48000 80000 96000 112000
(実測)
message/sec 1281 25639 48124 78742 94555 97731
(Server)CPU [%] 46.9 312.2 426.8 625 723.2 718
(Server)RAM [%] 2 6.8 9.8 14 17.3 18.7

80.
user/room 8
message/user/sec 1
waittime[
ms] 1000
rooms 100 400 800 1000 1200 1400 1600
(想定) users 800 3200 6400 8000 9600 11200 12800
(想定)
message/sec 6400 25600 51200 64000 76800 89600 102400
(実測)
message/sec 6356 25472 51202 63890 75912 88143 99033
(Server)CPU [%] 139.4 269.1 425 500.3 625.8 699.2 765.3
(Server)RAM [%] 2 3.6 5 5 5.2 5.2 6.6

81.
user/room 8
message/user/sec 15
waittime[
ms]
66.66666
6666666
7
rooms 10 50 70 80 90 100 110 120 130 140
(想定) users 80 400 560 640 720 800 880 960 1040 1120
(想定)
message/sec 9600 48000 67200 76800 86400 96000 105600 115200 124800 134400
(実測)
message/sec 8912 45967 64648 74035 83211 91581 99596 106775 112889 116739
(Server)CPU [%] 161.5 374.2 489.7 535.8 582.1 632.1 666.4 703.7 726.9 784.7
(Server)RAM [%] 2.1 2.3 2.3 2.3 2.3 2.2 1.8 2.6 3 3.4

82.
実際のゲームでの使われ方

83.
App
PubSub
Private Topic
Private Topic
matching start
list
matching
Private Topic battle starter

84.
HW障害への対応

85.
App
PubSub
PubSub
PubSub
1. battle info
2. 割り振り先をMySQLから取得
3. IP:Port, Token, Topic
4. 接続開始
監視サーバー
サーバー一覧

86.
App
PubSub
PubSub
PubSub
1. Down
2. 検知
3. リスト更新
4. 切断されたので問い合わせ
5. Downを確認して割り振り先を決定・保存
6. 新割り振り先を案内
監視サーバー

87.
バージョンアップ
今繋いでいる人
クライアントのバージョンxサーバーのバージョン
新しいサーバーをたてて、Appでの新規接続の案内先を変更
既存の接続がいなくなったら落として終了

88.
Room Worker
Room情報をゲームロジックまで含めて面倒をみる
最初に Subscribe する
ブローカーからはクライアント扱い

89.
App
PubSub
Battle Topic
6.battle info 2.battle start
room worker
3.room create
4.subscribe
5. ok
7. IP:Port, Token, Topic
8. subscribe

90.
作ってみて
思ったより速度が出た
デグレさせない事の重要さ
運用を最優先の姿勢

91.
ご清聴ありがとうございました

92.
One More Thing

93.
ArkPS Server

94.
OSSとして公開予定

95.
https://github.com/arkps/
(予定地)