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

Transcript

1. ゲームを支える バックエンドエンジニア のリアルを公開！
2. ゲームバックエンドについてよく聞かれること • ゲームのバックエンドってどのように動いているのか • ゲームのバックエンドの特徴 • どのような技術が使われているのか • ゲーム開発の体制や流れについて これらにお答えしつつ 実際にバックエンドエンジニアがどのように働いているのかを 紹介させていただきます！
3. 3 ゲームタイトルの裏側について
4. ゲームクライアント と ゲームバックエンド クライアント 4
5. • 目に見えない体験を提供 ◦ “いつでも” 遊べる！ ◦ “いつまでも” 遊べる！ • ユーザー体験を追求するが あくまでWebアプリケーションの延長上 ◦ APIサーバーがあってその裏にDBがあって ◦ 非常にオーソドックスなWebアプリの構成 ◦ ゲームバックエンドならではの特徴は 後ほど紹介 ゲームクライアント と ゲームバックエンド 5
6. ゲームクライアント と ゲームバックエンド 6
7. ゲームバックエンド の特徴
8. • 新作ローンチ時やイベントリリース時は急激にアクセスが増加 ◦ 平時であっても特定の時間帯（日毎の更新タイミング、夕食後など）は増加 • 高負荷でサーバーがダウンしないよう事前の対策が必須になる ◦ 単純にサーバーを増やすだけだとコストが嵩むのでパフォーマンス効率が重要 特徴その1 急激な負荷増減 8 このような急上昇を 針に例えてスパイクというよ
9. 特徴その2 低遅延と通信環境 • モバイル端末は通信環境が不安定 ◦ 自宅 Wi-Fi で快適にプレイする人 ◦ 移動車内で接続が安定しない人 • ゲームは 双方向 & 低遅延 を要求 ◦ 対戦したり、協力したり ◦ 相手の通信状況に左右されると プレイ体験が悪化する • リアルタイム専用サーバーを構築 ◦ ユーザー同士の間に立って 通信環境の変化を吸収 ◦ ただ中継させるだけでなく ゲームロジックを持たせることも 9
10. • マスタデータ ◦ キャラクター性能やイベントルールなどのゲーム仕様を定義したデータ ▪ ゲームは非常に多機能なのでマスタデータだけでテーブル数が100を超える • ユーザーデータ ◦ ユーザーのプレイ状況を格納するデータ ▪ 慎重に扱わないとサービスとしての信用、継続可能性を一気に失う ◦ ソーシャル性は高負荷とトレードオフ ▪ 非アクティブユーザーを含む数百万のアカウントからフレンドを検索 • ログデータ ◦ ユーザーの行動分析や、不正行為、不具合発生時の調査に利用するデータ これらが運用年数を重ねる毎に、テーブル数もレコード数も増えていく 特徴その3 特性の異なるデータの数々 10
11. • コロプラならではですが、ユーザーが遊べない時間を作らない方針で 開発をしています 特徴その4 オンラインメンテナンス環境 (ノーメンテ) 11
12. 使われている技術 開発の流れについて
13. 13 バックエンドの技術スタック 主要なものを ピックアップしてみたよ
14. 2011 DC → AWS 14 2013 html5 → Unity 2017 AWS → Google Cloud Zend → Laravel 2018 Spanner 2021 TiDB 2023 〜 Web3 / AI 技術の移り変わり 2020 Go / Agones
15. サーバー構成 15
16. 16 ゲーム開発の流れ 立 上 げ 新規開発プロジェクト 運用プロジェクト ア ッ プ デ ｜ ト ベ ｜ タ ロ ｜ ン チ ア ッ プ デ ｜ ト 大きくフェーズに分けると • 立ち上げ → α → β → ローンチ の 新規開発プロジェクト • ローンチ → 運用 の 運用プロジェクト ア ッ プ デ ｜ ト 計画 実行 監視 開 発 企 画 検 証 ア ル フ ァ 計画 実行 監視 開 発 企 画 検 証
17. 17 ゲーム開発の流れ 立 上 げ 新規開発プロジェクト 運用プロジェクト • 立ち上げから、α、βを通し、繰り返し検証・開発を繰り返しながら 企画・ゲームを固めていく ベ ｜ タ ア ル フ ァ 計画 実行 監視 開 発 企 画 検 証 ア ッ プ デ ｜ ト ロ ｜ ン チ ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト 計画 監視 開 発 企 画 検 証 実行
18. 18 ゲーム開発の流れ 新規開発プロジェクト 運用プロジェクト • デバッグ、負荷試験などを綿密に行い、いざローンチ • コロプラでは LCE (Launch Coordination Engineering) の ローンチに向けた負荷試験・サポートのエンジニアチームがいます ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト 計画 監視 開 発 企 画 検 証 実行 立 上 げ ア ル フ ァ 計画 監視 開 発 企 画 検 証 実行 ベ ｜ タ ロ ｜ ン チ
19. 19 ゲーム開発の流れ 新規開発プロジェクト 運用プロジェクト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト 計画 監視 開 発 企 画 検 証 実行 立 上 げ ア ル フ ァ 計画 監視 開 発 企 画 検 証 実行 ベ ｜ タ ロ ｜ ン チ
20. 20 ゲーム開発の流れ 新規開発プロジェクト 運用プロジェクト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト • ローンチ後も、新機能追加、UX向上、パフォーマンス改善 などの アップデートを繰り返していく • 機能開発単位で 企画 → 開発 → 検証 のサイクルは新規開発同様行っていく ア ッ プ デ ｜ ト 計画 実行 監視 開 発 企 画 検 証 立 上 げ ア ル フ ァ 計画 開 発 企 画 検 証 ベ ｜ タ ロ ｜ ン チ
21. • 新規開発・運用どちらにおいても、多くの職種と連携して開発 • サーバーエンジニアの領域を飛び越え クライアントや企画に関わるエンジニアも多い 21 開発体制 新規開発PJ A 開発初期 新規開発PJ B α期 運用PJ C プランナー デザイナー ゲームエンジニア バックエンドエンジニア - … … … …
22. ここからは 実際の働き方を エンジニアから紹介
23. • バックエンドエンジニア 約90名 • ゲーム業界出身：20% • ゲーム業界以外出身：40% • プロパー：40％ 新規/運用 開発 23 コロプラのバックエンドエンジニアについて サーバー 基盤 インフラ
24. 新規/運用開発
25. 25 自己紹介 • 2018年新卒入社 • 新規開発＆運用 • 今年父親になった 文屋 勝 技術基盤本部 バックエンドエンジニア部
26. 26 どこにいるバックエンドエンジニアの話？ 新規開発PJ A 開発初期 新規開発PJ B α期 運用PJ C プランナー デザイナー ゲームエンジニア バックエンドエンジニア - … … … … 　 PJにいる 　 バックエンドエンジニアの話
27. 27 ゲーム開発の流れ 立 上 げ 新規開発プロジェクト 運用プロジェクト ア ッ プ デ ｜ ト ベ ｜ タ ロ ｜ ン チ ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト 計画 実行 監視 開 発 企 画 検 証 ア ル フ ァ 計画 実行 監視 開 発 企 画 検 証 • 新規開発・運用に分けて、それぞれお話しします
28. 28 新規開発 立 上 げ 新規開発プロジェクト 運用プロジェクト ベ ｜ タ ア ル フ ァ 計画 実行 監視 開 発 企 画 検 証 ア ッ プ デ ｜ ト ロ ｜ ン チ ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト 計画 監視 開 発 企 画 検 証 実行 • 0から1をすることが多い • 短期間で一気に作る
29. 新規開発のサイクル 29
30. 30 1. 企画の仕様を一緒に考える デザイナー クライアント バックエンド プランナー 今週は 必殺技 を作ろう！
31. 31 1. 企画の仕様を一緒に考える デザイナー クライアント バックエンド プランナー キャラの性格的に 派手なエフェクト にしたい！ 今週は 必殺技 を作ろう！ 遠距離攻撃にして テクニック重視に するのはどう？ ヒット感のために 音を重たいものに したいね
32. 32 2. 企画の仕様を考える クライアントに送る データの形を相談しに行こう 必殺技に必要なデータは？ 必殺技名・再生モーション・ 威力・消費ポイント...etc DBのテーブル設計は これを親にして 残りを子にするか...
33. 33 3. 手を動かす ・・・ ッターン カタカタ
34. 34 4. 繋ぎ合わせる 開発環境で データ返すよう にしたよ モーション 作ったよ
35. 35 5. みんなでプレイする カメラは もっと上からがいいな この手順だと 発動しない... 爽快感のために 音を変えたい この位置だと 指でボタン隠れるね
36. 36 6. ブラッシュアップして完成 ボタンの位置を 変更したよ バグ直したよ
37. 運用 37
38. 38 運用 新規開発プロジェクト 運用プロジェクト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト 計画 実行 監視 開 発 企 画 検 証 立 上 げ ア ル フ ァ 計画 開 発 企 画 検 証 ベ ｜ タ ロ ｜ ン チ • 1から10をすることが多い • 負荷監視 • エラー調査＆対応 • お問い合わせ調査＆対応
39. 負荷監視 39 • 常に監視しているプログラムがSlackに通知 • 負荷が上がるタイミングでは人による監視
40. 負荷監視 40 • アプリケーションサーバー・データベースなどの負荷をみる ◦ CPU使用率・メモリ使用率・レスポンスタイム・書き込みレイテンシなど
41. 41 エラー調査＆対応 • エラーが検出されるとSlackに通知 • ログを見たり、コードを追ったりして調査＆対応
42. 42 お問い合わせ調査＆対応 • 特定のユーザーで起きているエラーの調査＆対応 • 正常系で処理してしまった不具合の調査＆対応 アイテム合成をしようとしても エラーが出て出来ない... ログボが何度でも受け取れるけど 不具合じゃないかしら？
43. 43 まとめ 新規開発 • 0から1をすることが多い • 短期間で一気に作る 運用 • 1を10にすることが多い • 負荷監視 • エラー調査＆対応 • お問い合わせ調査＆対応
44. サーバー基盤
45. 氏名　 ： 部署　 ： 第3バックエンドエンジニア部 自己紹介 Y.N. • 2018年に新卒入社 • 最近までゲームタイトル所属のバックエンドエ ンジニアをやっていた • 現在はLCEチームで新作のお手伝いやライブラ リの整備などをやっている サーバー基盤グループ LCEチーム
46. • サーバー基盤グループの中の1チーム ◦ 様々なプロジェクトに広く関わってい く横断的なチーム • その中でも特に専門とする役割ごと にチームが分かれている ◦ SRE（長期運用） ◦ LCE（新作ローンチ） ◦ PE（開発運営の環境整備と提案） ◦ RTPE（マルチ開発/配信基盤） LCE (Launch Coordination Engineering) チーム LCEチーム SREチーム RTPEチーム PEチーム サーバー基盤グループ
47. LCE (Launch Coordination Engineering) チーム 新規開発プロジェクト 運用プロジェクト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト 計画 監視 開 発 企 画 検 証 実行 立 上 げ ア ル フ ァ 計画 監視 開 発 企 画 検 証 実行 ベ ｜ タ ロ ｜ ン チ ここを成功させる！
48. LCE (Launch Coordination Engineering) チーム 新規開発プロジェクト 運用プロジェクト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト 計画 監視 開 発 企 画 検 証 実行 立 上 げ ア ル フ ァ 計画 監視 開 発 企 画 検 証 実行 ベ ｜ タ ロ ｜ ン チ • 負荷試験 • スケジュール管理 • コミュニケーションの橋渡し • 社内ライブラリの整備 • 新作チームのお手伝い • 全社向けのシステム開発 ローンチへ向けて それ以外の業務
49. ローンチまでのスケジュール ローンチを控えたプロジェクトに参加！ ローンチへ向けた準備を進める 負荷試験実施 新作ローンチ！ 数 ヶ 月 一 年 ≀ • ゲームの仕様 / システム構成の把握 • 負荷試験の準備 ◦ 環境構築 ◦ 試験用プログラム作成
50. ローンチを控えたプロジェクトに参加！ ローンチへ向けた準備を進める 負荷試験実施 新作ローンチ！ このあたりの お話をします！ 数 ヶ 月 一 年 ≀ ローンチまでのスケジュール • ゲームの仕様 / システム構成の把握 • 負荷試験の準備 ◦ 環境構築 ◦ 試験用プログラム作成
51. 一週間の働き方 〜今週は負荷試験をするぞ！編〜
52. 月曜日　負荷試験の準備 　・試験したい環境やコード がちゃんと用意できている？ 　▷ 最新コードの取り込み ・プログラムは問題なく動作する？ 　▷ 最小限の構成で動作確認 ・実施手順に不備はない？ ・特に注視しておきたいところは？ 　▷ 手順書 / チェックシートの見直し
53. 火曜日　負荷試験の実施 試験環境の準備 ⇩ 試験用のプログラムを実行 ⇩ ログやメトリクスをチェック しながら十分なデータが取れるまで 数時間負荷をかけ続ける ⇩ お片付け
54. 水曜日　結果の精査 たまに特定のリクエスト でエラーになっている
55. 木曜日　問題点の修正 問題点の解決へ向けて行動しました • すぐに直せそう ◦ 直す • ゲーム側の処理に問題がありそう ◦ 開発チームに共有 • 通信側に問題がありそう ◦ インフラチームに共有 • よくわからない ◦ 各所に相談しながら原因調査 ユーザーの動きをうまく 模倣できていない！ 原 因
56. 金曜日　修正確認 再度負荷試験を実施しました • 対応を取り込んで、発生していた 問題が修正されたことを確認 • 他にも気になるところがいくつか 見つかる • 来週はそれらの問題に取り組んで いこう！ しかし...
57. サーバー基盤 • 様々なプロジェクトに横断的に関わっていく • 専門領域ごとにチームが分かれている LCEチーム • 新作タイトルのローンチを成功させる • 負荷試験 / ライブラリ整備 / 開発支援 • アプリケーションのボトルネックを調査して解消する ローンチ前のとある一週間の働き方について紹介させていただきました。 まとめ
58. インフラ
59. • T.U. • 株式会社コロプラ2016年中途入社
 • バックエンドエンジニア部に所属（2016~2021）
 ◦ サーバーエンジニアとしてアプリケーション開発を担当
 • インフラストラクチャ部に所属（2021~）
 ◦ GKEタイトルのインフラ運用と改善を担当
 自己紹介
60. • インフラ業務について ◦ インフラ体制 ◦ 作業方針 ◦ ゲーム開発向けの作業 ◦ インフラ環境強化作業 • 実際の一週間の働き方 • インフラ業務の特徴 本日の内容
61. インフラ業務について インフラストラクチャ部 社内インフラ ゲームインフラ VM GKE • 社内インフラ ◦ 社内システムとネットワークな どのインフラ環境管理 • ゲームインフラ（VM） ◦ VMタイトルのサーバー環境構築 及び運用 • ゲームインフラ（GKE） ◦ GKEタイトルのサーバー環境構 築及び運用 • インフラ体制 私
62. インフラ業務について • 安定 ◦ サービスダウンを発生させない ◦ サーバー障害が発生した時にす ぐ通知が届く、すぐ対処できる • 効率 ◦ 環境構築のスピードアップ ◦ 開発効率向上向けの運用改善 • コスパ ◦ インフラコストを最適化 • 作業方針 安定 効率 コス パ
63. 63 インフラ業務について 立 上 げ 新規開発プロジェクト 運用プロジェクト ア ッ プ デ ｜ ト ベ ｜ タ ロ ｜ ン チ ア ッ プ デ ｜ ト ア ッ プ デ ｜ ト 計画 実行 監視 開 発 企 画 検 証 ア ル フ ァ 計画 実行 監視 開 発 企 画 検 証 • ゲーム開発向けの作業 諸々初期設定 開発環境構築 環境設定最適化 運用仕組み改善 本番環境構築 監視環境構築 負荷監視、障害対応、運用改善 本番環境スペック最適化 負荷試験環境構築 インフラ構成設計 ※それと開発段階関係なく、権限付与、サーバー設定変更や証明書更新など細かい作業もある
64. 64 インフラ業務について • インフラ環境強化作業 インフラ構成最新化 運用改善 … Multiクラスタ負荷分散 … x NEGs 開発環境IP制限 Header認証 open-match導入 SpannerAutoScaler導入 インフラ定期ジョブ
65. 実際の一週間の働き方 今週の温度感 • 開発中タイトルの負荷試験環境の引き渡し（優先度高い） ◦ 残り作業は主に監視系の導入とロギング出力周りの対応 • 運用中タイトルの開発と本番環境のRedis移行（優先度やや高い） ◦ Redisを可用性とコスパのバランスを取るためにMemoryStore Redisに移行 • 開発中タイトルの Agones 系バージョン更新（優先度普通） ◦ GKEバージョンの更新に伴って、Agonesも対応するバージョンに更新する • 開発中タイトルの Gitlab Runner 改善（優先度普通） ◦ イメージビルドのジョブが静的解析のジョブを待つこと多く効率が悪い • 手作業を自動化させる（優先度低い） ◦ K8sカスタムリソースで実装するか、Temporal Workflowで実装するか検討中
66. 実際の一週間の働き方 月曜日 週末の負荷確認して本 番スペック調整した 開発中タイトルから証 明書更新依頼がきたの で証明書発行して開発 環境に反映した 負荷試験環境構築を続行、今日は各クラスタにメトリク ス収集と保存用のツールをインストールして、Grafana ダッシュボードでちゃんと表示できるところまで Jenkinsバージョン更新 依頼がきたので、火曜日 の14時から実施すること になった 開発環境MemoryStore Redis移行に関して、水曜 日の朝10:30から実施す ることになった
67. 実際の一週間の働き方 火曜日 負荷試験環境構築を続行、今日は ロギング除外設定したり、 BigQueryに転送設定したりした 最低限の動作は問題なさ そうなので、負荷試験を担 当するLCEチームに権限 付与して環境を引き渡した 予定通り14時か らJenkinsバー ジョン更新 作業自動化をTemporal Workflow で開発することを決め、ひとまず 最新の golang sdkを使ってテス ト用のコードを書いてみた 本番podのcpu使用率に異 常発生、nodeが怪しいの で該当nodeをdrainして解 消 翌日移行予定の開発環境 MemoryStore Redisインスタ ンスをTerraformで起動し、最低 限の動作確認を実施した
68. 実際の一週間の働き方 水曜日 予定通り10:30から開発環境の Redisを動作影響なしで MemoryStore Redisに移行した 開発チームと相談し、開発環境 Redis移行後一日以上は様子 を見ることになったため、本番 環境移行を翌日の17時から実 施するよう調整した 開発チームと連携してAgones のバージョン更新と動作確認を 実施した 負荷試験環境でリージョンを跨いで InternalLB経由でクラスタ間通信する時に疎 通しない問題を調査し、グローバルアクセスを 許可する設定が足りないことが判明し、チャー ト側に設定追加で解消した 翌日移行予定の本番環境 MemoryStore Redisインスタ ンスをTerraformで起動し、最低 限の動作確認を実施した
69. 負荷試験環境に Datadog APMを導入し てほしいという依頼を受け た 実際の一週間の働き方 木曜日 開発チームから明日プ レイ会行うため、dev 環境のサーバー台数を あげたい依頼を受けた 予定通り17:00から本番環境の redisをサービス影響なしで MemoryStore Redisに移行した Temporal Workflow開発に関し て、Activityの実装を進めてみた Gitlab Runnerのjobが頻繁に詰 まる問題があったため、イメージビ ルドと静的解析は別Runnerで実 行されるようにした dev環境のサーバー台数を 調整し、念のため監視系の スペックもあげた
70. 実際の一週間の働き方 金曜日 負荷試験環境にDatadog APM導入した MemoryStore Redis移行作業が 終わったので、前のRedisインス タンスのconnection状況見て、 問題ないので削除した タスク確認会で今週のま とめした 本番監視系のノードプー ルをスペックダウンでき そうなので次のコスト削 減プランを立てた
71. インフラ業務の特徴 サーバーエンジニアの業務と比較すると、私が思った幾つかの特徴 • 同時に複数タイトルのタスクを持つ、その中から優先度決めて進む ◦ サーバーエンジニアだと一つのタイトルの業務だけに絡むことがほとんど • 急ぎな作業依頼が来て今の作業を中断することがよくある ◦ サーバーエンジニアだと長い時間に開発作業に集中することが多い • 本番環境でのオペレーションを慎重にやらないと障害に繋がる ◦ サーバーエンジニアだと新機能新イベントなどリリースする時にドキドキ • 権限とIP制限周りの作業でセキュリティ意識が大事 ◦ サーバーエンジニアだと機密情報の扱いやチート対応などのセキュリティ意識が大事 • 攻められる技術の方向が幅広い ◦ サーバーエンジニアだとプログラミング知識を磨くことが多い