【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発＆運営技法

【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発＆運営技法

• 1.
  20対20リアルタイム通信対戦オンラインゲームの サーバ開発＆運用技法 　 代表取締役　本城　嘉太郎 取締役CTO　仁木　拓磨 運営開発部　西山　高志 株式会社
• 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タイプのオンラインゲームを複数本開発し、クリスタル◆コンクエストの開発、運用を担当。 現在は通信ミドルウェア＆総合サーバパッケージ「モノビットエンジン」の研究開発に従事。 運営開発事業部　副部長　西山　高志
• 4.
  対象タイトル紹介   13-8-26 4 「クリスタル◆コンクエスト」は、 チーム対戦型横スクロールアクションバトルゲームです。 プレイヤーは最大20人vs20人、4つのクラスで役割分担し、 多彩なスキルを使ったり、強力な召喚獣を配下として操ったりしながら、 敵軍の本拠地を陥落させることで自国を勝利へと導きます。 強力なマッチング機能により、 ひとりで気軽に短時間のバトルに参加したり、 より強さを求めて仲間とパーティを組み、 さまざまな連携や戦略を駆使した協力プレイで、 定石のない白熱したバトルを楽しむことが可能です。（wikipediaより） クリスタル・コンクエスト©2012 SQUARE  ENIX  CO.,  LTD.
• 5.
  対象タイトル紹介 13-8-26 5 ■クリスタルコンクエストの特徴 ・最大40人対戦のリアルタイム通信アクションゲーム ・ロビーでマッチング→バトルへ遷移 　　　→いわゆる一般的なMOタイトルです！ ■技術的な特徴 ・ワンワールド設計 ・クライアントはFlashPlayer ・サーバはLinuxベース ・通信エンジンは自社開発のミドルウェアを使用 　（モノビットエンジンのプロトタイプ） ■本講演でお話すること ・サーバ周りを中心にお話しします。 ・2年前に設計されたサーバとなるので、 どう作ったかだけでなく、反省点と良かった点、 実際やってみて気づいた点などもお話しします。 クリスタル・コンクエスト©2012  SQUARE ENIX  CO.,  LTD.
• 6.
  【設計編】  
 1. データベース構成 2. ゲームサーバ構成 3. 可用性、安定性の向上 4. 負荷分散 13-8-26 6 【設計編】　目次
• 7.
  １．データベース構成
 マシン構成   性能向上施策など 13-8-26 7
• 8.
  【設計編】１，データベース構成
 ■まずデータの保存方法の選択 •  データベース •  ファイル • KVS   •  etc...   →  迷わずデータベース すべてのデータをレコード単位で保存 13-8-26 8
• 9.
  【設計編】１，データベース構成
 何故データベースか – アイテム一つに至るまでトレースしたい – SQLで集計、調査したい – データ構成を変更できる – どこからでもアクセスできる 何故KVSではないか – 集計ができない 13-8-26 9
• 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
• 17.
  ２．ゲームサーバ構成
 マシン構成、ネットワーク構成など   13-8-26 17
• 18.
  【設計編】２，ゲームサーバ構成
 ■システムの前提条件   •  クラウドで運用   – 仮想マシンなので比較的性能が低い   – 突然落ちる、通信が途絶える   – IPアドレスがころころ変わる   •  グローバルIPアドレスはできるだけ節約   •  いつでもサーバを増やせるように 13-8-26 18
• 19.
  【設計編】２，ゲームサーバ構成
 13-8-26 19 バトル バトル バトル ・・・ リレー リレー リレー ・・・ GSｖ1 ・・・ GSｖ2 ・・・ GSｖ3 ・・・ GSｖ4 ・・・ DB DB ・・・ データ データ ・・・ データベース バックエンド ゲームサーバ フロントエンド 1台ずつ固定I Pアドレスを 持つ
• 20.
  ３．可用性、安定性の向上
 
 サーバ構成の仮想化について   13-8-26 20
• 21.
  【設計編】３，可用性、安定性の向上
 ■「サーバは落ちてもサービスは落ちない」   •  サーバが落ちてもすぐに復帰できるように   •  落ちたサーバだけに影響を限定して、サービス全体に波及 しないように   •  クラウドなので「マシンは落ちる」前提で        ↓    サーバの処理単位をプロセス内で分離、    仮想プロセス的なIDを持たせるようにした   13-8-26 21
• 22.
  13-8-26 22 バトル ・・・ バトル ・・・ リレー リレー リレー ・・・ GSｖ1 ・・・ GSｖ1 ・・・ GSｖ2 ・・・ GSｖ2 ・・・ DB DB ・・・ データ ・・・ データベース バックエンド ゲームサーバ フロントエンド データ ・・・ プロセス 仮想プロセス 【設計編】３，可用性、安定性の向上

• 23.
  ■効果１   •  IDで通信できる    →物理的なサーバの場所を気にしなくてよくなった   •  仮想プロセスはいつでも作ったり消したり出来る    →特定の仮想プロセスに依存しなくなるので、同じ種類  　のサーバの増減が容易になった    →どんなタイミングでもシステムに参加できるので、再起  　動が容易になった    →MOゲームの特性に合わせて、接続ユーザ数に応じた  　ルームを起動・終了可能になった   13-8-26 23 【設計編】３，可用性、安定性の向上

• 24.
  ■効果２   •  システム全体が仮想プロセスの消失を前提にしている    →落ちたマシン、プロセスだけに影響を限定できる   •  クライアントはリレーを介してIDで通信している    →ルーム移動やバトル前後で、接続し直さなくてもIDの  　変更だけで通信するサーバを切り替えられる   13-8-26 24 リレー GameSv GameSv 【設計編】３，可用性、安定性の向上

• 25.
  ■ユーザデータの保全   •  ユーザデータはすべて「データサーバ」で保持   •  DBへのユーザデータ保存・更新もすべてデータサーバ   •  他のゲームサーバは、データサーバのコピーを扱う      ↓   データサーバが落ちたらユーザデータを失う？    →複雑なことをしないので落ちたことがありません   13-8-26 25 【設計編】３，可用性、安定性の向上

• 26.
  ４．負荷分散
 
 
 仮想サーバ構成の活用   13-8-26 26
• 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など) 暗号化 暗号化 通信 結合 解凍 復復号化 サーバ クライアント 【開発編】  ３．パケットの暗号化,  圧縮,  分割 ※  クライアントからサーバへの通信も同様。サーバ間では暗号化せず。 ゲームの 受信処理理
• 34.
  34 通信量の削減 実測値で8Mbpsの回線速度で遊べるように パケットを圧縮しても、サーバからクライアントへの送信量が多い 特別な解決法は無い。最適化をこつこつと メイン画面はルーム内の 情報だけあればよいが、 ミニマップは全体が必要 視覚的に荒い情報なので、 300ミリ秒間隔で更新 例１  ミニマップ 【開発編】  ４．通信データ削減技法 （解凍や復号化といった処理も重いし…）
• 35.
  35 例2  移動 サーバ上で移動経路を 算出 方向転換した座標の リストを送る クライアントで曲線補間 【開発編】  ４．通信データ削減技法
• 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  高負荷時でも、レスポンス良く快適に遊べるか そもそも何故やるのか 【開発編】  ６．大人数同時接続テストの実際 重要！
• 40.
  40 ・ローカル環境で各サーバプロセスを1～3つ起動 ・200接続 ・テストサーバ ・4千接続 ・topコマンドで負荷を監視 ・本番サーバ ・複数個所からの3万接続 ・muninで負荷を監視 小規模 中規模 大規模 【開発編】  ６．大人数同時接続テストの実際
• 41.
  41 ダミークライアント ・通常のゲームクライアントのような画面描画を持たない ・クライアントのインスタンスを多数生成 ・指示した行動を全インスタンスが一斉に実行 ・エージングテスト用の自動行動 Windows  PC ダミー クライアント ダミー クライアント サーバ 1PCで1000接続 PC PC PC ダミー クライアント ダミー クライアント PC PC PCPCPC 【開発編】  ６．大人数同時接続テストの実際 異なる場所からも 同時に接続
• 42.
  42 テスト手順 ・事前に7万人分のデータをDBへ投入 ・タイムテーブルに沿って操作 ログイン ロビー間移動 ロビー内での移動、チャット 探索の実行（Luaスクリプトの検証） マッチング バトル バトルを終えてロビーへ帰還 ログアウト  ～  別のアカウントでログイン 【開発編】  ６．大人数同時接続テストの実際
• 43.
  43 何を直したか ・バトルサーバのメモリを増設 ・ログ保存用にDBを分離 ・チャット量に上限を設ける ・マッチングが集中したら、バトルの成立時間を分散させる ・ロビー入室やバトル参加の条件変更    （様々な要因により、1分くらい待たされてしまう事があった） 負荷テストの結果、サーバが落ちるといったバグの修正のみでなく、 サーバの増強やゲーム処理の調整も行った。 等々。 【開発編】  ６．大人数同時接続テストの実際 開発編は以上です！
• 44.
  【運用編】   1. 運用監視 2. 負荷最適化 3. 運営中DB設計変更の実際 13-8-26 44 【運用編】　もくじ
• 45.
  １．運用監視
 
 
 13-8-26 45
• 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
• 50.
  ２．負荷最適化 13-8-26 50
• 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
• 57.
  ３．運営中DB設計変更の実際 13-8-26 57
• 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
• 62.
  おわり •  ご静聴ありがとうございました！ 13-8-26 62 ・ゲームサーバの設計、構築、運用のご相談を承ります。 ・3階中央にブースを出展していますので、ご質問などありましたらお越し下さい。