2019-04-18 thu. 第 7 回 Google Cloud INSIDE Games & Apps 株式会社セガゲームス安倉 剛司氏 と森田 公一氏の登壇スライドです。

1. 『イドラ ファンタシースターサーガ』
を支えるGCP
安倉剛司
森田公一
株式会社 セガゲームス 第３事業部

2. 自己紹介
安倉 剛司
株式会社セガゲームス
第３事業部 プログラムセクション リードプログラマー
2000年セガ・エンタープライゼス（現セガゲームス）に入社。
コンシューマタイトルでUIや3Dグラフィックを担当後、
サーバエンジニアに転じて運営タイトルの開発と運営を担当。
現在は『イドラ ファンタシースターサーガ』のテクニカルディレクターとして開発
と運営に取り組んでいる。

3. 自己紹介
森田 公一
株式会社セガゲームス
第３事業部 テクニカルサポートセクション リードプログラマー
2012年セガ（現セガゲームス）に入社。
主にサーバサイドエンジニアとして運営タイトルの開発を担当。
現在は各種クラウドサービスの評価／検証、既存タイトルのコンテナ化、
Kubernetes を利用した共通基盤の開発に取り組んでいる。

4. 本日のアジェンダ
• 『イドラ ファンタシースターサーガ』の事例紹介
◦ アプリ紹介
◦ サーバ構成
◦ GAEとDatastoreの活用事例
◦ Firebase Realtime Databaseのチャット事例
◦ Stackdriver活用事例
• Kubernetes Engine 活用事例紹介
◦ 共通基盤サービスの事例
◦ 『イドラ』開発環境の運用効率化の事例
◦ Kubernetes Engine 活用事例まとめ

5. 『イドラ ファンタシースターサーガ』
の事例紹介

6. 『イドラ ファンタシースターサーガ』
の事例紹介
アプリ紹介

7. アプリ紹介
7

8. 『イドラ ファンタシースターサーガ』
の事例紹介
サーバ構成

9. Common Point Servers
Raid API Servers
General API Servers
サーバ構成
Game
Client
Dev/Ops
Team
Cloud Load
Balancing
GM Tool Server
Compute Engine
Operation Server
Compute Engine
DB Server Common
MySQL
Compute Engine
Master/Slave Instances
HTTPS
HTTPS
SSH
DB Server Shard 0/1
MySQL
Compute Engine
Master/Slave Instances
Memcached
Server
Compute Engine
4 Instances
WebGW Server
Compute Engine
API Server
Compute Engine
Multiple Instances
Batch Server
Compute Engine
Service Server
Compute Engine
Multiple Instances
DB Server Common
MySQL
Compute Engine
Master/Slave Instances
DB Server Shard 0/1
MySQL
Compute Engine
Master/Slave Instances
API Server
Compute Engine
Multiple Instances
Chat Server
Firebase
Realtime Database
Redis Server
Compute Engine
3 Instances
Cloud
Datastore
App
Engine
SEGA ID
Service
PSO2
Server
Official
Web
Server
Common
Infrastructure Services
Kubernetes Engine
Multiple InstancesCloud Storage

10. 『イドラ ファンタシースターサーガ』
の事例紹介
GAE と Datastore の活用事例

11. GAEとDatastoreの活用事例
• GAE導入理由
• 『イドラ』と『PSO2』で共有する『イドラポイント』サーバが必要
• 『イドラポイント』サーバを独立したサーバにしたい
• 『イドラ』がメンテナンス中でも『PSO2』でポイントを使いたい
• 『PSO2』がメンテナンス中でも『イドラ』でポイントを貯めたい
• メンテナンスフリーで管理コストを減らしたい
• 構成
• GolangでREST APIを構築
• Cloud Datastoreでポイントデータ管理
• GAEの運用実績
• 2018年11月27日サービス開始から約5ヶ月経過
• 障害は一度もなく稼働を続けている

12. GAEとDatastoreの活用事例
•共通ポイント獲得状況の解析事例
ゲーム側GCPプロジェクト 解析側GCPプロジェクト
DB Server
Compute Engine
KPI Data
BigQuery
Cloud StorageCloud Storage
Cloud
Datastore

13. 『イドラ ファンタシースターサーガ』
の事例紹介
Firebase Realtime Database のチャット事例

14. Firebase Realtime Databaseのチャット事例
•Realtime Database導入理由
• 開発当初は予定していなかった
• サーバの工数が確保できなかった
• Stackdriverと連携ができる

15. Firebase
GCP
Firebase Realtime Databaseのチャット事例
Game
Client
Dev/Ops
Team
GM Tool Server
Compute Engine
API Server
Compute Engine
Multiple Instances
Chat Server
Firebase
Realtime Database
Stackdriver
Logging
KPI Data
BigQuery
Firebase
Functions

16. Firebase Realtime Databaseのチャット事例
•Realtime Databaseのチャット用データ構成
"chats" : {
// ルーム情報
"rooms" : {
},
// ユーザ情報
"users" : {
},
// メッセージ情報
"messages" : {
},
}

17. Firebase Realtime Databaseのチャット事例
•ルーム情報のデータ構成
"chats" : {
// ルーム情報
"rooms" : {
"RoomID1",
"RoomID2",
"RoomID3",
"RoomID4",
・・・
},

18. Firebase Realtime Databaseのチャット事例
•ユーザ情報のデータ構成
"chats" : {
// ユーザ情報
"users" : {
"UUID1" : {
userName: "AAAAAAAA"
userNo:1
rooms : {
"RoomID1",
"RoomID2",
},
},
・・・
},

19. Firebase Realtime Databaseのチャット事例
•メッセージ情報のデータ構成
"chats" : {
// メッセージ情報
"messages" : {
"RoomID" : {
1: {
message:”チャットメッセージ”
その他チャット情報
},
・・・
},
・・・
},

20. Firebase Realtime Databaseのチャット事例
•ルールについて
• クライアントからのアクセス制限のためのルール
• ゲームサーバーからは管理者権限でアクセスできる
{
"rules": {
".read": false,
".write": false,
// ルーム情報
"rooms": {}
// ユーザ情報
"users": {}
// メッセージ情報
"messages": {}

21. Firebase Realtime Databaseのチャット事例
•ルーム情報のルール例
// ルーム情報
"rooms": {
// 読み込みは誰でもOK
".read": "auth != null",
// 追加できるのは管理者権限のみ（サーバから追加する）
".write": "false",

22. Firebase Realtime Databaseのチャット事例
•ユーザ情報のルール例
// ユーザ情報
"users": {
".read": false,
".write": false,
// ユーザ毎のルール
"$uid": {
// ユーザ情報の読み込みは自分自身のみ
".read": "auth.uid == $uid",
".write": "false",
// userNoとuserNameを必須とする
".validate": "newData.hasChildren(['userNo', 'userName'])",

23. Firebase Realtime Databaseのチャット事例
•メッセージ情報のルール例
// メッセージ情報
"messages": {
".read": false,
".write": false,
// ルーム毎のアクセシビリティ
"$roomid": {
// chats/rooms/$roomidにルーム情報がありかつ、
// chats/users/auth.uid/rooms/$roomidにルーム情報がある
". read": "(root.child('chats').child('rooms').child($roomid).exists() &&
root.child('chats').child('users').child(auth.uid).child('rooms').child($roomid)
.exists())",
". write":

24. 『イドラ ファンタシースターサーガ』
の事例紹介
Stackdriver活用事例

25. Stackdriver活用事例
•Stackdriver Monitoring
• Realtime Databaseも含めて監視
•Stackdriver Logging
• サーバのすべてのログをfluentdで転送してLoggingで閲覧
• ApacheのアクセスログやOSのMessageログなど

26. Kubernetes Engine 活用事例紹介

27. Kubernetes Engine 活用事例紹介
共通基盤サービスの事例

28. 共通基盤サービスとは
主にモバイル向けのタイトルにおいて
よく使うバックエンドの機能を共通化し、
開発／チェックのコスト削減および
サービスの信頼性向上を目的として開発したシステム

29. バックエンド共通化の要件
1. 特定の言語に依存しない

30. バックエンド共通化の要件
1. 特定の言語に依存しない
⇒ ライブラリではなく、独立したサービスとして実装（gRPC+Protocol Buffers）

31. 共通基盤サービスの要件
1. 特定の言語に依存しない
2. 特定のクラウドベンダーに依存しない
3. タイトルごとに独立している
4. メンテナンスコストが低い
5. 可用性／スケーラビリティが高い
⇒ ライブラリではなく、独立したサービスとして実装（gRPC+Protocol Buffers）

32. 共通基盤サービスの要件
1. 特定の言語に依存しない
2. 特定のクラウドベンダーに依存しない
3. タイトルごとに独立している
4. メンテナンスコストが低い
5. 可用性／スケーラビリティが高い
⇒ ライブラリではなく、独立したサービスとして実装（gRPC+Protocol Buffers）
⇒ コンテナ＋Kubernetes でポータビリティを確保
⇒ 各タイトルのクラウド環境内に個別にシステムを構築
⇒ Infrastructure as Code & Immutable Infrastructure
⇒ Kubernetes の自己修復／オートスケール機能を活用
⇒ マイクロサービスアーキテクチャを採用
Kubernetes で
すべて解決！

33. 共通基盤サービス構成
SEGA
HTTPS
GitLab Cluster
Push
image
CIS Dev Cluster
Common Infrastructure Service(Develop)
Build/Push
image
CIS Production Cluster
Default Pool
SEGA ID
ServiceFixed Nodes
Kubernetes Engine
2 Nodes
Autoscaling Pool
Autoscale Nodes
Kubernetes Engine
Autoscaling
CIS Pods
kube-system pods
Authentication
Firebase
Cloud MessagingMessaging
Virtual Currency
Git push/
Run manual jobs
helm tiller
Authentication
CIS Services(dev)
Kubernetes Engine
Pull
image
helm
install/
upgrade
CIS Images
Container Registry
helm
install/upgrade
Game Infrastructure
KPI Logs/
DB Snapshots
Game Servers
Compute Engine
Management
Tool
Compute Engine
gRPC
Internal Load
Balancing
Pull
image
IDOLA Production
DB Server
MySQL
Compute Engine
Kubernetes Engine
Push
notification
Apple
App Store
Validate
Receipts
Logging Stackdriver
Logging

34. Game Infrastructure
Instance Group
#F9FBE7
共通ログ基盤サービス構成
CIS Production Cluster
Log Aggregator Pool
Aggregator Nodes
Kubernetes Engine
Autoscaling
KPI Logs/
DB SnapshotsGame Servers
Compute Engine
Internal Load
Balancing
IDOLA Production
Syslog
Apache
Logs
App Logs
Stackdriver
Logging
tail
Instance Group
#F9FBE7
KPI Logs/
DB Snapshots
Syslog
Apache
Logs
App Logs tail
Management
Tool
Compute Engine
Forwarder
Fluentd
td-agent
Forwarder
Fluentd
td-agent
forward
Log AggregationLog
Aggregation
Re-tagging + Filtering
Fluentd
td-agent +
fluent-plugin-google-cloud
SEGA
Web
Console
HTTPS
GitLab Cluster
Git push/
Run deploy jobs
Kubernetes Enginehelm
upgrade
fluent.conf
fluent.conf
Edit

35. Kubernetes Engine 活用事例紹介
『イドラ』 開発環境の運用効率化の事例

36. 以前の開発環境
Game Infrastructure
Instance Group
#F9FBE7
KPI Logs/
DB SnapshotsGCP 1
Compute Engine
API Server
Service Server
Management
Tool
Redis Server
Memcached
Server
MySQL
Instance Group
#F9FBE7
KPI Logs/
DB SnapshotsGCP 2
Compute Engine
API Server
Service Server
Management
Tool
Redis Server
Memcached
Server
MySQL
Static
external IP
Static
external IP
SEGA
Dev/Check
Team
Instance Group
#F9FBE7
KPI Logs/
DB SnapshotsGCP 3
Compute Engine
API Server
Service Server
Management
Tool
Instance Group
#F9FBE7
KPI Logs/
DB SnapshotsGCP N
Compute Engine
API Server
Service Server
Management
Tool
IDOLA Development
…
… Common Infrastructure
Services
Kubernetes Engine
Multiple Instances
SEGA
Repository
Server
Admin
Run deploy jobs
Compute Engine
Clone
Create/Delete
instance

37. 以前の開発環境の主な問題点
• 1 環境に 1 GCE インスタンスが必要
• 新しい環境の追加は気軽にはできないため、あらかじめ十分な数の環境を用意する必要がある
• 各環境は複数人で共用かつ別用途で使い回しなため、何かしら変更する場合は相談と全体への周知が必
須
• 環境名は「”GCP”＋連番」なため、用途やアプリバージョンなどは別途管理表が必要

38. 改善後の開発環境
SEGA
Run build/deploy
jobs
SEGA
Dev/Check
Team
IDOLA DevelopmentGame Cluster
Nodes
Kubernetes Engine
Autoscaling
kube-system podsNginx Ingress Controller
Nginx Ingress
Controller
Virtual Host
Name
helm tiller
Namespace “latest”
Common
Infrastructure Services
Game Servers
Namespace
“v10101-rev12345-newevent”
Common
Infrastructure Services
Game Servers
…
CIS Images
Container Registry
Pull
image
GitLab Cluster
Kubernetes Engine
Push
image
helm
install/upgrade
Repository
Dev/Check
Team
Clone

39. 新開発環境の改善点
• 1 環境に 1 GCE インスタンスが必要
⇒コンテナ化したことで 1 インスタンス（ノード）に複数の環境を乗せられるように
• 新しい環境の追加は気軽にはできないため、あらかじめ十分な数の環境を用意する必要がある
⇒オートスケールを活用し、すべて自動化することで、簡単に環境を追加／削除可能に
• 各環境は複数人で共用かつ別用途で使い回しなため、何かしら変更する場合は相談と全体への周知が必
須
⇒用途ごとに専用環境を作成、使い捨てに
⇒関係者だけが利用するため、事前の相談と周知が不要に
• 環境名は「”GCP”＋連番」なため、用途やアプリバージョンなどは別途管理表が必要
⇒環境名に命名規則を導入。名前から用途やバージョンを推測できるように

40. 改善の結果
• インスタンス料金が約１/２に！
• 完全自動化により、インフラ管理コストがほぼ 0 に！
• 誰でも簡単に自分専用の環境を作成できるようになり、チェック作業効率が UP！

41. Kubernetes Engine 活用事例紹介
まとめ

42. Kubernetes のメリット
• コンテナ＋Kubernetes なら「Infrastructure as Code」、
「Immutable Infrastructure」を簡単に実現できる
⇒ 結果として、自動化やインフラの管理に掛かるコストを大幅に削減できた
• コンテナ、Kubernetes はマイクロサービス アーキテクチャと相性が良い
⇒ 多数のサービスとそのインフラの管理は Kubernetes がなければ
やっていられない
⇒ 不要なサービスを省いたり、必要最小限でスケールアウトできるので
コストメリットも大きい
• Kubernetes 環境さえあればどこにでもポーティングできる

43. Kubernetes のデメリット
• やはり学習コストは高い
◦ Kubernetes だけでなく Docker や Helm など覚えることが多い
◦ 特に Kubernetes はコンテナだけでなく抽象化されてたインフラリソースなどもまとめて
管理するため、アプリ開発者にはやや負担が大きい
⇒ 専門チームを組織しナレッジを蓄積する
⇒ アプリ開発者の責任範囲をコンテナイメージ作成までとし、その先は専門チームに
任せられるのが理想

44. 最後に

45. エンジニア募集
エンジニア募集中です
https://sega-games.co.jp/recruit/career/