Slide 1

Slide 1 text

1 安全なローンチを支える 負荷試験 2023年 最新版

Slide 2

Slide 2 text

2 ● 新作ゲームのローンチ前開発サポート ● 共通で利用する社内ライブラリの開発・保守 氏名  : 部署名 : ごましお @halnique 技術基盤本部 第2バックエンドエンジニア部 サーバー基盤グループ LCEチーム 自己紹介

Slide 3

Slide 3 text

● ゲームのバックエンドの負荷はローンチ時に最も急激にスパイクする ○ 事前登録やインフルエンサーによるプロモーションなど、ユーザーの期待を高めるよう なマーケティング ● 一方で、最もサービスを停止したくないタイミングでもあるため、ローンチする 前の負荷試験は特に重要 ● 本日はコロプラで新しいゲームをローンチする前の負荷試験について紹介 3 前置き

Slide 4

Slide 4 text

4 前置き ローンチ!

Slide 5

Slide 5 text

試験の流れ 5 1. ゲームをプレイしてログを収集する 2. 試験クライアントを実装する 3. 複数人のプレイログを収集する 4. 試験を実施する 5. 試験結果を評価する 6. 規模を増やしながら4-5を繰り返す 7. [番外] データベースのウォームアップ

Slide 6

Slide 6 text

試験の流れ 6 1. ゲームをプレイしてログを収集する 2. 試験クライアントを実装する 3. 複数人のプレイログを収集する 4. 試験を実施する 5. 試験結果を評価する 6. 規模を増やしながら4-5を繰り返す 7. [番外] データベースのウォームアップ

Slide 7

Slide 7 text

この時点でのゲームの開発状況の想定 ● ゲームのコア部分のプレイサイクルはできている ● レベルデザインが完成していなくてもOK 目的 ● ゲームの特性を把握する ● 試験クライアント実装に必要な情報を収集する ○ API呼び出し順 ○ リクエストパラメータ → 次のステップで試験のシナリオの材料になる 7 1. ゲームをプレイしてログを収集する

Slide 8

Slide 8 text

試験の流れ 8 1. ゲームをプレイしてログを収集する 2. 試験クライアントを実装する 3. 複数人のプレイログを収集する 4. 試験を実施する 5. 試験結果を評価する 6. 想定の最大負荷をかけた状態で試験基準を満た すまで規模を増やしながら4-5を繰り返す 7. [番外] データベースのウォームアップ

Slide 9

Slide 9 text

Golang製の独自フレームワーク アプリケーションのAPI定義から 呼び出しコードを生成可能 パラメータを指定して実行可能 9 gamebot

Slide 10

Slide 10 text

10 シナリオ実装例

Slide 11

Slide 11 text

Q. なんで自前で作ってるんですか? A. 11 2. 試験クライアントを実装する

Slide 12

Slide 12 text

Q. なんで自前で作ってるんですか? A. 独自の要件に合わせやすいから ● API呼び出しコードを定義ファイルから自動生成 ● パラメータで負荷をシミュレート可能 ● リトライ戦略など細かいカスタマイズ ● リアルタイムゲームサーバーとの接続 ● クライアントのメトリクスをPrometheusに連携 ● GKE環境にデプロイ可能 12 2. 試験クライアントを実装する

Slide 13

Slide 13 text

Q. 収集したログからシナリオ自動生成とかできたら便利じゃない? A. 13 2. 試験クライアントを実装する

Slide 14

Slide 14 text

Q. 収集したログからシナリオ自動生成とかできたら便利じゃない? A. 以前はそういうアプローチもあった ログを特定のフォーマットで出力してそれを読み込んで試験するというやり方もあっ たが、課題もあった ● アプリケーションの修正に合わせてログを取り直す必要がある ● ランダムな実行結果を再現するのが難しい(seed固定できない)ケースがある 初期実装だけログから自動生成して、あとは人力でメンテナンスするハイブリッド形 式はありかもなと思っている 14 2. 試験クライアントを実装する

Slide 15

Slide 15 text

Q. なんでGolangで実装しているの?UnityのゲームならC#でそのまま動かせばいいん じゃない? A. 15 2. 試験クライアントを実装する

Slide 16

Slide 16 text

Q. なんでGolangで実装しているの?UnityのゲームならC#でそのまま動かせばいいん じゃない? A. ありかも(未検証) たしかにクライアントコードをそのまま負荷試験に使えれば、管理面でも仕様への追 従という面でもメリットは大きそう 検討する価値はあると考えているが、クライアント実装時点でUnityとの依存をなるべ く小さくするよう考慮してもらったり、クライアント開発にかなり制限をかける必要 はありそう 16 2. 試験クライアントを実装する

Slide 17

Slide 17 text

試験の流れ 17 1. ゲームをプレイしてログを収集する 2. 試験クライアントを実装する 3. 複数人のプレイログを収集する 4. 試験を実施する 5. 試験結果を評価する 6. 規模を増やしながら4-5を繰り返す 7. [番外] データベースのウォームアップ

Slide 18

Slide 18 text

開発チームのプレイ会や社内プレイ会など、大人数がプレイするタイミングでログを 収集する 目的 ● 1ユーザーあたりのRPSを測定する ● API呼び出しの割合を把握する なるべく多くの人数でプレイしたログが収集できると試験の精度が上がる 18 3. 複数人のプレイログを収集する

Slide 19

Slide 19 text

試験の流れ 19 1. ゲームをプレイしてログを収集する 2. 試験クライアントを実装する 3. 複数人のプレイログを収集する 4. 試験を実施する 5. 試験結果を評価する 6. 規模を増やしながら4-5を繰り返す 7. [番外] データベースのウォームアップ

Slide 20

Slide 20 text

1. 試験クライアントのバイナリを含んだ コンテナイメージを作成 2. コンテナイメージをGKEにのせるため のマニフェストを作成 3. Spinnakerでマニフェストをデプロイ 20 4. 試験を実施する

Slide 21

Slide 21 text

21

Slide 22

Slide 22 text

22

Slide 23

Slide 23 text

試験の流れ 23 1. ゲームをプレイしてログを収集する 2. 試験クライアントを実装する 3. 複数人のプレイログを収集する 4. 試験を実施する 5. 試験結果を評価する 6. 規模を増やしながら4-5を繰り返す 7. [番外] データベースのウォームアップ

Slide 24

Slide 24 text

Monitoring ● gcp services Prometheus ● application ● gamebot ● gke resources 24 5. 試験結果を評価する BigQuery ● application logs Grafana

Slide 25

Slide 25 text

試験条件 適切な負荷がかけられているかどうか 25 5. 試験結果を評価する RPS (同時接続数 x 1ユーザーあた りRPS) を超える APIカバー率 基本的に100% アクセス傾向 プレイログ収集時と近い 継続時間 ピーク状態で n 時間以上 入会速度 想定入会速度を超える ステータス (リトライ含め)最終的に全て2xx 系 レイテンシ 50/90/99/99.9 など各テール レイテンシがそれぞれ n 秒以内 プレイ感 通常時と高負荷時でゲームのプ レイ感に影響がない 評価項目 品質として問題ないか (ゲームによる)

Slide 26

Slide 26 text

26 5. 試験結果を評価する

Slide 27

Slide 27 text

1. ゲームをプレイしてログを収集する 2. 試験クライアントを実装する 3. 複数人のプレイログを収集する 4. 試験を実施する 5. 試験結果を評価する 6. 規模を増やしながら4-5を繰り返す 7. [番外] データベースのウォームアップ 試験の流れ 27

Slide 28

Slide 28 text

Q. いきなり最大規模でやらないのはなんで? A. コスト最適化のため 大規模な負荷試験はお金がかかる! 小さい規模で見つかる問題は小さい規模の試験で潰しておくと無駄が出ない ● 繰り返し実施しやすい ● スケールイン/スケールアウトが容易 な試験環境にしておくことが重要 28 6. 規模を増やしながら4-5を繰り返す

Slide 29

Slide 29 text

29 ミニマムな規模でも起きがちな問題 ● そもそもアプリケーションエラーが潰しきれていない ● index の設定などクエリのミス ● キャッシュなどのTTL設定ミス 規模を増やすにつれて起きやすい問題 ● ロック ● ホットスポット(Spanner) ● データ転送量 ● マッチング 6. 規模を増やしながら4-5を繰り返す

Slide 30

Slide 30 text

スケールイン/スケールアウトをパイプライン化しておくと便利 ● gke cluster ○ Temporal ● hpa (horizontal pod autoscaler) ● spanner nodes (processing units) 使うときに使う分だけ! 30 6. 規模を増やしながら4-5を繰り返す

Slide 31

Slide 31 text

● ローンチ時のサービス品質を保つために必要不 可欠な負荷試験について紹介しました ○ 正しい負荷をかけ、適切に評価する ○ 効果的・効率的に試験する まとめ 31

Slide 32

Slide 32 text

32 以上 ありがとうございました

Slide 33

Slide 33 text

33 時間が余れば

Slide 34

Slide 34 text

1. ゲームをプレイしてログを収集する 2. 試験クライアントを実装する 3. 複数人のプレイログを収集する 4. 試験を実施する 5. 試験結果を評価する 6. 規模を増やしながら4-5を繰り返す 7. [番外] データベースのウォームアップ 試験の流れ 34

Slide 35

Slide 35 text

Spannerウォームアップについて/ColoplTech-02-03 35 7. [番外] データベースのウォームアップ

Slide 36

Slide 36 text

spanner-warmer ● INSERT / SELECT で負荷をかけつ つデータを投入する dankichi ● spanner-warmerのPod数をコント ロールして実行する ● spannerの負荷をモニタリングし ながらspanner-warmerの規模を 調節する 36 7. [番外] データベースのウォームアップ

Slide 37

Slide 37 text

37 2022年はSpannerのチューニングに関する公式情報もかなり増えた ● Cloud Spanner のウォームアップ ツールとベンチマーク ツールでアプリケーションのリリースを簡 単に [Google Cloud 公式ブログ] ● ツールを使った Cloud Spanner のウォームアップ [michityさん@Google Cloud Japan Customer Engineer] ● Cloud Spanner 向け Query Insights のご紹介: 事前構築されたダッシュボードでパフォーマンス問 題のトラブルシューティングを行う [Google Cloud 公式ブログ] ● Introducing lock insights and transaction insights for Spanner: troubleshoot lock contentions with pre-built dashboards [Google Cloud 公式ブログ] ● A deep dive into Spanner’s query optimizer [Google Cloud 公式ブログ] 7. [番外] データベースのウォームアップ

Slide 38

Slide 38 text

コロプラではLaravelからSpannerを利用するためのドライバ colopl/laravel-spanner を公開しています PHP >= 8, Laravel >= 9 対応 フィードバックお待ちしております 38 7. [番外] データベースのウォームアップ