Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

COLOPL Inc.
November 22, 2023

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

COLOPL Inc.

November 22, 2023
Tweet

More Decks by COLOPL Inc.

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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 側のレイテンシ参考値も載せています

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide