Google Cloud PlatformでWebSocketを使いまくったソーシャルゲーム基板を作ったのでシェア

1. でソーシャルゲームを
1本出してみた！
株式会社 Zeadle 長谷川祐介
2014-07-28

2. はじめに！
• 単なるエンジニアなので気楽に聞いて下さい。
• また今回の発表の内容は
GCP上でGCPの機能を活用しながらいわゆるソーシャルゲーム
の設計をしてみました！
そしてできましたよ！という内容になってます。
• これから導入を検討されている企業のみなさまの良い参考になれ
ばと考えています。

3. index
• 会社説明
• 自己紹介
• ゲーム紹介
• GCP上で今回作ったアーキテクチャの説明

4. 会社説明
社名株式会社Zeadle
設立2013年
代表川方慎介
社名の由来Zeal(熱意)とDoodle(いたずら書きをする)

5. 自己紹介
氏名長谷川祐介
経歴
20代に転々としながら
2010年にgloops(旧gms)へ
2014年4月1日からZeadleへ
職種いわゆるインフラエンジニア
GCP歴約4ヶ月
その他AWSもAzureもVM側だけど数ヶ月以上触ってます。
基本的にはオンプレが多いです。

6. ゲーム紹介

7. ゲームタイトル

8. 斬神
• 戦国ファンタジー風味の
リアルタイムバトル
• Mobage NBPFで提供
• 完全にWeb！
• WebSocketバリバリ仕様
• 同時に20人でボスを叩け
ます！
• http://ap.zs.zeadle.net/

9. アーキテクチャ

10. Google各種サービス
Compute Engine
Application / WebSocket
redis, MySQL etc…
LoadBalancer, Network Firewall
metadata, snapshot
CloudDNS DNSはすべて依存
CloudStorage 静的ファイル配信、バックアップなど
BigQuery KPI関連とログ系すべて
Google Analytics もはや説明の必要なし

11. お世話になってるみなさん！

12. インスタンス種別
• Application x 21
• WebSocket x 21
• Entry（事前登録用）x 2
• JobQueue Worker x 7
• API（Platformと連携）x 3
• MariaDB x 11
• Redis x 6
• Redis（JobQueue用）x 2
• Operation Central x 1
• KPI収集 x 1
production/staging合わせて

13. Application/WebSocket
WebSocketインスタンスはlocalにredisが起動

14. WebSocketへの振り分け手法
• LoadBalancerを使ってません！
いわゆるHTTP Dispatcherを独自
で構成してます。
• 監視結果を元に
正常なWebSocketインスタンス情
報を更新
• 各レイドボス出現タイミングで選択
• 伐討祭（リアルタイムバトル）では
team_id単位で利用するインスタン
スを選択
• こういったインスタンスの監視を元
にしたクラスタ稼働状況は
Applicationと連携して自動で更新
稼働してます。

15. Redis
• haproxyで処理系から接続
• 各目的別でデータをsharding
• websocketの後ろでpub/sub
• Resque?かわからないけどPythonのJobQueueとしても

16. MariaDB
• haproxyで処理系から接続
• lookup, master, contents, historyと複数のスキーマ分割
• userNはlookupでマッピングして分割
• BackupにはPercona XtraBackupとmysqldumpを状況に応じ
て使い分けそれぞれCloud Storageへバックアップ
• configは完全に自動化

17. Deploy
• Active/Standbyの切り替え
• 今のところJenkinsとか使っ
ていません。
• Deployはgit pull
• 切り替えはconsulのkv使っ
ていて１秒程度
• 同じくRollbackも！
• メンテナンス切り替え
メンテナ時特定IPだけ許可
特定IPはStandbyに通す
• 各種操作はオーケストレーショ
ンを通してHipChatへ通知

18. Monitor
• 全インスタンス共通でオレオレ仕様になってますｗ
• configは起動時にmetadataから取得してくるタグをベースに自動生成
• consulから起動するmonitor用のscriptで直接metrixをlibratoへ
• consulのHTTP API health/stateを利用してデータをサマってHipChatへ
• またBigQueryのApplicationLogをHipchatへ（logglyでもできるけど後付なんで

19. Operation Central
• さきほど紹介したDeployTool
• PerlのCinnamon
• nginx, haproxy, fluentd, consul, etc…のconfig自動生成
• 各種daemonのコントロールなど
• セットアップなどにも活用
• 各種操作はHipChatへ通知

20. KPI
• よく言われるKPI必須項目系以外にも各種進行度などグラフ化
• 短い間隔（現状１分間隔）でMariaDB/Redis/BigQueryを活用
してデータ集計
まだBigQueryの利用率が低いがリリース期間が短いためこれか
ら活発になっていくと思われる！
• 結果はすべてLibratoへ送りグラフ描画
• またGoogle Analyticsを活用中

21. bootstrap
• operation用のインスタンスをsnapshot取得
• 上記snapshotからstartup scriptを利用して作りたいサーバー
種別用のtagを付与しながらaddinstanceするだけ
• startup scriptが起動時に各種configを自動生成しながら所定の
サーバーに仕上げてくれる形になってます。
• cloud storageにUploadして使っています。
• 上記をまとめたコマンドセットを発行できる仕組みを作って対応
してます。

22. 運用に利用してる画面

23. 斬神インフラの今後の課題
• AutoScaleはまだ未実施
• WebSocket系の構成を見直し、保険をもう少し作りたい。
• consulが恐ろしく便利！
ただしちょっと関係ないけどserverがすんごいバッファ食うｗ
（clientは問題無し

24. これからやりたいこと
• stream使いたい！
ゲームで導入すると面白いことがいろいろできそうな気がする！
• docker化
大好きなんですがリリース準備中はちょっとタイミング悪かったの
で・・・
• 現在外部依存している部分についてはコストを見ながら徐々に
BigQueryなどを活用したものに移行していこうと思ってます。

25. ご清聴ありがとうございました！
!
今後ともよろしくお願い致します！