ゲームを支えるバックエンドエンジニアのリアルを公開！

by COLOPL Inc.

Slide 1

Slide 1 text

Slide 2

Slide 2 text

ゲームバックエンドについてよく聞かれること ● ゲームのバックエンドってどのように動いているのか ● ゲームのバックエンドの特徴 ● どのような技術が使われているのか ● ゲーム開発の体制や流れについてこれらにお答えしつつ実際にバックエンドエンジニアがどのように働いているのかを紹介させていただきます！

Slide 3

Slide 3 text

3 ゲームタイトルの裏側について

Slide 4

Slide 4 text

ゲームクライアントとゲームバックエンドクライアント 4

Slide 5

Slide 5 text

● 目に見えない体験を提供 ○ “いつでも” 遊べる！ ○ “いつまでも” 遊べる！ ● ユーザー体験を追求するがあくまでWebアプリケーションの延長上 ○ APIサーバーがあってその裏にDBがあって ○ 非常にオーソドックスなWebアプリの構成 ○ ゲームバックエンドならではの特徴は後ほど紹介ゲームクライアントとゲームバックエンド 5

Slide 6

Slide 6 text

ゲームクライアントとゲームバックエンド 6

Slide 7

Slide 7 text

ゲームバックエンドの特徴

Slide 8

Slide 8 text

● 新作ローンチ時やイベントリリース時は急激にアクセスが増加 ○ 平時であっても特定の時間帯（日毎の更新タイミング、夕食後など）は増加 ● 高負荷でサーバーがダウンしないよう事前の対策が必須になる ○ 単純にサーバーを増やすだけだとコストが嵩むのでパフォーマンス効率が重要特徴その1 急激な負荷増減 8 このような急上昇を針に例えてスパイクというよ

Slide 9

Slide 9 text

特徴その2 低遅延と通信環境 ● モバイル端末は通信環境が不安定 ○ 自宅 Wi-Fi で快適にプレイする人 ○ 移動車内で接続が安定しない人 ● ゲームは双方向 & 低遅延を要求 ○ 対戦したり、協力したり ○ 相手の通信状況に左右されるとプレイ体験が悪化する ● リアルタイム専用サーバーを構築 ○ ユーザー同士の間に立って通信環境の変化を吸収 ○ ただ中継させるだけでなくゲームロジックを持たせることも 9

Slide 10

Slide 10 text

● マスタデータ ○ キャラクター性能やイベントルールなどのゲーム仕様を定義したデータ ■ ゲームは非常に多機能なのでマスタデータだけでテーブル数が100を超える ● ユーザーデータ ○ ユーザーのプレイ状況を格納するデータ ■ 慎重に扱わないとサービスとしての信用、継続可能性を一気に失う ○ ソーシャル性は高負荷とトレードオフ ■ 非アクティブユーザーを含む数百万のアカウントからフレンドを検索 ● ログデータ ○ ユーザーの行動分析や、不正行為、不具合発生時の調査に利用するデータこれらが運用年数を重ねる毎に、テーブル数もレコード数も増えていく特徴その3 特性の異なるデータの数々 10

Slide 11

Slide 11 text

● コロプラならではですが、ユーザーが遊べない時間を作らない方針で開発をしています特徴その4 オンラインメンテナンス環境 (ノーメンテ) 11

Slide 12

Slide 12 text

使われている技術開発の流れについて

Slide 13

Slide 13 text

13 バックエンドの技術スタック主要なものをピックアップしてみたよ

Slide 14

Slide 14 text

2011 DC → AWS 14 2013 html5 → Unity 2017 AWS → Google Cloud Zend → Laravel 2018 Spanner 2021 TiDB 2023 〜 Web3 / AI 技術の移り変わり 2020 Go / Agones

Slide 15

Slide 15 text

サーバー構成 15

Slide 16

Slide 16 text

16 ゲーム開発の流れ立上げ新規開発プロジェクト運用プロジェクトアップデ｜トベ｜タロ｜ンチアップデ｜ト大きくフェーズに分けると ● 立ち上げ → α → β → ローンチの新規開発プロジェクト ● ローンチ → 運用の運用プロジェクトアップデ｜ト計画実行監視開発企画検証アルファ計画実行監視開発企画検証

Slide 17

Slide 17 text

17 ゲーム開発の流れ立上げ新規開発プロジェクト運用プロジェクト ● 立ち上げから、α、βを通し、繰り返し検証・開発を繰り返しながら企画・ゲームを固めていくベ｜タアルファ計画実行監視開発企画検証アップデ｜トロ｜ンチアップデ｜トアップデ｜ト計画監視開発企画検証実行

Slide 18

Slide 18 text

18 ゲーム開発の流れ新規開発プロジェクト運用プロジェクト ● デバッグ、負荷試験などを綿密に行い、いざローンチ ● コロプラでは LCE (Launch Coordination Engineering) のローンチに向けた負荷試験・サポートのエンジニアチームがいますアップデ｜トアップデ｜トアップデ｜ト計画監視開発企画検証実行立上げアルファ計画監視開発企画検証実行ベ｜タロ｜ンチ

Slide 19

Slide 19 text

19 ゲーム開発の流れ新規開発プロジェクト運用プロジェクトアップデ｜トアップデ｜トアップデ｜ト計画監視開発企画検証実行立上げアルファ計画監視開発企画検証実行ベ｜タロ｜ンチ

Slide 20

Slide 20 text

20 ゲーム開発の流れ新規開発プロジェクト運用プロジェクトアップデ｜トアップデ｜ト ● ローンチ後も、新機能追加、UX向上、パフォーマンス改善などのアップデートを繰り返していく ● 機能開発単位で企画 → 開発 → 検証のサイクルは新規開発同様行っていくアップデ｜ト計画実行監視開発企画検証立上げアルファ計画開発企画検証ベ｜タロ｜ンチ

Slide 21

Slide 21 text

● 新規開発・運用どちらにおいても、多くの職種と連携して開発 ● サーバーエンジニアの領域を飛び越えクライアントや企画に関わるエンジニアも多い 21 開発体制新規開発PJ A 開発初期新規開発PJ B α期運用PJ C プランナーデザイナーゲームエンジニアバックエンドエンジニア - … … … …

Slide 22

Slide 22 text

ここからは実際の働き方をエンジニアから紹介

Slide 23

Slide 23 text

● バックエンドエンジニア約90名 ● ゲーム業界出身：20% ● ゲーム業界以外出身：40% ● プロパー：40％新規/運用開発 23 コロプラのバックエンドエンジニアについてサーバー基盤インフラ

Slide 24

Slide 24 text

新規/運用開発

Slide 25

Slide 25 text

25 自己紹介 ● 2018年新卒入社 ● 新規開発＆運用 ● 今年父親になった文屋勝技術基盤本部バックエンドエンジニア部

Slide 26

Slide 26 text

26 どこにいるバックエンドエンジニアの話？新規開発PJ A 開発初期新規開発PJ B α期運用PJ C プランナーデザイナーゲームエンジニアバックエンドエンジニア - … … … … 　 PJにいる　バックエンドエンジニアの話

Slide 27

Slide 27 text

27 ゲーム開発の流れ立上げ新規開発プロジェクト運用プロジェクトアップデ｜トベ｜タロ｜ンチアップデ｜トアップデ｜ト計画実行監視開発企画検証アルファ計画実行監視開発企画検証 ● 新規開発・運用に分けて、それぞれお話しします

Slide 28

Slide 28 text

28 新規開発立上げ新規開発プロジェクト運用プロジェクトベ｜タアルファ計画実行監視開発企画検証アップデ｜トロ｜ンチアップデ｜トアップデ｜ト計画監視開発企画検証実行 ● 0から1をすることが多い ● 短期間で一気に作る

Slide 29

Slide 29 text

新規開発のサイクル 29

Slide 30

Slide 30 text

30 1. 企画の仕様を一緒に考えるデザイナークライアントバックエンドプランナー今週は必殺技を作ろう！

Slide 31

Slide 31 text

31 1. 企画の仕様を一緒に考えるデザイナークライアントバックエンドプランナーキャラの性格的に派手なエフェクトにしたい！今週は必殺技を作ろう！遠距離攻撃にしてテクニック重視にするのはどう？ヒット感のために音を重たいものにしたいね

Slide 32

Slide 32 text

32 2. 企画の仕様を考えるクライアントに送るデータの形を相談しに行こう必殺技に必要なデータは？必殺技名・再生モーション・威力・消費ポイント...etc DBのテーブル設計はこれを親にして残りを子にするか...

Slide 33

Slide 33 text

33 3. 手を動かす・・・ッターンカタカタ

Slide 34

Slide 34 text

34 4. 繋ぎ合わせる開発環境でデータ返すようにしたよモーション作ったよ

Slide 35

Slide 35 text

35 5. みんなでプレイするカメラはもっと上からがいいなこの手順だと発動しない... 爽快感のために音を変えたいこの位置だと指でボタン隠れるね

Slide 36

Slide 36 text

36 6. ブラッシュアップして完成ボタンの位置を変更したよバグ直したよ

Slide 37

Slide 37 text

運用 37

Slide 38

Slide 38 text

38 運用新規開発プロジェクト運用プロジェクトアップデ｜トアップデ｜トアップデ｜ト計画実行監視開発企画検証立上げアルファ計画開発企画検証ベ｜タロ｜ンチ ● 1から10をすることが多い ● 負荷監視 ● エラー調査＆対応 ● お問い合わせ調査＆対応

Slide 39

Slide 39 text

負荷監視 39 ● 常に監視しているプログラムがSlackに通知 ● 負荷が上がるタイミングでは人による監視

Slide 40

Slide 40 text

負荷監視 40 ● アプリケーションサーバー・データベースなどの負荷をみる ○ CPU使用率・メモリ使用率・レスポンスタイム・書き込みレイテンシなど

Slide 41

Slide 41 text

41 エラー調査＆対応 ● エラーが検出されるとSlackに通知 ● ログを見たり、コードを追ったりして調査＆対応

Slide 42

Slide 42 text

42 お問い合わせ調査＆対応 ● 特定のユーザーで起きているエラーの調査＆対応 ● 正常系で処理してしまった不具合の調査＆対応アイテム合成をしようとしてもエラーが出て出来ない... ログボが何度でも受け取れるけど不具合じゃないかしら？

Slide 43

Slide 43 text

43 まとめ新規開発 ● 0から1をすることが多い ● 短期間で一気に作る運用 ● 1を10にすることが多い ● 負荷監視 ● エラー調査＆対応 ● お問い合わせ調査＆対応

Slide 44

Slide 44 text

サーバー基盤

Slide 45

Slide 45 text

氏名　：部署　：第3バックエンドエンジニア部自己紹介 Y.N. ● 2018年に新卒入社 ● 最近までゲームタイトル所属のバックエンドエンジニアをやっていた ● 現在はLCEチームで新作のお手伝いやライブラリの整備などをやっているサーバー基盤グループ LCEチーム

Slide 46

Slide 46 text

● サーバー基盤グループの中の1チーム ○ 様々なプロジェクトに広く関わっていく横断的なチーム ● その中でも特に専門とする役割ごとにチームが分かれている ○ SRE（長期運用） ○ LCE（新作ローンチ） ○ PE（開発運営の環境整備と提案） ○ RTPE（マルチ開発/配信基盤） LCE (Launch Coordination Engineering) チーム LCEチーム SREチーム RTPEチーム PEチームサーバー基盤グループ

Slide 47

Slide 47 text

LCE (Launch Coordination Engineering) チーム新規開発プロジェクト運用プロジェクトアップデ｜トアップデ｜トアップデ｜ト計画監視開発企画検証実行立上げアルファ計画監視開発企画検証実行ベ｜タロ｜ンチここを成功させる！

Slide 48

Slide 48 text

LCE (Launch Coordination Engineering) チーム新規開発プロジェクト運用プロジェクトアップデ｜トアップデ｜トアップデ｜ト計画監視開発企画検証実行立上げアルファ計画監視開発企画検証実行ベ｜タロ｜ンチ ● 負荷試験 ● スケジュール管理 ● コミュニケーションの橋渡し ● 社内ライブラリの整備 ● 新作チームのお手伝い ● 全社向けのシステム開発ローンチへ向けてそれ以外の業務

Slide 49

Slide 49 text

ローンチまでのスケジュールローンチを控えたプロジェクトに参加！ローンチへ向けた準備を進める負荷試験実施新作ローンチ！数ヶ月一年 ≀ ● ゲームの仕様 / システム構成の把握 ● 負荷試験の準備 ○ 環境構築 ○ 試験用プログラム作成

Slide 50

Slide 50 text

ローンチを控えたプロジェクトに参加！ローンチへ向けた準備を進める負荷試験実施新作ローンチ！このあたりのお話をします！数ヶ月一年 ≀ ローンチまでのスケジュール ● ゲームの仕様 / システム構成の把握 ● 負荷試験の準備 ○ 環境構築 ○ 試験用プログラム作成

Slide 51

Slide 51 text

一週間の働き方〜今週は負荷試験をするぞ！編〜

Slide 52

Slide 52 text

月曜日　負荷試験の準備　・試験したい環境やコードがちゃんと用意できている？　▷ 最新コードの取り込み・プログラムは問題なく動作する？　▷ 最小限の構成で動作確認・実施手順に不備はない？・特に注視しておきたいところは？　▷ 手順書 / チェックシートの見直し

Slide 53

Slide 53 text

火曜日　負荷試験の実施試験環境の準備 ⇩ 試験用のプログラムを実行 ⇩ ログやメトリクスをチェックしながら十分なデータが取れるまで数時間負荷をかけ続ける ⇩ お片付け

Slide 54

Slide 54 text

水曜日　結果の精査たまに特定のリクエストでエラーになっている

Slide 55

Slide 55 text

木曜日　問題点の修正問題点の解決へ向けて行動しました ● すぐに直せそう ○ 直す ● ゲーム側の処理に問題がありそう ○ 開発チームに共有 ● 通信側に問題がありそう ○ インフラチームに共有 ● よくわからない ○ 各所に相談しながら原因調査ユーザーの動きをうまく模倣できていない！原因

Slide 56

Slide 56 text

金曜日　修正確認再度負荷試験を実施しました ● 対応を取り込んで、発生していた問題が修正されたことを確認 ● 他にも気になるところがいくつか見つかる ● 来週はそれらの問題に取り組んでいこう！しかし...

Slide 57

Slide 57 text

サーバー基盤 ● 様々なプロジェクトに横断的に関わっていく ● 専門領域ごとにチームが分かれている LCEチーム ● 新作タイトルのローンチを成功させる ● 負荷試験 / ライブラリ整備 / 開発支援 ● アプリケーションのボトルネックを調査して解消するローンチ前のとある一週間の働き方について紹介させていただきました。まとめ

Slide 58

Slide 58 text

インフラ

Slide 59

Slide 59 text

● T.U. ● 株式会社コロプラ2016年中途入社  ● バックエンドエンジニア部に所属（2016~2021）  ○ サーバーエンジニアとしてアプリケーション開発を担当  ● インフラストラクチャ部に所属（2021~）  ○ GKEタイトルのインフラ運用と改善を担当  自己紹介

Slide 60

Slide 60 text

● インフラ業務について ○ インフラ体制 ○ 作業方針 ○ ゲーム開発向けの作業 ○ インフラ環境強化作業 ● 実際の一週間の働き方 ● インフラ業務の特徴本日の内容

Slide 61

Slide 61 text

インフラ業務についてインフラストラクチャ部社内インフラゲームインフラ VM GKE ● 社内インフラ ○ 社内システムとネットワークなどのインフラ環境管理 ● ゲームインフラ（VM） ○ VMタイトルのサーバー環境構築及び運用 ● ゲームインフラ（GKE） ○ GKEタイトルのサーバー環境構築及び運用 ● インフラ体制私

Slide 62

Slide 62 text

インフラ業務について ● 安定 ○ サービスダウンを発生させない ○ サーバー障害が発生した時にすぐ通知が届く、すぐ対処できる ● 効率 ○ 環境構築のスピードアップ ○ 開発効率向上向けの運用改善 ● コスパ ○ インフラコストを最適化 ● 作業方針安定効率コスパ

Slide 63

Slide 63 text

63 インフラ業務について立上げ新規開発プロジェクト運用プロジェクトアップデ｜トベ｜タロ｜ンチアップデ｜トアップデ｜ト計画実行監視開発企画検証アルファ計画実行監視開発企画検証 ● ゲーム開発向けの作業諸々初期設定開発環境構築環境設定最適化運用仕組み改善本番環境構築監視環境構築負荷監視、障害対応、運用改善本番環境スペック最適化負荷試験環境構築インフラ構成設計 ※それと開発段階関係なく、権限付与、サーバー設定変更や証明書更新など細かい作業もある

Slide 64

Slide 64 text

64 インフラ業務について ● インフラ環境強化作業インフラ構成最新化運用改善 … Multiクラスタ負荷分散 … x NEGs 開発環境IP制限 Header認証 open-match導入 SpannerAutoScaler導入インフラ定期ジョブ

Slide 65

Slide 65 text

実際の一週間の働き方今週の温度感 ● 開発中タイトルの負荷試験環境の引き渡し（優先度高い） ○ 残り作業は主に監視系の導入とロギング出力周りの対応 ● 運用中タイトルの開発と本番環境のRedis移行（優先度やや高い） ○ Redisを可用性とコスパのバランスを取るためにMemoryStore Redisに移行 ● 開発中タイトルの Agones 系バージョン更新（優先度普通） ○ GKEバージョンの更新に伴って、Agonesも対応するバージョンに更新する ● 開発中タイトルの Gitlab Runner 改善（優先度普通） ○ イメージビルドのジョブが静的解析のジョブを待つこと多く効率が悪い ● 手作業を自動化させる（優先度低い） ○ K8sカスタムリソースで実装するか、Temporal Workﬂowで実装するか検討中

Slide 66

Slide 66 text

実際の一週間の働き方月曜日週末の負荷確認して本番スペック調整した開発中タイトルから証明書更新依頼がきたので証明書発行して開発環境に反映した負荷試験環境構築を続行、今日は各クラスタにメトリクス収集と保存用のツールをインストールして、Grafana ダッシュボードでちゃんと表示できるところまで Jenkinsバージョン更新依頼がきたので、火曜日の14時から実施することになった開発環境MemoryStore Redis移行に関して、水曜日の朝10:30から実施することになった

Slide 67

Slide 67 text

実際の一週間の働き方火曜日負荷試験環境構築を続行、今日はロギング除外設定したり、 BigQueryに転送設定したりした最低限の動作は問題なさそうなので、負荷試験を担当するLCEチームに権限付与して環境を引き渡した予定通り14時からJenkinsバージョン更新作業自動化をTemporal Workﬂow で開発することを決め、ひとまず最新の golang sdkを使ってテスト用のコードを書いてみた本番podのcpu使用率に異常発生、nodeが怪しいので該当nodeをdrainして解消翌日移行予定の開発環境 MemoryStore RedisインスタンスをTerraformで起動し、最低限の動作確認を実施した

Slide 68

Slide 68 text

実際の一週間の働き方水曜日予定通り10:30から開発環境の Redisを動作影響なしで MemoryStore Redisに移行した開発チームと相談し、開発環境 Redis移行後一日以上は様子を見ることになったため、本番環境移行を翌日の17時から実施するよう調整した開発チームと連携してAgones のバージョン更新と動作確認を実施した負荷試験環境でリージョンを跨いで InternalLB経由でクラスタ間通信する時に疎通しない問題を調査し、グローバルアクセスを許可する設定が足りないことが判明し、チャート側に設定追加で解消した翌日移行予定の本番環境 MemoryStore RedisインスタンスをTerraformで起動し、最低限の動作確認を実施した

Slide 69

Slide 69 text

負荷試験環境に Datadog APMを導入してほしいという依頼を受けた実際の一週間の働き方木曜日開発チームから明日プレイ会行うため、dev 環境のサーバー台数をあげたい依頼を受けた予定通り17:00から本番環境の redisをサービス影響なしで MemoryStore Redisに移行した Temporal Workﬂow開発に関して、Activityの実装を進めてみた Gitlab Runnerのjobが頻繁に詰まる問題があったため、イメージビルドと静的解析は別Runnerで実行されるようにした dev環境のサーバー台数を調整し、念のため監視系のスペックもあげた

Slide 70

Slide 70 text

実際の一週間の働き方金曜日負荷試験環境にDatadog APM導入した MemoryStore Redis移行作業が終わったので、前のRedisインスタンスのconnection状況見て、問題ないので削除したタスク確認会で今週のまとめした本番監視系のノードプールをスペックダウンできそうなので次のコスト削減プランを立てた

Slide 71

Slide 71 text

インフラ業務の特徴サーバーエンジニアの業務と比較すると、私が思った幾つかの特徴 ● 同時に複数タイトルのタスクを持つ、その中から優先度決めて進む ○ サーバーエンジニアだと一つのタイトルの業務だけに絡むことがほとんど ● 急ぎな作業依頼が来て今の作業を中断することがよくある ○ サーバーエンジニアだと長い時間に開発作業に集中することが多い ● 本番環境でのオペレーションを慎重にやらないと障害に繋がる ○ サーバーエンジニアだと新機能新イベントなどリリースする時にドキドキ ● 権限とIP制限周りの作業でセキュリティ意識が大事 ○ サーバーエンジニアだと機密情報の扱いやチート対応などのセキュリティ意識が大事 ● 攻められる技術の方向が幅広い ○ サーバーエンジニアだとプログラミング知識を磨くことが多い