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

[haiiromikotte]

TPリアルタイム表示と敵につけたマークの表示などの影響と思われますが、その交換として、募集板の名前がフルネームから略称にかわりました。
かなり現状でもキツキツなリアルタイム通信量をどう減らすかという問題があると思います。
　
サーバー間募集ではかなりリアルタイムでやり取りする情報量が増えます。
特に所属サーバーの情報はかなり大きくのしかかってくると思います。
おそらく、マッチングの方法などよりも、そこが一番のネックで実装が出来ないんだと今までのPLLでの吉Pの発言から想像します。
　
そうなると、Notonさんが図で出してくれた一例はあまりにもそれに逆行している気がします。（今の募集板よりもリアルタイムで情報をやり取りしなければいけない情報が飛びぬけて増える危険性がある。）
たぶん、そこをどう減らすか、ですが･･･
一番削れるのは板内の自由コメ欄でしょうか。ここは文字数を減らすか、コメ欄自体をなくすかしかないのかなと思います。
あとはジョブ構成ですかね。ロール構成までは指定できるでしょうが、ジョブ構成までの指定は難しくなるような気がします。
あとは最大表示人数かな？と思います。
ただ、そうなると一極集中しかねないクエストをこれ以降実装しようとすると、モブハント実装時や一時期の人気FATEと同じような「表示されない」問題がでてくる危険性が･･･。
　
板はリアルタイム性が大事ですから、リアルタイムにしないとかなり問題がでてきそうですし。
　
信長の野望オンラインだったかと思いますが、キャラ情報を削るために他キャラクターを極力黒子にして黒子が街中やフィールドを移動している仕様にしていた記憶があります。
あれならばかなり通信量を減らせるはず･･･。
ただ、私たちプレーヤー側がのっぺら黒子が街中を歩き回る姿を容認できるかとか別の問題があるかな。。。
　
あとはキャラメイク時の自由度の制限くらいしか思いつかないですね･･･。

[noton-noton]

略

＞コンテンツマッチ処理の待ち行列をキャッシュする必要があるでしょう？

いらなんじゃないですか？
コンテンツマッチ処理も、ユーザーのアクセスと非同期だからです。
データーの追加処理は、末尾に追加していくだけですから全体を参照する必要ありませんし。

仮に今のシステムで使っているなら、その範疇を超えるようなことになるのでしょうか？
しかも、処理ごとにデーターの内容が変化するので、キャッシュする意味がありません。

高速性を保持したいなら、オンメモリで十分でしょう。


あとですね。通常のCF処理の利用者のほうが圧倒的に数が多い中、僅かな「募集」をそこに混ぜると、大量の通信問題？が発生するというご意見は如何なものでしょうか？
何度もお伝えしていますが、一連の処理はユーザーの通信とは非同期なので、高速性を求められていません。

部分分に分解してお聞きします。
１）募集の登録部分（既存とほぼ同じ　数十バイトの追加データー）
２）募集から、外部サーバー利用を希望している募集を選択する部分（処理）
３）募集ワールドサーバーから、CFサーバーへ登録する処理
４）CF上におけるマッチング処理（既存とほぼ同じ）

どの部分に、どういった理由で必要ですか？
既にキャッシュなどは既存のシステムにも実装されているでしょうから、この新しい機能に対して必要な部分をお願いします。

[noton-noton]

略

＞TPリアルタイム表示と敵につけたマークの表示などの影響と思われますが、その交換として、募集板の名前がフルネームから略称にかわりました。

その因果関係はたぶん関係ないのでは？
募集板の名前は、レイアウト的な話だと思います
TPリアルタイムは、PS3の画面処理の関係ではないでしょうか？　その代わりPTボーナスの表示場所がPT一覧に移りました。

＞サーバー間募集ではかなりリアルタイムでやり取りする情報量が増えます。
リアルタイムの情報の定義は？

＞所属サーバーの情報
INDEXですむから、2バイトで済みそうな・・・

＞（今の募集板よりもリアルタイムで情報をやり取りしなければいけない情報が飛びぬけて増える危険性がある。）
私の考えている募集板は、外部ユーザーが全て揃った段階でシャキーん処理にうつります。
（途中はない）
そういう意味では、クライアントとの情報量はかわりません。

情報量は時間に対して多いかが重要です。
書き込みを見ていると総量を気にされているようですが、アクセスしていないデーターが増えても、通信トラフィックは増えません。

募集板は更新ボタンを押さないと、データーは更新されません。
リアルタイム処理ではありません。

クライアントの通信情報量なら、募集板で募集の内容を考えて登録する処理より、IDで遊んでいるときのほうが増えます。

[Seev]

前置き～
まずは拙い図への反応ありがとうございます。何言ってんだコイツと一蹴されなくてホッとしてます。
いくつか書き込みや頂いた意見を拾って補足を述べたいと思います。

まずWorldサーバの構成についてですが、確かに「○○エリアが落ちた～」等の話を聞くので、内部は複数のサーバに分かれていると考えるのが自然ですかね。
仮に1サーバでやっているとしても各プロセスが分離されていると思うので、一概に「Worldサーバ」と一つにしたのがまずかったかもしれません。
ただまぁ外部から見た場合「Wrold」というのは一つのIPに紐付いており、IPが切り離されている他Worldよりは近い（密な）状態になっていうとは思うので、
例えサーバが分かれていたとしても一つのWorldサーバが持つ各役割を「プロセス」と呼称したいと思います。
（外部から見たらいくつだろうと、中から見たら全部分かれてて一緒だろってツッコミはあるかも！でもあくまでイメージ！）
～前置き終了

・【現行の募集掲示板と、提案の募集サーバの違いについて】
私は一つのWorldサーバには複数のプロセスが紐付いていて、各々が自分の領分を管理していると考えています。
　チャットプロセス（どのエリアでもPT会話は見えるとか）
　エリアプロセス*n（エリア毎のキャラ位置とか、バトル情報とか？）
　パーティプロセス（誰がどのPTに入ってるとか。類似でFCプロセスとか）
で、現行の募集掲示板はあくまでこの中の1プロセスだと思っています。
　PT募集プロセス（誰がどんな募集してるとか残り時間とか）

そしてPT募集プロセスとはPT処理の受け渡しをするだけなので、申請が来たらパーティプロセスに投げて終わりという機能です。
このため、募集掲示板にはWorld間通信を行う仕組みもCF申請を行う仕組みも無く大した拡張性も無い。
つまり「現行の募集掲示板の機能を拡張して、サーバ間募集を行おう」という試み自体が「このままでは無理」なのではと思っています。
（言わば「PTの仲介」をやっているだけなので、サーバ間でPTが組めない以上この仕組には乗れない）

そこで提案している募集サーバは、「現行の仕組みとは全く異なり、CFの仲介を行う機能を作ろう」という提案です。

続きます（毎度長くてすいません）

[Seev]

例えるなら現行の募集掲示板がやっている事は、○イーダの酒場のお姉さんです。
　「姉ちゃん。なんかいい仕事ねぇか」
　「そうねぇ。こんな募集ならあるわよ」
　「そうだな……これにするか」
　「わかった。リーダーに連絡を取ってあげる」
という。（なんだこの小芝居。書き込んだあと羞恥で悶える気がする）

これに対して提案している機能は本来の意味での「掲示板」です
　「挑戦者求む！　詳しくは○○まで」
　「これから○○へ行きます。同行者募集中」
といったイメージ。

このためリアルタイム性はありませんが用途としては最低限を確保しており、
手続き処理自体は既存のCFが行ってくれるので、これ自体に大きな機能付与は必要ありません。

また、DC内全サーバから閲覧される負荷についても書かれていますが、
これは、複雑な処理を行っているWorldサーバと切り離し比較的な単純な別サーバ化することで
負荷状況に合わせて分散サーバ等を持つことで解決出来ないかなと考えていました。
（完全に別サーバに置くので極論同じDCに置く必要すら無く、よくあるクラウド型の時間単価サーバ使うとか……セキュリティ的に無理か）
募集情報は募集サーバ間でのみ同期処理を取ればよいので、それ自体はWroldサーバやCFサーバに影響を与えません。


あと、携帯等からの閲覧・書き込みについてですが、Web＝HTTPだろうって安直に考えてしまいましたが、
ライブラエオルゼアアプリの中に専用プロトコルを解釈する仕組みを乗っけてしまえば独自プロトコルだろうとなんだろうと問題なかったですね。
しかもID情報なんかを自前で持ってるからHTMLに比べ文字情報等も節約出来るし。


以上、「リアルタイムは無理なら諦めてしまえ！」「ブッキングしたら後から来た方諦めろ！」
というように割り切った後ろ向きな対応案なので、決して最善な案では無いと思っていますが。補足まででした。

[btk]

＞Tonpooさん
これは自分も見たことありますね。
このページにある、「多くのオンラインゲーム」がFFXIVの例です。
DQXのほうは、1ワールドの多チャンネルで、全体として一つのDBを持っているという構造になってますね。そのため、その一つのDBに対しての性能要求が極めて高く、以下の商品でそれを実現しているそうです。
https://www.oracle.com/jp/corporate/...p20150427.html

＞MisatoMisaさん
Ciscoの製品事例にでてるんですねー、これは初めてみました！
社内システムでの採用事例のようですのでゲーム側のネットワークとは別かと思いますが、Cisco強いですね。

＞haiiromikotteさん
えっとですね、それはちょっとまた別の話になってしまいますね。notonさんも言及されていますが。
＞TPリアルタイム表示と敵につけたマークの表示などの影響と思われますが、その交換として、募集板の名前がフルネームから略称にかわりました。
このトレードオフは、マッチングなどの処理を行うサーバではなく描画を行うクライアント側の問題ですね。よくいうメモリガーの一例ですが。
今回の議論の焦点となるのはクライアント側の性能ではないので、haiiromikotteさんの懸念については、あまり問題にならないと思います。
ご意見ありがとうございます！

[btk]

◆実装方法について
・btk案
DC内の各APサーバ経由でユーザからのRead/Writeが行われるRDBもしくはNoSQL,KVSサーバ（まぁこれはできりゃーなんでもいいですね）を新設
そのサーバはユーザアクセスによりリアルタイムにr/wが入る -> 要求性能が高くなる可能性が高い（吉田P/Dの言葉を信頼するなら100,000rpsをさばける性能が必要？）

・notonさん案(自分が理解しきれていない部分がありますので、補足・修正いただけますと助かります！)
既存のCFサーバ（CFサーバはDC内ワールド跨ぎの処理が既に可能）に、PT募集欄経由でキュー（という認識であってます？）を積むシーケンスを新規実装
->ユーザが募集掲示板を見た時に、サーバ跨ぎのPT募集状況の閲覧はどういう経路で行われるのでしょうか？CFにつまれてるキューの中身を舐めるイメージ？そもそもそれは実装されない？
・参加を希望するプレイヤーがDC内PT募集を確認し、参加を行うのは既存のCFからコンテンツへ参加するシーケンスと同等の流れ？

↑上記について、確認、訂正いただければと思います。

CFでのコンテンツ参加シーケンスを流用し、またそれはプレイヤーのアクセスとはリアルタイムで同期しなく、またそもそも参照も不可というのであれば
仰る通りハードウェアの追加もいらないと思います。仕様で制限を設けることで、コストカットを実現する例になりますね。

・Seevさん案
・募集サーバを新設（btk案といっしょ
ただし、リアルタイム性はある程度あきらめる。
->どの程度まであきらめて、逆にどの程度を確保するのが望ましいでしょうか？
ブッキングしたらあとから来たほうあきらめろ！は既存のPT募集もいっしょですね。おそらくここの間隔が長くなる、ことは予想されるかと思います。

ちなみに、現在のPT募集はリストの再取得を行うと１度の取得で３～５秒程度「前回の検索結果を取得中です。」のエラーになります。
おそらく連続クリックによる負荷対策の一環だと思いますが、ここの間隔をさらに長くすることで、ある程度の負荷対策にはなるかと思います。

単純計算で、100,000ユーザの同時アクセスがあった場合に、一人当たり更新可能な間隔を１０秒に１度とすると要求性能としては10分の１になりますね。


引き続き、おもしろそーと思った方はぜひぜひお気軽にご意見お寄せくださいませ～

[Asakusa]

うむ、よくわからん。

鯖跨いで募集かけれる仕様はとても興味があるので水を撒きに来ました。
考えれば考えるだけ負荷ガーになってると思うので、CF方式に近い方式でキューを分けた方が良いんじゃないでしょうか。
カテゴリー分け　→　細分化　→　要項　→　応募　って流れで。
例えると
蛮神戦　→　〇〇戦　→　練習PT!　→　ぽち　ってイメージで。

Seevさんの独り小芝居にニヤニヤしてしまいましたが…いい案だとおもうよ！
単純に日本にあるデータセンターを一括してくれりゃそれで十分嬉しい気もしますが…ダメっすかｗ

[Keroliane]

中々興味深いスレですねぇ。
細かいことはさっぱりわかりませんが(´･ω･`)

一つ気になったのは、マッチング処理はリアルタイムじゃない案でしょうか。
詳しいことは良くわからないですが、リアルタイムにマッチングされない、PT募集状況が更新されないということは
以下のような状況が起きる可能性があるって事です？

（仮に５分間隔でマッチングするとして）

0：00　PT募集を掲載する
1：00　PT募集を見たリューサンAが参加ポチる　←　まだマッチングされてないからPT募集は埋まらない
1：10　同じくPT募集を見たリューサンBが参加ポチる　←　すでに予約が入ってるけどマッチングされてないから予約が出来る
・
・
・
5：00　リューサンA＜4分待ったけど入れたヤッター
　　　　リューサンB＜4分近く待ったのに締め切られましたってなんだよそれ

例では2人ですけど、人気の募集（埋まりやすい枠）なんかはもっと人が集まってくると思うんですよね。
その度に多くの人がなんだよそれ(´･ω･`)って状態になるんじゃないかなぁと。
マッチングが一定間隔でしか行われないとなるとその間は結果待ちで何もできないわけですし、流石にストレスがすごいことになりそうな気がします。

どれくらいの間隔でマッチング処理をするかにもよるんでしょうけれども、その辺って大丈夫なんでしょうか。

[Dainopu]

ソフトウェア開発の基本は、
「要求(機能)定義」→「仕様起こし」→「実装」
なわけで、
最初の2つが曖昧なまま(完成系の仕様が統一されないまま)議論しても、
あんまり意味が無い気がしますけど…。

たぶん、ここに書き込みを行っている方それぞれで、
イメージしているものが大なり小なり違っている気がしますし。