コロプラ_SRE_LCE_ゲームバックエンド_性能との戦い

by COLOPL Inc.

Slide 1

Slide 1 text

コロプラ SRE/LCE ゲームバックエンド性能との戦い

Slide 2

Slide 2 text

2 氏名　：部署名：松野岳記技術基盤本部第 3 バックエンドエンジニア部サーバー基盤グループマネージャー

Slide 3

Slide 3 text

3 概要内容コロプラのゲーム API サーバーの性能確保のための取り組みを紹介 Cloud Spanner の話題が多めかも対象 Google Cloud でのサーバー運用に興味があるアプリケーション開発者, etc.

Slide 4

Slide 4 text

目次 4 01 コロプラについて 02 バックエンド性能のための取り組み 03 最近気になる機能

Slide 5

Slide 5 text

スマートフォンゲーム等のエンタメ事業を中心とした会社ですコロプラについて 5

Slide 6

Slide 6 text

1 2 ゲームサーバーの課題アクセスローンチ時にいきなり最大級のアクセス運用中にも極端なスパイクデータユーザー数イベント等のデータの積み上げ 6

Slide 7

Slide 7 text

アクセスローンチイベント開始 7

Slide 8

Slide 8 text

データ 8

Slide 9

Slide 9 text

コロプラの選択 Google Cloud のマネージドサービスへ ● 自力でのインフラ運用の限界 ○ データベースを中心に運用コストが重圧に ■ VM で立てたサーバーを手動で増減 ■ VM にインストールした MySQL を自力でシャーディング ● クラウドインフラのブレイクスルー 9

Slide 10

Slide 10 text

コロプラバックエンド概要 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

Slide 11

Slide 11 text

コロプラバックエンド概要 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

Slide 12

Slide 12 text

運用性・スケーラビリティ ● 優秀なスケーラビリティ ○ 本番のアクセスの波への対応 ● Infrastructure as Code ○ 運用・保守の安全性 ○ 環境の増減 (dev, stress, etc.) Google Kubernetes Engine 12

Slide 13

Slide 13 text

Cloud Spanner ゲームに使えるのかというチャレンジ ● 結論から言うと採用して正解だった ○ データベースのスケール運用は大幅に改善 ■ Node 数を調整するだけ ● 明確な注意点があるのでそれを避ける ○ 急激なデータ増加 ○ ホットスポット ○ トランザクションとロックの特性 13

Slide 14

Slide 14 text

コロプラ LCE の活動ゲームのローンチを成功させるために取り組むエンジニア Launch Coordination Engineer ローンチという特殊なフェーズの経験を蓄積している ● サーバー性能の確保 ● ローンチ後に必要になる社内機能の整備 ● ローンチプロセスのリード 14

Slide 15

Slide 15 text

コロプラ LCE の活動サーバー性能の確保の流れローンチ時にいきなりピークが来るゲームサーバーを確実にスタートさせる取り組み ● データサイエンスやマーケと想定ユーザー数を決定 ● ゲームを遊ぶ ● 試験クライアントの開発 ● プレイ会の開催 ● 負荷試験 15

Slide 16

Slide 16 text

コロプラ LCE の活動サーバー性能の確保の流れローンチ時にいきなりピークが来るゲームサーバーを確実にスタートさせる取り組み ● データサイエンスやマーケと想定ユーザー数を決定 ● ゲームを遊ぶ ● 試験クライアントの開発 ● プレイ会の開催 ● 負荷試験 ○ Cloud Spanner を正しく使えているかの確認 16

Slide 17

Slide 17 text

コロプラ LCE の活動負荷試験の流れ ● ウォームアップ ● 試験クライアントから負荷をかける ● 性能確認して足りないところをチューニング ● 性能目標まで繰り返し 17

Slide 18

Slide 18 text

Cloud Spanner - ウォームアップ Cloud Spanner の特性 ● Node (Process unit) と Split の概念 ○ Node: 指定する処理能力 ■ 指定可能 ○ Split: データの分割単位 ■ 稼働中に自動で分割出典: https://cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes 18

Slide 19

Slide 19 text

Cloud Spanner - ウォームアップ Cloud Spanner の特性 ● 課題 ○ Split が少ないと Node を増やしても処理能力を発揮できない ○ ローンチ時のデータ増加速度は Split の分割より圧倒的に速い出典: https://cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes 19

Slide 20

Slide 20 text

Cloud Spanner - ウォームアップウォームアップの実施 ● 事前に負荷をかけて Split を作っておく ● 自作のウォームアップツール (dankichi) ○ 目標 Node 数を指定すると Split が作られるように負荷をかけてくれる ○ 処理概要 ■ 1 Node の状態で大量の INSERT と SELECT を繰り返す ■ 高 CPU 状態になったらその Node 数では十分な Split があると判断 ■ Node を追加する ■ 目標 Node 数まで繰り返し 20

Slide 21

Slide 21 text

Cloud Spanner - ウォームアップウォームアップの実施 ● 確認方法 ○ CPU が頭打ちになっていないか ○ 対象テーブルに以下のような SQL を実行 SELECT COUNT(1) FROM XXX@{FORCE_INDEX=_BASE_TABLE} ■ Explaination で Number of executions が大体の Split 数 ○ Key Visualizer ● その他 ○ 公式の Blog 記事や負荷ツールも出ています 21

Slide 22

Slide 22 text

Cloud Spanner - Hotspot Hotspot の回避 ● アクセスの集中する Split ができてしまうと処理能力を発揮できない ● よくある原因 ○ 連続性のあるキー (数値、時刻) を持ったテーブルやインデックス ■ グローバルインデックスはうっかり踏みやすい ○ 少数のデータに依存しやすいアプリケーションロジック 22

Slide 23

Slide 23 text

Cloud Spanner - Hotspot Hotspot の回避 ● 確認方法 ○ Key Visualizer 23

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Cloud Spanner - トランザクションロックの機構 ● 普通は最初の処理が先の方が優先 ● 優先度の高いトランザクションがロックを持っているロック待ちになる ● ←では Txn2 は Txn1 が Commit するまで待つ Txn1 Txn2 begin R/W begin R/W Read A Read A Write A Commit Commit 25

Slide 26

Slide 26 text

Cloud Spanner - トランザクションアプリケーションでの対応 ● R/W トランザクションで複数の主体が Write する行へのアクセスは避ける ○ ゲームでは自分以外のユーザーデータに基本的にアクセスしない ○ 他ユーザー情報 (フレンド機能など) では工夫が必要 ■ キャッシュデータのみアクセス ■ R/W トランザクション外で Stale Read させる ● Abort されたら処理を丸ごとリトライ ● 確認方法 ○ Lock Insights, Transaction Insights, Query Insights などのツール 26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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と感じます

Slide 29

Slide 29 text

Cloud Spanner 小まとめ ● 分散できれば勝ち ○ バッドプラクティスを踏まなければデータ量に関係なく良好な性能 ● スケールに関する運用は非常に便利 ○ 使い方を間違えてなければ Node 数を調整するだけ (下げる時にむしろ注意) ○ 最近 Autoscaler も登場しました ● 公式ツールも充実してきたし本番でも使える 29

Slide 30

Slide 30 text

MySQL Hotspot になりやすいデータ用 ● 主にマスタデータ ○ 開催中のイベントなど特定データに全員がアクセスする ○ ユーザーからの更新はない ● メリット ○ Read レプリカを任意のサイズにスケールできる ● その他 ○ Cloud SQL Enterprise Plus が出た ■ ダウンタイムが本番実用レベルになった 30

Slide 31

Slide 31 text

MySQL - 参考値 ● アプリケーション視点 p50 ~ p99 ● 用途を制限しているので更新系はなし ● 大量の buffer pool ローンチ直後長期タイトル SELECT (軽) 200μs ~ 600μs 300μs ~ 1ms SELECT (重) 300μs ~ 2ms 2 ~ 100ms INSERT - - UPDATE - - 31

Slide 32

Slide 32 text

MySQL - 参考値 ● アプリケーション視点 p50 ~ p99 ● 用途を制限しているので更新系はなし ● 大量の buffer pool ローンチ直後長期タイトル SELECT (軽) 200μs ~ 600μs 300μs ~ 1ms SELECT (重) 300μs ~ 2ms 2 ~ 100ms INSERT - - UPDATE - - 32 正直に100msと書いていますがこれは要修正事案です (このパフォーマンスで満足しているわけではないです )

Slide 33

Slide 33 text

Redis Enterprise Cloud フルマネージドの Redis サービス ● Google Cloud Console のパートナーソリューションから選択 ● コロプラでは歴史的経緯もあり Redis Enterprise Cloud を使用 (Redis Enterprise Cloud Flexible と 2 種類ある) ● 優秀な運用性 ○ ダウンタイム非常に小さい ○ 運用中にメモリを増やせるなど便利 ○ 英語さえできれば 24/7 support 33

Slide 34

Slide 34 text

Redis Enterprise Cloud アプリケーションサイド ● アクセス経路 ○ ゲームロジック → PhpRedis → twemproxy → Redis ● 用途 ○ 単純なキャッシュ ○ 更新主体ではないデータの参照用 34

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Slide 37

Slide 37 text

PHP / Laravel ● PHP ってどうなんですか ○ 昔のイメージが悪すぎるだけで最近のバージョン良いです ○ コロプラはなぜゲームアプリケーションで PHP を使い続けるのか ● コロプラの取り組み ○ 前述のプラクティスをライブラリ化 ■ リトライ耐性, データアクセスコードの生成 , 外部コンポーネントのエラーハンドリング, etc. ○ Cloud Spanner を Laravel で利用するライブラリを公開中 ■ colopl/laravel-spanner (GitHub) ● ライフハック ○ Go や Java のレポジトリもウォッチしておくと良いかもしれない... 37

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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 ここもデータに正直に載せましたが満足しているわけではなく要修正事案です

Slide 40

Slide 40 text

最近気になる機能 ● Cloud Spanner Data Boost ● Multicontainer support in Cloud Run 40

Slide 41

Slide 41 text

最近気になる機能 Cloud Spanner Data Boost ● Cloud Spanner と独立したコンピューティングリソースでデータにアクセスするサービス ○ アプリケーションと分析ジョブのより明確な住み分けなどに期待出典: https://cloud.google.com/spanner/docs/databoost/databoost-overview 41

Slide 42

Slide 42 text

最近気になる機能 Multicontainer support in Cloud Run ● Cloud Run でサイドカーが設定可能に ○ よりシンプルなインフラでスモールスタートとライトな運用に期待出典: https://cloud.google.com/run/docs/deploying?hl=en#sidecars 42

Slide 43

Slide 43 text

まとめ ● コロプラでは運用課題から Google Cloud のマネージドサービスを利用するスタイルを選びました。この点にはとても満足のいく状況です。 ● アプリケーションでは主に各種ストレージの使い分けによって自己管理時代以上の性能を発揮できています。 ● コロプラはこのくらいの性能で運用していますという数値を紹介させてもらいました参考になれば幸いです。 43

Slide 44

Slide 44 text

Thank you 44