野生のエンジニアたちが、サーバ跨ぎのPT募集実装に向けてアレコレ議論するスレッド

[Paradice]

うーん…静観してましたけどそろそろツッコミたくなってきた。
なんか物凄く根本的なとこ無視してるので勘違いな方向にぶっ飛んでる気がするんですよね。
開発がサーバガ+コストガのproc発動させてる原因をそもそもちゃんと予測出来てないんじゃないかと。

今回開発から出てる言葉は技術的な難色ではなく、設備的な難色です。
これは元スレの方でも話した通り、この機能を置くならCFマッチングサーバが条件として合うが、
そこに機能を足すことでの「CFマッチングサーバの」トラフィック増にサーバが耐えられないから足さないと厳しいってとこですよね。

じゃ、トラフィック増によってへたるのってどこ？っていうのを考える必要があると思います。
ネットワークに関しちゃ所謂ビッグデータなんていうFFの何倍もトラフィックのあるものでもイーサネットで賄えます。
つまりDC内の通信設備の問題じゃないんです。
まぁDC跨ぎとかになるとロケールの違いなんかもあるので通信設備的な問題も出るかと思いますが
CF機能の範囲の話であればわざわざコストの高いInfiniBandとか導入してもオーバースペックでしかない。

では問題はなに？って言うと、その増大したアクセスによるアクティブスレッド数の増加っていう点です。
ゲームなんかだとどうしてもKeep-Aliveな接続を必要とするので、それが一局集中することでCPU、メモリ負荷が跳ね上がる。
これによって本来提供しているCF機能にも遅延、障害を生む可能性があるレベルのトラフィック増が見えてるからこそ「サーバ増設」っていう見解なんだと思います。
おそらくこの要望に関してはここをクリアしない限り実装が難しいのかなと自分は考えますが、
エンジニアとして談義するならこの辺飛び越えて機能の話をしても…と言うのが正直な感想ですね。
エンジニアだとしてもインフラ考えたことのないコンテンツ系のアプリ屋さんの発想かなと。

まだワールド統合整理で空くサーバを当てて実現できないか→ワールド統合のネックは何か
とかの方が目がある様に思います。
また、そういう意味では元スレのタイトルは意外と的を射たものだったりしたなーと思ってます。

[F-DUCT]

>not on-notonさん

ご説明ありがとうございます。
ほぼおっしゃってるイメージは掴めました。
特に募集側で固定の補充などでは便利そうです。
通常の募集板と並行してできるのは素敵ですね。
気になるのはやはり応募側の方でしょうか。
プリセットの項目も限界あるでしょうしね……

[noton-noton]

HarukaPhilantha　さんへ

募集前のチャット等については、技術的側面より、実際に機能として必要かどうか？
これをまず考えたほうが良いでしょうね。

折角機能があったとしても、募集が揃う前に離しても無駄

「よろしくー」しか伝えないのであるなら、中で揃ってからでも遅くない…など。

技術面と関係なく考えられます。


＞ってココまで書いて思ったのは、クライアント（発注）側の立場がいないとやりづらいんだってことですね。
スレットタイトルから、書き込みを遠慮されているのかもしれませんね。
色々な書き込みがあった方が盛り上がるので、私は歓迎ですけど


F-DUCTさんへ
ありがとうございます。
万能ではありませんからね。ただ無いよりはあった方が助かると思います。

[noton-noton]

Paradiceさんへ

ご意見ありがとうございます。
トラフィックの増加について懸念されているようですが、私はこれに対して楽観視しています。

理由の一つが、トラフィックが問題になるぐらい「募集が立ち」かつ「それに興味があるプレイヤー」が存在するなら、
そもそもこの機能が必要ないからです。
裏を返せば、そんなに利用者は増えない事が予測できます。

募集に集まらないから必要とされているのですからね。

また、最初の提案の時にも書きましたが、「パッチ後や混雑時には利用できないようにする」としています。

また現行のCFサーバーに影響があるなら、ほぼ同じ構成で専用のCF2を用意することで対応できるのでは無いでしょうか？
ご指摘のように、一つのサーバーへのトラフィックが問題なら、分散が一番効果があります。


＞ゲームなんかだとどうしてもKeep-Aliveな接続を必要とするので、それが一局集中することでCPU、メモリ負荷が跳ね上がる。
＞これによって本来提供しているCF機能にも遅延、障害を生む可能性があるレベルのトラフィック増が見えてるからこそ「サーバ増設」っていう見解なんだと思います。

CFサーバーにはサービスとして参照はありません。
（状況の表示がありますが、CFが直接返す必要が無い処理なのでここでは問題にしません）

基本的には参加への登録があるだけで、処理が終われば即切断です。
登録のタイミングは、負荷がかからないようなタイミングで遅延登録が可能です。
（ユーザーに挙動が見えないため）

また、CFへの登録を待つために、APサーバー＜＞CFサーバーのAliveをOnにする必要はないでしょう。

また、ワールドとの接続と違って、CFや募集は使い終われば直ぐに接続を切っても問題ありません。
ここがリアルタイム処理とは違うところです。

ところで、CFに影響がある予測ですが、どれぐらいの募集数の増加と、閲覧数の増加を見込んでの事なのでしょうか？
また、何故一極集中するのでしょうか？　この機能が実装されると、プレイヤーは一斉にCFに登録するのでしょうか？
CFの利用者が何％増えると、問題になるのでしょうか？

私は、Sモブハントのリアルタイム処理の方が、負荷がかかってると思います。

[Paradice]

モブハンの負荷は自分が体感しやすいクライアントの負荷だからそう見えるだけですね
そもそもエリア内各所で100人くらいが同時に戦闘行為を行ったとしても集まってなければサーバ負荷がないと言うわけじゃないですよね。
なのでそれこそ「負荷はたいして変わらない」です。
まぁフィールド過疎り気味だから変わるってのは違う話なのでこれ以上はご自身で考えて欲しいですが。
対して、CFはどこにいるユーザだろうがアクセスでき、かつ状況のポーリング、マッチングのプッシュ等の双方向アクセスもある機能です。
サーバ同時ログイン数の多いゴールデンタイムに3割のユーザが利用した
として、どちらの負荷が高いかなんてのは言うまでもないですよね
且つ、あれはクロスワールドなのでそれがワールドの人数比例でさらに倍、3倍と言うものです。
ここに機能を足すと言うことは更にCFサーバへの負荷を上げると言うことになります。
先ほど3割としたものが仮に4割になったとしても相当なものですよね。この状況をさして「一極集中」と表現したまでです。
少なくともサーバ側で最も過負荷である部分はログインサーバかCFのどちらかと言うレベルだとは思います。
この様なユーザからも見えるところと開発の発言から類推して、と言うのが先の内容です。

あと、数字は1ユーザである自分には知り様もないですが、その質問でどんな答えを期待しているのでしょうか。

[noton-noton]

Paradice　さんへ
＞CFはどこにいるユーザだろうがアクセスでき、かつ状況のポーリング、マッチングのプッシュ等の双方向アクセスもある機能です。

CF機能は、CFサーバーがユーザーとは直接通信はしていないでしょうね。
募集情報をいったんAPサーバが受け取って、CFのキューにポストするだけじゃないかな？
（ここでAPとCFはいったん切断）

CFサーバーはCPUレベルのループではなく、１秒置き程度のゆっくりしたタイミングで処理
キューから募集データーを取り出せばいいのだし。（ここでは通信は発生しない）
非同期だから、（CPU・メモリ）リソースの許す範囲で順番にアクセスする事が仕様上許されます。

最悪、マッチング速度を遅くすることで、処理の時間当たりの負荷は下げられます。

マッチ後は、PT情報を処理用のプロセスキューにポスト、　
・APサーバーにクライアントで確認ダイアログを出す命令を送信、レスポンスを待つ（あくまでAPとクライアントの通信）
・失敗した場合（全員の同意を得られない）は成功している部分を、CFへ再ポスト
・成功した時はCF処理フェーズへ

相手のレスポンスが帰るまで、待つようなプログラム設計にはしてないと思いますよ。

もともとCFはクロスサーバーだから、機能を追加したら（能力を超える通信が）大幅に増えるというご意見にも疑問符が付きます。

ところで、CFでKeep-Alive Onが必要な部分はどこでしょうか？

[noton-noton]

＞あと、数字は1ユーザである自分には知り様もないですが、その質問でどんな答えを期待しているのでしょうか。

GTの募集数を観れば、おのずと数字が想定できませんかね？
約１０サーバー分の、エンドコンテンツの募集の数は幾つでしょうか？

ざっくりと２００前後ではないでしょうか？
２割増えても４０募集分

自動的に、その募集をCFに組み込んだとして、CFの利用が４０増えたら機能が止まるような話？？？

募集をCFに混ぜても大丈夫ではないですかね？

[Paradice]

まぁ簡単に考えてもエリア移動で別サーバへの接続仕直しが発生し、且つその際にCFの申請状態は維持されてなきゃいけないってことは
CF登録のコンテンツ表示が出てる間、クライアントはCF用に1つスレッドを確保してます。
エリア移動中にシャキったとか、まぁ普通にプレイしてても経験しますよね

ということはゲーム本体を司るサーバプログラムとは切り離されたところでセッションをキープしてるのは明白です
これがCFとの継続的なセッションがある証拠かなと思いますが

少なくともマッチング完了してからコンテンツへの移動はクライアント処理です
マッチングの組み合わせそのものはキュー処理としてIDなりで行っているとしても
クライアントとのやり取りはリアルタイム性を保持してますよ？
このことはフォーラムひっくり返しても「取り消したのにマッチングされた」という話がないことからも間違いないと思います
少なくとも1秒もラグを持っているならクライアント処理で取り消してるのに通知を受け取るというアホな動作が起こりかねません
また接続しているセッションを右のサーバから左のサーバへクライアントに気付かれずなんて手法はやろうと思えばできなくはないでしょうが
新生時にシームレスを断念しているところからもそうではないと見てとれます

まぁとはいえあくまでも自分の憶測ですから正しいのかは不明ですが

[Paradice]

募集の登録数だけが増えるトラフィックだと思ってるなら見積もりが甘々です
応募しようか閲覧していいのがないから閉じる
これだけでもアクセスは発生しますよね

たからこそ本当の負荷はユーザには「分からない」と言っているのですが

[noton-noton]

Paradice　さんへ
まず登録時には、キューへのポストで処理しているということでよろしいですね？

＞エリア移動中にシャキったとか、まぁ普通にプレイしてても経験しますよね
これは、通常のエリア処理とCFマッチングが別である事の証明でしかありません。

＞クライアントとのやり取りはリアルタイム性を保持してますよ？
DC内部のトラフィックのを問題にされてましたよね？
そこは（クライアント　APサーバ間）、最初から否定していません。

（募集が成立するまでセッションを維持する事はやらないでしょう、
３０秒間維持する通信が発生するのは、PTマッチングが終わった後ですよね？）


クライアントとAPサーバーの間なら、APサーバーは並列化されているので、
そこの通信が増えても、貴方が指摘しているセッションは増えても問題ないはずです。
（そのためのAP並列化だから）

＞このことはフォーラムひっくり返しても「取り消したのにマッチングされた」という話がないことからも間違いないと思います
取り消しができるということは、いったん仮マッチングが終了しています、動きとしては問題ありません。
（マッチングされて、確認ダイアログが表示されないと拒否できない）
全員が揃ったのを確認して、成功以外はすべて失敗する　という仕組みではないでしょうか？

いずれにしても、APとクライアント間が通信を維持してる間に、APとCFが通信維持しているという話ではないでしょう。
（そちらは維持する理由がありませんからね）

＞応募しようか閲覧していいのがないから閉じる　これだけでもアクセスは発生しますよね

ユーザーが増えて、アクセスが増えることを否定してはいませんよ。
システムを揺るがすような事が起きますか？　という事なのですが。

もしこれがCFに限った話なら、申し込みをするまでは通信は発生しません。（定型のあのメニューはクライアントが処理できるので）

募集の閲覧では通信が発生するので、減らす方法を考えるのがこのスレッドの目的ですよｂ
折角、このスレッドに参加していただけるのなら、成功する方へお知恵をお借りしたいと思います。