• Like
ゲームサーバ開発現場の考え方
Upcoming SlideShare
Loading in...5
×

ゲームサーバ開発現場の考え方

  • 37,900 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
37,900
On Slideshare
0
From Embeds
0
Number of Embeds
22

Actions

Shares
Downloads
208
Comments
0
Likes
177

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ゲームサーバ 開発現場の考え方 1
  • 2. 今日のお話 ゲームサーバってどうやって作るの? 普通のWebサーバと何が違うの? 作る時に気にすることは? そんな疑問にお答えします! 2
  • 3. 略歴 ゲーム開発を7年ほど 殆どがiアプリ or スマフォアプリ 主にサーバ、ここ2年はクライアントメイン サーバは主にJava(Tomcat) クライアントはJava(iアプリ)、C#(Unity) 3
  • 4. はじめに 今回の内容は、全て私一個人の経験則 に基づいた考え方です。ご了承下さい。 資料は後ほど公開いたします 4
  • 5. プロジェクト開始
  • 6. プロジェクト開始 パズドラ風のゲームを開発する事になりました パズドラ風ゲームの特徴・・・ 通信はHTTPのみ。 クライアントはネイティブアプリ。 起動後はメニュー画面(フレンド、ガチャ、ユニット編成、ク エスト選択など)。 クエスト部分はクライアントのみで遊び、結果をサーバに送 信。 6
  • 7. パズドラ風ゲーム サーバ ロ グ イ ン フ レ ン ド ガ チ ャ ユ ニ ッ ト 編 成 ク エ ス ト 受 託 ク エ ス ト 結 果 クエスト開始 タイトル 画面 ゲーム開始 メニュー 画面 クエスト終了 クエスト 画面 7
  • 8. 開発体制 プロデューサー(統括、予算の責任者) ディレクター(クオリティの責任者) プランナー(仕様、データ作成) デザイナー(絵、UIレイアウト) プログラマー 8
  • 9. 最初に ゲームの概要を理解した段階で、まずは 全体のアーキテクチャを検討する。 9
  • 10. 想定するシステム構成 KVS DB(Master) DB(Slave) DB(Slave) ・・・ Webサーバ クライアント クライアント クライアント クライアント Webサーバ ・・・ クライアント クライアント クライアント クライアント 10
  • 11. 通信システム リアルタイム通信が不要であればHTTP 送受信(POST)するデータ形式は? XML, JSON, MessagePack, Google Protocol Buffers, 独自シリアライズ 通信の頻度とデータ量、デシリアライズ処理の重 さ、開発&デバッグのやりやすさなどから検討(慣 れないうちはJSONオススメ) 11
  • 12. 想定負荷 例)DAU(Daily Active Users) 10万 10万 x 20 Login/日= 200万 Login/日 => 23 Login/秒 3倍して 23 x 3 ≒ 70 Login/秒 これが日々のピーク Webサーバ1台で12程度さばけると仮定すると、Webサーバ6台 となる。(この時点はざっくり) 基本的にログインが最も重い(多くのデータを読み込み、送信 する必要がある)ので、まずはログインの負荷を目安に考える。 12
  • 13. システム構成案 Web サーバ6台 DB(Master)1台、DB(Slave)2台 KVS 1台 Webサーバからのコネクション数は、DB(Master):30, DB(Slave):50, KVS:100とする 要求を満たす最もシンプルな構成を心がける 無駄に複雑な構成にして失敗するケースは多い 13
  • 14. 言語、ミドルウェア 言語やミドルウェア、フレームワークを決める 慣れや実績で決める Webサーバ:Tomcat(Java), Seasar2(s2jdbc) DBサーバ:MySQL KVS:memcached クライアント:Unity 14
  • 15. システム構成 KVS DB(Master) memcached MySQL DB(Slave) 30 100 MySQL Webサーバ クライアント クライアント クライアント クライアント DB(Slave) 50 x6 MySQL Tomcat + Seasar2 クライアント クライアント クライアント クライアント Unity 15
  • 16. 基盤開発 16
  • 17. 基盤開発 通信処理基盤 DB処理基盤 ソースコード自動生成ツール マスターデータ用ツール チーム開発用環境構築 17
  • 18. 通信処理基盤 MVC形式 or チャンク形式 MVC形式:1つの通信に1つの機能 チャンク形式:1つの通信に複数の機能 どちらもメリット・デメリット存在す る。(個人的にはチャンク形式を採用) 18
  • 19. 通信処理基盤 MVC形式 ログインリクエスト 処理が1対1 ログインレスポンス クライ アント に対応 フレンド承認リクエスト フレンド承認レスポンス サーバ 「フレンド承認レスポンス」に最新のフレ ンドリストを組み込みたい場合、サーバ・ クライアントの両方で対応が必要 19
  • 20. 通信処理基盤 MVC形式 メリット 分かりやすい フレームワークが既存で存在する デメリット 通信の設計変更毎に実装作業が発生する 20
  • 21. 通信処理基盤 チャンク形式 クエストリスト フレンドリスト ログイン ログイン フレンドリスト クエストリスト クライ アント フレンドリスト フレンド承認 各チャンク の振り分け 処理が必要 フレンド承認 フレンドリスト サーバ 「フレンド承認」に最新のフレンドリスト を組み込みたい場合、クライアントが「フ レンドリスト」を組み込むだけでOK 21
  • 22. 通信処理基盤 チャンク形式 メリット 仕様変更に柔軟に対応可能 細い回線の時に威力を発揮 デメリット 機能の振り分け処理などのフレームワークの開発が必要 慣れてないとバグを生みやすい 22
  • 23. DB処理基盤 ER図作成方法、DDL文出力方法、プログ ラマ間での共有方法を決める(既成のツー ルで良い) DBのマイグレーション(テーブルのカラ ム変更など)方法に関してはこれといって 決め手はない。地道にAlter Table文を書い てプログラマ間で共有するぐらい。 23
  • 24. ソースコード自動生成ツー ル 定型文的なソースは、極力ソースコードを生成するツールを自作し たい 特にサーバ・クライアント間で共有するソース(通信のクラス、 define、enum、マスターデータ) 自動生成の元データ形式は例えば以下 通信のクラス:JSON define, enum:Excel or CSV マスターデータ(後述):Excel 24
  • 25. ソースコード自動生成ツー ル “login” : { “request” : { “id” : “string”, “password” : “string” }, “response” : { “result” : “int” } } 通信データ定義JSON public class LoginRequest { public String id; public String password; } public class LoginResponse { public int result; } public class LoginProcess { private LoginRequest request; private LoginResponse response; public void exec() { // サーバのログイン処理を記述 } } 出力ソースコード 25
  • 26. ソースコード自動生成ツー ル MONEY_MAX int 999999 MONEY string Gem SWORD enum(WeaponType) 1 GUN enum(WeaponType) 2 ROD enum(WeaponType) 3 define, enum定義CSV public class Definition { public static final int MONEY_MAX = 999999; public static final String MONEY = “Gem”; } public enum WeaponType { SWORD = 1, GUN = 2, ROD = 3, } 出力ソースコード 26
  • 27. マスターデータ用ツール マスターデータとは:ゲームで利用する 各種固定データ データをプログラムで処理出来る形式 (JSON, バイナリなど)に変換 サーバ・クライアントで読み込む用の ソースコードも生成する 27
  • 28. マスターデータ用ツール id name attack 1 スライム 3 2 ゴブリン 15 3 ドラゴン 750 モンスター定義Excel “Monster” : {[ {“id” : 1, “name” : ”スライム”, “attack” : 3}, {“id” : 2, “name” : ”ゴブリン”, “attack” : 15}, {“id” : 3, “name” : ”ドラゴン”, “attack” : 750}, ]} モンスターデータJSON public class MonsterData { public final int id; public final string name; public final int attack; } モンスターデータ ソースコード 28
  • 29. チーム開発用環境構築 ファイル共有(svn) コミット内容をメールで共有 自動ビルド環境(Jenkins) ソースコード静的解析(Coverity) 29
  • 30. 基盤開発まとめ ここまでは経験豊富なベテラン開発者で固めると 良い。特にゲーム経験のある方の主導で構築する べき。 何かチャレンジしたいことがあればこの時期に検 証の日程と目標を定めておくこと。 この時期の過ごし方で、プロジェクトがデスマー チ化するかはほぼ決まる、技術者にとってプロ ジェクトで最も重要な時期になる。 30
  • 31. 機能実装 31
  • 32. 機能実装 タスク単位の工数見積は、全力の2倍。作業は見積の 半分を目標。 例:全力で2日なら見積もり4日、但し2日で完了 を目標にする。 作業内容を洗い出して、不安な箇所や不明点を解決 してから着手する 上記2点を守れればスケジュールの遅延はほぼでない 32
  • 33. サーバ・クライアント 同一人物開発 サーバ・クライアントの、同一開発者による実装オススメ 機能実装段階でのサーバなんて単なるデータ処理。作れて当たり前と考 えるべし。 クライアントのUIと一緒に作ることで工数を大幅に削減できる。(例: サーバ5日、クライアント5日のタスクを、サーバ&クライアント合わせ て3日で実装) メリットは挙げきれない。コミュニケーション不要、通信の設計書不要、 処理の最適化が可能、単体テスト簡略化(クライアント実装 単体テス トコード)、仕様変更&バグ修正容易、問題解析・対応能力向上、様々 な実装方法を理解することでコーディングセンスが向上、技術力向上 33
  • 34. サーバ・クライアント 同一人物開発 注意点 サーバ技術者 => クライアント開発 リソース(画像、音声など)管理に注意。省メモリを意識し、使い 終わったら解放する。 画面を常に動かす。固まらせない。 クライアント技術者 => サーバ開発 DBの勉強期間は十分に取る。最初は触らせないぐらいでも良い。 危険なコード(デッドロック、無限ループ)に注意する。 34
  • 35. 実装時の注意点
  • 36. 実装時の注意点 資産は減らしてから増やす アイテムの購入やトレード、移動などの際には、必ず「減らす」 後に「増やす」 例)アイテム購入時は、お金を減らしてからアイテムデータを 作る 逆だと何かの問題により処理が中断された場合、資産の無限増殖 (デュープ)が出来る危険性がある。 特定のユーザの「得」は、他のユーザの「損」 但し、問題発生時にユーザは不利益を被る。ログを残して補填対 応を適切に実施する必要がある。 36
  • 37. 実装時の注意点 チート対策 チートはされる。様々な方法でチートされる。 プレイ中のメモリ書き換え、通信データ改ざん クライアントは嘘をつく。チートされても最悪の事態は回避出来 るような仕様にするべき。また、クライアントから送信されたデー タは、全パラメータをチェックする。 ユーザの資産(お金、アイテム等)は必ずサーバで生成する。 (ガチャ、ドロップアイテム等) 乱数アルゴリズムはたまに質の悪いのがあるので注意。メル センヌ・ツイスタはオープンソースの実装もありオススメ。 37
  • 38. ログ ログは2種類。ユーザの行動ログ、システムログ ユーザの行動ログ:ユーザからの問題やクレームの 解析、運営のための統計データに利用(特にユーザ の資産に関わる部分は必ず取ること) 検索システム、統計処理が必要 サーバのシステムログ:問題検知、解析に利用 担当者への通知の仕組みが必要 38
  • 39. その他 開発者を増やすならこの時点で。機能 実装なら誰でも出来る。(基盤開発が 適切に行なわれている前提) 39
  • 40. デバッグ BTS(Bug Tracking System)を使う(Mantisや自作ツール など) Redmineなどのプロジェクト管理ツールをそのまま使 うことも可能だが、管理するタスクの粒度が細かく なるので余りオススメしない。 この時期にブラッシュアップの要望が大量に来る 定期的にリストアップ、優先度付けを行うと良い。不 慣れなプランナーは思いつく限り言ってくるので 40
  • 41. 本番サーバ選定 CPU メモリ HDD Web ⃝ ⃝ △ ゲームが動作する DB △ ◎ ⃝ データベース △ ◎ △ キャッシュデータ保存 ◎ 管理ツール ログ収集など KVS 管理サーバ △ △ 用途 ※ 実際には機能実装時点で仮決定しておく 41
  • 42. 本番サーバ選定 各ミドルウェアで必要なパラメータを決める catalina.sh Javaヒープサイズ 8GB server.xml 最大スレッド数 2000 Webサーバ (Tomcat) DB接続数 Master : 30 Slave : 50 KVS接続数 100 max_connections 300 innodb_buffer_pool_size 8GB context.xml DBサーバ (MySQL) my.cnf 事前に決めておかないと、後でメモリ使用量などの計算 が合わなくなる 42
  • 43. 本番サーバ選定 その他、CDNで大きなファイル、大量のファイ ルを配布(キャラ画像データなど) フロントのWebサーバは仮想マシンでOK(多 少遅くなっても許容範囲。ディスクI/Oも少な い) バックエンドのDBサーバは物理サーバ(常に 一定以上のパフォーマンスが必要なため) 43
  • 44. 負荷テスト Jmeterや自作ツールを使う 本番稼働後のデータ量、アクセス数を想定(100万ユーザ、10万 DAUなど) 大体1年後ぐらいを想定する。最近のスマフォのサービスの寿 命は1年程度が多い。想定外に売れたら運用後に頑張る。 CPU使用率、メモリ使用量の監視、重いクエリの発見 負荷テスト自体はサービスインの2ヶ月前までには実施する。万一 ハードウェア調達が必要になった場合、1ヶ月はかかるので。 44
  • 45. サービスイン後 サーバの負荷状況を監視(同時接続数、DAUと合わせて)し、 しきい値を越える or 異常検知でアラートメール 監視ツール:hobbit, Zabbix, Xymon 障害発生時、サーバによって放置度合いが異なる。 一定期間放置可能:冗長化されたWebサーバ 早めに復旧させたい:管理用サーバ、バックアップサーバ 即時対応必須:DBサーバ 45
  • 46. サービスイン後 ゲーム自体の定期的なバージョンアップ バグやプランナーの設定ミスによる障害は日常茶飯事 障害に対する対応方法はディレクター判断で毎回 異なる(即時メンテ、告知のみなど) ユーザにお詫びを配布する仕組みは必要(特定の ユーザ、全ユーザ、特定期間にログインした全ユー ザ、等) 46
  • 47. サービスイン後 保守、トラブル対応しながら追加機能の実装 を行うので、開発期間はサービスイン前の軽 く倍はかかる。 バースト的な負荷(メンテ明けやイベント開 始時など)の対策は必要かも。 過去1週間ログインしたユーザをメモリに キャッシュしておく、など 47
  • 48. 終わりに 当然ながら、全てを対応する必要はない。タイトルによって考え方、 重要度は大きく異なってくる。 「 かったら対応」は現場では有効な判断 但し、対応コストはあらかじめ検討しておくこと。 メジャーなタイトルほどローテクで何とか凌いでいる場合が多い。(開 発・運営期間が長いし、新しい技術はリスクが高いので採用されにく い) しかも多くの開発者が関わるため、作りが雑になる 最初は小規模のプロジェクトを数多く経験する方が良い 48
  • 49. 終わりに 常にベストな環境にあるとは限らない。炎上プロジェクトのヘルプをさ せられる場合も多い。 であればせめて以下だけでも意識したい。 なるべくツールによる自動化 サーバ・クライアントの各々の作りを把握し、問題を追えるように する。 目標とする工数と、スケジュール化する工数の区別 迷ったらシンプルに作る(シンプル => 複雑は可能だが、複雑 => シンプルは不可能なので) 49
  • 50. ご清聴、ありがとうご ざいました 50