読者です 読者をやめる 読者になる 読者になる

Lattice in the Lettuce

The monologue of a scientist.

ROの鯖の仕組み

某所で書くって言っちゃったので寝る前に書いておく。

その前に前置き、私はプログラミングについてそれほど理解していない。一応C++/Perl/VBは書けるが、もう何年もしていないし、通信プログラムはhttpとROのBOT以外したことがない。解析についてはデバッガを走らせたり、アセンブラを読む程度しか出来ない。なので、あまり専門語は用いずに書こうと思う。

下記の内容は、AEGISが流出した折に実際に動かして挙動確認して分かったものである。

ROの鯖(AEGIS)の種類は4+1で、以下の通り。

・アカウント鯖(ログイン鯖と言われてるもの)
・キャラ鯖(キャラセレとか言われてるもの)
・インター鯖
・ゾーン鯖
・MSのSQL

MSのSQL使ってるというのでピンときた人もいるかと思うが、各鯖「アプリ」はWindowsネイティブである。しかもサービスではない。見た目はDOS窓。開発当初はNT4で動いていた。

図解するとこんな感じになる。

アカウント鯖

アカウント鯖はその昔Webログインじゃなかった頃はここでログインしていたが、今は3つあるグループを選択する以外でプレイヤーが目にする事はなくなった。ちなみにキャラ鯖へデータが渡った後は、アカウント鯖へ戻ってこれなくなる。

キャラ鯖

アカウント鯖でグループを選ぶと、次に行くのがキャラ鯖で、ゲームするワールドを選ぶ、キャラを選ぶ、キャラパス入れる、キャラ情報をインター鯖に送る、までが受け持ち。キャラデータに関するSQLの入出力はこの鯖が担当する。

インター鯖

インター鯖はゾーン鯖の補助として働いていて、キャラ鯖から貰ったキャラデータをインスタンスに格納するとともに、該当ゾーン鯖へ送るような処理をしている。ワールド毎に存在しているっぽい。キャラの実データはインター鯖に残り、必要なデータだけがゾーン鯖へ渡る。そのためゾーン鯖は必要に応じて、必要なデータをインター鯖へ問い合わせている。

余談だが、性別データはキャラ鯖経由ではなく、クライアント経由でゾーン鯖へ渡される。この理由は不明。性転換するとBAN対象になる。結婚式のあと性転換するとタキシードとドレス両方見れる。

インター鯖は他に、白チャを除く各種チャットの受け渡しや、各ゾーン鯖のキャラ状態(どのゾーンに居るか)、NPCでの売買、露店と地面以外での取引を各ゾーン鯖から都度送られるデータで把握している。

ゾーン鯖

ゾーン鯖はいわゆるゲームしている鯖で、複数のマップを抱えていっぱいある。

キャラに何らかの変化(ゾーン内外のマップ移動、NPC取引、取引窓での取引など)があると、インター鯖へその都度データを問い合わせているが、なぜか露店と地面については都度確認していない。おおよそ5分に1回、まとめてインター鯖へ送っている。これはどうしてか?というと、露店と地面経由の「取引」は初期設計に入っておらず、開発中に後付けされたものだから。

昔あったDUPE

10年ほど昔、インター鯖はオソトから見ることが出来た。本来その必要はまったくないのだが、なぜかグローバルIPが振られていた。

これを悪用してDUPEしてた連中が居た。

メンテでは、まずゾーン鯖がインター鯖経由でキャラのログアウト情報を渡す処理をしたあと終了する、インター鯖はキャラ鯖へキャラデータを渡して終了、キャラ鯖はSQLへ書き出して終了、という形で進行していく。

メンテの直前、露店や地面を使ってアイテム移動を行い、「データ保存させるキャラ」を正常にログアウトさせた直後、インター鯖をDDoSで殺す。インター鯖が死んだ状態では、ゾーン鯖はデータを渡せずにタイムアウトして終了してしまう、つまりキャラデータが保存されなくなる。だから「保存させたくないキャラ」の方はゾーン鯖がタイムアウトで落ちるまで放置しておく。

ゾーン鯖はDDoS対策されてたようでハンパな攻撃では落ちず、そのためメンテ時が狙われていたようである。

この件は、インター鯖をローカルIPにしてオソトから見れなくすることで解決した。

ダブルカウント

接続スレで変なのが「ガンホーが23時の接続数を捏造してる!」とかファビョっているが、これはありえない。接続数カウントはゾーン鯖からインター鯖へ送られるキャラ情報を元に、インター鯖がカウントしてキャラ鯖へ送っている。ここらへんの処理はAEGISのネイティブ処理で、スクリプト操作ではどうにもならない。

第一、ガンホーは一般向けに表示しているこの「接続数」を何かに用いているわけではない。この点については後で述べる。

さて、なぜ23時の接続数が多くなったのかというと、インター鯖がキャラをダブルカウントしているからと考えられる。

接続数カウントの仕組みを書いておく。

1.キャラ鯖がインター鯖へ問い合わせをする。
2.インター鯖は格納しているキャラのプロセスの総数を答える。
3.キャラ鯖が表示。

ここに実は問題がある。抱えているキャラデータの総数ではなく、問い合わせのあった時点でのプロセス数を答えているために起きている問題なのだ。

言葉で表現するとめんどくさいので、これも図解してみる。

スタックプロセスというのは、ゾーン鯖から要求のあった命令を、プロセスとして配列に格納する。この配列に入っている命令を処理スレッド(スレッド数は負荷に応じて増えるっぽい、限界はあるだろうが)で順次処理していく。処理が終わればフラグをつけて、そのまま配列においておく。

一旦、箱に貯めておいて、あとから順次取り出して実行していく感じである。

キャラ鯖から接続数を問い合わせされたときは、このプロセスの数を答えている。通常であれば、処理はプレイヤーが意識出来るほどの時間を要さず終わるのだが、多数の要求が一度に来た場合には、とりあえず片っ端から配列に入れるだけ入れる、処理は全部後回し、って事になる。

23時の一斉要求とガンホーの対策

今回は、23時の砦イベント終了と同時に、ゾーン鯖からインター鯖へ一斉に要求が来たため、上記のような事が起きたと考えられる。

では9月12日の緊急メンテは何かというと、上記インター鯖の負荷に関した修正だった。といってもインター鯖自体をどうにかするわけには行かないようで、砦イベントを実行しているゾーン鯖の変更止まりだったようだ。

あるゾーンから別のゾーンへ移動する際には、インターを経由する。だがマップが違ってもゾーンが同じであれば、インター経由にはならずゾーン内の処理のみで済む。

これはWP(ワープポイント)詰まりとか言われている問題の解消が目的だったようで、接続数云々は関係ないというか、ガンホーはこの接続数はとくに見ていない。

ではどこを見ているか、というと、キャラ鯖がSQLにログインログアウトの時刻を書き込んでいるので、そこからアカウント毎のトータルタイムを算出しているようである。

23時の接続数など見ているのはプレイヤーだけ

SQLに時刻が書き込まれ、SQL上ですべてのプレイヤーのプレイした時間を算出出来るのに、特定時刻の接続数を指標にするはずはない。接続数からは、どのような年齢・性別のプレイヤーがレベルいくつでキャラは何で、何時頃にどれくらい遊んでいたかなど、一切分からないからだ。

様々な情報が分かるデータと、たった一つの事しか分からないデータ、どちらを取るかなど考えるまでもない。

あんな接続数など見て妄想しているのは、クリックゲーに血道を上げているネトゲ病のプレイヤーと、私のような面白半分で暇潰ししている第三者だけだろう。

鯖キャンの処理

ところで、このインター鯖を経由した処理の面白い挙動の一つに、鯖キャンというものがある。ゾーン鯖とクライアント間でコネロスしても、キャラは結構長い間、ゾーンというかマップに表示され続ける。

コネロスしてパケットが届かなくなっているなら、すぐにでも消えておかしくはないのだが、そうならない。これは、インター鯖とクライアントが直接通信していないために、インター鯖ではコネロス発生を確認出来ないため。

ゾーン鯖がタイムアウトを確認してインター鯖へ送るまで、キャラはマップ上にどーんと残り続ける事になる。

ガンホーがんばってる

ガンホーがんばってます!とかってのがその昔あった。私はこれは、本当だと思う。AEGISは15年近く前に作られた非常に古いアプリケーションである。Windows98やOffice97を今でも使い続けているのと変わらない、恐らく様々な苦労があるだろう。

パッチアップデートではプレイヤーのニーズを逸脱しまくって不評を買いすぎているのも事実だが、AEGISのような設計不良のモノを現在でも頑張って使っているのは、すごい努力なのだろうと思う。

そんな気持ちもあって、少々熱を入れて書いてみた。

関係ないけど

砦でMVP。ET以外だと凄く久しぶり。
WPが詰まってたところは全部ゾーン移動の発生するWPだった。

ちなみにうちの鯖は1回もクリア出来なかった。