第五回ゲームサーバ勉強会

6月18日（土）13時より「第五回ゲームサーバ勉強会」が開催されました。

この日のイベントには約55名が集結。参加者のほぼ全員がエンジニアです。

リアルタイムサーバに関する話を中心に、3名が講演されました。

登壇者とテーマはそれぞれ下記の通り。

「EmbulkとDigdagとデータ分析基盤と」
トレジャーデータ株式会社高橋達さん（@nora96o）

「リアルタイムサーバ」
株式会社gumi 清水佑吾さん（@yamionp）

「リアルタイム通信ゲームの実装例」
株式会社Aiming 山藤智之さん

それではスタートです！

EmbulkとDigdagとデータ分析基盤と

高橋達（たかはし・とおる）／トレジャーデータ株式会社 サポートエンジニアマネージャー。奈良先端科学技術大学院大学を卒業した後、サイオステクノロジー株式会社での勤務を経て2015年にトレジャーデータへ入社。

1人目の登壇者は、トレジャーデータ株式会社の高橋達さん。データ分析基盤を普段触っていない人を対象とした高橋さんの講演では、主に下記3点についてのお話がありました。

オンラインゲームとデータ分析基盤の関わり
「Embulk」ができること
「Digdag」ができること

データ分析基盤が必要な３つの理由

オンラインゲームの運営においてデータ分析基盤は欠かせないものとなってきています。その背景について高橋さんは3つの理由を説明します。

・現状を知るため
まず、アクセスUU数、継続率、課金額、課金率などの「基本的なKPI」を始め、「イベント参加率」「ステータスの推移」などの現状を把握するためにデータ分析基盤は使われています。

・データ分析の流れをスムーズにするため
現状を把握した次に行うのは、データの分析です。「顧客の分類」「ターゲットの決定」「ターゲットの行動追跡」「仮説作成」「仮説の検証」などにもデータ分析基盤が使われます。

・データの民主化
経営層を始め、どの職種でもデータを利用する機会が増えています。ビジュアル化を行うなど、誰でもわかりやすい形でデータを利用するためにはデータ分析基盤の導入が必要です。

トレジャーデータでは、こうした分析基盤を支えるために「Fluentd」「Embulk」「Digdag」といったOSS（オープンソースソフトウェア）を開発・提供しています。

「Embulk」でできること

続いて、高橋さんは「Embulk」について紹介します。

「Embulk」は、ある場所「A」から別の場所「B」へレコードを転送するためのオープンソースの「バルク転送ツール」です。その大きな特徴はプラグイン機構であること。これにより「A」と「B」の多用な組み合わせをサポートします。

バルク転送を行う上で、一般的には次のような点が難しいと言われています。

・入力データの正規化
null、日付、改行、エスケープ、文字コードなどフォーマットのバリエーションが多いデータをクレンジングする難しさ。

・エラー処理
壊れてしまった例外値の扱い、重複データ転送の回避、ネットワーク障害からの復旧などのエラーを処理する難しさ。

・メンテナンス
継続的な動作を確保したり、転送要件の変更に対する対応の難しさ。

・パフォーマンス
増大するデータ量に対して性能を保つ難しさ。

「Embulk」はこういった問題を解決するために開発されました。データファイルを少しだけ読み込んでデータ定義を予測してくれる「guess」、実際にデータ転送を行う前にデータを読み込んでみる「preview」といった、「Embulk」独自の機能がバルク転送を容易にします。

高橋さんは実際に「guess」や「preview」を使った例をデモで紹介します。

注目の新OSS「Digdag」って？

もちろん「Embulk」でも全ての問題を解決できるわけではありません。例えば、事前処理・事後処理といった、単体処理フレームワークやジョブキューを続きから実行をすることなどに課題があるとユーザーからも指摘があります。

しかし、これらは「Embulk」で解決することではなく、むしろ処理の一連の流れを管理するところで解決すべきだとの考え方を高橋さんは示します。そして、その考えから生まれたのが「Digdag」です。

6月15日にOSS化されたばかりの「Digdag」は、「Embulk」も含めたあらゆるバッチ処理のワークフローを簡単に扱うためのオートメーションツール。ビルドを行ったり、ランを実行したり、スケジュール実行をしたり、モニターをしたりといった複雑なパイプライン処理をシンプルに行うことが可能です。

高橋さんは、「Embulk」を使ってローカルのCSV ファイルを「PostgreSQL」へロードし、「Ruby」で「SQL」に集計し、「Python」で「Slack」に通知するという一連のフローを「Digdag」から実行するデモを披露します。

当日の高橋さんのスライドはこちらで公開されています。

リアルタイムサーバ

清水佑吾（しみず・ゆうご）／株式会社gumi 研究開発。サーバへの取り組みは15年ほど。

2人目の登壇者は、モバイルオンラインゲームの開発・運営を行っている株式会社gumiの清水佑吾さん。清水さんによる「リアルタイムサーバ」では、

なぜリアルタイムサーバを作らなければいけないのか
なぜ自作したのか
なぜErlangを採用したのか

などについて紹介されました。

リアルタイム通信を実現するTCP

まず、清水さんはモバイルゲームにリアルタイム通信が必要な背景を説明します。

スマートフォンの浸透による端末性能の改善や、ネットワーク環境の向上といった側面から、ユーザーを同士の一体感を生む本当の同時プレイが必要になり、今までよりも濃密なゲーム体験を提供が求められているのが現在のモバイルゲームです。

そこで、サーバ側から通信ができないHTTP通信ではなくTCPを使う方法を清水さんは紹介。最初こそクライアントから送る必要がありますが、一度コネクションが確立すればサーバ側からも好きなタイミングで通信できる点が強みです。

このTCPを使ったリアルタイム通信のメリットはどちら側からも送り始められることに加え、HTTPと比較すると通信コストが小さいことだそうです。

なぜ自作？

自社のゲーム特有な仕様への対応の必要性や「Windows Server」では機能過多で運用コストが高いこともあり、清水さんはミドルウェアを自作します。

選択したのは「Pub/Subモデル」。このモデルの大きなメリットのひとつは、メッセージを「Publish」するPub側が、メッセージを購読（Subscribe）するSub側を意識する必要がないという点です。その結果、オンラインゲームでよく見られる「Roomモデル」のようにRoomを管理する必要がありません。

さらに既存の複雑なシステムがあってもシンプルに導入できることが「Pub/Subモデル」のメリットでもあります。

プロトコルに関しては、数bitを切り詰めるよりもシンプルであることを優先しました。さらに、重要視したのは拡張性です。その結果、TLV（type-length-value）ベースのプロトコル構造を採用。この構造には拡張しやすいことと、実装が比較的容易であるというメリットがあると清水さんは説明します。

「Erlang」ってなにがいいの？

サーバのコンセプトはプロトコルで定義される以上のことはせず「土管としての役割に徹する」こと。サーバ側では端末とのステート（状態）を保持することはあっても、ユーザーのデータやゲームのデータは持たないように設計します。

例えば、ユーザーの認証などではデータベースに問い合わせる必要がありますが、必要なデータは全て外部に問い合わせを行います。

清水さんは実装にあたり、プログラミング言語として「Erlang」を使用します。1998年からオープンソースとなったエリクソン社製の関数型言語である「Erlang」。会場のほとんどの方が名前は知っているものの、実際に使ったことがある方はわずか2人ほどしかいません。清水さんは、一体なぜ「Erlang」を採用したのでしょうか？

「Erlang」の大きな特徴は超軽量なプロセスです。一瞬で立ち上がり、ごくわずかなメモリしか使用しません。

そのため、インスタンスを作るような感覚でプロセスをプログラミングしていきます。1台のサーバの中で、数万から数十万といったプロセスが走るのだとか。また、プロセス間ではメッセージ通信ができ、受け取り側は任意のタイミングで取り出すことが可能です。

また、「Erlang」は耐障害性に優れていることも特徴です。それを可能にするのが「Let it Crash」というアプローチです。あるプロセスでエラーが起こると、そのプロセスを監視している「Superviser」がエラーの起こったプロセスの再起動や後始末を行います。「Superviser」による監視ツリーを作ることで、何か障害があった際に綺麗に解放することが可能になります。

負荷試験などを経て、清水さんは「思ったよりスピードが出た」と「Erlang」でのリアルタイムサーバを評価しました。

また、清水さんが開発したリアルタイムサーバは、年内を目処にオープンソースとして公開する予定があるとのことです。

当日のスライドはこちらで公開されています。

「リアルタイム通信ゲームの実装例」

山藤智之（やまふじ・さとし）／株式会社Aiming エンジニア。猫大好きな、猫アレルギー持ち。

最後の登壇者は、オンラインゲームを開発・運営する株式会社Aiming の山藤智之さん。山藤さんは、オンラインゲームを作るのに必要な通信技術として

通信企画と通信内容
通信ライブラリ

について紹介しました。

ゲームによって異なる通信形式

山藤さんも、先ほど登壇した清水さんが紹介したように、単方向通信の「UDP」ではなく双方向通信の「TCP」がリアルタイム通信ゲームには必要だと説明します。

常時接続していることで、クライアントのリクエストに対してリプライするだけではなく、サーバ側からクライアントにプッシュが可能だからです。

接続された通信の内容は主に「キーフレーム形式」と「メッセージ形式」の2つ。

「キーフレーム形式」は、コントローラーからの入力情報や少ないデータを断続的に送り合う形式で、対戦格闘ゲームなどに有効とされています。

「メッセージ形式」は、手続き呼び出しをメッセージ化して必要なデータをやりとりする形式。アクション性が低いターンゲームやMMO（大規模多人数型オンライン）ゲームで使われています。

こうした通信の企画や形式は、プロジェクトの規模や内容によって適切に選択する必要があると山藤さんは指摘します。

独自通信ライブラリの開発

続いて、山藤さんは社内に導入した共通通信ライブラリを紹介します。

開発当時の7年ほど前にはあまりOSSがなかったため、Aimingでは自社でメッセージベースのライブラリを開発することを決定。

ソケット部分のコードは、iOSやAndroid、PC、家庭用ゲーム機など、異なるクライアントやプラットフォーム間での通信を提供する必要があります。

さらに、この通信ライブラリはアプリケーションに対してRPC（Remote Procedure Call）を提供しています。RPCとは、別のマシンで動いているメソッドをプログラムから呼び出す仕組み。山藤さんは、バイトオーダーでのデータの表現方法や、パケット構造でのメッセージの表現を紹介します。しかし、実装における問題点も。それはメッセージをひとつ追加するごとに追加・修正しなければいけないコード量が多いという点です。