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ヵ月前までにはテストを実施すると良いとのこと。最後に運用フェーズでは、サーバの負荷状況を監視しつつ、個々の障害を内容面で優先順位を付けて対応していきます。このほか追加機能の実装はトラブル対応と並行となることが多いため、最低でも倍の時間がかかると注意を促しました。

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

ログの管理と将来を見越したサーバ設計が重要

最後に登壇したgumiの古閑学さん。家庭用ゲームの開発会社で8年過ごした後、ソーシャルゲーム業界に飛び込んで3年が経過。奮闘ぶりについて振り返りました。

2011年にサーバエンジニアとして、初めてソーシャルゲーム開発に参加した古閑さん。当時は右も左もわからず、無我夢中で開発を続けていました。多くのゲームで「体力」パラメータが鍵を握っていると考え、KVSを活用して更新できるようにしたところ、通信の不具合などで体力が消費されたのに、経験値がアップされないという事態が発生。データベースとKVSの整合性を取る難しさを痛感したと言います。

また参照の多いデータをキャッシュに格納したところ、「⁠更新したはずなのに昔のデータを参照している」「⁠キャッシュの削除忘れ」といったバグに悩まされることに。「⁠キャッシュは便利だがバグりやすく、バグが見つかりにくい」ことを学びました。こうした教訓から、現在もキャッシュの使用は最小限に留めているそうです。

その後、ユーザの増加と共にサーバのスケールアウトを実施。プレイヤーのデータをシャードごとに分割管理していきました。ところがソースコードの一部にバグが潜んでおり、データが一部紛失してしまいます。ログの保存が不十分だったために、全回復までには至りませんでした。

さらにゲームの人気が峠を越し、次第にユーザ数が減少。分割したシャードはそのままに、再びデータを統合する作業に直面します。こうした経験からログ管理の重要性や、将来のスケールアウト・スケールダウンを見越した設計の重要性を学びました。

これらの経験を積みながら、次第にメインプログラムを任されるようになった古閑さん。あるときゲームデザイナーから25人対25人のチーム戦の提案を受けました。人気の高いゲームシステムですが、それだけサーバ負荷も大きくなります。そのためチーム戦専用のデータベースを作成し、専用サーバ内だけ対戦できるように工夫するなどしました。その後、さまざまなトラブルが発生しつつも、適時対処しているとのことです。

サーバエンジニア視点でのゲームデザインとは

清水さんの講演はクライアント側の開発者に対して、基本的なサーバ構成について解説する内容でした。上原さんの講演はプロジェクトの立ち上げから運用まで、実際の開発に即した形でゲームサーバの作り方を解説。最後に古閑さんの講演では、新人エンジニアが複数のプロジェクトに携わりながら、次第にサーバの知識を深めていく、キャリアパスに即した内容でした。

三者が異口同音に説明したのは「ソーシャルゲームの根幹にはデータベースがあること」「⁠プレイヤーはゲームプレイやアイテムの購入などを通して、データベースに自分だけの価値を創造していくこと」「⁠クライアント／サーバ間の通信は思った以上に不具合が発生しやすいこと」「⁠チートやエラー、アクセス負荷などでデータベースが破損する恐れが常にあり、それらを見越した対策が必要であること」などでした。

これらはサーバエンジニア視点からみたソーシャルゲーム像であり、技術レベルも初級者から中級者向きで、非プログラマ職の参加者からも、わかりやすいと好評でした。終了後は交流会が開催され、積雪にも負けず多くの参加者が参加。深夜までさまざまな交流が続けられました。

勉強会後の交流会から自分が主催することに

初開催ながら大盛況に終わったゲームサーバ勉強会。主催したのは大手ゲーム会社でサーバエンジニアを務める望月大作さんです。きっかけとなったのは、本連載の第1回でも紹介したGamePM勉強会でした。もともとコミュニティ活動に興味があり、さまざまな勉強会に参加したり、運営のサポートなどをしていた望月さん。「⁠自分には話すネタがない」と悶々としていたところ、交流会で「ゲーム業界ではサーバの勉強会がない」という話になり、自ら主催することになりました。

もっとも具体的な方法がわからなかったため、運営はGamePM勉強会の主要メンバーがサポートすることに。勉強会は有料開催で、講師陣の交流会参加費に充てられましたが、徴収と管理もGamePMが担当。会場も知人経由でグリーから提供を受けることができました。これに対して、講師陣の声がけは望月さんが実施。このように、既存コミュニティから枝分かれする形で、新しいコミュニティが誕生することに。まさにコミュニティ活動の連鎖効果だと言えるでしょう。

一方で、最大の懸念材料は当日の積雪で、どの程度参加者が集まるのか、最後まで不安だったとのこと。実際には多くの参加者が集まり、本当に嬉しかったそうです。「⁠自分でも行動すれば何かできるんだという自信をもらいました。良かった！ 次もお願いします！ と言われたときは、本当にやって良かったなあと感じました」と話されました。

ゲーム業界でサーバエンジニアリング分野は、クライアントプログラマにとって、まだまだ未知の領域というのが実情です。今回のテーマ設定もそうした認識のギャップが背景にありました。そのため、初心者から中級者向けの内容に焦点が当てられることに。今後も長く活動を続けることを念頭におきつつ、次第に扱う技術レベルを高めていきたいとのこと。データベースに焦点を当てたトピックやソーシャルゲームだけでなく、MMORPGなど分野別のサーバ構築術、測定ツールなどのテーマも想定しているそうです。

そもそも、大前提としてWeb/IT業界に比べて、ゲーム系でサーバ勉強会が少ない理由には、どういった背景があるのでしょうか。望月さんは「オープンソース界隈の技術を使うことが多いWeb/IT業界に比べて、ゲーム業界では大手を中心に社内開発を行う傾向にあるため、勉強会が相対的に少ないのではないでしょうか」と分析します。また、ログの管理やテスト方法などについても、Web/IT業界では比較的フォーマットが決まっており、横展開しやすいのに比べて、ゲーム業界ではジャンルやタイトルごとに独自性が強く、ノウハウが共有しにくい点もあるのではないかと言います。

もっとも最近ではゲーム業界でも、オープンソースのミドルウェアも多用されています。「⁠そもそも、講師ができるような人が会社で忙しすぎるのでは……。自分の周りだけかもしれませんが、仕事が好きな人も多いですね」と補足されました。

そして、最近ではゲーム業界でも国内最大のカンファレンス「Computre Entertainment Developers Conference（CEDEC⁠）⁠」をはじめ、大小さまざまな勉強会が開催されています。望月さんもまた、CEDECで講師を務めた経験があります。そうした大規模なカンファレンスとの違いを聞いたところ、「⁠小規模勉強会は特定の技術分野に興味のある人が中心なので、より濃い話ができるのが良いですね」とのこと。また、よりアットホームな雰囲気で、フランクな話ができるのも魅力だと言います。

本勉強会に限らず、ゲーム業界の勉強会はWeb/IT業界と異なり、週末に半日かけて開催される例が多いのが特徴です。それだけ平日は業務が忙しく、勉強会といえども参加する暇がないという声が聞かれます。一方で「仕事が大好き、会社が大好き、でもコミュニティ活動には興味がない」人もまだまだ多いのが事実。望月さんも「興味のある分野の勉強会に、交流会も含めて参加してみると、また違った意識を持てるようになるかなぁと思っています」と言います。

最後にコミュニティ活動に参加する意義について尋ねると、「⁠ゲーム業界に対して何かしら貢献することで、会社にも成果として戻ってくるはずだと考えていますので、なるべく意識を高く持って取り組んで行きたいですね」と回答されました。数ヵ月に一度のペースで開催していきたいとのことですので、Web/IT業界の人も参加されてみてはいかがでしょう。