■サーバーの負荷問題の解決の見通しはついているのですか？

[Minna]

面白いスレッドですね。

私も少し書いてみようか・・・。

ラグの原因、それはfeifongさんが書かれているとおり、レスポンス速度が一番問題です。
で、このレスポンス速度は小さなプログラムだとあまり気になりませんが、このような大がかりなC/Sシステムであると、サーバー側で十中八九メモリリーク起こしてます。

他のネットゲームでは、それらを凌ぐために週１メンテナンスを実施しています。この週１のメンテナンス中に何をするかというと・・・

１．サーバープログラムの再起動（メモリリフレッシュ）
２．データベースのRebuild-Index（Index検索を有効活用するため）

この辺りが主にやることです。
特に１．は必須、２．は時間がかなりかかるので３ヶ月に１回が目安かと思いますが。
で、今のFF14ですが・・・・週１メンテなど行っていませんよね？なので時間が経つにつれ、サーバー側でメモリリークを起こしてレスポンス低下を招き
ユーザー（クライアント）側にはそれがラグに写るという事に繋がると考えます。

もちろん、それ以前にサーバープログラムの処理実装がお馬鹿な為、レスポンスが悪いというのも考えられますが、こちらはパッチ毎に少しずつ改善していってるようで・・・。
まだまだ足りませんけどね。（元がどれだけ産廃プログラムだったかという事の裏返しでもありますが）


なので、パッチでのレスポンス改善ももちろん行う必要がありますが、週１メンテを実施するというのも一つの手です。ここまでやっていないのも珍しいというかおかしいくらいなので。

実施曜日は、週の頭や週末を避け、水曜くらいが妥当でしょうね。

[vbsnbk]

週１メンテナンス

確かに他のネトゲでは大抵やってますね。大規模なサービスプログラムではメモリリーク含むバグを根絶するのは難しいので、運営の定期メンテでカバーするというのは現実的な解かもしれません。

今はリテイナー街もサーバ再起動時に配置が記憶されますので、定期メンテのユーザにとってのデメリットは「その時間遊べない」位でしょうかね。他のネトゲと違って全世界サービスをうたってる以上、毎回ピークタイムにメンテが掛かるエリアのユーザにとっては迷惑な話かもしれませんが(苦笑)。

[feifong]

お世話になります。

リークはないんじゃないかな。　「要素数」が変動する要素が少ないし。　設計上、上限を作れる（定められる）サーバだしね
だからこそ、ゲームサーバに手を入れることを極端に恐れているし、実際、ゲームデータ部分のみの変更パッチが殆どだし
DBサーバでリークがあるようなら、冗長化して定期的にノードを再起動すれば、ホットリフレッシュもできるでしょう
競売もないし、DBサーバすら使っていないんじゃないかな。　よくてログアウト時にプレイヤ情報をDBにコミットしている位じゃないかな
まことしやかに書いておりますが、全部妄想です。

最初にオートアタックに手を入れたのだから、それはクライアントからの非同期アクション投入が、サーバ負荷の一番の原因だったのかもですね。
次に来るのは、移動速度制限、エリアの疑似分割、戦闘・行動・表情など結果到達範囲の縮小、可視範囲の縮小、天候エフェクトカットスイッチの追加、初期表示用のキャラクタ装備のプリロード（＝装備読込契機の延伸）、表示キャラクタ数の大幅削減、遠方で移動するPC/NPCの座標情報通知間隔の間引き、シームレスの撤廃、LSチャンネルの一本化、mob移動頻度の削減、友好NPCのモーション決定をクライアントで自動決定（これすらゲームサーバで決定しているような予感）などかな？と妄想している次第です。

今日はまだ飲酒していないので、筆が進みませんので、これにて。　暇つぶしの妄想ネタになれば幸いです


（てか、「かな」ばっかりな駄目な文章…）

[Minna]

お世話になります。

リークはないんじゃないかな。　「要素数」が変動する要素が少ないし。　設計上、上限を作れる（定められる）サーバだしね
だからこそ、ゲームサーバに手を入れることを極端に恐れているし、実際、ゲームデータ部分のみの変更パッチが殆どだし
DBサーバでリークがあるようなら、冗長化して定期的にノードを再起動すれば、ホットリフレッシュもできるでしょう
競売もないし、DBサーバすら使っていないんじゃないかな。　よくてログアウト時にプレイヤ情報をDBにコミットしている位じゃないかな
まことしやかに書いておりますが、全部妄想です。

最初にオートアタックに手を入れたのだから、それはクライアントからの非同期アクション投入が、サーバ負荷の一番の原因だったのかもですね。
次に来るのは、移動速度制限、エリアの疑似分割、戦闘・行動・表情など結果到達範囲の縮小、可視範囲の縮小、天候エフェクトカットスイッチの追加、初期表示用のキャラクタ装備のプリロード（＝装備読込契機の延伸）、表示キャラクタ数の大幅削減、遠方で移動するPC/NPCの座標情報通知間隔の間引き、シームレスの撤廃、LSチャンネルの一本化、mob移動頻度の削減、友好NPCのモーション決定をクライアントで自動決定（これすらゲームサーバで決定しているような予感）などかな？と妄想している次第です。

今日はまだ飲酒していないので、筆が進みませんので、これにて。　暇つぶしの妄想ネタになれば幸いです


（てか、「かな」ばっかりな駄目な文章…）

今のところ、大がかりなシステムでメモリリークしないプログラムはまず組めないでしょう。凄腕プログラマ（Wizard級）が寄って集ってやるなら話は別ですが。
DBサーバーでリークというのは有り得るでしょうがそれほど酷くはない・・・といったイメージ。逆に起こりまくるのはそれは製品として屑です。誰も買わない。
冗長化するならば、今のところOracle RAC一筋じゃないでしょうかね。それ以外の冗長化はゴミ。使い物にならないです。ま、ライセンス料の高いOracleをFF14に使ってるかどうか定かではありませんが。

DBへのコミットは定期的に行われているようです。行われてないとオンラインゲームは巻き戻りの嵐ですけど。
一部、ウィジットを表示したときにコミットしている箇所もあります。（当たり前か＾＾）
例：クラスランクのコミットはステータス＞習得クラスを開いたときに行われる節がある。
　　ランクが上がって習得クラスを見たとき、その時にランク数が書き変わるのを目視出来ることによるもの。お試しあれ。

どのRDBMSを選んでもそうですが、初期パラメータで使用しているとパフォーマンスは全然出ません。この辺りはDBエンジニアの経験がものを言うところです。
少し弄るだけで、劇的にパフォーマンスは変わります。そりゃもう20秒のクエリが1秒以内とかそんな感じで。
また、テーブル正規化も正しく行われており、クエリも高速化を計るような組み立てをしていればここでもパフォーマンスは変わりますね。
逆に、クエリをO/Rマッパなどに任せて動的に組んだ場合、最悪使い物にならないほど遅い。この辺りをどう組んでいるか見てみたいモノですね。

ゲームサーバーの根幹に手が付けられないのは、以下の理由と睨んでいます。

１．コードがスパゲティ過ぎる
２．仕様書/APIドキュメントなどが存在しない。あるのはイミフなコメント行のみ
３．コードが冗長している＝うまくオブジェクトに分離できていない
４．オブジェクト指向で組んだは良いが、メモリ使用率の事を考慮に入れていない

まだまだあるでしょうが、ざっと出るのは上記４つくらいですね。クライアントにも同様のことが言えますけど。
クライアントは画像を読み込み、オンメモリ処理をかけているようなので、同じ場所に滞在していれば全然重くなりません。
しかし、街やマップを移動していると、新しい画像をメモリ上に展開するので、たちまちに重くなります。
通常、使われなくなったメモリ上のオブジェクトは解放してあげるのが世の常ですが、たぶん、現行FF14クライアントはそんなのしていない。
なので、ウル->BWを行き来するだけで、クライアントは激重になっていく。マップでは嵐や雨といったエフェクトもありますので余計にね。
クライアントが重くなると何が起こるか？それは受け取り側での情報ロストですかね・・・普通に考えるならば。
R0の悪魔はこの辺りから来ていると考えています。



ゲームサーバーのメモリリフレッシュ、DBのIndexデフラグ、クライアントのメモリリフレッシュ・・・これらをうまく行うためにも、定期メンテナンスは実施すべき。今からでも遅くない。

余談ですが、何億とRowがあるテーブルのRebuild-Index（Oracle）は、６時間以上かかりましたね・・・。１ヶ月後同じように行ったら２時間ほどで終わりましたが。
あの時は家に帰れないのではとヒヤヒヤしました・・・(´・ω・`)

[Zhar]

DBへのコミットは定期的に行われているようです。行われてないとオンラインゲームは巻き戻りの嵐ですけど。

一点だけ。
FF11では、キャラデータの保持にはDBを使ってないそうです。（それでも実績として、鯖運営の安定性は高かった）
ソースは大昔の（今は亡き）DBマガジンです。運用担当者がそう言ってました。
残念ながら何月号かは失念・・・廃刊のちょい前です。
仮に、基幹周りの設計がFF11を踏襲している場合、FF14もそうだということになりますね。
※FF11サービス開始当初、S&Iとかでやたらとプレゼンしてたアレ（Oracle10gを使った大規模クラスター）は
課金系・POLまで含めた構成の話だった模様です。私も、この話読んだ時割とびっくりしましたよ。

# ちなみにOracle一択ってちょっと違和感あるなあ・・・大規模システムだったらDB2とかの方がマトモだと思うんだけど

[Minna]

一点だけ。
FF11では、キャラデータの保持にはDBを使ってないそうです。（それでも実績として、鯖運営の安定性は高かった）
ソースは大昔の（今は亡き）DBマガジンです。運用担当者がそう言ってました。
残念ながら何月号かは失念・・・廃刊のちょい前です。
仮に、基幹周りの設計がFF11を踏襲している場合、FF14もそうだということになりますね。
※FF11サービス開始当初、S&Iとかでやたらとプレゼンしてたアレ（Oracle10gを使った大規模クラスター）は
課金系・POLまで含めた構成の話だった模様です。私も、この話読んだ時割とびっくりしましたよ。

# ちなみにOracle一択ってちょっと違和感あるなあ・・・大規模システムだったらDB2とかの方がマトモだと思うんだけど

調べてきました。2008年3月号のようですね。また古くのWeb記事ではこの件に関してのカンファレンスも開かれていたようで。
キャラデータをファイルとしてですか・・・。コストがバカ高いですねぇ。（ここでいうコストはストレージのRead/Write）
しかしファイル保存という事ならば、ロドストのヒストリ同期が遅いというのも頷けますね。おそらくキャラクターキャッシュの更新を行う処理がスケジューラで
動いていると考えられますから、そのスケジューラが動くまではロドストで最新ヒストリが閲覧できないとなりますので。

そしてファイルということならば、且つFF11の頃よりも高性能ということならば、おそらくはKVS系の何かでしょうね。ちと難しそうだな・・・。
KVSについては私はあまり知識がないので、深くは語れません。概念的なモノは理解してるんですが・・・(´・ω・`)

OracleもDB2も古くからあるRDBMSであり双方がトップシェアを狙っているのは確かですね。
でもまぁ突き詰めて、パフォーマンス・チューニングを適切に施せばどのRDBMSでもモンスターに化けますが。
トランザクションが多いシーンであるとやはりOracleのトランザクション処理が優秀と言えるかと思います。
シーンに応じた、またコスト面も考えてRDBMSを選ぶのが普通ですねぇ。

某重力のMMOでDBがSQL Serverだったのを知ったときは吹き出しそうになりましたが・・・
それでもFF14の当初のようなラグラグ・ゲームじゃなかったのは確かです。

[Zhar]

調べてきました。2008年3月号のようですね。また古くのWeb記事ではこの件に関してのカンファレンスも開かれていたようで。

おおう、私の適当な書き込みから調べて戴いたんですね。
申し訳ない、古い本はどんどん捨ててるものですから(´Д｀; )ヾ

キャラデータをファイルとしてですか・・・。コストがバカ高いですねぇ。（ここでいうコストはストレージのRead/Write）

どうでしょう？一定以上のリクエスト数がある場合、DBを使ってもその辺のコストって下がらないと私は思うんですが。
むしろ、アプリケーション側の実装で細かく制御できる分、DBを使う方が不利じゃないかと感じます
（なので件の記事は驚きはしましたが、結構ストンと胸に落ちました）

OracleもDB2も古くからあるRDBMSであり双方がトップシェアを狙っているのは確かですね。
でもまぁ突き詰めて、パフォーマンス・チューニングを適切に施せばどのRDBMSでもモンスターに化けますが。
トランザクションが多いシーンであるとやはりOracleのトランザクション処理が優秀と言えるかと思います。
シーンに応じた、またコスト面も考えてRDBMSを選ぶのが普通ですねぇ。

んですね。ですが私はOracleは嫌いです(´∀｀)
某MMOって多分FFTチックなグラのアレかと思いますが、SQL Serverってだけで吹くのはMSに失礼じゃｗ
97の時は随分アレでしたが、2000あたりからだいぶマトモになってきてますよ。
Oracleみたいに細かいパラメータ制御が出来ないので、そういうのを飯の種にしている人は嫌いますが
阿呆なテーブル設計とか阿呆なSQL食わせなきゃいいだけです。
Oracleってそういう馬鹿を力技で捻じ伏せちゃうところがありますからね・・・っと脱線が過ぎるか。失礼ｗ

[Minna]

おおう、私の適当な書き込みから調べて戴いたんですね。
申し訳ない、古い本はどんどん捨ててるものですから(´Д｀; )ヾ

こういうとき、デジタルデータで保存しておくとかさばらなくて良いですよねぇ・・・。
デジタルだと今ならスマホとかで通勤・通学中に読めたりしますし。
オライリーがんばれ！（謎）

どうでしょう？一定以上のリクエスト数がある場合、DBを使ってもその辺のコストって下がらないと私は思うんですが。
むしろ、アプリケーション側の実装で細かく制御できる分、DBを使う方が不利じゃないかと感じます
（なので件の記事は驚きはしましたが、結構ストンと胸に落ちました）

実装を複雑にするか、それともRDBMSにお任せするか・・・どちらかだと思います。
後々のことも考えると、実装は簡素で良い・・・改良しやすいし(´・ω・`)
もちろん、様々なコストを考えた実装をしていただかないと、どちらでも「おばかさぁ～ん」って田中理恵声で罵ってもらううことになりますが。

んですね。ですが私はOracleは嫌いです(´∀｀)
某MMOって多分FFTチックなグラのアレかと思いますが、SQL Serverってだけで吹くのはMSに失礼じゃｗ
97の時は随分アレでしたが、2000あたりからだいぶマトモになってきてますよ。
Oracleみたいに細かいパラメータ制御が出来ないので、そういうのを飯の種にしている人は嫌いますが
阿呆なテーブル設計とか阿呆なSQL食わせなきゃいいだけです。
Oracleってそういう馬鹿を力技で捻じ伏せちゃうところがありますからね・・・っと脱線が過ぎるか。失礼ｗ

その力技でもねじ伏せられないクエリを近頃見ましたよ。制作者表へ出ろ！と心の中で叫びました。
SQL Serverは土台がWindows・・・という段階でアウトーーーー！セキュリティパッチ毎にダウンタイムとか嫌だよもん・・・
しかもパッチの影響でいろいろ動かなくなることもしばしば・・・もっと嫌だよもん(´・ω・`)


おっと・・・ゲームから大分逸れてしまった・・・。技術系の話は面白いのでついつい・・・。
あまり逸れるとRepさんに私の存在を消されてしまう or リアルで３時間遊んでこい！コースを選ばれてしまうので、自重しておきます。

[Gilgamesh]

技術系の話が、エラいＬｖで展開されてるので、私からしてみれば「神々の討論会」にしか見えなかったヨ(；´Д｀)

　サーバーの負荷問題に関してなのですが､コレって実言えば「クローズドβテスト」の段階で解決されるべき問題じゃなかったのかなと、今にして思えば感じており､元βテスターとしては、口惜しい所でもあります。

　なんでこんな事を思ったのかと言うと､今月頭ごろ、このフォーラムでも｢チョッピリ吹き荒れた」”とあるネトゲの「クローズドβテスト」”での出来事がキッカケなのです。

　というのも、その「クローズドβテスト」が開始されたのは午後４時、私が参加したのが､午後８時を過ぎていたのですが、そのときの「とあるネトゲ」の状態と言えば・・・ＦＦ１４を「はるかに上回る」激烈級のラグに襲われていたのです。

（普通に動いても、超スローモーション状態だったのです。周りに人が居なくてＭｏｂばかりになってもね。ＵＩの反応速度も､ＦＦ１４の開始当初”よりも”遅かったです。開始当初のＦＦ１４を普通にプレイできるＰＣを以ってしてもね。）

　で、開始して約１０分後・・・運営側より「只今から緊急メンテナンスに入ります。メンテナンスが明けるのは、午後１０時半を予定しております」という緊急アナウンスが入り､全員が強制ログアウト。

　その後､午後１０時半を回って、再度ログインしてみたら・・・そこは正しく「別世界か！！」と思えるほど、ラグが殆ど無くなった「とあるネトゲ」の姿だったのです。

　そのときのチャットウィンドウは、「よくやった！！！」「おめでとう！！」という歓声で埋め尽くされました｡

　クローズドβテスト後に放送された､公式のＵＳＴ番組内（しかも、日本側の総合Ｐ自ら出てきてます）にて、こんな発言をなさってました。

　「ユーザーに､『サーバーの数が少なかったから、重かったんでしょう？』とブログ等に書かれたりしましたが､あれは当初の予定通りでした｡ところが、予期せぬ別のトラブルが発生してしまい､初日の緊急メンテということになってしまいました。こういうことを発見することも､クローズドβテストの目的なんです」

　正に「目から鱗が落ちた」と同時に､「コレ（ＦＦ１４）のクローズドβの時に、なんで「全体的に付きまとうラグ」を指摘できなかったんだ」と自らの知識力の無さを反省した次第です・・・。

　少々負荷問題とは関係が無い文になっちまったかもしれませんが､元βテスターの「くやしさ」を判ってもらえれば幸いです・・・。

[Kristina_Farron]

CBの時点いろいろ指摘されても改修する気 (時間?) すらなかったよ。
UIと戦闘まわりのバグつぶしだけ手一杯。
そういえばFF11の時PS2 CBがかなり長期間で進行、一旦安定化した段階になってから発売だったけど、
やっぱり「αより毛は生えた」状態で14の強行発売を決めたトップは一番いけない・・・