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

Copyright Drecom Co., Ltd. All Rights Reserved.1

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

株式会社ドリコム川上知成市川毅明


講演者紹介テクノロジー本部研究開発部長• 川上知成–技術調査– PM ・TD レビュー

同部• 市川毅明–アーキテクト–ゲーム・汎用基盤開発


本セッションの概要• 弊社崖っぷちバスターズ®でリアルタイム通信4人協力バトルの実現に、MQTTprotocolを採用

• インターネット時代における通信技術のトレンドとともに採用に至った選定過程、クライアント／サーバー実装やインフラ構成などを紹介

受講者が得られるであろう知見：• 技術採用プロセス事例• リアルタイム通信

ゲームクライアント・サーバー開発技術・手法• OSS技術の活用方法


目次1. ネットワークゲームの近年の流れについて2. インターネットモバイルリアルタイム

ゲームを実現する課題3. 弊社事例：崖っぷちバスターズ®1. 通信技術選定2. MQTTとは3. 実装について

1. 全体概略2. サーバー実装概略3. アプリケーション実装

4. 考察5. そして未来へ…


IoTとは？


IoT

＝Internet of ThingsIoT背景

デバイスの進化ネットワーク技術の進化

ゲームスマートフォンクラウド上での運営


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


ネットワークゲーム• 2000年前後– アーケード：店舗間専用線– パソコン通信、インターネット– MO/MMORPGの誕生

• 2010年頃以降– 高速インターネット環境 Gbps– MO/MMORPGの普及と多様化– eSports 誕生– モバイルゲームの一般化


モバイルの潮流• 通信環境：– 従量課金– パケット定額– ブロードバンド普及wifi通信の利用促進

– 3G/4Gの誕生→常時接続通信が可能に

• 携帯モバイルゲーム– カジュアル・ミニゲーム– webソーシャルゲーム– Nativeソーシャルゲーム→携帯モバイルゲームの一般化

常時通信×携帯モバイルゲームが進化→リアルタイム体感へ


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


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


通信環境• 回線速度

業務用～家庭用～移動通信（3G/4GLTE）例:10Gbps超～数G - 100MB～70- 20 MB–理論値と実測値–不安定• 帯域保証• 物理的な干渉・回折• 移動体通信網とWifiの混在

→転送頻度/データ量の考慮


実装手法• protocol：リアルタイム通信の特殊性– UDP / TCPなど通信protocol の選択/設計– Data Format / Payload 設計

• 実装効率：ゲームという専門性ó汎用性–設計はゲームロジックによるアプリ毎様々


インフラ環境• インフラ環境の変化：–専用線＋オンプレミス–インターネット＋オンプレミス–インターネット＋IaaS／Paasクラウド

• 技術課題– Load Balancing– NAT超え–爆発的なユーザ増加に合わせた受け入れ→可用性・冗長性


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


崖っぷちバスターズ® ご紹介崖っぷちバスターズ®は、壁を壊して、敵を崖から突き落す、新感覚のぶっ放し協力バトルゲームです。GPS連動したエリアバトルでスコアランキングを競い、エリアNo.1になることで、そのエリアを制圧しながら拡大していくことができます。また、大4人で遊べるマルチプレイ機能を搭載!仲間と連

携して必殺技を繰り出せば、敵に大ダメージを与えることができます。手に汗握るバトルが繰り広げられる、「みんなで遊べるゲーム」の決定版です。


ゲームの特徴 <通信>• シングルプレイ–Web API通信を中心に構成–バトルはスタンドアローン

• マルチプレイ–バトルはリアルタイム通信を行い、最大4名の複数プレイヤーが１つのバトルセッションで協力プレイ


開発基盤BisqueBisqueにて開発

Copyright Drecom Co., Ltd. All Rights Reserved.� 28

Bisque!

Bisque÷ûĔŃĞĲĿĤĨİđŇĸ<J!

ÇÔÏ×ÕÑÏ�ÊÓÖÒÐÓÐÔÙ�

ÑÌÍ�ÊÓÖÒÐÓÐÔÙ�

JNI�ObjecGve'C++!


通信技術選定


通信技術選定の背景弊社観点• 強み–WebAPIを中心のサーバー/クライアント資産–クラウド利用実績

• 弱み–リアルタイムサーバー・クライアント構築–リアルタイム通信ゲーム制作


リアルタイム通信実現に向けて◯方針

– 実現スピード重視既存技術を活用し、工期短縮

– ゲーム仕様実現に焦点

◯ゲーム仕様– 1Room 4名のターン制

◯技術要件– リアルタイム性→同期通信– 同期性の担保レイテンシー：最大1秒目標

クライアントにHostを立て、サーバはメッセージの同期のみクライアント側ではメッセージを元に再現

プロトを経て


技術検討


技術検討の一部• http polling• websocket• Socket.io• MQTT• Platform機能• 商用エンジン

• 選定観点– Protocol– Server実装– Client実装–ライセンス総合的に評価

MQTT案ベースに詳細検討


Client

検証フェーズ

検証仮実装本実装結合 β

■MQTT案

Game

インフラ

ミドルウェア選定

単体負荷試験

クラウド選定

構成設計

ブラッシュアップ

実データ負荷テスト

組み込みテスト

α→機能洗い出し

仕様検証

基本ライブラリ選定

ライブラリ実装チューニング

単体検証

仕様ブラッシュアップ

組み込み実装


MQTTとは?


MQTTとはMQTT(MQ Telemetry Transport) • MQTTとは、publish/subscribeモデルに基づくメッセージプロトコル

• 低速・不安定なネットワークで動作するための機能や非力なデバイスで動くための軽量化、同期通信な点などが特徴

• 事例：Facebook Messenger など各種Chat


歴史1999年よりIBMが主導で商用製品提供も2011年 Eclipse Foundationへコード寄贈2013年 OASIS 国際標準化団体で標準化へ

・・・発展途中・・・

Ø近年ではサービス提供事業者もØProtocol仕様はロイヤリティフリーØ サーバー/クライアント実装複数


特徴• 軽量：固定ヘッダーは2byte,

Payload: Max256MB• Topic：送受信先. 階層構造• QoS:

• Will• Retain• CleanSession

※TCP Connection NAT配下でも問題なく動作。

0:At most once1:At least once2: Exactly once


概要：Pub/Subモデル

MQTT BrokerpublisherSubscriber

Topic例：/cedec/2015/room315/iot/cedec/2015/room315/gameengine/cedec/2015/room315/#/cedec/2015/+/iot

ABCD

ABA B CA D


実装について


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


全体概略


MQTT Cluster

BackEnd全体構成 Draft

internet

Client pub / sub / http(rest)

LB (MQTT) LB(web)LB (HTTP)

Web/APWeb/AP Web/

APWeb/AP

KVS DBDBKVS

Reverse-‐Proxy

MQTT Broker

REST Worker

MQTT BrokerMQTT BrokerMQTT Broker

direct routing

※検討当時資料


BackEnd構成概略

internet

Client pub / sub / http(rest)

LB(web)

Web/APWeb/AP Web/

APWeb/AP

KVS DB

MQTT BrokerMQTT BrokerMQTT BrokerMQTT Broker

direct routing

※検討当時資料


利用方法概略• MQTT Broker ServerをBattleInstanceServerの位置づけで利用。

• Broker Serverの利用：– Topic ⇒ Room– Room管理はAPIServer制御– Broker ServerよりMessageを配信– QoS ⇒ 再現性/信頼性コントロール


サーバー実装概略


Room

MQTTBroker

WebAP

MQTTBroker

MQTTBroker …

同期接続(mqtt)非同期接続(http)

Room

Matching

GameClient

マルチプレイバトルの接続イメージ


MQTT Broker

GameHostClient

１

同期接続(mqtt)非同期接続(http)

Room

GuestClient

２

GuestClient

３

GuestClient

４

バトルターンのイメージ

SessionMasterとして同期委譲管理

Web/AP


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


WebAPIサーバー• Clientが接続するBroker Serverを選定しBalancing

• ノード死活監視、cacheリスト化• リストから“Least connections”で接続


BrokerServer選定• 検証観点–１台あたりの性能・コストパフォーマンス最大化を重視

–高負荷時の安定性• 最終候補–Mosquitto→シングルスレッド、クラスタ無し(要自作)– RabbitMQ with MQTT Plugin→マルチスレッド、クラスタ有り(要検証)


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

言語: erlang


BrokerServer構成について• 構成案– Broker Standalone Parallel

– Broker Clustering※一部課題あり：Performance劣化等

• 仕様の割り切り– Cloudの性質上可用性には限界あり– FailOverの検知復旧時間と体感待ち時間とのトレードオフ

→Standaloneで利用


BrokerServer ScaleOut• Standaloneのためインスタンス増設でScaleOut

• AWSを利用しAutoScalingを実現– CPU使用率監視

• 研究としてスポットインスタンス利用することでコスト圧縮も可能– 手法詳細はslideshareにて。

http://www.slideshare.net/GedowFather/gedow-‐style-‐aws-‐spot-‐instance


アプリケーション編


MQTTクライアント選定



• フルスクラッチから書く

• Paho Embedded

• Mosquitto

調査の結果この3点が候補に挙がりました


フルスクラッチから書く

• 全部自分で作る

• 全部自分で作るので比類無き自由度

• 全部自分で作るので工数爆発

• (実は30%位作った)


paho

• Eclipse Foundation謹製

• ANSI Cで書かれ、データ処理だけを提供するので移植性と実装の自由度が高い

• 通信部分は自力で実装する必要あり


Mosquitto

• 古くからあるMQTTブローカー

• コア部分がlibmosquittoとして分離されており、単体のMQTTクライアント/サーバーライブラリとして利用可能

• リッチな高レベルAPIが揃っている



検証の結果、Mosquittoを選定

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


Mosquittoの難点

• BSDソケットを使っているが、iOSで動作が怪しいヶ所が多数

• pthreadを使っているがiOS/Androidで未実装の関数(排他周り)を多数使用

• 他にも色々と･･･(主にシステムコール周り)


内製ライブラリ”Bisque”

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


内製ライブラリでの解決

• 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


Bisqueの紹介



• ソースコードレベルでクロスプラットフォームを実現する為のライブラリ群

• スマホからサーバーまで、対応可能なプラットフォームのAPIを抽象化

• ゲームエンジンや他処理系への組み込みを意識し、可能な限りプリミティブに設計



同一ソース群から3エディションが存在します

Bisque Workstation Edition(PC版)

Bisque

Bisque Datacenter Edition(サーバー版)


サウンド用I/F

OpenAL OpenSL /dev/audioXaudio2

下回りの実装は適なAPIを選択

アプリ開発者にはプラットフォームを意識させな

い


One and Half 設計


柔軟な上部(ゲームエンジンやアプリ)

強靭なでシンプル設計の根元

(抽象化レイヤー)


サーバー(Ruby)

クライアント

Bisque アーカイブモジュール

Bisque アーカイブモジュール

全く同じコードから生成されるので完全互換のデータ持ち回りを実現


・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


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


Topicの構造

ROOM/

Common System Private Host

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


Topicの構造

System Private Host

Topicを分ける事でメッセージフィルターを実現メッセージの振り分けをシステムに任せる

ROOM/

Common


Topicの構造

Commonホストからのゲストへのメッセージ配信用ゲストプレイヤーがSubscribe

Systemシステムメッセージ用全員がSubscribe

Privateゲストへの個別メッセージ用各員がPrivate/<プレイヤーID>にSubscribe

Hostホストプレイヤーへのメッセージ用ホストがSubscribe


Topicの構造

Commonホスト

ゲスト

ゲスト

例：ホストプレイヤーからのメッセージ配信

ホストはpubだけ(subしない)

ゲストはCommonにSub


Topicの構造

System

ホスト

ゲスト

ゲスト

例：全体への配信

全員がSubscribe


Topicの構造

Host ホスト

ゲスト

ゲスト

例：相互死活判定(ライブパケット)

ゲストはHostにPub


Topicの構造

Private/ゲストIDホストゲスト

例：相互死活判定(ライブパケット)

ホストは送信元のゲストに返信Pub


Pub/sub

・Topicを分ける、Subscribeする物を選ぶ事で必要なメッセージだけを受信する事が出来る

・SubscribeしたTopicのメッセージは全て飛んでくるので自分でPublishした物も受信してしまう

・Pub専用、Sub専用、Pub/Sub両用を使い分ける事により細かいメッセージ制御が可能


QoS

・崖っぷちバスターズ®ではQoS0とQoS1を使用

・欠損しても影響の無いデータはQoS0

・欠損が許されないデータはQoS1


QoS

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


QoS

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


タップ〜ヒットまでのpub

タップ

移動・スワイプ

ヒット

QoS1のメッセージさえ届けばゲームが成立するように設計

QoS1

QoS0


その他

・pubの量を減らす為、メッセージにプライオリティーを付け即時送信する必要の無いデータはバッファリングしてから塊で送信

・QoS1でクリティカルな物には返信要求ビットを立て、再送させるメカニズムを作成

・これにより1ゲーム2000アクションで100pub、総通信量を100KB程度に抑える事に成功


セキュリティー



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


Mosquittoで構築したサーバーにSSL有無で1000回pub(とあるAndroid スマートフォン)


pubだけでSSL無しの約10倍

該当端末ではゲームに支障を来す可能性も

星の数程あるAndroid端末では同じ現象が起きる端末の存在を否定できない

SSL無し

SSL

一部 Android端末でSSLが遅い！


“Bisque”難読化ライブラリ採用

• 通信の難読化には弊社タイトルで実績のある内製難読化ライブラリを採用

• 改竄防止が主な目的なので本格的な暗号は必要ない

• ゲームで3タイトル、その他アプリでも利用されています(本当にクリティカルなデータはSSLを使用)

• アルゴリズムは複数ありますが、今回は128bitブロックの物を採用(送信データはほぼ1ブロックに収まる)


難読化ライブラリのチューニング

1024バイトの文字列を1000回難読->復号を繰り返した結果

チューニング前

チューニング後

高速性には定評があるが、リアルタイム通信での使用に耐える為、対応アーキテクチャー全てでベクタライズを中心とした徹底的ハンドオプティマイズを実施


その結果・・・• AES128(弊社はUnityで利用)より250倍速く

• 前バージョン比8000%高速化

• (コード行数50倍)

AES128

チューニング前

チューニング後


データ構造

• 高速でコンパクト

• Protocol BuffersよりもプリミティブなAPI

• サーバー側(スクリプト言語)との相互運用に優れる

通信内容はmsgpackを採用


データ構造

MQTTではプリミティブなデータが飛び交うので通信内容のコンテナ化を実施しました

ヘッダー実際のデータ(msgpack) 付帯データ

※何かに似てますが、“それ”とは違います


データ構造

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

ヘッダーデータ付帯データ

ヘッダーデータ付帯データ


データ構造

難読化

このデータを難読化して送受信します

※1000レコード連結した実際のデータをビットマップにしています


データ構造

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


テスト

• 地下鉄(接続が頻繁に切り替わる)

• 社内スマホ用Wi-Fi(昼休みに不安定)

• ヴィンテージWi-Fiルーター(パケット損失多発)

• 激しい帯域制限を掛けたVPN

• 居酒屋

• 野外

実際にプレイされる環境を想定した検証を実施


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


野外テストの模様


こんな場所です


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


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


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


わかった事

• LTE〜3G〜圏外を繰り返す洋上でも再接続するとBrokerが保持している限りQoS1のメッセージが飛んでくるのでゲームが成立する

• Willは、通信速度が極端に不安定になる悪天候の川沿いでpingに答えられないケースが多数(これに関してはサーバー依存の可能性も有り)

• 利根川の高圧線の下では切断多発でゲームにならないのでやめてください(iOS)

• クライアント側で実装しなくてもメカニズムでカバーしてくれるMQTTの洋上での可用性は救世主クラス！

• 特殊な環境でのプレイテストは机上や疑似環境では起こらないナチュラルなトラブルが発生

するので、是非やりましょう


今後について

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


考察


考察• MQTT BrokerServerを選択し、リアリタイム通信ならびにターン制ゲーム実装はゲーム仕様マッチのため可能。

• MQTT protocolやBrokerServerにも課題はあり、要継続改善。


そして未来へ…


選定技術の今後について• RabbitMQ with MQTT利用– erlangによる実装知見–今後の発展型：ターンベース→MO/MMO/MOBAの可能性

• Rubyを中心にしたWeb技術–MQTT protocol ライブラリ– Elixirの採用とBEAM親和性


リアルタイム技術トレンド– OSSその他protocol例

• HTTP1.1• CoAP• (SPDY)• HTTP2• Reliable UDP• MessagePack• ProtocolBuffers

– 独自・汎用実装• OSS• ネットワークエンジン• IoT PaaSの登場• 自社・自前開発

– 市場の変化• 例: IPv6への対応


IoTの今後• IoTとしての決定版は？– Protocol– インフラ基盤の構築（内製、クラウド）– デバイス疎／密連携– 継承・委譲関係

• マクロ、ミクロのアクション・オペレーション

• ゲームでの利用– 特定環境（アミューズメント施設、販売店舗）– コンシューマ環境（ホーム、モバイル）


まとめ• リアルタイム通信にMQTT選定• 弊社事例を元に、MQTTのリアルタイム通信ゲーム実装の紹介

• 今後のIoT技術への期待


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

Technology

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