2011-04-02

最近もらった本: オンラインゲームを支える技術

オンラインゲームを支える技術 をいただきました. ありがとうございます.

どこかで聞いた割と当たり前の話ばかり...なのは当たり前で, 著者は私が前に勤めていた会社のボス. 仕事で相談した時のアドバイス, 各種レクチャー, 雑談/議論, 社内の blog や Wiki で見聞きした話がまとまっている. デジャブ感はないとおかしい. 目次は 出版社の書籍案内ページ に詳しい.

広いトピックを網羅して情報量はすごい. 逆にそれが祟って見通しが下がり, 説明も散漫になりがちのは残念だった. とはいえ 3 章の "オンラインゲームのアーキテクチャ" は割とよくまとまっている. あとは 4,5,6 章の疑似ケーススタディの中など各所で性能評価を扱っている部分が面白かった.

仕事のはじめに "こんな感じで作ろうと思う" とボスに話をすると, まず聞かれるのが性能, 特に帯域の見積りと遅延だった. ボスは何かにつけて性能を概算していた記憶がある. 最初のころ私はこの性能概算を単なるボスの趣味だと思っていたが, 後から身をもってその必要性を思い知る... 私は性能への態度が甘く, しょっちゅう酷い目に遭っていた.

一通りのプログラムが動いたあとでベンチマーク用 bot を書き負荷をかけると著しい接続リセットがおこり, あわてて netstat の出力を見たらパケット再送が多発している <サーバ帯域不足>, パートナー企業に API を渡してから(中略)データベース用バックエンドでオーバーロードがおこる <サーバ計算資源不足>, ステージング環境経由で動かすとキャラクタのメッシュデータが全然ダウンロードされてこない <クライアント帯域不足>, ようやく表示されたキャラクタを動かすと今度はぴょこぴょこワープしてしまう <遅延>. 思いだすだけで胃が痛い.

オンラインゲームはサーバの構成が多様な上に融通がきかなくなりがちで, 問題がみつかってから直すのでは手遅れ. 大規模な修正やサーバの追加を必要とすることが多かった. 私の失敗も, いくつかは同僚のハック, デスマ, 運(そもそもユーザがつかないとか)によって切り抜けられたが, 頭を下げてサーバを増やしてもらったこともあった. うう胃が...

同僚がトラブルシュートに参加するプロジェクトでも, 見積不在で突飛なサーバ構成がトラブルの種になっているものがあった. そんなトラブルを避ける性能概算の例がこの本にはいくつか出てくる. 何も知らないとそもそも測る対象すらわからないので, 本に登場する計算例を眺めるのは面白いと思う.

個人的にはウェブの二層/三層構成のように, 真似しておけば大きく失敗はしない鉄板パターンが 常識として広く知られればいいのにと都合のいい期待をしてしまう. この本でもいくつか典型的な構成(=アーキテクチャ)が紹介されている. ベテラン開発者なら知っているはずの知識なのだろう.

最近はブラウザでもそれなりの絵を描き通信することができるようになりつつあるなど, クライアントテクノロジーの敷居は下がってきた. 願わくばサーバテクノロジーの敷居も下がり間口の広い世の中になればいいと思う.