ネットゲーム開発者がサーバレスしてみたver1.10

@Lexues inc. All rights reserved.
JAWS-UG沖縄勉強会 Cloud on the beach 2016
勉強会の部（経験者向けトラック）
ネットゲーム開発者が
サーバレスしてみた
1
Ver.1.10
2016.04.29
株式会社レキサス鈴木康元

@Lexues inc. All rights reserved.2
とりあえず、お前だれよ？

鈴木康元 39歳
出身茨城 → 東京 → 北海道 → 沖縄
趣味 GWave、嫁、半導体情報収集
経歴ゲーム開発(15年)、教育系アプリ開発、
SIer(1年)、レキサス２年目
担当ハロペアプリ開発リーダー(SPL)
コトバンバン開発リーダー(SPL)
ADOC-H開発リーダー(SPL) など
得意技地味プログラム（高速化とか）
主に設計とコアな部分や難易度が高い
部分の実装担当
レキサスプロダクト企画開発部
R&D担当システムエンジニア

twitter @yasuharutwi
facebook yasuharu.suzuki.50
よかったらフォローお願いします。
お友達になりましょう。

これまでやってきたこと
”ゲーム開発”

GAMEPACKシリーズ
• 主に富士通FMVシリーズへのバンドルソフトとして、Windows95以来１０年以上続けて組み込み製
品として採用された。
(C) DATT JAPAN INC
※ダットジャパン株式会社より許諾を得て掲載しております。

やる雀、ゴルフやり隊シリーズ
• 2001年に世界初の携帯端末向け４人対戦麻雀アプリ「やる雀」を松下電器産業と共同開発。
• 翌年には毎週新しいゴルフコースが追加される「ゴルフやり隊」もS-inした。

ゲームパックMOBシリーズ
• PC向け「GAMEPACK」シリーズのモバイル端末向けバージョンを開発。
• Bluetooth対戦、HTTP通信によるネット対戦（1stバージョン）などに対応し、対戦機能を充実。
• 2年後にはUDP通信による高速ネット対戦（2ndバージョン）に対応した。
1stバージョンアプリ本数：7本
対戦アプリ：４本
2ndバージョンアプリ本数：15本
対戦アプリ：11本

私が開発してきた
ネット対戦ゲーム
について解説していきたいと思います

ネット対戦ゲーム
“とにかく低レイテンシが求められる”

1stバージョン

普通なら
「大量アクセスに耐えられるように
設計しましょう！」
という議論がありそうなものですが….

「どうせ誰も遊ばんだろう」

携帯電話の利用シーンを考えると、
電車の乗り降りなど10秒以下の短時間で
さくっと遊べるアプリの方が流行る。
対戦相手の手番を待ってプレイする人は
少ないだろうと予測していた。

開発期間：アプリ７本（うち対戦４本）
プログラマ：４名×２人月
ネット対戦のサーバ側の実装期間：せいぜい0.5人月
他にアプリそのものの実装時間や、Bluetooth対戦の
実装も必要だった。
（課金処理やランキング、ユーザー管理も標準装備）
「開発リソース？そんなものはない！」

mobile client
users
Internet
web server
web server
web server
database
database
1stバージョン構成図
サーバサイド：Javaのみ
通信：HTTPのみ
レスポンス：200ms〜300ms
１秒あたりの総処理量：せいぜい200ms〜300ms

Internet
ソフトウェア構成
シングルプレイ
ネット対戦対応
ユーザー情報
ランキング
マッチング
ネット対戦
サーバアプリ

当初は予想通り、誰も遊ばなかった。。。
※同時対戦数＝多くて１〜２

転機

まさかの「将棋」アプリヒット
初のVGA端末登場

「超美麗ディスプレイ」などとメーカーが持ち上げる
「VGAアプリコーナー」ができる
ただし、VRAM容量は変わらず、実質1/4
当然「将棋」も余裕でメモリ不足。。。
画像をテトリスして詰め込みました。
↓

同時対戦数は２０〜３０に
１秒あたりの総処理量：4000ms〜6000ms
ピーク時には毎日アラート
※ちなみに携帯アプリのNET対戦アクティブ率は1%以下。
つまり月額300円のサービスで2000名ほどの新規ユーザーを獲得した計算になります。

お願いだから遊ばないでください
（心の叫び）

「意外とネット対戦て遊ぶ人いるんだな」
加えてネット対戦利用者は
サービス継続率がめちゃくちゃ高い
↓
では力を入れて開発しましょう

というわけで
開発コード：NET-ZERO
1ms以下（0ms）のレイテンシを
目標にして開発しました

mobile client
users
Internet
web server
web server
web server
database
database
1stバージョン構成図＠おさらい
サーバサイド：Javaのみ
通信：HTTPのみ
レスポンス：200ms〜300ms
１秒あたりの総処理量：6秒（30名対戦時）

mobile client
users
Internet
vs server
web server
web server
database
database
2ndバージョン構成図
サーバサイド：Java + C言語(対戦サーバはフルC言語)
通信：HTTP+UDP
レスポンス：0ms（測定不能）
１秒あたりの総処理量：50ns(50名対戦時)
インメモリDB（10秒に1回DBへ書き込み）、オンCPUキャッシュリングバッファ

Internet
ソフトウェア構成＠おさらい
ユーザー情報
ランキング
マッチング
ネット対戦
サーバアプリ

Internet
ソフトウェア構成 2ndバージョン
ユーザー情報
サーバアプリ
その他
ランキング
マッチング
ネット対戦

6000ms
↓
50ns

6000ms（30名対戦時）
↓
50ns（50名対戦時）
ざっくり比較ですが
とりあえず1000万倍くらいは高速化されますた
＜1秒間あたりの総処理時間について＞読みたい人は読んでくさい。
対戦サーバ内で実際に処理を行った時の処理時間を総和して計算。1stバージョンではHTTPであったためアプリから常に通信が来ていた（厳密には２秒に１回程度）が、2ndバ
ージョンではUDPになったため、相手のアクションを待つタイプのアプリ（麻雀、将棋、大富豪など）では１０秒〜数１０秒に１度しか通信が来なくなった。さらに2ndバー
ジョンではゲームデータはすべてオンメモリ化、10秒に1度バックグラウンドでHDDに保存、通信処理は別スレッドでポーリング＆送信するなど様々な最適化を行い、1リクエ
ストに対する処理時間も数100ns(ナノ秒) 〜数100us（マイクロ秒）レベルにまで高速化された。これらの改善により、サーバサイドの総処理時間は劇的に改善された。

さて。IoT

アプリ側つくりました。
で、
メンテナンス情報の表示どうしようかなと

CloudFront
写真
CloudWatch
Cognito IAM Role
AWSサービスへの
認証情報取得
S3
期限付きURL
Dynamo
Mobile
Platform
トークン登録
メッセージ送信要求
SNS
Lambda
CDN
Xamarin
Mobile
Client
User
Route 53
Amazon API
Gateway
超シンプル

1stバージョン
リスクは負いたくないですね。
（セコいのは相変わらずです）

・アプリ側は通信できなくても動作するように実装。
・Dynamoは主キーとrangeキーでデータ引っ張ってきて返すだけ。
・ユーザー固有のデータでもないので問題出たら削除可能。
超スモールスタート。

・費用を見積もりやすくなった。Lambdaって課金されんの？ｗ
・Dynamoって大して安くないね。書き込みスループットが５倍て。
・Dynamoはユーザーデータであまり編集されないものを入れるべき。
・自動パーティション便利。
・ALTER_TABLEいらないのも便利。メンテいらず。
・メンテ告知を関係者と協議するコストを考えると安くなる？
・Lambdaのレスポンスは150ms〜300ms程度
・マシンに優しく、人に（設計に）厳しいDynamoさん。多少とっつきにくい
・RDSよりは低レイヤー、低レベルなソリューション
・スループットで簡単にパフォーマンスをUP/DOWN。耐障害性が高い。
・テーブルごとにスループット設定しなければならないのは、ちと面倒
成果

先のネット対戦との比較

1stバージョン：6000ms (30名)
先のネット対戦との比較
vs server
web server
Lambda
2ndバージョン：50ns (50名)
Lambda：150ms〜300ms
ソフトウェアは違いますし、本来単純比較は出来ませんので、
あくまでお遊び程度でお考えくださいm(_ _ )m
※128MB時。メモリ増やすと速くなることも。

1000人来たら？

1stバージョン：300秒 (1000名)
1000人来たら？
vs server
web server
Lambda × 1000
2ndバージョン：1us (1000名)
Lambda：150ms〜300ms (1000名)
※Lambdaは1000インスタンスまでオートスケール
※なので1000名来ても処理時間は変わらず

Lambda、恐るるに足らず！
（言いたかっただけ）
真面目な話、FPSのような即応性を求められるゲームは無かったので、サーバ内の処理時間が
150ms(Lambda)でも、1us(2ndバージョン)でも、ユーザー体験としてはさほどかわらないです。

1stバージョン
耐障害性
vs server
web server
Lambda × 1000
2ndバージョン
Lambda
1000名来られると、そもそも動かない。
アラート鳴り続ける。
サーバの不調によりときどき落ちる。
（お客様にお詫びのコイン配布）
※実際にLinuxの不具合やハードの不調と思われる現
象で落ちたことが何度かあった。
300秒＠1000名
1us＠1000名
150ms＠1000名
基本落ちない。
（ソフト的な不具合がないこと前提ですが。）
※落ちても1/1000の問題のため、サービス全体へ
の影響は少ない。ユーザーからすると通信エラーと
なるだけで、リトライすれば済む。

将来的にはもう少し使いたいので
いい経験になった。

CloudFront
写真
CloudWatch
Cognito IAM Role
AWSサービスへの
認証情報取得
S3
期限付きURL
Dynamo
Mobile
Platform
トークン登録
メッセージ送信要求
SNS
Lambda
CDN
ELB EC2
SES
SQS
Kinesis
Xamarin
RDS
Redshift
Mobile
Client
User
Route 53
ElastiCache
Amazon API
Gateway
将来的にはこれくらい。

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

ネットゲーム開発者がサーバレスしてみたver1.10

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (14)

Similar a ネットゲーム開発者がサーバレスしてみたver1.10

Similar a ネットゲーム開発者がサーバレスしてみたver1.10 (20)

ネットゲーム開発者がサーバレスしてみたver1.10