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

[btk]

Seevさんの図、わかりやすくていいですねー
構成図や通信の流れをきれーにかける人は大事ですｗ

JobフィルタとILフィルタですが、これはPTに参加するときに条件を満たしてるかどうか、という判定を司る部分だと思います。アプリケーション層ですね。
で、これはそもそもＰＴ募集掲示板には既に実装されているものですよね。
なので、自分としては「既存のＰＴ募集掲示板プロセスを機能として独立させて、ＤＣ内全サーバからの通信を受け付ける募集サーバに実装する」が、一番シンプルでわかりやすいと思ってます
※ただし、通信量はめっちゃ増える

＞２．PTマッチングシステム
これが今回必要とされている「ＤＣ内ワールド跨ぎＰＴ募集機能」でしょうかね、

＞３．CF募集掲示システム
逆にこちらはおまけですね、できるならこれもあっていいと思います。
全体的に、どのコンテンツが人気なのか、というのが目に見える機能といったイメージでしょうか？
※逆に、人が集まってないコンテンツはあー人いないんだとあきらめを加速するような気もしますね。。

[btk]

>notonさん
んんんん、やっぱりそもそも僕といろいろ認識違うところがありそうですね、、

そもそもキャラデータはキャラデータ用のDBが持っており、キャラごとにユニークなID（プライマリキー）に紐づくテーブルにデータが各々入っていると思います。
これはデータ量が膨大なのでオンメモリでは処理しません。
※逆にオンメモリで処理するのは、HPや各スキルのCTなどの、バトルなどでシビアなレイテンシが要求されるデータですね。こちらはDBではなくKVSの類で実装されてると思います。
※※DB,KVSと書いてますがどちらもそれぞれ独自実装のなんかすごいの使ってるんじゃないかなぁとも思います

＞・レベル情報はルーレット等の動作から、すでに検索項目、マッチング情報に含まれていると思います。
含まれている、というよりも通常のエリアサーバにいようがコンテンツサーバにいようが裏のDBとやりとりしているので含まれている、という表現はちっと？ですね

また、いわゆるルイーダの酒場案ですが、個人的に一番懸念点となるのはエリアとしての情報を維持しないといけない、ということになると思います。
通常のエリアとして実装されるのであれば、それに耐えうるだけのコストが当然必要になるので、、見た目にはすごいわかりやすくていいと思うんですけどね。


引き続き、「ワールド跨ぎのPT募集機能」について、こーいうのがほしい！というご意見お待ちしております

============================================================

通信とその量について

たいへんわかりやすいですね！概ね同意ですが、ちょろっと質問が。。

＞多くのサーバーでも、この方式が取られていますが、サーバー間通信では、データーをパケットに分離して送る方法は無駄が多いので、
＞特に速度が求められるシステムでは、光ファイバーを使って効率の良いファイル転送を使います。
んんんん、そんなことあります・・？？それネットワーク層どんな実装になってるんだろう。。
TCPの信頼性を捨てて得られる高速な処理って、僕が知らないだけなのかもしらないけどちょっとわかんないですね。。
notonさんの説明されている内容に関するRFCあったら教えてほしいです。

[noton-noton]

InfiniBand
ttps://ja.wikipedia.org/wiki/InfiniBand

InfiniBand(インフィニバンド)とは、非常に高いRAS（信頼性・可用性・保守性)を持つ基幹系・HPC系のサーバ/クラスター用高速I/Oバスアーキテクチャ及びインターコネクトのこと。

ネットワーク構成
InfiniBandではEthernetのような階層型ネットワークと異なり、スイッチ型ファブリック接続を採用している。

ーーーーーーーーー
PCIバスを使う
Myrinet


FC-SAN 【 Fibre Channel Storage Area Network 】
SANは大規模なサーバコンピュータの記憶装置として利用されるもので、ストレージ間、および、サーバとストレージとの間を高速な通信ネットワークで相互に結ぶ。FC-SANではこれをFibre Channelによって実現し、装置間の接続には光ファイバーが、通信プロトコルにはFCP（Fibre Channel Protocol：ファイバーチャネルプロトコル）が用いられる。

こんなところでしょうか

ーーー
＞オンメモリ
オンメモリなのは、募集とマッチングに必用な最低限のデーターだと思われます。

キャラのIDコードで紐づいたデーターは、おそらくキャッシュに乗せられているのではないでしょうか？（更新はDBへ）　ここの認識はそれ程違っていないと思います。

[noton-noton]

色々考察：

CFサーバーには既にサーバーグループとの物理的な配線実装済み。

自動マッチング：
CFサーバーで、機能がひとつしか持てないという事はありえませんので、拡張された部分はCFの別途アプリケーションでカバーできると思われます。


募集掲示板を閲覧する方法：

この方法の成功の鍵は、いかに無駄な募集板の閲覧を減らせるか？　にかかっています。
＞（募集内容やコメントを確認するための通信オーバーヘッド、一時的なPTの置き場、事前に会話するためのチャットシステムなど）

今の募集板の表示だと、募集全てを表示してしまうため、これを減らすルールが必要です。
ひとつが、募集を出す側が「サーバー間募集を使う」と選択式にすることと、
8人PTのみにすること
対象外の募集は閲覧しない

さらに、サーバー間　募集板を除く際は、通常の募集板とは別に参照できる機能を別に設けて、
「条件をあらかじめ入れてから」募集閲覧ができるようにすると閲覧数が減ります。

「2層、練習PT」この条件で最初から減らせば、例え全サーバーを対象に検索をかけても、結果が絞られているために、通信コストが抑えられます。
（強制的に設定させる）

ここまで減らせた場合、募集メッセージの確認などは、
ワールド内であろうが外であろうが、配線さえつながっていれば、通信コスト的な事は誤差の範囲だと思われます。
（問題はその配線のほうなのですが）

データセンター
　・グループ1
Aegis／Atomos／Carbuncle／Garuda／Gungnir／
Kujata／Ramuh／Tonberry／Typhon／Unicorn

　・グループ2
Alexander／Bahamut／Durandal／Fenrir／Ifrit／
Ridill／Tiamat／Ultima／Valefor／Yojimbo／Zeromus

　・グループ3
Anima／Chocobo／Hades／Ixion／Mandragora／
Masamune／Pandaemonium／Titan／Asura／Belias

こうしてみると、１グループに約10ワールドがありますので、グループまで超えて募集できるようにしなくても
良いのではないでしょうか？

[yoshi_mal]

きっとUDPでも使っているんだろう（白目）

[noton-noton]

FF14構造　（予想）


APサーバーとワールドサーバーをつなぐ部分、コンテンツ接続の部分が得に高速性が要求される
また、キャラクターデーターはオンライン中はキャッシュに展開。
更新は、DBとキャッシュに同時に行われる

yoshi_mal　さんへ
＞UDP
TCP/IP以外のプロトコルがあるのですよ。
ハイエンドでは、既にパケット通信の限界にきているようです。
UDPは動画配信でもないかぎり使えないかな。

[AerialLuster]

久しぶりにフォーラムを見てたら面白そうなスレッドを見つけて流し読みをしていたのですが、、、

いきなり話題に割り込んで恐縮ですが、そもそも論として皆さんはFFXIVのすべてのDCがネットワーク接続されてゲーム情報がやり取りされている構成を想定されているように見えるのですが、
現在ゲームクライアントを起動したときにログインする前に接続先DCが設定されている状況を鑑みるに、各DCはすべて独立したクローズなサーバー構成なのではないのでしょうか？？

今回の議論の発端となっている、異なるDCのワールドでマッチングができないのは、このためなのでは？と思います。

DCを分割するきっかけとなったのがラグを解消することが大きな目的でもあったことから、この構成であれば同じDC内のキャラクター同士でしかマッチングできないという理由にも納得できます。
ゲームを運営する側にとっても世界中のDC同士を接続して運営する必要もなく、DCを独立して構成したほうが障害耐性が上がり、同期のための遅延がなくなり構成が簡素になるためメリットのほうが大きいです。



文字数がオーバーしたので続く。。。。

[AerialLuster]

続き。。。。


ここまでの私の予想を勘案して、異なるDC内のワールド同士でマッチングさせるにはどうすればいいのか？を考えると、
DC内のサーバー構成はフィールドやID毎に細かくサーバーが分かれていると吉Pの発言で聞いた覚えがあります。
そこで、IDでの活動に必要な情報（セッション、キャラデータ、募集データ、などなど）を他のDCと共有するためのサーバー群を各DC毎に追加します。

追加するサーバー群は以下の手順でマッチングを行います。
・（必要な場合）募集掲示板はDC間共有のデータおよび、DC内の現システムの募集データの２つの情報を持ち、まとめてゲーム内で表示させる
・CFにDCを跨いで参加登録をする場合に、DC間共有のマッチングサーバーに登録
・マッチングしてID突入をする際に、PTのDC所属先が最も多いDCで、DC間共有するためのテンポラリDBにキャラクターデータをコピーする（このとき、マスタDBのレコードはロックする）
・IDはDC間共有のコンテンツサーバーで実行される（DCを跨ぐ代償として「ラグは許容してね」が条件）
・ID終了・または切断後、マスタDBにデータを書き戻しする


現在のシステムを考えずに都合のいい状況でこの構成の利点を挙げると、
・マッチング後の実行はセッションサーバーの接続先をDC間共有のサーバー群に差し替えることで、DC間共有のためのサーバー群は現システムのサーバー構成をほぼ再利用できる

もともとDCは世界中にあり、ラグ対策のためにDC毎にワールドをまとめて、（おそらく）DCはクローズドな環境であるとするならば、
DC間共有のための仮想的なDCを別建てにしてそこに必要なゲームデータをコピーして実行すればいいんじゃない？ってのが私の考えでした

こんなんでどうでしょう？？

[noton-noton]

AerialLusterさんへ

ご意見ありがとうございます。
DCセンター事に分離されているというのは、正しいと思います。
ここからDCまたいでの募集は、現状では不可能という判断も正しいと思います。

各拠点をまたくサーバーというご提案は、次の点から厳しいと考えられます。
・募集といった比較的遅い処理だけなら、耐えられる。
・しかしコンテンツはそうはいかず、クライアントが接続されているのは、各DCのAPサーバーなので、十分な速度を確保しつつコンテンツが共有できない。

そもそも日本と外国のDCをまたぐような機能は、歓迎されないので実装しない。

よって、最大でも、同じDC内の別グループ間までが妥当なところでしょうか？
個人的には、同グループ内だけでも十分だと思うのですけどね。

[Iruru]

ロドストにパーティ募集機能はありますので、そこを通じてPTを募集し（所謂外部サーバにあたるし、別にロドストに限らなくてもよい）CF申請時にキーを発行して8人がキーを入力して申請すればマッチングされるという形なら割と容易に実現できそうかな？と素人程度の考えですがなんとなく思いました。
CFをまたいだ募集が欲しいのも結局零式のようなハイエンドコンテンツになりますので事前の綿密な打ち合わせも必要でしょうし外部ツールに頼ることが多いだろうから全てをゲーム内に実装して貰う必要はないかなと思います。
全然技術的な話じゃなくてすみません。