CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…

Copyright Drecom Co., Ltd. All Rights Reserved.
1
IoT向け汎用protocol MQTTの
リアルタイムゲーム通信利用と実装、
そして未来へ…
株式会社ドリコム
川上知成
市川毅明

2
講演者紹介
テクノロジー本部研究開発部長
• 川上知成
– 技術調査
– PM ・TD レビュー
同部
• 市川毅明
– アーキテクト
– ゲーム・汎用基盤開発

3
本セッションの概要
• 弊社崖っぷちバスターズ®でリアルタイム
通信4人協力バトルの実現に、MQTT
protocolを採用
• インターネット時代における通信技術の
トレンドとともに採用に至った選定過程、
クライアント／サーバー実装やインフラ
構成などを紹介
受講者が得られるであろう知見：
• 技術採用プロセス事例
• リアルタイム通信
ゲームクライアント・サーバー開発技術・手法
• OSS技術の活用方法

4
目次
1. ネットワークゲームの近年の流れについて
2. インターネットモバイルリアルタイム
ゲームを実現する課題
3. 弊社事例：崖っぷちバスターズ®
1. 通信技術選定
2. MQTTとは
3. 実装について
1. 全体概略
2. サーバー実装概略
3. アプリケーション実装
4. 考察
5. そして未来へ…

5
IoTとは？

6
IoT
＝Internet of Things
IoT
背景
デバイスの進化
ネットワーク技術の進化
ゲーム
スマートフォン
クラウド上での運営

7
ネットワークゲーム
近年の流れについて

8
ネットワークゲーム
• 2000年前後
– アーケード：店舗間専用線
– パソコン通信、インターネット
– MO/MMORPGの誕生
• 2010年頃以降
– 高速インターネット環境 Gbps
– MO/MMORPGの普及と多様化
– eSports 誕生
– モバイルゲームの一般化

9
モバイルの潮流
• 通信環境：
– 従量課金
– パケット定額
– ブロードバンド普及
wifi通信の利用促進
– 3G/4Gの誕生
→常時接続通信が可能に
• 携帯モバイルゲーム
– カジュアル・ミニゲーム
– webソーシャルゲーム
– Nativeソーシャルゲーム
→携帯モバイルゲームの一般化
常時通信×携帯モバイルゲームが進化
→リアルタイム体感へ

10
インターネットモバイル
リアルタイムゲームを
実現する課題

11
課題
• 通信環境
• 実装手法
• インフラ環境

12
通信環境
• 回線速度
業務用∼家庭用∼移動通信（3G/4GLTE）
例:10Gbps超∼数G - 100MB∼70- 20 MB
– 理論値と実測値
– 不安定
• 帯域保証
• 物理的な干渉・回折
• 移動体通信網とWifiの混在
→転送頻度/データ量の考慮

13
実装手法
• protocol：
リアルタイム通信の特殊性
– UDP / TCPなど通信protocol の選択/設計
– Data Format / Payload 設計
• 実装効率：
ゲームという専門性ó汎用性
– 設計はゲームロジックによるアプリ毎様々

14
インフラ環境
• インフラ環境の変化：
– 専用線＋オンプレミス
– インターネット＋オンプレミス
– インターネット＋IaaS／Paasクラウド
• 技術課題
– Load Balancing
– NAT超え
– 爆発的なユーザ増加に合わせた受け入れ
→可用性・冗長性

15
弊社事例：
崖っぷちバスターズ ®

16
崖っぷちバスターズ® ご紹介
崖っぷちバスターズ®は、壁を壊して、敵を崖から突き落す、新感覚のぶっ
放し協力バトルゲームです。GPS連動したエリアバトルでスコアランキング
を競い、エリアNo.1になることで、そのエリアを制圧しながら拡大していくこ
とができます。また、最大4人で遊べるマルチプレイ機能を搭載!仲間と連
携して必殺技を繰り出せば、敵に大ダメージを与えることができます。手に
汗握るバトルが繰り広げられる、「みんなで遊べるゲーム」の決定版です。

17
ゲームの特徴 <通信>
• シングルプレイ
– Web API通信を中心に構成
– バトルはスタンドアローン
• マルチプレイ
– バトルはリアルタイム通信を行い、
最大4名の複数プレイヤーが１つの
バトルセッションで協力プレイ

18
開発基盤Bisque
Bisqueにて開発
Copyright Drecom Co., Ltd. All Rights Reserved. 28
Bisque!
Bisque !
JNIObjecGve'C++!

19
通信技術選定

20
通信技術選定の背景
弊社観点
• 強み
– WebAPIを中心のサーバー/クライアント資産
– クラウド利用実績
• 弱み
– リアルタイムサーバー・クライアント構築
– リアルタイム通信ゲーム制作

21
リアルタイム通信実現に向けて
⃝方針
– 実現スピード重視
既存技術を活用し、工期短縮
– ゲーム仕様実現に焦点
⃝ゲーム仕様
– 1Room 4名のターン制
⃝技術要件
– リアルタイム性→同期通信
– 同期性の担保レイテンシー：最大1秒目標
クライアントにHostを立て、
サーバはメッセージの同期のみ
クライアント側ではメッセージを元に再現
プロトを経て

22
技術検討

23
技術検討の一部
• http polling
• websocket
• Socket.io
• MQTT
• Platform機能
• 商用エンジン
• 選定観点
– Protocol
– Server実装
– Client実装
– ライセンス
総合的に評価
MQTT案ベースに詳細検討

24
Client
検証フェーズ
検証仮実装本実装結合 β
■MQTT案
Game
イ
ン
フ
ラ
ミドルウェア選定
単体負荷試験
クラウド選定
構成設計
ブラッシュアップ
実データ負荷テスト
組み込みテスト
α→機能洗い出し
仕様検証
基本ライブラリ選定
ライブラリ実装チューニング
単体検証
仕様ブラッシュアップ
組み込み実装

25
MQTTとは?

26
MQTTとは
MQTT(MQ Telemetry Transport)
• MQTTとは、publish/subscribeモデルに基づ
くメッセージプロトコル
• 低速・不安定なネットワークで動作するための
機能や非力なデバイスで動くための軽量化、同
期通信な点などが特徴
• 事例：
Facebook Messenger など各種Chat

27
歴史
1999年よりIBMが主導で商用製品提供も
2011年 Eclipse Foundationへコード寄贈
2013年 OASIS 国際標準化団体で標準化へ
・・・発展途中・・・
Ø 近年ではサービス提供事業者も
Ø Protocol仕様はロイヤリティフリー
Ø サーバー/クライアント実装複数

28
特徴
• 軽量：固定ヘッダーは2byte,
Payload: Max256MB
• Topic：送受信先. 階層構造
• QoS:
• Will
• Retain
• CleanSession
※TCP Connection NAT配下でも問題なく動作。
0:At
most
once
1:At
least
once
2:
Exactly
once

29
概要：Pub/Subモデル
MQTT Broker
publisher
Subscriber
Topic例：
/cedec/2015/room315/iot
/cedec/2015/room315/gameengine
/cedec/2015/room315/#
/cedec/2015/+/iot
A
B
C
D
A
B
A B C
A D

30
実装について

31
実装について
マルチプレイバトルにおける
• 全体概略
• サーバー実装概略
• アプリケーション実装

32
全体概略

33
MQTT
Cluster
BackEnd全体構成 Draft
internet
Client

pub
/
sub
/
http(rest)
LB
(MQTT) LB(web)LB
(HTTP)
Web/
AP
Web/
AP
Web/
APWeb/
AP
KVS DBDBKVS
Reverse-‐Proxy
MQTT
Broker
REST Worker
MQTT
BrokerMQTT
BrokerMQTT
Broker
direct
routing
※検討当時資料

34
BackEnd構成概略
internet
Client

pub
/
sub
/
http(rest)
LB(web)
Web/
AP
Web/
AP
Web/
APWeb/
AP
KVS DB
MQTT
BrokerMQTT
BrokerMQTT
BrokerMQTT
Broker
direct
routing
※検討当時資料

35
利用方法概略
• MQTT Broker Serverを
BattleInstanceServerの位置づけで利用。
• Broker Serverの利用：
– Topic Room
– Room管理はAPIServer制御
– Broker ServerよりMessageを配信
– QoS 再現性/信頼性コントロール

36
サーバー実装概略

37
Room
MQTT
Broker
Web
AP
MQTT
Broker
MQTT
Broker …
同期接続(mqtt)
非同期接続(http)
Room
Matching
Game
Client
マルチプレイバトルの接続イメージ

38
MQTT Broker
Game
Host
Client
１
同期接続(mqtt)
非同期接続(http)
Room
Guest
Client
２
Guest
Client
３
Guest
Client
４
バトルターンのイメージ
SessionMasterとして
同期委譲管理
Web/AP

39
WebAPIサーバー
• マッチング処理：
– ロビーにてマッチング処理(非同期)
– ルーム管理:
作成,メンバーJOIN/CANCEL,中断/再開,終了,破棄

40
WebAPIサーバー
• Clientが接続する
Broker Serverを選定しBalancing
• ノード死活監視、cacheリスト化
• リストから Least connections で接続

41
BrokerServer選定
• 検証観点
– １台あたりの性能・コストパフォーマンス最
大化を重視
– 高負荷時の安定性
• 最終候補
– Mosquitto
→シングルスレッド、クラスタ無し(要自作)
– RabbitMQ with MQTT Plugin
→マルチスレッド、クラスタ有り(要検証)

42
BrokerServer開発
• RabbitMQ with MQTT Plugin利用
– MQTT自体仕様のみで実装はプロダクト依存
– 不足機能の実装例
• topicの制限や禁止
• Payload Size制限
• Client操作の制限(Server設定値)
• Queues expire化
• MQTT向けのlogging
言語: erlang

43
BrokerServer構成について
• 構成案
– Broker Standalone Parallel
– Broker Clustering
※一部課題あり：Performance劣化等
• 仕様の割り切り
– Cloudの性質上可用性には限界あり
– FailOverの検知復旧時間と体感待ち時間とのト
レードオフ
→Standaloneで利用

44
BrokerServer ScaleOut
• Standaloneのためインスタンス増設で
ScaleOut
• AWSを利用しAutoScalingを実現
– CPU使用率監視
• 研究としてスポットインスタンス利用すること
でコスト圧縮も可能
– 手法詳細はslideshareにて。
http://www.slideshare.net/GedowFather/gedow-‐style-‐aws-‐spot-‐instance

45
アプリケーション編

46
MQTTクライアント選定

47
• フルスクラッチから書く
• Paho Embedded
• Mosquitto
調査の結果この3点が候補に挙がりました

48
フルスクラッチから書く
• 全部自分で作る
• 全部自分で作るので比類無き自由度
• 全部自分で作るので工数爆発
• (実は30%位作った)

49
paho
• Eclipse Foundation謹製
• ANSI Cで書かれ、データ処理だけを提供する
ので移植性と実装の自由度が高い
• 通信部分は自力で実装する必要あり

50
Mosquitto
• 古くからあるMQTTブローカー
• コア部分がlibmosquittoとして分離されており、
単体のMQTTクライアント/サーバーライブラ
リとして利用可能
• リッチな高レベルAPIが揃っている

51
検証の結果、Mosquittoを選定
• Cで書かれておりコンパクト
• コードが綺麗で読みやすい(もしもの時に重要)
• 外部ライブラリ依存が皆無
• BSDソケットさえあれば何処でも動く

52
Mosquittoの難点
• BSDソケットを使っているが、iOSで動作が怪
しいヶ所が多数
• pthreadを使っているがiOS/Androidで未実装
の関数(排他周り)を多数使用
• 他にも色々と･･･(主にシステムコール周り)

53
内製ライブラリ”Bisque”
Thread/Socket周りを
クロスプラットフォーム基盤として開発している
”Bisque”を利用した置き換え実装を行いました

54
内製ライブラリでの解決
• Socket/pthreadの弊社ライブラリBisqueで置き換え
を実施
• ただし、Mosquittoのソースには手を加えない
-> includeオーバーライド
+ Redefineリューション!
// ライブラリビルド時に定義
#define pthread_create BQ_compat_pthread_create
#define pthread_join BQ_compat_pthread_join
#define pthread_cancel BQ_compat_pthread_cancel

55
Bisqueの紹介

56
• ソースコードレベルでクロスプラットフォームを実現
する為のライブラリ群
• スマホからサーバーまで、対応可能なプラットフォー
ムのAPIを抽象化
• ゲームエンジンや他処理系への組み込みを意識し、
可能な限りプリミティブに設計

57
同一ソース群から3エディションが存在します
Bisque
Workstation
Edition(PC版)
Bisque
Bisque
Datacenter
Edition(サーバー版)

58
サウンド用I/F
OpenAL OpenSL /dev/audioXaudio2
下回りの実装は最適
なAPIを選択
アプリ開発者にはプラッ
トフォームを意識させな
い

59
One
and
Half
設計

60
柔軟な上部
(ゲームエンジンやアプリ)
強靭なでシンプル設計
の根元
(抽象化レイヤー)

61
サーバー(Ruby)
クライアント
Bisque
アーカイブモジュール
Bisque
アーカイブモジュール
全く同じコードから生成されるので
完全互換のデータ持ち回りを実現

62
・Windows
Phone
8
・Windows
10
Mobile
・iOS
・Android
・Tizen
対応プラットフォーム(2015/08
現在)
スマートフォン
PC系
・Windows
Vista以降(i386/amd64/ARM)
・Solaris
8以降
・Linux
(kernel
2.6.32以降)
・MacOS 10.5以降(PPCもOK!)
・OpenVMS
(Alpha)
・*BSD

63
崖っぷちバスターズ®での事例紹介

64
Topicの構造
ROOM/
Common System Private Host
“部屋”に対して4つのTopicがぶら下がる構造
この構造がセッション毎に作られる

65
Topicの構造
System Private Host
Topicを分ける事でメッセージフィルターを実現
メッセージの振り分けをシステムに任せる
ROOM/
Common

66
Topicの構造
Common
ホストからのゲストへのメッセージ配信用
ゲストプレイヤーがSubscribe
System
システムメッセージ用
全員がSubscribe
Private
ゲストへの個別メッセージ用
各員がPrivate/<プレイヤーID>にSubscribe
Host
ホストプレイヤーへのメッセージ用
ホストがSubscribe

67
Topicの構造
Commonホスト
ゲスト
ゲスト
例：ホストプレイヤーからのメッセージ配信
ホストはpubだけ(subしない)
ゲストはCommonにSub

68
Topicの構造
System
ホスト
ゲスト
ゲスト
例：全体への配信
全員がSubscribe

69
Topicの構造
Host ホスト
ゲスト
ゲスト
例：相互死活判定(ライブパケット)
ゲストはHostにPub

70
Topicの構造
Private/ゲストIDホストゲスト
例：相互死活判定(ライブパケット)
ホストは送信元のゲストに返信Pub

71
Pub/sub
・Topicを分ける、Subscribeする物を選ぶ事で必要なメッセー
ジだけを受信する事が出来る
・SubscribeしたTopicのメッセージは全て飛んでくるので自分
でPublishした物も受信してしまう
・Pub専用、Sub専用、Pub/Sub両用を使い分ける事により細
かいメッセージ制御が可能

72
QoS
・崖っぷちバスターズ®ではQoS0とQoS1を使用
・欠損しても影響の無いデータはQoS0
・欠損が許されないデータはQoS1

73
QoS
矢印のモーション等
アバウトに扱って問題の無い
データはQoS0で送信

74
QoS
必殺技発動
衝突等
進行に絡むデータはQoS1

75
タップ〜ヒットまでのpub
タップ
移動・スワイプ
ヒット
QoS1のメッセージさえ届けばゲームが成立するように設計
QoS1
QoS0

76
その他
・pubの量を減らす為、メッセージにプライオリティーを
付け即時送信する必要の無いデータはバッファリン
グしてから塊で送信
・QoS1でクリティカルな物には返信要求ビットを立て、再送さ
せるメカニズムを作成
・これにより1ゲーム2000アクションで100pub、総通信量を
100KB程度に抑える事に成功

77
セキュリティー

78
MQTT
over
SSLという便利なソリューションがあります

79
Mosquittoで構築したサーバーにSSL有無で1000回pub
(とあるAndroid
スマートフォン)
pubだけでSSL無しの約10倍
該当端末ではゲームに支障を来す可能性も
星の数程あるAndroid端末では同じ現象が起きる端末の存在を否
定できない
SSL無し
SSL
一部 Android端末でSSLが遅い！

80
“Bisque”難読化ライブラリ採用
• 通信の難読化には弊社タイトルで実績のある内製難読化
ライブラリを採用
• 改竄防止が主な目的なので本格的な暗号は必要ない
• ゲームで3タイトル、その他アプリでも利用されています(本
当にクリティカルなデータはSSLを使用)
• アルゴリズムは複数ありますが、今回は128bitブロックの
物を採用(送信データはほぼ1ブロックに収まる)

81
難読化ライブラリのチューニング
1024バイトの文字列を1000回難読->復号を繰り返した結果
チューニン
グ前
チューニン
グ後
高速性には定評があるが、リアルタイム通信での使用
に耐える為、対応アーキテクチャー全てでベクタライズ
を中心とした徹底的ハンドオプティマイズを実施

82
その結果・・・
• AES128(弊社はUnityで利用)より250倍速く
• 前バージョン比8000%高速化
• (コード行数50倍)
AES128
チューニン
グ前
チューニン
グ後

83
データ構造
• 高速でコンパクト
• Protocol BuffersよりもプリミティブなAPI
• サーバー側(スクリプト言語)との相互運用に優れる
通信内容はmsgpackを採用

84
データ構造
MQTTではプリミティブなデータが飛び交うので
通信内容のコンテナ化を実施しました
ヘッダー実際のデータ(msgpack)
付帯
データ
※何かに似てますが、“それ”とは違います

85
データ構造
複数のデータを固めて飛ばす可能性を考え
チェーン構造を取れるように設計
ヘッダーデータ
付帯
データ
ヘッダーデータ
付帯
データ

86
データ構造
難読化
このデータを難読化して送受信します
※1000レコード連結した実際のデータをビットマップにしています

87
データ構造
シンプルに汎用性を高く設計したため、セーブ
データやHTTP通信のデータコンテナとしても採
用されました

88
テスト
• 地下鉄(接続が頻繁に切り替わる)
• 社内スマホ用Wi-Fi(昼休みに不安定)
• ヴィンテージWi-Fiルーター(パケット損失多発)
• 激しい帯域制限を掛けたVPN
• 居酒屋
• 野外
実際にプレイされる環境を想定した検証を実施

89
崖っぷちバスターズ®の目玉要素、陣取りの為に
特殊なテストも実施しました

90
野外テストの模様

91
こんな場所です

92
悪条件野外テスト(洋上)

93
ゲストプレイヤーが船酔いに・・・

94
悪条件野外テスト(高速助手席)

95
わかった事
• LTE〜3G〜圏外を繰り返す洋上でも再接続するとBrokerが保持している限りQoS1のメッセー
ジが飛んでくるのでゲームが成立する
• Willは、通信速度が極端に不安定になる悪天候の川沿いでpingに答えられないケースが多数
(これに関してはサーバー依存の可能性も有り)
• 利根川の高圧線の下では切断多発でゲームにならないのでやめてください(iOS)
• クライアント側で実装しなくてもメカニズムでカバーしてくれるMQTTの洋上での可用性は救世
主クラス！
• 特殊な環境でのプレイテストは机上や疑似環境では起こらないナチュラルなトラブルが発生
するので、是非やりましょう

96
今後について
BisqueのTCP周りはIPv6に対応済みなので今
後も踏まえてPaho Embeddedに移行予定です

97
考察

98
考察
• MQTT BrokerServerを選択し、リアリ
タイム通信ならびにターン制ゲーム実装
はゲーム仕様マッチのため可能。
• MQTT protocolやBrokerServerにも課
題はあり、要継続改善。

99
そして未来へ…

100
選定技術の今後について
• RabbitMQ with MQTT利用
– erlangによる実装知見
– 今後の発展型：
ターンベース→MO/MMO/MOBAの可能性
• Rubyを中心にしたWeb技術
– MQTT protocol ライブラリ
– Elixirの採用とBEAM親和性

101
リアルタイム技術トレンド
– OSSその他protocol例
• HTTP1.1
• CoAP
• (SPDY)
• HTTP2
• Reliable UDP
• MessagePack
• ProtocolBuffers
– 独自・汎用実装
• OSS
• ネットワークエンジン
• IoT PaaSの登場
• 自社・自前開発
– 市場の変化
• 例: IPv6への対応

102
IoTの今後
• IoTとしての決定版は？
– Protocol
– インフラ基盤の構築（内製、クラウド）
– デバイス疎／密連携
– 継承・委譲関係
• マクロ、ミクロのアクション・オペレーション
• ゲームでの利用
– 特定環境（アミューズメント施設、販売店舗）
– コンシューマ環境（ホーム、モバイル）

103
まとめ
• リアルタイム通信にMQTT選定
• 弊社事例を元に、MQTTの
リアルタイム通信ゲーム実装の紹介
• 今後のIoT技術への期待

104
ご清聴ありがとうございました。

CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…

More Related Content

What's hot

Viewers also liked

Similar to CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…

More from Drecom Co., Ltd.

Recently uploaded

CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…