Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コロプラ_SRE_LCE_ゲームバックエンド_性能との戦い
Search
COLOPL Inc.
November 22, 2023
Technology
0
1k
コロプラ_SRE_LCE_ゲームバックエンド_性能との戦い
COLOPL Inc.
November 22, 2023
Tweet
Share
More Decks by COLOPL Inc.
See All by COLOPL Inc.
PHPStan をできる限り高速化してみる
colopl
0
470
コロプラ最新作インフラ構成について
colopl
0
150
Cloud Spanner 導入で実現した快適な開発と運用について
colopl
1
1.9k
コロプラのオンボーディングを採用から語りたい
colopl
7
2.2k
怖くない!ゼロから始めるPHPソースコードコンパイル入門
colopl
1
430
大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~
colopl
3
5.5k
長期運用プロジェクトでのMySQLからTiDB移行の検証
colopl
3
1.7k
ゲームを支えるバックエンドエンジニアのリアルを公開!
colopl
1
1.5k
新卒3年目の ゲームバックエンドエンジニアが これまでに経験したこと
colopl
1
1.7k
Other Decks in Technology
See All in Technology
LLMで構造化出力の成功率をグンと上げる方法
keisuketakiguchi
0
450
Google Cloud で学ぶデータエンジニアリング入門 2025年版 #GoogleCloudNext / 20250805
kazaneya
PRO
14
3k
SRE新規立ち上げ! Hubbleインフラのこれまでと展望
katsuya0515
0
160
Strands Agents & Bedrock AgentCoreを1分でおさらい
minorun365
PRO
6
240
生成AI時代におけるAI・機械学習技術を用いたプロダクト開発の深化と進化 #BetAIDay
layerx
PRO
1
1k
【CEDEC2025】『Shadowverse: Worlds Beyond』二度目のDCG開発でゲームをリデザインする~遊びやすさと競技性の両立~
cygames
PRO
1
290
Kiroでインフラ要件定義~テスト を実施してみた
nagisa53
3
310
「Roblox」の開発環境とその効率化 ~DAU9700万人超の巨大プラットフォームの開発 事始め~
keitatanji
0
100
S3 Glacier のデータを Athena からクエリしようとしたらどうなるのか/try-to-query-s3-glacier-from-athena
emiki
0
180
Kiroから考える AIコーディングツールの潮流
s4yuba
4
670
ビジネス文書に特化した基盤モデル開発 / SaaSxML_Session_2
sansan_randd
0
260
AWS re:Inforce 2025 re:Cap Update Pickup & AWS Control Tower の運用における考慮ポイント
htan
1
210
Featured
See All Featured
Done Done
chrislema
185
16k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
A Modern Web Designer's Workflow
chriscoyier
695
190k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
Transcript
コロプラ SRE/LCE ゲームバックエンド 性能との戦い
2 氏名 : 部署名 : 松野 岳記 技術基盤本部 第 3
バックエンドエンジニア部 サーバー基盤グループ マネージャー
3 概要 内容 コロプラのゲーム API サーバーの 性能確保のための取り組みを紹介 Cloud Spanner の話題が多めかも
対象 Google Cloud でのサーバー運用に 興味があるアプリケーション開発者, etc.
目次 4 01 コロプラについて 02 バックエンド性能のための取り組み 03 最近気になる機能
スマートフォン ゲーム等の エンタメ事業を中心とした会社です コロプラについて 5
1 2 ゲームサーバーの課題 アクセス ローンチ時にいきなり最大級のアクセス 運用中にも極端なスパイク データ ユーザー数 イベント等のデータの積み上げ 6
アクセス ローンチ イベント開始 7
データ 8
コロプラの選択 Google Cloud のマネージドサービスへ • 自力でのインフラ運用の限界 ◦ データベースを中心に運用コストが重圧に ▪ VM
で立てたサーバーを手動で増減 ▪ VM にインストールした MySQL を自力でシャーディング • クラウドインフラのブレイクスルー 9
コロプラ バックエンド概要 Kubernetes Cluster Monitoring Prometheus Async Servers GKE Pods
Queue RabbitMQ, etc. Cache Redis Load Balancer KPI Analytics BigQuery Logs Cloud Logging ユーザー API Servers (PHP) GKE Pods User Data Cloud Spanner Visualization Grafana クラウドサービス( AWS) CDN CloudFront Storage S3 Master Data MySQL, etc. Multiple Replica Realtime Servers (Go) GKE Pods 10
コロプラ バックエンド概要 Kubernetes Cluster Monitoring Prometheus Async Servers GKE Pods
Queue RabbitMQ, etc. Cache Redis Load Balancer KPI Analytics BigQuery Logs Cloud Logging ユーザー API Servers (PHP) GKE Pods User Data Cloud Spanner Visualization Grafana Master Data MySQL, etc. Multiple Replica Realtime Servers (Go) GKE Pods クラウドサービス( AWS) CDN CloudFront Storage S3 11
運用性・スケーラビリティ • 優秀なスケーラビリティ ◦ 本番のアクセスの波への対応 • Infrastructure as Code ◦
運用・保守の安全性 ◦ 環境の増減 (dev, stress, etc.) Google Kubernetes Engine 12
Cloud Spanner ゲームに使えるのかというチャレンジ • 結論から言うと採用して正解だった ◦ データベースのスケール運用は大幅に改善 ▪ Node 数を調整するだけ
• 明確な注意点があるのでそれを避ける ◦ 急激なデータ増加 ◦ ホットスポット ◦ トランザクションとロックの特性 13
コロプラ LCE の活動 ゲームのローンチを成功させるために 取り組むエンジニア Launch Coordination Engineer ローンチという特殊なフェーズの経験を蓄積している •
サーバー性能の確保 • ローンチ後に必要になる社内機能の整備 • ローンチプロセスのリード 14
コロプラ LCE の活動 サーバー性能の確保の流れ ローンチ時にいきなりピークが来るゲームサーバーを 確実にスタートさせる取り組み • データサイエンスやマーケと想定ユーザー数を決定 • ゲームを遊ぶ
• 試験クライアントの開発 • プレイ会の開催 • 負荷試験 15
コロプラ LCE の活動 サーバー性能の確保の流れ ローンチ時にいきなりピークが来るゲームサーバーを 確実にスタートさせる取り組み • データサイエンスやマーケと想定ユーザー数を決定 • ゲームを遊ぶ
• 試験クライアントの開発 • プレイ会の開催 • 負荷試験 ◦ Cloud Spanner を正しく使えているかの確認 16
コロプラ LCE の活動 負荷試験の流れ • ウォームアップ • 試験クライアントから負荷をかける • 性能確認して足りないところをチューニング
• 性能目標まで繰り返し 17
Cloud Spanner - ウォームアップ Cloud Spanner の特性 • Node (Process
unit) と Split の概念 ◦ Node: 指定する処理能力 ▪ 指定可能 ◦ Split: データの分割単位 ▪ 稼働中に自動で分割 出典: https://cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes 18
Cloud Spanner - ウォームアップ Cloud Spanner の特性 • 課題 ◦
Split が少ないと Node を増やしても 処理能力を発揮できない ◦ ローンチ時のデータ増加速度は Split の分割より圧倒的に速い 出典: https://cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes 19
Cloud Spanner - ウォームアップ ウォームアップの実施 • 事前に負荷をかけて Split を作っておく •
自作のウォームアップツール (dankichi) ◦ 目標 Node 数を指定すると Split が作られるように負荷をかけてくれる ◦ 処理概要 ▪ 1 Node の状態で大量の INSERT と SELECT を繰り返す ▪ 高 CPU 状態になったらその Node 数では十分な Split があると判断 ▪ Node を追加する ▪ 目標 Node 数まで繰り返し 20
Cloud Spanner - ウォームアップ ウォームアップの実施 • 確認方法 ◦ CPU が頭打ちになっていないか
◦ 対象テーブルに以下のような SQL を実行 SELECT COUNT(1) FROM XXX@{FORCE_INDEX=_BASE_TABLE} ▪ Explaination で Number of executions が大体の Split 数 ◦ Key Visualizer • その他 ◦ 公式の Blog 記事や負荷ツールも出ています 21
Cloud Spanner - Hotspot Hotspot の回避 • アクセスの集中する Split ができてしまうと処理能力を発揮できない
• よくある原因 ◦ 連続性のあるキー (数値、時刻) を持ったテーブルやインデックス ▪ グローバル インデックスはうっかり踏みやすい ◦ 少数のデータに依存しやすいアプリケーション ロジック 22
Cloud Spanner - Hotspot Hotspot の回避 • 確認方法 ◦ Key
Visualizer 23
Cloud Spanner - トランザクション トランザクションの機構 • 基本概念 ◦ シリアル化可能性 ◦
全てが commit の瞬間に発生したとみなせるか ◦ SELECT FOR UPDATE はない • ←は Txn2 が Abort される Txn1 Txn2 begin R/W begin R/W Read A Read A Write A Commit Commit 24
Cloud Spanner - トランザクション ロックの機構 • 普通は最初の処理が先の方が優先 • 優先度の高いトランザクションが ロックを持っているロック待ちになる
• ←では Txn2 は Txn1 が Commit するまで待つ Txn1 Txn2 begin R/W begin R/W Read A Read A Write A Commit Commit 25
Cloud Spanner - トランザクション アプリケーションでの対応 • R/W トランザクションで複数の主体が Write する行へのアクセスは避ける
◦ ゲームでは自分以外のユーザーデータに基本的にアクセスしない ◦ 他ユーザー情報 (フレンド機能など) では工夫が必要 ▪ キャッシュデータのみアクセス ▪ R/W トランザクション外で Stale Read させる • Abort されたら処理を丸ごとリトライ • 確認方法 ◦ Lock Insights, Transaction Insights, Query Insights などのツール 26
Cloud Spanner - 参考値 • アプリケーション視点 p50 ~ p99 •
軽 : simple condition • 重 : complex condition ローンチ直後 長期タイトル SELECT (軽) 7 ~ 15ms 7 ~ 15ms SELECT (重) 50 ~ 110ms 50 ~ 300ms INSERT (軽) 8 ~ 20ms 8 ~ 20ms INSERT (重) 20 ~ 60ms 20 ~ 90ms UPDATE (軽) 7 ~ 15ms 7 ~ 15ms UPDATE (重) - 20 ~ 50ms 27
Cloud Spanner - 参考値 • アプリケーション視点 p50 ~ p99 •
軽 : simple condition • 重 : complex condition ローンチ直後 長期タイトル SELECT (軽) 7 ~ 15ms 7 ~ 15ms SELECT (重) 50 ~ 110ms 50 ~ 300ms INSERT (軽) 8 ~ 20ms 8 ~ 20ms INSERT (重) 20 ~ 60ms 20 ~ 90ms UPDATE (軽) 7 ~ 15ms 7 ~ 15ms UPDATE (重) - 20 ~ 50ms 28 シンプルなアクセスでは 数年分のデータが積み上がっても劣化していない! コロプラの使っている範囲では 本当に無限スケール DBと感じます
Cloud Spanner 小まとめ • 分散できれば勝ち ◦ バッド プラクティスを踏まなければデータ量に関係なく良好な性能 • スケールに関する運用は非常に便利
◦ 使い方を間違えてなければ Node 数を調整するだけ (下げる時にむしろ注意) ◦ 最近 Autoscaler も登場しました • 公式ツールも充実してきたし本番でも使える 29
MySQL Hotspot になりやすいデータ用 • 主にマスタデータ ◦ 開催中のイベントなど特定データに全員がアクセスする ◦ ユーザーからの更新はない •
メリット ◦ Read レプリカを任意のサイズにスケールできる • その他 ◦ Cloud SQL Enterprise Plus が出た ▪ ダウンタイムが本番実用レベルになった 30
MySQL - 参考値 • アプリケーション視点 p50 ~ p99 • 用途を制限しているので
更新系はなし • 大量の buffer pool ローンチ直後 長期タイトル SELECT (軽) 200μs ~ 600μs 300μs ~ 1ms SELECT (重) 300μs ~ 2ms 2 ~ 100ms INSERT - - UPDATE - - 31
MySQL - 参考値 • アプリケーション視点 p50 ~ p99 • 用途を制限しているので
更新系はなし • 大量の buffer pool ローンチ直後 長期タイトル SELECT (軽) 200μs ~ 600μs 300μs ~ 1ms SELECT (重) 300μs ~ 2ms 2 ~ 100ms INSERT - - UPDATE - - 32 正直に100msと書いていますが これは要修正事案です (このパフォーマンスで満足しているわけではないです )
Redis Enterprise Cloud フルマネージドの Redis サービス • Google Cloud Console
のパートナーソリューションから選択 • コロプラでは歴史的経緯もあり Redis Enterprise Cloud を使用 (Redis Enterprise Cloud Flexible と 2 種類ある) • 優秀な運用性 ◦ ダウンタイム非常に小さい ◦ 運用中にメモリを増やせるなど便利 ◦ 英語さえできれば 24/7 support 33
Redis Enterprise Cloud アプリケーション サイド • アクセス経路 ◦ ゲームロジック →
PhpRedis → twemproxy → Redis • 用途 ◦ 単純なキャッシュ ◦ 更新主体ではないデータの参照用 34
Redis Enterprise Cloud - 参考値 • p50 ~ p99 •
ローンチ直後タイトル ◦ Memory 2GB 程度 • 長期タイトル ◦ Memory 10GB 程度 • PhpRedis は シリアライズ等も込み ローンチ直後 長期タイトル PhpRedis get 500μs ~ 1.5ms 800μs ~ 1.5ms set 500μs ~ 1.5ms 900μs ~ 1.8ms hGetAll - 800μs ~ 1.7ms hSet - 800μs ~ 1.5ms Redis 側 avg 100 ~ 150 μs 100 ~ 300 μs 35
Redis Enterprise Cloud - 参考値 • p50 ~ p99 •
ローンチ直後タイトル ◦ Memory 2GB 程度 • 長期タイトル ◦ Memory 10GB 程度 • PhpRedis は シリアライズ等も込み ローンチ直後 長期タイトル PhpRedis get 500μs ~ 1.5ms 800μs ~ 1.5ms set 500μs ~ 1.5ms 900μs ~ 1.8ms hGetAll - 800μs ~ 1.7ms hSet - 800μs ~ 1.5ms Redis 側 avg 100 ~ 150 μs 100 ~ 300 μs 36 Redis で 1.5ms と言うと Redis Enterprise 様の性能に誤解を招いてしまうので Redis 側のレイテンシ参考値も載せています
PHP / Laravel • PHP ってどうなんですか ◦ 昔のイメージが悪すぎるだけで最近のバージョン良いです ◦ コロプラはなぜゲーム
アプリケーションで PHP を使い続けるのか • コロプラの取り組み ◦ 前述のプラクティスをライブラリ化 ▪ リトライ耐性, データアクセスコードの生成 , 外部コンポーネントのエラーハンドリング, etc. ◦ Cloud Spanner を Laravel で利用するライブラリを公開中 ▪ colopl/laravel-spanner (GitHub) • ライフハック ◦ Go や Java のレポジトリもウォッチしておくと良いかもしれない... 37
PHP / Laravel - 参考値 • p50 ~ p99 ローンチ直後
長期タイトル 参照系 API (軽) 60 ~ 500ms 60 ~ 800ms 参照系 API (重) 600 ~ 1.3s 800 ~ 2.9s 更新系 API (軽) 300 ~ 600ms 400 ~ 1.7s 更新系 API (重) 1.0 ~ 1.7s 1.0 ~ 7.1s 38
PHP / Laravel - 参考値 • p50 ~ p99 ローンチ直後
長期タイトル 参照系 API (軽) 60 ~ 500ms 60 ~ 800ms 参照系 API (重) 600 ~ 1.3s 800 ~ 2.9s 更新系 API (軽) 300 ~ 600ms 400 ~ 1.7s 更新系 API (重) 1.0 ~ 1.7s 1.0 ~ 7.1s 39 ここもデータに正直に載せましたが 満足しているわけではなく要修正事案です
最近気になる機能 • Cloud Spanner Data Boost • Multicontainer support in
Cloud Run 40
最近気になる機能 Cloud Spanner Data Boost • Cloud Spanner と独立したコンピューティング リソースでデータにアクセスするサービス
◦ アプリケーションと分析ジョブの より明確な住み分けなどに期待 出典: https://cloud.google.com/spanner/docs/databoost/databoost-overview 41
最近気になる機能 Multicontainer support in Cloud Run • Cloud Run でサイドカーが設定可能に
◦ よりシンプルなインフラで スモールスタートとライトな運用に期待 出典: https://cloud.google.com/run/docs/deploying?hl=en#sidecars 42
まとめ • コロプラでは運用課題から Google Cloud の マネージドサービスを利用するスタイルを選びました。 この点にはとても満足のいく状況です。 • アプリケーションでは
主に各種ストレージの使い分けによって 自己管理時代以上の性能を発揮できています。 • コロプラはこのくらいの性能で運用しています という数値を紹介させてもらいました 参考になれば幸いです。 43
Thank you 44