簡単に捨てれる開発、検証環境(Happy Elements) twitter@aki017

開発環境の問題

OSのバージョンがそれぞれ違う
複数のバージョンを並行して使う必要がある（互換性がない）
手順書が古くなる
- 一つ一つのコマンドを入力していく形
  →これでは別のバージョンが入る可能性がある。
- 別のバージョンが必要なある場合がある
  →他の環境(Windows,Linux)ではできないことも…

問題を解決するには？

Docker（仮想環境を構築するもの）を使えばよい
Dockerなら

全員が同じ環境を使うことができる
1コマンドで環境が構築できる
一つの環境を更新すればその環境を全員が読み込むので手順書の更新がほぼ必要ない
docker-compose を使うと複数のコンテナをまとめて便利

検証環境の問題

複数のステージングが必要になる
- 環境による挙動を見るとき
- 新たな要素を追加した挙動を見るとき
- イベントの挙動を見るとき etc...

→Dockerを使うことで解決できる！！

まとめ

WindowsではDocker構成に苦労するけど、Docker使おう

ゲームエンジニアのためのデータベース設計(DeNA Games Osaka) @人西聖樹 twitter@sairoutine

ゲームのデータをどうやって保存する？

RDBMS
KVS
etc...

RDBMSとは

データを表で管理する
表同士を関係させることでデータを組み合わせる
ACID特性

ゲームデータの特徴

ユーザが主キー
期間限定データ・永続データなど種類がある
マスタ（読み込み用）データが多い
状態更新が多い
可用性・整合性が大切
- (課金ユーザ様すごく敏感)

データベース構築時に考えること

Maste/Slave構成
垂直分割
並行分割

Master/Slaveとは

MasterDBで制御操作を行い、一方的に操作されるSlaveDBを作る

Slaveを参照用に
Slaveの複数作成は簡単
しかし、更新はMasterに集中する
→Master がボトルネックになりがち

Masterの分割

垂直分割

テーブルの種類によって複数のDBに分ける

Join句使えない
均等な負荷を考えなければならない

水平分割

レコードごとに複数のDBに分ける

auto_incrementを使えない

複数のDBへのトランザクションをどうするか？

コミットタイミングはすべて同一が楽

アプリ開発時に気を付けること

適切なindex
- 完全二分木にする
- オプティマイザを走らせて計画する
クエリ発行量を減らす
- きれいに正規化しない
- あえてカラムを分割する
- 時限付きデータ（イベントデータ）は別テーブルに
- IN句でSELECT
- Bulk Insert（一括インサート）
- 一つの構文でInsertもしくはUpdateを切り替える構文もある
行ロック
- 同時操作を常に意識する
- レコードロックを行う
- ロック順番は統一して、デットロック発生に気を付ける
- きちんと存在するレコードに対してロックする（存在しない場合、全てをロックしてしまう可能性があるため。）
レプリケーション遅延対策
- 大量コミットによってMasterの変更が遅れること
- キャッシュにつめて、遷移先で使用する
- 更新系はMasterを更新する

オプティマイザとは

SQLがどのindexを使ってどの順序でアクセスするのかを計画する
EXPLAIN構文…計画の実行結果を表示できる

MySQLはコストベースでオプティマイザする

CPU使用量
I/O量など

→(開発環境と変わる場合があるので)本番環境でオプティマイザを走らせるほうが良い

KVSとの併用

KVSとは

ハッシュ・連想配列を使ったDBのこと。SQLを使わなくて良くなるのでRDBに代わるデータ管理をできるようになるのではないかと期待されている。

ゲームデータのキャッシュは難しい
更新が頻繁なので、キャッシュクリアが大変
ReadOnlyのデータをキャッシュしよう

Amazon API Gateway を活用したゲームサーバー構築(AWS) @清水崇之 twitter@shimy_net

ゲームバックエンドの一般的なコンセプト

APIとして考える
HTTP + JSON
フレンドリスト
バイナリのアセットデータ
拡張性・可用性
- 分散処理
- ELB

AWSを使えば高い可用性と拡張性

EC2で構築するのはしんどい

ならばAmazon API Gateway

キャッシュができる
クラウドウォッチでモニタリングなどを使える
簡単にすぐ作ることができる

DynamoDB

AWS上に存在するDBアプリ

Lambda

AWS上にデータの処理を記述する部分

API Gateway

AWSのインタフェース。HTTPレスポンスの設定や動かす処理の振り分けなどを行える

メソッドの設定…入力値などの検査
処理の設定…使用するファンクションの設定

※ MOCKがテスト用に便利

レスポンスの設定… HEADERの設定
APIの設定…コール数の設定など

ゆるドラ運営記(Clover lab)@松本亮太 twitter@matumo0627

ゆるドラって？…北欧神話をもとに作られるたゲーム
http://yurudora.com/

ゆるどらの構成

PHP
C++
JS

通常のハイブリットとの違い

Web画面を表示するものとNativeアプリを7:3で両立させたアプリ

なぜハイブリッド？

ノウハウ・資産をいかすため
小規模チーム
短期開発

疑似パーティション

一つのデータ群を複数のテーブルで分割管理すること
例）一つのテーブルにID下一桁が1のユーザデータがまとめられる

テーブルの負荷を軽減するため
普段から使用するデータ
データが増えることが予想できる
不要なデータと必要なデータが混ざっている
不要なデータも必要になる可能性がある

メリット

データ参照・更新の負荷分散

デメリット

集計が大変

バッチ実行してたら途中で止まる件

冪等性を考慮しよう
冪等性（冪等性）…ある操作を一度でも複数回でも行った場合でも同じ効果を得られること

ミス対策
予期せぬエラーに備える

詫び石の配布中などにエラーが起きた場合など

どうする？

トランザクションを小分けにする
どこまで行ったかを保存しておく

プレゼント配布に4時間かかる問題

全ユーザーにプレゼントを配布するバッチ処理に時間がかかる
→ログイン時に付与を行う

できるようになったこと

OS別に
アイテムはどんなものでも配布可能に
配布された時刻の指定可能に
指定ユーザーのみに
etc...

メンテンパル現象

メンテ（中に）テンパる現象
→メンテナンス手順書を作成する

確認程度の設定
追加・変更点記載
どのコマンドを使うのか

まとめ

泥臭く失敗だらけでも作ることができる
あきらめずに作れば何とかなる

アプリ開発・運用で後々楽をするために知っておくべきUnityのサービス(ユニティ・テクノロジーズ・ジャパン) @鎌田泰行

複雑化開発・多様化する運用

→必要なのは楽をすること

開発フェーズ

Asset Store

資料・素材をマーケットプレイスで買える機能

Unity Maltiplayer

ネットワークゲームを簡単に作れる
フレキシブルにゲームを作ることができる。（多様なゲームを作りやすい）

Unity Cloud Build

ゲームのビルドを自動化・高速化できる機能
リポジトリを登録して自動でビルド・デプロイされる

Unity Collaborate

プロジェクトをチーム制作しやすくする機能

運用フェーズ

Unity Analytics

ゲームユーザの解析・表示を行ってくれる機能

生データのエクスポート
ヒートマップ（ユーザのクリックポイントなどを解析できる）

Unity Ads

フリーゲームの広告などを行える機能

Unityから見たPhoton Cloud(クラウドクリエイティブスタジオ)@安藤健二,武藤辰矢

PUN(Photon Unity Networking)

マッチングサーバの用意などを吸収するフレームワーク

Photonのサーバ構成

NameServerへのアクセス
↓
MasterServerへのアクセス（ロビーやマッチング）
↓
ゲームアプリサーバへのアクセス

クライアントからのアクセス状態は?

接続が完了するとPhotonNetwork.connectedAndReadyプロパティがtrueになる

マッチメイキング

Photon.joinOrCreate()メソッドを呼び出すだけでよい

まとめ

PUNが煩雑な処理を自動化してくれる
プロトタイプの作成までは簡単
Photon Cloudの概念把握のドキュメントが公式では不十分

パネルセッション(Klab)@牧内大輔,山本雅也

EMLancherとは？

自作のテストアプリ配信ツール（OSS）

なんで作ったの？

社内でアプリ共有をするために既存のものでは不足部分があったから。
既存システムがなくなるのでは？となったから。

他社製品・既存品じゃいけなかったの？

なんで？とほぼ同様。
既存品が使いにくくなる予想から使われるようになった

なぜOSSに？

自己や会社の宣伝にもなる
事業にすることで保守する必要がでてしまうから

最近やっていることは？

Photonの解析
SQLiteの解析
etc...

Packdropとは？

通信遅延やパケットロスを疑似的にシミュレートをする装置

なんで作ったの？

シミュレートを誰でも簡単にできるようにしたかったため

他社製品・既存品じゃいけなかったの？

作れそうだった
作りたかった
拡張性がつけやすいため

なぜOSSに？

自分の宣伝になる
作り手が増えて、触ることができる人が増えてほしいから
仲間が増えて更に活発になれば良いと思うから

最近やっていることは？

CTOが過去に作ったOSSソフトを解析

リアルタイム通信ゲームの実装例(Aiming) @山藤智之

常時接続と非常時接続

非常時接続（単方向通信）

クライアントからの要求に対してレスポンスを返すのみ

常時接続（双方向通信）

サーバーからクライアントに対して要求することができる

通信形式

キーフレーム形式

フレームごとの入力を交換しあう形式。
格ゲーなどに使われる

通信量が少ない
処理が簡単なため、高速

メッセージ形式

手続きを呼び出すデータを通信し、必要なパラメータをやりとりする
MMOなどに有効

拡張しやすい
複雑なデータを扱いやすい

通信ライブラリの作成

RPC(Remote Procedure Call)

ネットワーク上の別マシンで動いている手続きをプログラム内から呼び出す機能

実現するためには？

呼び出す順番の保証
バイトオーダーによってデータがおかしくなるのを防ぐ

バイトオーダーとは？

OSによってがパケット送受信時にデータの並び順が変わってしまう問題

ビックエンディアン
リトルエンディアン

これをうまく考えることで送信料削減ができる

RPCのパケット構造

バージョン
関数のID
引数のリスト
制御用パケット番号

IDL(Interface Definition Language)

送信用・受信用などと複数送受信用関数を記述しなければならないのを簡易化するために使う言語

定義を書けば自動で選択した言語での関数が生成されるように
選択した言語のジェネレータを作成しやすいように
XMLを元に

負荷試験をしよう！(Klab) @内海恵介

目標性能試験

目標の数値が達成できるかを見る（）

Request Per Sec (rps)
Request time
アクセス想定を元に使う

どんな時？

広告ブーストをかけるとき
新機能追加時
コラボ

限界性能試験

現在耐えられる負荷を知る（アプリの性能を知る）

なんのため？

ボトルネックを知ることができる
Webサーバ１台でのrpsを知れる

どうやるの？

現在の構成で一旦落とす
↓
落ちる直前のテストまでレベルを下げる

拡張限界性能試験

インフラ構成の限界を知る（札束で何とか出来る部分を知る）

なんのため？

簡単に追加することが出来る部分を知るため
さらに分けることが出来る部分を知るため

なぜ負荷試験をするのか

負荷に怯えないため
修正案を提出しやすくするため
アプリケーションの性能を誇示するため

負荷試験に使うツール

プロファイラ

ログなどを使って性能解析を行うツール

メトリクス

サーバの負荷などをグラフ化するツール

攻撃側クライアント

サーバに対して攻撃をするためのクライアントツール

負荷試験用ロジックはいれない
プレイヤーと同じ画面遷移
マスターデータと出来る限り同じデータ
シナリオを複数用意して実行する

落とし穴

ELBPreWarming…ロードバランサのプレウォーミングをする
攻撃性能が足りていない場合