Tweet
Tweet

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 Workflowで実装するか検討中

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

実際の一週間の働き方 火曜日 負荷試験環境構築を続行、今日は ロギング除外設定したり、 BigQueryに転送設定したりした 最低限の動作は問題なさ そうなので、負荷試験を担 当するLCEチームに権限 付与して環境を引き渡した 予定通り14時か らJenkinsバー ジョン更新 作業自動化をTemporal Workflow で開発することを決め、ひとまず 最新の 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 Workflow開発に関し て、Activityの実装を進めてみた Gitlab Runnerのjobが頻繁に詰 まる問題があったため、イメージビ ルドと静的解析は別Runnerで実 行されるようにした dev環境のサーバー台数を 調整し、念のため監視系の スペックもあげた

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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