ちょっと技術的な話になる。
私の知人に、かつてはアルファベット三文字の某有名SI会社に在籍していて、今はどういう訳か某ネットゲームの会社に勤めている変り種がいる。
彼はネットワークとDBの専門家である。ゲーム業界には元来DB周りに詳しい人があまり多くなかったらしく、しかしネットゲームの開発にはDBやネットワークのアーキテクチャに関する知識が必須で、要は引き抜かれたらしいのだが、当人それ程ゲーム好きでもないのに面白いルートに行くなーと思っていた。
機会があったら金融業界とネットゲーム業界のシステム周りの違いについて聞いてみたいなーと思ってたんだが、この前久々に会ったら色んな話が聞けた。特定されない程度においおい書いてみよう。ぼかして書く為、ところどころいー加減だが勘弁して頂きたい。
今日はサーバとかデータのやり取りとか、技術的な話。
まず、前提。オンラインシステムの肝の一つに、「誰がデータを持つか」というものがある。
凄く大雑把な図式としてのオンラインシステムは、大体三人の役者から構成されている。データベース、アプリケーションサーバ、クライアントである。データベース(以後DB)はその名の通り、必要なデータをもっている人。アプリケーションサーバ(以後AP)は、それらデータを色んな形に加工して、ユーザーに提供する人。クライアントは、ユーザーのPC上で動くソフト。
で。大本のデータはデータベースに集中させなくてはならない訳だが、データベースは元来ハード単位での分散処理をさせにくい機械なので(RACだろーがなんだろうが、「台数を増やせば無条件で速くなる」というソリューションはDBに存在しない筈だ)、なんでもかんでもデータベースに問い合わせているとパフォーマンスがどんどん落ちる。
なので、「一時的な置き場所」として、上書きが頻繁でないデータや、他のクライアントとの整合性が強く求められないデータに関しては、クライアントに持たせたりAPサーバに持たせたりする訳だ。こうすれば、アクションの度にいちいちDBが問い合わせを受けたりはしないので、DBに全てのデータが集中しているよりはレスポンスがなんぼか向上する。多分一般的な設計手法なんだと思う。
で、ここからが彼の話なのだが。彼がネットゲーム(というかMMORPG)の開発現場にいってみてまず始めに衝撃を受けたことは、「呆れる程クライアントがデータを持っていない」ことだったそうだ。
そもそもその開発現場では「データの分散」という概念自体がなかったらしく、変更が生じないマスターデータから同画面内のキャラクターの位置情報に至るまで、何から何までDBがもっていたらしい。しかも、クライアント側でキャッシュというものを殆ど持たない設計になっているから、ことあるごとにクライアントソフトがサーバにデータを呼びにくる。
必然的に、ユーザーのキャラクターが何らかのアクションをする度にDBに参照や更新の処理が発生し、バッファキャッシュだけでは到底解決出来ないから物理IOがじゃんじゃか増える。
一部の処理ではロックの解決法が考慮されていなかったらしく、誰か一人のプレイヤーがある行動をすると、その行動処理が終わるまで他のプレイヤーの画面が更新されない、などという状況すら発生していたらしい。
この頃に起きた問題というのが凄くって、サーバサイドからの視点としても色々と面白い。ちょっと箇条書きにしてみる。
・同一処理エリア内にプレイヤーキャラが20人以上いるとクライアントが固まっていた。
・クライアントが固まると一部のプロセスがゾンビになる場合があったので、スタッフがkillコマンドを直に流して落としていた。クライアントとの通信が切れたらアラームが発生するソフトがそれだけの為に作られ、24時間体制のシフトが組まれていた。
・無謀にもその状況で公式イベントを開催してみたら、DBサーバのCPU使用率が98%から落ちなくなり、ロードアベレージが100を越えた(1未満であることが望ましい値)。
・参加していたプレイヤーのクライアントソフトが一つ残らず落ちた。怖くて誰も2ちゃんを開けなかった(MMORPGのスタッフには、自分のゲームのスレに常駐している人が結構多いそうである)。
・kill -9 を流してもプロセスが落ちない。
・仕方ないのでサーバをリブートしようとしてもなかなか落ちてくれないので、どうしようもなくなって電源を落としたらDBが立ち上がらなくなった。
地獄絵図である。
このDBが具体的に何なのかは分かる人もいるかも知れないが、この当時のスタッフにそのDBに関する知識が深い人がいなかったことは確かな様だ。まあ、稼働中のサーバの電源を落とすだけでも十分阿鼻叫喚だが、もっと恐ろしいことは大体月に一度くらいは上の様な事態が発生していたということだろう。よくサービス生き残ったなあ、と思ったけど、意外に珍しいことじゃないんだろうかコレ。
勿論、こんな構成になっていたことには理由もあった。
「クライアントに持たせたあらゆるデータはチート(プレイヤーがデータを細工すること)の対象になる」という経験則が大前提として設計開始当初からででーーんと横たわっており、あらゆるデータをDBに置かざるを得なかった、というのが彼が受けた説明である。結果として、このゲームのクライアントソフトは殆ど描画処理専用ツールと化していた。
DBサーバをひたすらごてごてと拡張することによってどうにかこうにか息を繋いできた訳だが、ぼちぼち余力がつきる状況だったという。
で、彼が突貫工事で設計の見直しを行い、比較的リソースが空いていたサーバを一台データのプール用に割り振って、DBのデータをそのサーバのメモリにキャッシュしてDB問い合わせ回数を減らすことによって、なんとかゲームの延命に成功したという。この設計変更はそれはそれで後々問題の種になるのだが、まあ緊急回避なので他にやりようがない。何年か前のことだそうだ。
色々聞いていると、確かに「一般的なシステム開発」の場面と「ネットゲームの開発」の場面って考え方とか文化が全然違うんだなあ、と。私もDBについては色々といじくっている人ではあるのだが、それなりに平和な環境にいたんだなあと再認識した。まあ、この状態にするまでには苦労もあったが。
このネタについてはまた何か書くかも。
2008年09月23日
この記事へのトラックバック
[ゲーム]ゲーム職人とエンジニアの常識が相容れない限り、ネトゲは開発できないのかも
Excerpt: ネトゲに不可欠なサーバーについて書かれているすごくいい記事が出ていたので……。 不倒城: SI業界からネットゲーム業界に移った知人に色々話を聞いてきた。 彼はネットワークとDBの専門家である。ゲーム..
Weblog: あなたわ しにました
Tracked: 2008-09-23 18:56
中東のドバイでなぜか今、人気を呼ぶあの幻の次世代ゲーム機
Excerpt: 中東のドバイでなぜか今、人気を呼ぶあの幻の次世代ゲーム機 ...
Weblog: Pocketworks : Idea Portal
Tracked: 2008-09-24 05:47
不倒城: SI業界からネットゲーム業界に移った知人に色々話を聞いてきた。
Excerpt: 不倒城: SI業界からネットゲーム業界に移った知人に色々話を聞いてきた。
Weblog:
Tracked: 2012-01-17 19:43
確かにそんなに珍しくないような。
実際、ネットゲにおけるクライアントはビューワーでしかない、というのは私もそういう認識に近いですね。やべー。
もちろん負荷分散は考慮しますが。
ダメなのはこのゲーム会社だけに限らない。
今の日本だと、まともな技術者を捜す方が
ずっと難しいんじゃないかな。
あー、タイトルまずかったですかね。知人が全く業界のこと知らない訳ではないですが、基本的にはおっしゃる通り、「彼が入った数年前の某社」限定の話です。
>島国大和さん
補足ありがとうございますー。
島国大和さんに「珍しくない」と言って頂けると、説得力があり過ぎて嬉しいのと同時に、そんなにレアケースって訳でもないんだと知って戦慄出来ます。
>もちろん負荷分散は考慮しますが。
MMOって同時接続数も凄そうだし、その辺シビアそうですよね。
たまにネットゲームに繋いで、公式イベントでの画面一杯のプレイヤーキャラクターなど見ていると、サーバ運用の人の心労が想像出来て身につまされることがあります。
>とおりーさん
んー、どうなんでしょ。確かに、ネットゲームの開発屋さんとしては当時ダメだったのかも知れないですが、ゲーム会社としてはダメなところじゃないと思いますよ。
おらがやってるのはERPパッケージ、
それもスタッフ業務だからDBを意識したこともない。
(してないわけじゃないが)
非常に興味深いですな。
DB設計云々じゃなく、癌はそこだと言ってたよ。
これも3年くらい前の話。
そもそもDBやサーバーをいじれるようなエンジニアはゲーム業界の給料では見向きもしない。
だからいくら募集しても人が集まらないし、来てくれてもハズレが多い。
月給30万に満たない低賃金、仕事はゲーム業界お得意の万年デスマーチ、仲間のはずのゲームプログラマーからも仕事内容を理解されず（サーバー屋はスクリプト言語とサーバー設定いじってるだけのプログラム書けない奴、と思われがち。C++至上主義の狭い価値観がまかり通る世界）、サーバーが落ちれば責任を問われ、２ｃｈでは罵詈雑言の嵐・・・。
これでどうやって優秀なサーバーエンジニアを確保しろと？
最低限、一般エンジニア並みの給料を出さないと。
今のままじゃネットゲー業界に人材は集まりませんし、せっかく育ったエンジニアもとっととゲーム以外の業界に転職しちゃいますですよ。
NECかと思ったｗ
アルファベット3文字だとIBMもあるね。
表示上のキャッシュとして使用して、ゲーム進行上では信頼をしない。ｊｋ
そういう意味では描画専用っていうのはあながち間違っていない。
UCGOも同じようなトラブルかかえてたな・・
あげくに、オーバークロックで速くなる糞ゲーだったが・・・
負荷分散とかどうしてんのかなーと思ってたけど
何も考慮してないとことかやっぱあったんだ
実際、大規模イベントの失敗例を見ると、どこもいっしょな気がする
これは経験則ではなくて事実ですよ。
ゲームコードを逆アセンブル、メモリー覗いて解析なんて日常茶飯事です。
リアルマネートレードが行われる程度の人気が出たゲームでは、レアアイテム等をいくつか売るだけで中国では月収クラスの金額になるので必死にチートします。
チートが横行するとばからしくなって正規ユーザーが逃げますから死活問題です。
まあ、それにしてもそのゲームのシステムはおかしいですけどね。
このドタバタぶりはディンプスで正解じゃないか？
あとの国産は、ほぼ＊＊のエンジンつかってるし自社でここまでチューンするとかあそこ位しかありえない。
普通のMMOは驚くほど通信パケット量が少ないのであって、升されると困るアイテムとかステータスを除いた、地形データやらモデリングデータやらテクスチャはクラ保持が基本。
だいたい数年前だとしても1画面20人で固まるとかってどんだけ。それとクラが固まるのはDB周り処理じゃなく、クラ側レンダリングエンジンが腐ってるって話で、ここにもディンプスっぽい臭いがプンプンする。＊逆にサバが重いと、自分含めてジャンプ（サーバーラグ）する状態になる。
あとプレイヤーのデータは（韓国製だと特にMySQLの）オンメモリ使うからサーバー飛んだときに”巻き戻し”が発生するのであってDB保管とかはない。
というかやってたとしたらクソ設計の一言。MMOは秒単位で恐ろしいログ書き込み（数千人の動作ログやら戦闘ログ全部残す）をするから、設計悪いとどんな高級サーバでも動かない。