オンラインゲームのシステム全体像 - コロプラ 2026年度 新卒研修

コロプラの2026年度新卒研修で、バックエンドエンジニア向けに実施した「オンラインゲームのシステム全体像」の資料です。
コロプラのゲームを構成するコンポーネントの名前と役割を、VM・GKE・Cloud Run の3つの実行基盤の変遷とあわせて紹介しています。

Transcript

1. オンラインゲームの システム全体像 サーバー基盤グループ LCEチーム 仲山 2026
2. はじめに この研修では、コロプラのゲームを構成するシステムについて説明します。 最初に全体像を確認し、それぞれの構成要素について一つずつ見ていきます。 本日の研修を通して... • • • • サービスの全体像 それぞれの構成要素の名前と役割 通信時の処理の流れ これまでの技術的な変遷や負債解消の歴史 これらを 完全に理解 していただきます！ 2
3. コロプラのゲームシステム構成 アプリケーションの実行基盤の違いによって3つに分けられる • • • VM ◦ 白猫プロジェクト ◦ 黒猫のウィズ Kubernetes (k8s / GKE) ◦ ドラゴンクエストウォーク ◦ フェスバ+ Cloud Run ◦ 神魔狩りのツクヨミ 一番代表的な GKE 環境を例にして説明します！ 3
4. ゲームシステムを構成する主要コンポーネント ゲームシステムは様々なコンポーネントが組み合わさって構成されています。 アーキテクチャ図や業務中の会話でよく出てくるキーワードをなんとなく理解できる ようになりましょう！ Client LB App Img CDN Queue Batch DB KVS Proxy GS Builder Tool Job Monitoring Logging CI / CD User Search 4
5. まずは全体のアーキテクチャ図を 見てみましょう！ 5
7. 主要コンポーネント 7
10. Client • ゲームクライアント ◦ iOS app ◦ Android app ◦ PC (Steam) ◦ ブラウザ • クライアントエンジニアが主に Unity で作成 • ネットワーク経由でサーバーにアクセス 10
11. LB • • • ロードバランサー 複数のサーバーにリクエストを振り分けて分散させる 負荷の偏りを少なくし、台数調整やデプロイをやりやすくする 11
12. App • • • • • Game API Server バックエンドエンジニアの主戦場 Client からのリクエストを受け取り、データの取得や更新を行う 開発言語は PHP を利用し、最近は主に Laravel フレームワークを利用 Nginx + PHP-FPM にて動作 12
13. Img • • • • • Static File Server Unity のアセットデータやゲーム内で使用する画像ファイルを提供 /public/static 以下のファイルを返すだけの HTTP サーバーのようなイメージ 最近は Img サーバーは構築せず、AWS の Amazon S3 を利用 クライアントは CDN（後述）経由でデータを取得する 13
14. CDN • • • • Content Delivery Network 低遅延で高速なコンテンツ配信を実現 Img が提供しているデータに対して適用 データ更新時に変更を反映させるための手順が必要になったりするので要注意 ◦ ◦ キャッシュパージ クエリパラメータによるバージョニング 14
15. Queue • • Queue Worker / Dequeuer 即時性が求められない処理を非同期で処理するサーバー ◦ • 例：プロフィール情報の更新、ランキング更新、プッシュ通知 「本当の Queue」は RabbitMQ や Cloud Tasks を利用 RabbitMQ 15
16. Batch • • Cron ユーザートリガーではない定期的な処理を実行するサーバー ◦ • 例：イベント終了後の報酬配布、期限切れプレゼントの削除、ルームのお掃除 定期実行ではないもの、高負荷なもの、時間がかかるものは後述の Job も検討 16
17. DB • • • RDB / Database ゲーム設定、ユーザーデータ、ログデータなどの永続化を担う 格納するデータの特性に応じて、最適なデータベースを選択する必要がある よく見る構成 • MySQL (Cloud SQL) ◦ ◦ • masterdata operation（運用データ） Spanner ◦ userdata 17
18. KVS • • • • Key-Value 形式でデータを保存 シンプルなデータ構造かつインメモリにデータを保存するので高速 データが揮発することがあるので、主にキャッシュ用途で利用することが多い Redis を利用しており、Redis のデータ構造（Sets, Lists, Sorted Sets）など もよく使われる ◦ 例：キャッシュ、ランキング、マッチングの部屋管理 18
19. Proxy • VPC の外にあるサービスにアクセスする際に使用される • マニュアル通りにアクセスして繋がらなかったら Proxy を経由しているか確認 19
20. GS • Game Server / Realtime Server / Dedicated Game Server / PvP Server ◦ • ユーザー間のリアルタイム通信用のサーバー ◦ • 社内だと pvp, dgs, gs と呼称されることが多い PvP や PvE などのリアルタイム通信が求められる場合に用いられる 一緒にプレイするプレイヤーは同じサーバーに接続する 20
22. その他のコンポーネント 〜ゲームの開発・運用を支えるものたち〜 22
25. Builder • 踏み台サーバー / Bastion サーバー のこと ◦ • • コロプラでは歴史的経緯でこの呼び方となっている App や DB, KVS など各種サーバーにアクセスする際のハブとなるサーバー サーバーエンジニアの作業でかなりお世話になるはず 25
26. Tool • • • Admin Server 管理用の Web アプリケーションが動作しているサーバー プロジェクトの人、CX の人、協力会社さんなど運営に携わる人が利用する ◦ ◦ ◦ ◦ • マスターデータの反映 ユーザーの状況確認 統計情報の表示 業務効率化のためのあれこれ 利用者は Google アカウントでログイン ◦ Identity-Aware Proxy 最初に対応するタスクはここかも！ 26
27. Job • • 一時的にリソースを獲得して、特定のタスクを実行させる仕組み 「時間がかかる、処理が重い、突発的」などが当てはまる処理に利用 ◦ 例：リセット処理、データのバリデーション 27
28. Monitoring • • • サービスの状態を常に監視するサービス群 サーバーやアプリケーションの稼働状況、リソース使用率、エラー発生状 況などを監視するためのシステム ◦ Prometheus ▪ メトリクスの収集・保存 ◦ Grafana ▪ メトリクスの可視化 ◦ Datadog APM ▪ 分散トレースの可視化 異常を検知した際にはアラートを通知し、早期の問題解決に繋げる 28
29. Logging • 開発環境や本番環境はアプリケーションやシステムのログが一元管理されている ◦ • 主に系統が2種類 ◦ ◦ • 昔は各サーバーに直接接続して確認するなどが必要だった Cloud Logging ▪ app のログやミドルウェアのログなど、アプリケーションのログはまずここを確認！ ▪ デフォルトの設定では30日でログが消えてしまいます BigQuery ▪ 分析や監査用に保存するログを保存する ▪ 集計が必要なデータは BigQuery に流す アプリケーション開発においてログを確認するのは超重要！ ◦ ◦ Logging をうまく使いこなせるようになりましょう！ クエリライブラリなどを参考に使い方を学んでみることをお勧めします 29
30. CI/CD（1/3） • Continuous Integration / Continuous Delivery ◦ ソフトウェア開発プロセスを自動化し、継続的にコードの変更を統合、テスト、デプ ロイするための仕組み 各プロジェクトは主に GitLab + Spinnaker で運用 • GitLab ◦ ◦ ◦ • コード管理 テストや静的解析の実行 イメージビルド Spinnaker ◦ ◦ リリースプロセスのパイプライン化 GitLab CI と連携してブランチへの push をトリガーにデプロイ 30
31. CI/CD（2/3） 1 2 3 約1分 デプロイ専用 ブランチ GitLab git push deploy/dev1 コンテナをアップロー ド Artifact Registry デプロイしたいマン プッシュトリガーで コンテナをビルド 変更がないか常に監視 6 5 開発: 約1分 本番: 約10分 ポッドの差し替えを指 示 デプロイ完了通知 デプロイしたマン 4 順次に差し替え実施 （注意：新旧混在します） 31
32. CI/CD（3/3） • クライアント側もアセットバンドルを提供するための CI を構築している ◦ ビルドサーバーでアセットバンドルをビルド ◦ Img にアップロード ◦ CDN 経由で Client に配信 32
33. User Search • • • • Full-Text Search Engine 主に Tool から利用される Spanner が全ユーザーを跨いだ検索が苦手なので、そこをカバーするためのコ ンポーネントだが、最近は Spanner にも Data Boost や Full Text Search と いった機能が追加されているため、今後場合によっては不要になっていくかも プロジェクトによって異なるが、主に Elasticsearch などが利用されている • • マスターデータ ユーザー一人の詳細情報 • • ユーザー一覧の取得 条件に合致するユーザーの検索 33
35. 完全に理解できましたね！ 35
36. 開発環境について 〜ゲームの開発・運用を支えるものたち〜 36
37. 開発環境について みなさんが触る環境にはいくつか種類があって、それぞれ名前がついています。 • prd（本番環境） ◦ • stg（本番準拠） ◦ • 本番展開前にこちらに展開して動作確認をする dev（開発環境） ◦ • 運用中のゲームが動作する環境 機能開発中はこちらに展開して機能実装をする local（ローカル環境） ◦ 手元の PC の環境 37
38. ローカル環境の構成 • • OrbStack ◦ Docker Desktop Alternative ◦ OrbStack 上でコンテナを動かします Docker Compose ◦ 複数のコンテナを管理するコンテナオーケストレーションツール ◦ 開発に必要な各コンテナを起動します ▪ App ▪ DB ▪ KVS ▪ Queue ▪ User Search 38
39. VM 環境について 39
40. VM 環境とは • … GKE 導入（2018年）以前のプロジェクトのことをまとめて VM タイトルと呼んでいます 2014 2016 2018 2020 2022 2024 © ARMOR PROJECT/BIRD STUDIO/SQUARE ENIX All Rights Reserved. ©COLOPL, Inc. ©MIXI 40
41. VM 環境のアーキテクチャ 41
42. なぜ今の形になったのか？ 42
43. VM 環境でのつらみ • • 運用中のオペレーションコストが高い ◦ 施策リリース時の App 台数の調整 ◦ ホストエラー発生時の復旧対応 ◦ アプリケーション側での接続先設定の取り回し データベースの運用が大変 ◦ 自分たちで負荷分散の方法を考える必要がある ◦ 簡単にスペックを調整できない ◦ ダウンした時の影響がでかい上に復旧が大変 43
44. VM 環境でのつらみ • 運用中のオペレーションコストが高い ◦ 施策リリース時の App 台数の調整 ◦ ホストエラー発生時の復旧対応 ◦ アプリケーション側での接続先設定の取り回し → GKE でオペレーションを自動化！ • データベースの運用が大変 ◦ 自分たちで負荷分散の方法を考える必要がある ◦ 簡単にスペックを調整できない ◦ ダウンした時の影響がでかい上に復旧が大変 → Spanner でスケールの悩みを解消！ 44
45. が... まだまだツラみがある部分も... 45
46. GKE 環境の課題と今後の展望 • GKE のアップグレードが大変問題 ◦ 数ヶ月に一度コントロールプレーンとノードのバージョン更新 ◦ 本来であれば特に何も起こらないはずだが... ◦ • ▪ 謎の IO 負荷の上昇によりサービス影響 ▪ GKE 側のコンポーネントが謎のエラー なんでも GKE とすると運用中のものを全て上げて回るのも大変 Cloud Run などのより軽量な実行基盤も候補に！ ◦ コンテナ化された Web アプリケーションを手軽に動かせるサーバーレス環境 ◦ 神魔狩りのツクヨミで導入 ▪ 外部サイトにアーキテクチャを掲載中！ 46
47. さいごに 47
48. ノーメンテナンスについて コロプラではユーザー様がゲームをプレイできない時間をなるべく作らないように メンテナンス時間を設けない「ノーメンテナンス運用」を心がけています。 バックエンドエンジニアには、「ゲームを遊びたいのに、メンテナンスで遊べない...」 といったネガティブな体験をしないですむような エンジニアリング力が求められています。 アプリのアップデートや各種ミドルウェアの更新、障害対応など メンテナンス作業自体は発生しますが、これらをできるだけダウンタイムなしで 実施するにはどうしたらいいかなども日々考えていけるといいですね！ 48
49. Good Luck! 49