IT勉強会に突撃レポートし，開始のきっかけや，運営ノウハウなどについてお聞きしていく本連載。第9回目では久々にゲーム業界に焦点を当てます。お邪魔したのは2月8日（土）に初勉強会を開催した「ゲームサーバ勉強会」です。

当日は東京都心が20年ぶりの大雪に見舞われ，交通機関に多大な影響が発生。しかし会場の六本木ヒルズ・グリー本社セミナールームには50名ほどが参加し，ホットな議論が展開されるなど，関心度の高さを感じさせました。

ゲーム業界の開発工程は今も……

本連載の読者であれば説明は不要かと思われますが，今やソーシャルゲームをはじめとして，適切なサーバ運用はゲーム業界でも必須課題となっています。もっともソーシャルゲームもWebサービスも，大まかにクライアント側とサーバ側で開発が分かれる点では，変わりありません。

ただしWeb/IT業界では（企業によって異なりますが）エンジニア主導でサービスが開発されていくのに対して，ゲーム業界ではプロジェクトがゲームデザイナー・プログラマ・アーティスト・サーバエンジニアという分業体制で進むのが一般的。というのも開発の目標が「遊んでおもしろい」ゲームを作ることにあるからです。

一方でソーシャルゲームでは，「⁠おもしろさ」の中に画面遷移のレスポンスや課金に紐付いたユーザの資産価値構築と言った，新しい要素が加わっています。つまりサーバエンジニアにとって，安定運用するサーバインフラの構築は大前提。そのうえでクライアント側との円滑なコミュニケーションが，重要なタスクになるのです。

そのため告知ページには「サーバのことが，まったくわからないクライアント側の人も大歓迎です！」との一文が明記。参加者もクライアント側とサーバ側が半々で，ゲームデザイナーの参加もみられるという，ユニークな勉強会となりました。

勉強会は三部構成となり，はじめにソーシャルゲーム大手のgumiから清水佑吾（@yamionp）さんが「サーバーのおしごと Webサービスにおけるサーバー構成とその目的」と題して講演しました。続いて家庭用ゲーム開発の大手でソーシャルゲーム開発を手がける上原光晶さんが「ゲームサーバ開発現場の考え方」と題して講演。最後に再びgumiから古閑学（@_mamehiko_）さんが「サーバー未経験者がソーシャルゲームを通して知ったサーバーの事」と題して講演しました。

なお清水さん，上原さん，古閑さんの講演資料が以下のようにWeb上にアップされていますので，併せてご覧ください。

• サーバのおしごと Wevサービスにおけるサーバー構成とその目的：gumi 清水佑吾（@yamionp）
• ゲームサーバ開発現場の考え方：上原光晶
• サーバ未経験者がソーシャルゲームを通して知ったサーバーの事：gumi 古閑学（@_mamehiko_）

サーバ構成の意味をメンバー間で共有する

高校生のころからCGIやWebサイトを作成してアルバイトをしていたという清水さん。今ではgumiのサーバエンジニアとして，さまざまなタイトルを手がけています。同社ではサーバにAWS（Amazon Web Service）を使用し，使用言語やフレームワークにDjangoやPython，ミドルウェアにMySQLなどを採用。Webサービスなどでも用いられる，平均的なサーバ構成だと言って良いでしょう。もちろん，そこには一つずつ意味があります。清水さんはなぜこのような構成になっているのか，わかりやすく解説していきました。

クライアント端末とアプリケーションサーバがネットワークを介して直接つながる。これが一番シンプルな形のサーバ構成です。ゲームの人気が出て，1台のアプリケーションサーバでアクセス負荷が高まると，サーバのスペックを上げるか（スケールアップ）⁠，台数を増やすか（スケールアウト）をして対応します。しかし，このままではサーバが壊れるとデータが消失するなど，さまざまなリスクを抱えることになります。

そこでアプリケーションサーバからデータを取り出し，データベースサーバを新たに構築。さらに特定のアプリケーションサーバにアクセスが集中しないように，ロードバランサを設置して負荷分散を行います。データベースサーバを書き込み専用のマスターサーバと，読み出し専用のスレーブサーバに分けて，双方で同期を取れば，ますます効率アップ。しかし，そこにもさまざまな問題が発生し……と，徐々に複雑になって行きます。

その後，KeyValueStore（KVS）をはじめ，Memcached，Redisといった概念を紹介。データベース内のデータテーブルを，「⁠体力」「⁠ジョブ」などの項目別に分割する垂直分割や，プレイヤーごとに分割する水平分割などで切り分けて負荷分散させる手法なども紹介しました。とくに，データテーブルの作り方はゲームデザインにも関係するため，開発時にはクライアント側とのミーティングが欠かせないと言います。

「ソーシャルゲームでは，お客様にアイテムを販売しています。つまりデータベース上でお客様の価値が積み上がっていくのです。そのため価値の担保を，しっかりしなくてはなりません」（⁠古閑さん）⁠。

もっともWebアプリからネイティブアプリへの移行によって，アクセス負荷も減る傾向にあるとのこと。今後はそれに即したサーバ構成が必要になってくるだろうと話されました。

ネイティブアプリ開発に必要なサーバ構成とは？

続く上原さんのセッションでは，ネイティブアプリのソーシャルゲーム開発を題材に，サーバ構築の例が説明されました。タイトル画面からログイン後，メニュー画面でフレンド管理やガチャ，ユニット編成，クエスト受託などを選択。実際のクエストはクライアント側のアプリで実行し，その結果をサーバに転送するという仕様です。全体の工程が基盤開発・機能実装・運用の3フェーズに沿って説明されました。

はじめに，基盤開発フェーズでは，ゲームの概要に沿って必要なアーキテクチャを策定します。サーバ構成や台数などは，想定される負荷に基づき仮決定。通信処理基盤やデータベース処理基盤なども決めていきます。一般的にやりとりするデータはログイン時が最も大きいため，想定負荷もログイン時を想定すると良いとのこと。また「この時期の過ごし方で，プロジェクトがデスマーチ化するか否か，ほぼ確定する」と力説しました。

続く機能実装フェーズでは，サーバ側とクライアント側を同じプログラマで開発することの重要性について強調しました。これにより工数を大幅に削減できるほか，コミュニケーションロスの低下など，さまざまなメリットが発生すると言います。双方で使用する言語は異なりますが，同社では実際にこうした開発例が少なくないとのこと。一方でサーバ側はメモリ管理にルーズになりがちで，クライアント側はデータベースの基礎知識が欠如しているなど，双方でつまづきやすいポイントが異なるため，注意が必要とされました。

また，ゲーム内でアイテムなどが増減する場合は，増減の順序を間違えないように注意が必要だと言います。「⁠減らす」後に「増やす」のが原則で，これを誤ると不具合などで通信が中断した際，資産の無限増殖が発生する恐れがあるからです。加えて「チート対策は必須で，クライアントは嘘をつく」とばっさり。送信データは毎回，全パラメータをチェックすること，ユーザの資産（アイテムなど）は必ずサーバ側で生成すること――などを指摘しました。

機能実装が終わったら，デバッグと並行して負荷テストを実施します。負荷テストはサービスインして1年後の想定データ量が目安となります。物理サーバを使用する場合は，調達時間を見越して2ヵ月前までにはテストを実施すると良いとのこと。最後に運用フェーズでは，サーバの負荷状況を監視しつつ，個々の障害を内容面で優先順位を付けて対応していきます。このほか追加機能の実装はトラブル対応と並行となることが多いため，最低でも倍の時間がかかると注意を促しました。

「メジャーなタイトルほどローテクでしのいでいる場合が多い」と上原さんは語ります。開発・運用期間が長期にわたるうえ，枯れた技術のほうがリスクが低いからです。しかも多くの開発者がかかわるため，作りが雑になる傾向にあると言います。そのため「最初は小規模のプロジェクトを数多く経験するほうが良い」とコメント。また「単純な構成を複雑にすることはできるが，その逆は難しい」として，要求を満たす最もシンプルな構成を，常に心がけることを勧めました。