Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a 【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発＆運営技法
Similar a 【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発＆運営技法 (20)
Más de モノビット エンジン
Más de モノビット エンジン (16)
【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発＆運営技法
- 2. 本講演の趣旨 13-8-26 2 ■本講演の趣旨 20対20のリアルタイム通信対戦をブラウザで実現したオンラインゲーム 「クリスタル◆コンクエスト」（c)スクウェアエニックス2012 今回は、40人対戦を実現するためのサーバ開発と運用に焦点を当てて、 負荷分散、サーバ間通信、プロセス管理、データベース運用など、オンラインゲームの サーバ開発や運用全般的に応用できる技術的なトピックを解説します。 ■本講演の対象者 ・オンラインゲームのサーバ開発を担当されている、もしくはその予定のあるエンジニアの方。 ■タイムテーブル ・開始〜5分 講師紹介、タイトル紹介 ・5分〜25分 ＜設計編＞ ・25分〜45分 ＜開発編＞ ・45分〜60分 ＜運営編＞
- 3. 講師紹介 13-8-26 3 株式会社モノビット ＜事業内容＞ １，ネットワークゲームの開発と運営（コンシューマ、スマホ、ブラウザ） ２，通信ミドルウェア（モノビットエンジン）の研究開発 → 3階中央にブースも出しています 昭和53年生まれ。神戸出身。 19歳の時に出会ったUltimaOnline、Diabloに衝撃を受け、将来オンラインゲームを作ると決意。システムエンジニア、コ ンシューマゲームプログラマを経て、2005年にオンラインゲーム制作会社を創業。オンラインゲームエンジンを自社開発し つつ、2009年にはソーシャルゲームにも自社タイトルで参入。20タイトル以上のオンライン・ソーシャルゲームの開発と運営 を手がける。オンラインゲーム開発に専念するため、SAP事業を譲渡し、2013年1月に株式会社モノビットを設立し現職。 代表取締役社長 本城 嘉太郎 1980年生まれ。大阪出身。 代表の本城とともにオンラインゲーム開発会社を起業。 主にオンラインゲーム・ソーシャルゲームのためのサーバ、ネットワーク、データベースの設計と構築に携わる。 自社開発オンラインゲームエンジンのプログラム基盤も担当。 取締役CTO／ネットワーク技術部 部長 仁木 拓磨 1971年生まれ。島根出身。 アーケードゲームとコンシューマゲームのプログラミングを長年手がけ、5年前に本城が代表を務める会社へ入社。 MOタイプのオンラインゲームを複数本開発し、クリスタル◆コンクエストの開発、運用を担当。 現在は通信ミドルウェア＆総合サーバパッケージ「モノビットエンジン」の研究開発に従事。 運営開発事業部 副部長 西山 高志
- 8. 【設計編】１，データベース構成 ■まずデータの保存方法の選択 • データベース • ファイル • KVS • etc... → 迷わずデータベース すべてのデータをレコード単位で保存 13-8-26 8
- 10. 【設計編】１，データベース構成 ■全体構成 • MySQL 5.5 ＋ InnoDB （＋InnoDB Plugin） • レプリケーション（マスター／スレーブ構成） • ゲームデータ、ログ、管理、KPI 13-8-26 10 ゲームデータ ログ 管理 KPI
- 11. 【設計編】１，データベース構成 ■スレーブによる参照性能の確保 • バッチ処理 – ランキング集計、KPI集計 • 調査 • バックアップ – Full dumpなどの長時間の読み出し 参照性能はスレーブ増設で拡張 13-8-26 11
- 12. 【設計編】１，データベース構成 ■テーブルパーティショニング データベースの性能を「下げない」ための手段。 ※データベースは運用期間が長くなるほど性能が低下する 13-8-26 12 record すべてが 検索対象 index record 必要なレコー ドだけ読み 込み でも：インデックス 全体は検索対象 数千万、数億レコードになるとインデック スだけでもメモリを圧迫
- 13. 【設計編】１，データベース構成 ■テーブルパーティショニング データベースの性能を「下げない」ための手段。 ※データベースは運用期間が長くなるほど性能が低下する 13-8-26 13 index record パーティションのインデックス 、レコードだけが対象
- 14. 【設計編】１，データベース構成 ■パーティションの種類 Range、Hash、List、etc… • 基本的には日付ベースの Range – ログなどの時系列データに効果が高い – 一般的によく使われる方法 • 時間と関係無いデータは？ – ログではないゲームデータとか – 仕様に合わせて選びましょう – メモリに乗せる量が絞られるように 13-8-26 14 index record 2013年8月21日 2013年8月22日 2013年8月23日
- 15. 【設計編】１，データベース構成 ■テーブル圧縮 データベースの性能が「下がりすぎない」ための手段。 13-8-26 15 容量大きい 容量小さい （10分の1くらい） アクセス量多い アクセス量少ない メモリ上のデータ 量は変わらない 圧縮・解凍に CPUを使う
- 16. 【設計編】１，データベース構成 ■どんなときに圧縮？ • ディスクIO性能が低い（アクセスが遅い） • ディスクの容量単価が高く、容量を増やしにくい • マシン構成上、ディスク容量を増やしにくい →IaaSクラウド、置き換えしづらい物理マシン クラウドでも – ディスクが早い – 容量単価が安い – ディスクの増設、拡張がしやすい というサービスなら逆効果の場合も 13-8-26 16
- 18. 【設計編】２，ゲームサーバ構成 ■システムの前提条件 • クラウドで運用 – 仮想マシンなので比較的性能が低い – 突然落ちる、通信が途絶える – IPアドレスがころころ変わる • グローバルIPアドレスはできるだけ節約 • いつでもサーバを増やせるように 13-8-26 18
- 21. 【設計編】３，可用性、安定性の向上 ■「サーバは落ちてもサービスは落ちない」 • サーバが落ちてもすぐに復帰できるように • 落ちたサーバだけに影響を限定して、サービス全体に波及 しないように • クラウドなので「マシンは落ちる」前提で ↓ サーバの処理単位をプロセス内で分離、 仮想プロセス的なIDを持たせるようにした 13-8-26 21
- 23. ■効果１ • IDで通信できる →物理的なサーバの場所を気にしなくてよくなった • 仮想プロセスはいつでも作ったり消したり出来る →特定の仮想プロセスに依存しなくなるので、同じ種類 のサーバの増減が容易になった →どんなタイミングでもシステムに参加できるので、再起 動が容易になった →MOゲームの特性に合わせて、接続ユーザ数に応じた ルームを起動・終了可能になった 13-8-26 23 【設計編】３，可用性、安定性の向上
- 24. ■効果２ • システム全体が仮想プロセスの消失を前提にしている →落ちたマシン、プロセスだけに影響を限定できる • クライアントはリレーを介してIDで通信している →ルーム移動やバトル前後で、接続し直さなくてもIDの 変更だけで通信するサーバを切り替えられる 13-8-26 24 リレー GameSv GameSv 【設計編】３，可用性、安定性の向上
- 25. ■ユーザデータの保全 • ユーザデータはすべて「データサーバ」で保持 • DBへのユーザデータ保存・更新もすべてデータサーバ • 他のゲームサーバは、データサーバのコピーを扱う ↓ データサーバが落ちたらユーザデータを失う？ →複雑なことをしないので落ちたことがありません 13-8-26 25 【設計編】３，可用性、安定性の向上
- 27. 【設計編】４，負荷分散 ■クラウドであることの利点 スケールアウト（増設）、スケールアップ（スペック増強）が容易 ↓ Webサーバと同じように「増やせば良い」と考える ↓ 仮想プロセス構成を活用し、サーバ種別ごとに負荷に応じて 台数を増減 13-8-26 27
- 28. 【設計編】４，負荷分散 • リレーサーバ – 多数のクライアントが接続してくる – 複数台のリレーサーバをクライアントに選択させる – 自然分散に期待する • ゲームサーバ、バトルサーバ、データサーバ – 最も負荷の軽いサーバを選択（データ量、ユーザ数少ないなど） – ラウンドロビン – 足りなさそうだったらプロセスを増やす 仮想プロセス構成により負荷分散は自然と達成できた。 いくらでも増減できるので、コストバランスも最適化できる。 13-8-26 28 設計編は以上です！
- 29. 【開発編】 13-8-26 29 1. プロセス管理 2. データ同期システム 3. パケットの暗号化, 圧縮, 分割 4. 通信データ削減技法 5. サーバのデバッグ 6. 大人数同時接続テストの実際 【開発編】 目次
- 30. ClientClient Battle MySQL Login Communication Area Battle Relay Client Battle Linuxのプロセス MySQL ClientDataData Login Area Communication Battle Battle Relay Battle 子プロセス 2 【開発編】 １．プロセス管理 同種のプロセスは全て複数起動 ・負荷の分散 ・プロセスが落ちても サービスを継続可 ・追加起動もできる バトルは 直接クライアントと接続
- 31. ロビー/ギルド ルーム ロビー/ギルド ルーム 31 ProcessUnit Areaサーバの例 Process Unit ユーザデータの管理理 他のエリアサーバ との調停 外部Webサーバとの やり取り ロビー/ギルド ルーム ・各PUはユニークなIDを持つ。 ・そのIDを宛先として、PU間で メッセージを送れる。 ・1PUを1スレッドとして並列実行する。 （シングルスレッドモードでのビルドも可能） ・SQLのクエリ実行リクエスト ・外部Webサーバへのリクエスト PUの他にスレッド生成する物 【開発編】 １．プロセス管理 PUを派生
- 32. 32 データ同期システム 簡単に言えば、サーバ - サーバ間や、サーバ - クライアント間で 自動的に構造体の同期を取ることができるシステム。 Data Communication Area Battle ・どこに誰のユーザデータがあるかの 管理が容易 ・ユーザデータ移動の手順を 簡略化できる ・フロントエンドサーバが落ちても DBへのデータ保存を保証する Master Slave 【開発編】 ２．データ同期システム ここで 書き換えたら… …マスターと 他のスレーヴで同期 利点
- 33. 33 パケットの暗号化/圧縮/分割 ・攻撃やチート行為を防ぐ為には、暗号化が必要 ・圧縮と分割もやっている パケット ⽣生成 分割 圧縮(lz4など) 暗号化 暗号化 通信 結合 解凍 復復号化 サーバ クライアント 【開発編】 ３．パケットの暗号化, 圧縮, 分割 ※ クライアントからサーバへの通信も同様。サーバ間では暗号化せず。 ゲームの 受信処理理
- 36. 36 例3 チャット 極端に多いと、リレーサーバが処理しきれない でも、誰もそんなに発言しないでしょ？ 非常に低い確率で起きる → 確実に起きる おは よろ おつ 1 ＦＩＦＯキュー 6秒後 すぐに送信 10ミリ秒後に送信 1秒後 キューの上限を超えた → 発言者へエラーを返す 同一市内の 全員へ送る 2 120 バルス 【開発編】 ４．通信データ削減技法 バルス バルス
- 37. 37 Windows ローカル環境 VMware + CentOS shell(gcc, gdb等の操作) Webブラウザ(クライアント実行) 【開発編】 ５．サーバのデバッグ エディタ(Visual Studio, Eclipse等) FlashDevelop, Adobe Flash 1台のWindows PCで完結
- 38. 38 サーバのデバッグ ・フロントエンド → 良い物が無かった ・gdbtui（テキストユーザインタフェース） ・stl-views で list や map の中身を表示 ・.gdbinit での設定 “set print elements 0” など ・不正なメモリアクセスやメモリリークを調査 ・しかし、とても重い！ ・独自実装のロガーでログファイルへ出力 ｇｄｂを使い易く Valgrind printf デバッグ 【開発編】 ５．サーバのデバッグ
- 39. 39 大人数同時接続テスト n サーバ1台に3千人では一晩テストしても発生しない問題が、 10台に3万人では10分で発生する n 接続数を2倍にすると、負荷が2倍どころか それ以上に増える事がある （接続数が少ないうちは、接続数に比例しているように見える） n 非常にシビアなタイミングでのみ発生する現象の 発生確率を高める n 高負荷時でも、レスポンス良く快適に遊べるか そもそも何故やるのか 【開発編】 ６．大人数同時接続テストの実際 重要！
- 42. 42 テスト手順 ・事前に7万人分のデータをDBへ投入 ・タイムテーブルに沿って操作 ログイン ロビー間移動 ロビー内での移動、チャット 探索の実行（Luaスクリプトの検証） マッチング バトル バトルを終えてロビーへ帰還 ログアウト ～ 別のアカウントでログイン 【開発編】 ６．大人数同時接続テストの実際
- 43. 43 何を直したか ・バトルサーバのメモリを増設 ・ログ保存用にDBを分離 ・チャット量に上限を設ける ・マッチングが集中したら、バトルの成立時間を分散させる ・ロビー入室やバトル参加の条件変更 （様々な要因により、1分くらい待たされてしまう事があった） 負荷テストの結果、サーバが落ちるといったバグの修正のみでなく、 サーバの増強やゲーム処理の調整も行った。 等々。 【開発編】 ６．大人数同時接続テストの実際 開発編は以上です！
- 46. 【運用編】１，運用監視 ■監視体制 • 24h365dで監視サーバからのアラートに対応 • 手動停止や再起動などの一次対応はリモート操作 • データの更新、メンテナンスなどはチームが出社して ■再起動“しない”という対応 柔軟なサーバ構成のため再起動は簡単だが、万が一のこと を考えて次のメンテナンスまでそのままのこともある。 →1台居ない程度では（負荷以外は）問題ないので →運用体制の簡素化に貢献 13-8-26 46
- 47. 【運用編】１，運用監視 ■監視方法 • 統合監視ツールZabbix インストールも簡単のオールインワンパッケージ – 多数の監視項目が最初から用意されている – 柔軟に追加項目を設定できる – 簡単にグラフ化 – 閾値によるアラート – マシンのヘルスチェック – 負荷状況監視 – リソース使用状況監視 13-8-26 47
- 48. 【運用編】１，運用監視 • ゲームサーバプロセス監視 Linuxの標準的な Service スクリプトを利用 – Pidファイルチェック pidファイルにプロセスIDを記述。プロセスが実行されているか確認 – プロセス名チェック サーバ実行ファイル名のプロセスが実行されているか確認 – ポート監視 フロントエンドサーバの外向けポートが開いていて、且つ応答があ るかどうかを確認 これらを1分に1回チェック 13-8-26 48
- 49. 【運用編】１，運用監視 ■目視の重要性 各監視項目のグラフを定期的に目視でチェック ＜何故？＞ 数値情報による機械的なアラートでは障害と判断できないことがあるため 例）一時的にあるマシンのトラフィックが極端に下がった 例）CPU使用率が閾値内ギリギリに上昇してしばらく下がらない クラウドでは希によくあります。 ↓ 毎日チェックしていれば変化を見つけることが出来る 人間の眼で見て「予兆」を捉えることは大切 13-8-26 49
- 51. 【運用編】２，負荷最適化 ■サービスイン後の負荷 サービス開始してから判明する負荷もある クリコンでは：DB書込みが予想以上に多く参照が少ない 原因 – 特定条件によるユーザデータの保存回数が予想より多かった – インベントリテーブル構造の問題で、無駄な書込みが発生していた ↓ 無駄な更新の多発によりスレーブが追いつかず、レプリケ ーション遅延が発生。 13-8-26 51
- 52. 【運用編】２，負荷最適化 ■実例：インベントリテーブルの大幅な変更 13-8-26 52 所持アイテムとインベント リ情報が一体だったのを… アイテム、インベントリステータス、インベン トリ利用状況の３つに分割 1億レコード、10GBのテーブルを分割するのに6時間 データ容量も2倍以上に増加
- 53. 【運用編】２，負荷最適化 ■その他やっていること – 各テーブルのレコード数増加傾向をウォッチ – テーブルパーティショニング、圧縮の適用（漏れているテーブルに） – パーティション単位で古いデータを削除 13-8-26 53
- 54. 【運用編】２，負荷最適化 ■最適化タイミングを計る 「いつの時点でどのようにヤバイのか」を計るには 事前に指標を用意しておくことが大切 例：DBの場合 – ディスク使用量 – 秒間更新／参照クエリ回数 – 各テーブルの一定期間のレコード増加数 CPU使用率などはいつでもヤバさが分かる。 多いのか少ないのか、長いのか短いのか。 相対的に論ずるべきものの指標を用意しよう 13-8-26 54
- 55. 【運用編】２，負荷最適化 ■「いつ頃どれくらい」は出せるか？ 問）サービス開始後1ヶ月でのDBデータ容量を出して欲しい 答）アクティブユーザ数と同時接続数と基本的なユーザの プレイサイクルが分からないと。。。 ではダメ。 変動するパラメータはきちんと想定し、その上で 「このアクセス想定だったら」「いつ頃までに」 「少なくともこれくらいで」「どんなに多くてもこれくらいに」 「収まるはずだ」 と語れるようにしよう 13-8-26 55
- 56. 【運用編】２，負荷最適化 ■指標を持つ意味 • 事前設計段階では ：目標となる • 運営開始後は ：対応の判断材料になる 質の高い予測なんてできそうにないです。。。 →できるわけないです。 やっているうちに慣れて、段々と精度が上がります。 数をこなしましよう。 13-8-26 56
- 58. 【運用編】３，運営中DB設計変更 ■メンテ無しでできるDB改修 データベースが止まらないので、サービスに影響を与えない あんまり無いです。 – 不要なインデックスの削除 – Enumカラムに要素を追加 – 新規テーブルの追加 – 新規Rangeパーティションの追加（ただし条件付き） 13-8-26 58
- 59. 【運用編】３，運営中DB設計変更 ■メンテが必要なDB改修 データベースが停止するため、サービスが影響を受ける。 処理に長時間かかったり、DBの再起動が必要だったり。 やりたいとよく思うことは大抵当てはまります。 – カラムを追加、変更 – インデックスを追加 – Enumカラムの要素順序変更 – パーティション分割、条件を満たさない新規追加 – テーブル圧縮 – その他ほとんどのテーブル、カラム変更操作 13-8-26 59
- 60. 【運用編】３，運営中DB設計変更 ■DB改修でメンテをしないためには • 仕様に沿った設計にしすぎない – 企画や仕様で見られるデータ構造をそのまま適用しない – ゲームサーバ上で使うデータ構造もそのまま適用しない • データの抽象化とテーブルの正規化 – カラムを追加せずにデータを拡張できるように – 正規化しすぎるのもよくない（性能を犠牲にする） • 極力テーブル追加をしない – テーブル単位の対処が漏れやすい – クエリ負荷やテーブルのデータ量を見積もりづらい – 追加しないとか、実際には難しいです 13-8-26 60
- 61. 【運用編】３，運営中DB設計変更 ■DB改修でメンテをしないためには（続き） • 先を見越してインデックスを付ける – 一見不要でも、データの定義に応じて必要そうなら付けておく – でも増やしすぎると性能低下を招く。見極め大事 • 更新対象を最小限で抑えるようにする – ゲームサーバ上で更新された箇所だけを書き換える – DBへの保存はセーブデータではないと心得る 13-8-26 61