むかーしむかし、あるところに、ネットワークエンジニア兼データベースエンジニアがおりました。元々はネットワークが専門だったのですが、色んな仕事を片付けているうちにデータベースもやることになり、某高額なDB試験のゴールドまでとってしまったというハイスペックなエンジニアでした。
彼のことを、仮にCさんと呼ぶことにします。
Cさんは、某アルファベット三文字の有名SI会社に勤めていたのですが、どうした風の吹き回しか、本人は殆どゲームをやらないのにゲーム会社に転職して、当時まだ日本で幾つかのタイトルが出始めていたばかりの、MMORPGという世界に活躍の場を移すことになりました。
周りの人間は、彼のことを物好きだなーと言っておりました。私もそう思います。
Cさんは、そのMMORPGで、最初にドすげえ事態をなんとか片付けなくてはいけませんでした。
それは、「本来であればクライアントやアプリケーションサーバで分散処理をすべき色々な処理を、何から何まで全部DBのストアドプロシージャにやらせていた為、ちょっとでもユーザーからのリクエストが増えるとロードバランスもクソもなく一瞬でDBに全部の負荷が載ってきて、イベントなどやろう日には百発百中システムが止まる」という凄まじい阿鼻叫喚地獄絵図でした。
その辺の顛末は、もう8年くらい前ですが、こちらの記事に書きました。興味がある方はどうぞ。
SI業界からネットゲーム業界に移った知人に色々話を聞いてきた。
・同一処理エリア内にプレイヤーキャラが20人以上いるとクライアントが固まっていた。・クライアントが固まると一部のプロセスがゾンビになる場合があったので、スタッフがkillコマンドを直に流して落としていた。クライアントとの通信が切れたらアラームが発生するソフトがそれだけの為に作られ、24時間体制のシフトが組まれていた。・無謀にもその状況で公式イベントを開催してみたら、DBサーバのCPU使用率が98%から落ちなくなり、ロードアベレージが100を越えた(1未満であることが望ましい値)。・参加していたプレイヤーのクライアントソフトが一つ残らず落ちた。怖くて誰も2ちゃんを開けなかった(MMORPGのスタッフには、自分のゲームのスレに常駐している人が結構多いそうである)。・kill -9 を流してもプロセスが落ちない。・仕方ないのでサーバをリブートしようとしてもなかなか落ちてくれないので、どうしようもなくなって電源を落としたらDBが立ち上がらなくなった。地獄絵図である。
これは、負荷分散とかスケールアウトといったことについて技術的知見をもったアーキテクトが一人たりとも開発チームにいなかったことが原因で起きた事態であり、端的に「それまでのゲーム開発」と「オンラインシステム開発」に求められるスキルが異なることを示していたのだろう、と思います。もう結構な昔話ですので、最近のMMORPGでこんなことはさすがにないんだろうと思います。よく知りませんが。
で、そんな彼から、当時もう一つ、データのモデル設計についての面白い話を聞いていました。
それは、Cさんがデータのキャッシングについての知識と小技をフル稼働して、なんとかシステムのパフォーマンス問題を小康状態にした、その矢先のことでした。
開発メンバーが深刻な顔を付き合わせて、なにやら相談していました。「RMT」とか「ユーザーからのクレーム」といった単語が途切れ途切れに聞こえてきます。
Cさんは、手近なメンバーに聞いてみました。分からないことをすぐ率直に聞けるのは有能さの証です。
「なにかあったんですか？」
「あーいや、ユーザーからの突き上げが凄くってですね。。。RMTの調査と規制、ずっと先伸ばしにしてたんですけど、いい加減なんとかしないとってことで」
ゲームを殆ど遊ばないCさんは、当然RMTという言葉も知りませんでした。
「RMTってなんです？」
「リアルマネートレード。早い話、現金でゲーム内のお金やアイテムを入手するってことでして、規約では禁止されてるんですが」
現在ほど明確な指針は当時まだなかったようですが、RMTを放置すると業者やbotによる通常プレイヤーへの圧迫が起きる上、反社会的勢力の資金源になる場合もあり、ベンダーにとっては当時から頭痛の種でした。
「しかし、まず調査が一苦労なんですよね。。。」
「？ えーと、要は怪しいトレードをピックアップすればいいんですよね？確かにそこから通常取引との識別は難しいかも知れませんが、集中してそういう取引を行っているユーザーを特定すれば」
Cさんの感覚では、そこまで困難な話にも思えません。
「ええまあ、なのでそれ用のログ解析ツールを作ろうとしているんですが」
「ログの解析...？」
いまいち分かりません。何故わざわざログを解析する必要があるのか。
「トレードの履歴をまとめてピックアップすればいいんですよね？簡単なSQLで解決出来そうですが」
「SQLって、DBで検索するってことですか？」
そりゃそうです。何のためのDBなのか。
「ええまあ、一応パフォーマンスの問題がまだありますから、メンテナンス時間中にやった方がいいでしょうが」
「いや、トレードの履歴はログにしかありませんから、DBから検索するのは無理だと思いますが...」
「...はい？」
よくきいてみたところ、ド衝撃の事実が判明しました。このシステム、プレイヤーの位置情報とかその時点のステータスとかエリア内のオブジェクトの状態とか、クソどーでもよさそうなデータをDB管理していたくせに、なんとプレイヤーの所持金の出納データをDBで持っていなかったのです。
どういう話かといいますと。
例えば、銀行の現金残高のデータなんかは、必ず「全ての入出金データ」と「その合計をサマリーしたデータ」を別々のテーブルでそれぞれ管理しています。いつ、誰がいくら入金・出金したかという一件一件のデータが前者で、それら全てを合計したものが後者。こういう持ち方をすることで、最新のデータは一瞬で呼び出すことが出来ますし、一方履歴も全て追えるので、データの保証も常時行うことが出来ますし、「○月×日の所持金はいくらだったか」といったことも簡単に調査することが出来る訳です。ごく一般的なデータモデルです。
しかし悲しいかな、そのときの開発スタッフにはそういう知識がある人がいませんでした。彼らにとって、プレイヤーの所持金というものは、飽くまで「最新のデータだけ保持しておけばいい箱」でしかありませんでした。確かに、ドラクエやFFのようなオフラインRPGであれば、「いつ時点の所持金が幾らか」などということをセーブロードなしで再現する必要など発生しません。履歴管理の必要性など、そもそも設計段階で話題に挙がることすらなかったのです。
一応トレードの履歴はサーバーのログ管理機能でログに残ってはいるというものの、ログの書式も機能によってバラッバラで、しかもロギングの資料もなく、まずは機能ごとのログの解析が必要という有り様。端的に言って地獄です。
プレイヤーの所持金データをちょっとみれば分かることだったのですが、なにせ「ER図(DBの設計書)はないんですか？」と聞いてみたら「必要な資料なんですか？すいません、そういうの分かる奴がいないんで、調べて自分で作って頂けると...」と言われた現場です。全力でパフォーマンス問題に傾注していた彼は、まだその辺まで手がつけられていませんでした。
そして、でかい問題を解決した直後に降ってわいたこの問題が、やはりCさん以外に解決出来る問題でないことは明らかでした。Cさんの残業時間が入社直後の二ヶ月連続で250時間を越えることが確定した瞬間です。
結局この問題は、突貫でログ解析ツールをつくり、履歴テーブルを急造してそこにレコードを放り込もうとした矢先、ログを直近一週間分しか保持していないことが判明するという急転直下のひどいオチを迎える訳ですが、最終的には最新の状態を1レコードにしてそれ以降のデータのみ履歴で持つようにしたそうです(当然それ以降のデータしか調査・巻き戻しは出来ない)。大変ですよね。
Cさんはまだ同じ業界にいらっしゃいまして、さすがにこの当時ほどひどい事態は見なくなったということなのですが、今でもぽつぽつ面白い話は聞くことが出来ます。機会があれば(あとCさんの許可がもらえれば)また紹介したいと思います。
遠い、遠いオンラインRPGのお話でした。
って思えるような身につまされるようなｗ
他業界から入ってきた方はよくそうおっしゃいますし
それに耐え切れずにすぐ辞めていく方も多かった
IBMですか？
ゲーム作れる人間はいても、DB設計や構築ができる人間がいない。そしてそれが不足していることを指摘できる人もいない。その状況だと、負荷試験とかの試験プランもまともに書けないので、試験になっていない試験をしたままサービスインという恐ろしい状況ですね。
昔に比べると今はノウハウの蓄積があるのでここまでひどくはならないと思いますが、今でもソーシャルゲームなどで、高負荷でまともにゲームができないということは起きているので、いつまでたってもなくなるような問題ではないのでしょうね。
傍で聞いてる分には笑い話ですむのですが。
あれはひどかった。