COLOPL, Inc. All Rights Reserved
コロプラのゲームサーバー運用における
SREチームの取り組み
Slide 2
Slide 2 text
COLOPL, Inc. All Rights Reserved
2
● COLOPLのSREチーム
● SLI/SLO活動
● まとめ
Table of Contents
Slide 3
Slide 3 text
COLOPL, Inc. All Rights Reserved
3
● 松野 岳記 (Takeki Matsuno)
● 株式会社コロプラ (2018.10-)
● サーバー基盤グループMGR 兼 SREチームエンジニア
● サーバーサイドの運用・開発をタイトル横断的に活動
About me
Slide 4
Slide 4 text
COLOPL, Inc. All Rights Reserved
4
COLOPLのSREチーム
Slide 5
Slide 5 text
COLOPL, Inc. All Rights Reserved
5
COLOPL Engineer organization
Smartphone internet GCP, AWS, etc.
k8s, etc.
Server Framework
Client
Framework
Game Server
Game Client
インフラ
サーバー基盤
クライアント基
盤
ゲームプロジェクト
プラットフォーム
クライアントサイド サーバーサイド
Slide 6
Slide 6 text
COLOPL, Inc. All Rights Reserved
6
SREってなんでしょうかね?
● 一般には?
➭ Site Reliability Engineering
➭ SLI/SLO(*)を定めて信頼性のために活動する
● SLO?
➭ SLAとの違い
➜ SLAは達成できなかった時の保証の話
≒ ユーザー様が不満を持った時のもの
➜ SLOはサービスがどうあるべきかの基準
≒ ユーザー様が満足している状態を表現するもの
*) Service Level Indicators / Service Level Objectives
SRE
Slide 7
Slide 7 text
COLOPL, Inc. All Rights Reserved
7
SREってなんでしょうかね?
● 具体的には?
➭ SREというワードは有名なのに
SLI/SLOの例は見かけない...
➭ SLI/SLOというワードを中心に
コロプラSREチームの話をしたいと思います
● ちなみに
➭ 最近Seeking SREの日本語版が出ています
➭ みんな割りと色んなことやっている
SRE
Slide 8
Slide 8 text
COLOPL, Inc. All Rights Reserved
8
コロプラSREの起源
● いくつかのタイトルで運用実績が伸びてきた
● ユーザー様に継続的に楽しんでもらいたい
➭ コンスタントなイベント開発は外せない
➭ 性能面はインフラリソース追加で対応するものの
アプリケーションのチューニングが不足がちに
➭ サーバーダウン
● このままの運用品質では上を目指せない
COLOPL SRE
Slide 9
Slide 9 text
COLOPL, Inc. All Rights Reserved
9
ゲームサーバーの運用の困りごと
● アクセスの波
● ゲームイベント等のロジックの物量
● データの物量
COLOPL SRE
Slide 10
Slide 10 text
COLOPL, Inc. All Rights Reserved
10
アクセスの波 - 日次ユーザー数
COLOPL SRE
とある約1ヶ月間
イベントなどで
簡単に2倍以上変わる
Slide 11
Slide 11 text
COLOPL, Inc. All Rights Reserved
11
アクセスの波 - 日中アクセス量
COLOPL SRE
とある半日
ログインボーナス、
アプリ通知などで
簡単に何倍も変わる
Slide 12
Slide 12 text
COLOPL, Inc. All Rights Reserved
12
ゲームイベント等のロジックの物量
● 新しい体験を常に提供したい
● イベント再開催
COLOPL SRE
Slide 13
Slide 13 text
COLOPL, Inc. All Rights Reserved
13
データの物量
● イベントデータ
● ユーザーデータ
今回は触れないが
Spannerのような分散DBに移行した話も今後できるかも
COLOPL SRE
Slide 14
Slide 14 text
COLOPL, Inc. All Rights Reserved
14
インフラ指標だけでは長期的に品質を維持できる気がしない
● ゲームの特性
● イベントの特性
● 運用の特性
運用と共にアプリケーションからインフラまで通した品質活動をしたい
ちょうど世間でSREというワードが流行っていた
● これがやりたいイメージに近いのではないか?
● アプリケーション寄りから発足
COLOPL SRE
Slide 15
Slide 15 text
COLOPL, Inc. All Rights Reserved
15
具体的に何をしよう?
● 世間的にはインフラスタートのイメージが強い?
● Googleの教えを素直に受け止めてみる
➭ SREへの正しい道 その1.
状況に応じたユーザー重視のSLOを定義する (*)
➭ Google CREとも相談
信頼性とはユーザー様がどう思うか
SLI/SLOをどうするか自分たちのサービス次第
*) 参考記事
COLOPL SRE
Slide 16
Slide 16 text
COLOPL, Inc. All Rights Reserved
16
ユーザー様のゲーム体験を意識したSLI/SLOを考える活動をしよう
COLOPL SRE
Slide 17
Slide 17 text
COLOPL, Inc. All Rights Reserved
17
SLI/SLO活動
Slide 18
Slide 18 text
COLOPL, Inc. All Rights Reserved
18
Client side
COLOPL SRE SLI/SLO
Server side
Game server/Asset server
User journey action
boot
login
setup
screen draw
Journey 1:
e.g.) Login
Journey 2:
xxx
login API
user data API
asset download
ここはよく見る
Slide 19
Slide 19 text
COLOPL, Inc. All Rights Reserved
19
Client side
COLOPL SRE SLI/SLO
Server side
Game server/Asset server
User journey action
boot
login
setup
screen draw
Journey 1:
e.g.) Login
Journey 2:
xxx
login API
user data API
asset download
こっちのかたまりを
観察できるようにして
判断基準にしたい
ここはよく見る
Slide 20
Slide 20 text
COLOPL, Inc. All Rights Reserved
20
活動の流れ
● ゲームをやる
● ジャーニーをピックアップする
● データの収集機構を立てる
● 定期的にフィードバックする
COLOPL SRE SLI/SLO
Slide 21
Slide 21 text
COLOPL, Inc. All Rights Reserved
21
ゲームをやる
● やります
COLOPL SRE SLI/SLO
Slide 22
Slide 22 text
COLOPL, Inc. All Rights Reserved
22
ジャーニーをピックアップする
● ゲームのメインループを理解する
➭ e.g.) ログイン〜[キャラ編集>クエスト受ける>バトル]xN
● メインループ内のジャーニーと指標(SLI)を選び出す
➭ e.g.)「バトル開始」の「レイテンシ」, etc.
➭ SLO対象は15個くらいを推奨
● プランナーさんの考えを聞いてみる
● ステークホルダーと合意取る
➭ PM、CE、SE
➭ SLI/SLOが悪化したら必ずアクション考える
COLOPL SRE SLI/SLO
Slide 23
Slide 23 text
COLOPL, Inc. All Rights Reserved
23
データの収集機構を立てる
COLOPL SRE SLI/SLO
Cloud
Logging
Game
Server
Cloud
Pub/Sub
Cloud
Dataflow
BigQuery
Structured
Data
ETL
SLI
Aggregate
SLO
Summary
DB
Summary Data
...
Grafana
Slide 24
Slide 24 text
COLOPL, Inc. All Rights Reserved
24
定期的にフィードバックする
● 一旦モニタリング当初のSLIでSLOを決める
● 月毎で状況報告
➭ SLIの状態や傾向
➭ 気になるところはSRE側で
ゲームソースコードの調査等の深掘りも
● 四半期毎でアクションの話し合い
➭ 数字で出たものに対してノーアクションはしない
➭ アプリケーション対応しないならSLOを変える
COLOPL SRE SLI/SLO
Slide 25
Slide 25 text
COLOPL, Inc. All Rights Reserved
25
定期的にフィードバックする
COLOPL SRE SLI/SLO
xxxxx
xxxxx
xxx
xxx xxx
xxx xxx
xxx
xxx
xxx
Slide 26
Slide 26 text
COLOPL, Inc. All Rights Reserved
26
定期的にフィードバックする
COLOPL SRE SLI/SLO
xxxxx
xxxxx
Slide 27
Slide 27 text
COLOPL, Inc. All Rights Reserved
27
ジャーニー単位SLI/SLOでやっての感想・良かったこと
● リトライ素敵ってことがよく分かった
● 良い状態からモニタリング開始しておいた方がいい
● 例
➭ 一部のジャーニーでリトライが足りていなかったケース
➭ 乱高下しつつ徐々に劣化するケース
COLOPL SRE SLI/SLO
Slide 28
Slide 28 text
COLOPL, Inc. All Rights Reserved
28
一部のジャーニーでAPIリトライが足りていなかったケース
● シーンの性質上、他より手厚くリトライが必要なケースが判明
COLOPL SRE SLI/SLO
Slide 29
Slide 29 text
COLOPL, Inc. All Rights Reserved
29
一部のジャーニーでAPIリトライが足りていなかったケース
COLOPL SRE SLI/SLO
リトライの足りていなかった某ジャーニーのAvailability
その他のジャーニー
Slide 30
Slide 30 text
COLOPL, Inc. All Rights Reserved
30
一部のジャーニーでAPIリトライが足りていなかったケース
COLOPL SRE SLI/SLO
リトライ込みエラー数
Slide 31
Slide 31 text
COLOPL, Inc. All Rights Reserved
31
乱高下しつつ徐々に劣化するケース
● 先に説明したようにイベントの特性などで変わるものが多い
COLOPL SRE SLI/SLO
Slide 32
Slide 32 text
COLOPL, Inc. All Rights Reserved
32
乱高下しつつ徐々に劣化するケース
COLOPL SRE SLI/SLO
イベント要因
イベント要因 イベント要因
!?
SLO
某ジャーニーのレイテンシ
Slide 33
Slide 33 text
COLOPL, Inc. All Rights Reserved
33
ジャーニーとか関係なく見れるもの
● 全タイトルではジャーニーモニタリングできない
● APIのモニタリング
➭ シンプルにLatency, Availability, Response size
➭ 追加でUU vs Pod num vs リクエスト数
COLOPL SRE Other
Slide 34
Slide 34 text
COLOPL, Inc. All Rights Reserved
34
UUvsPod
(コスト効率)
リクエスト数vsPod
(処理効率)
リクエスト数vsUU
(熱量とゲーム特性)
COLOPL SRE Other
Slide 35
Slide 35 text
COLOPL, Inc. All Rights Reserved
35
今後
● データから合理的に運用判断し続ける事のレベルアップ
➭ SLO/エラーバジェットの改善と布教
● SLI/SLOをユーザー側へ寄せられないか
➭ 指標がユーザーにとってどういう意味を持っているのかを
高めていきたい
COLOPL SRE Other
Slide 36
Slide 36 text
COLOPL, Inc. All Rights Reserved
36
まとめ
● ユーザー様にとってのサービス信頼性という軸を持って活動をしたい
● 変化の激しい中で長期的にゲームサービスの品質を表現して
維持できるようにしたい
● 横断的組織に居るがプロジェクトチームへのフィードバックまできちんと
やっていきたい