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

Quote:

---

Originally Posted by Heatmind

それなら他で議論して欲しいですね。理解出来るもの同士が投稿し続ければ、他の話題が埋もれてしまう事もありますし。

---

・向こうのトピの話題埋もれを考慮して（他で議論するため）新しいトピを立てたので、向こうではこれ以上専門用語で埋もれる事はない。
・このトピでは、専門話以外は起こらないと思うので、他の話題が埋もれる事はない。
・このトピが活発に使われてても、トピが一つ上がるだけなので、新着トピが埋もれる心配は少ない。

なので何の問題も無いと思いますが。
フォーラムやるなって意味なら私から言える事は御座いません。

Quote:

---

Originally Posted by Heatmind

引用中：文字数制限があるので省略させてください。

---

そうですね。もしこのスレッドがフォーラムに不適切であると判断されればモデレータさんにクローズしていただきましょう。その判断待ちということでお願いします。

>noton-notonさん
サーバ構成については、僕も似たような認識です。クックパッドの開発者ブログでも見て語ったほうが早いレベルですねｗ

僕が気にしているレイヤ4以下とは、
APサーバ -> 募集サーバ　への通信量・頻度ですね。

＞配列の検索を行うのは、配列が置いてあるサーバー上のプログラムで動かすと思いますよ。
＞なので、マッチング処理そのもので通信の下層部分を気にする必要は無いかな？と

この内容において、マッチング処理そのものを行うプロセスのスループットと同時に、上記通信を行うサーバ間ネットワークのスループットの両方がどの程度要求されるのか？ということを問題視、疑問視しています。
例えばの話、この募集サーバがSQLサーバとして1台新設された場合、このサーバのポート数はピーク時に十分足りる設計になっているか？など。
#可用性も含めて考えれば1台ということはないでしょう、最低でもマスタースレーブ構成でリードレプリカ用意したいですね、参照を分散すれば気にする必要もなくなるかな
#ちなみに吉田P/Dは、この数字について50~60万、という数字を発言されているようです。おそらくこれは全ワールド合算の数字でしょうが、6DCある現在、1DCあたり10万程度とみるのが一応公式準拠になるんですかね？ほんとかよｗ

noton-notonさんの書き込みにおける「マッチング処理」とは、PT募集が出されて、ほかのプレイヤーがそれに参加する一連の流れという認識でよいでしょうか？
（この一連の処理についてもトランザクションをある程度考慮しないといろんな事故のもとになる気がしますね。。）

上記処理は、バッチ処理ではなくユーザがPTへ参加するボタンを押したときに発生するものかと思うので、上記内容について確認したいです。

こういう場所があってもいいと思いますよ。

自分は知識がないちんぷんかんぷんですが、元スレが専門用語だらけでついていけなかったので
分けて下さった配慮に感謝します。


自分が興味がない・理解ができないから投稿を抑制するのはちょっと違うと思います。
一定期間参加人数が極端に少ないとかであれば後程考える必要があるかもしれませんが
まだ立ったばかりですし懸念するのは早すぎると思います。


あと会社の内情を知らないのに～って言っても
外部からの考案で何かしらいいヒントが埋まってるかもしれません。
ネガティブな会話をしているわけではないので、好きな話をしてもいいと思いますよ。

ここからいい案が生まれるといいですね。
（横やり失礼しました。）

Quote:

---

Originally Posted by btk

すみません、略させていただきます。

---

私も言葉が過ぎたようですし、話の腰を折ってしまい申し訳ありませんでした。

おそらく、すぐにできそうなのにできない理由は、サーバーの構成が負荷に対する耐性に特化し、
細かく役割分担させてるからなんじゃないかなぁって思っているメカトロエンジニアです。

例えば、大規模前提であるため
ユーザーがCF参加 ⇒ 複数のCFサーバーのいずれかに登録 ⇒ そのサーバー内で順番にマッチング ⇒ 複数のIDサーバーのいずれかに登録
という流れのシステムになっているのではないでしょうか？
少なくとも、私ならそうやって作ります。

その場合、負荷がかかったときにうまく分散させる事は可能ですが、
すべての人が自由にサーバー間を越えてPTを組むのが難しいのではないかと思います。
（CFサーバーAとCFサーバーBは情報のやり取りをしていない）
（だからキーワードによるPTマッチングのシステムも作れない）
（CFサーバーを指定してからキーワードによるPTマッチングのシステムなら低コストで作れそう）

システムの拡張にはコストもかかりますが、リスクの方が怖いのではないかと思います。
だから、従来あるシステムをできるだけ再利用して考えるのが良いかと思います。

先日CFでロビーIDに転送され、そこでPT募集を行えたらいいのではないかというスレを見かけました。
あのアイデアは非常に優れており、あのシステムの延長でサーバー間PTマッチングを模索すればいけそうな気がします。
（それでも従来CFサーバーでPTを組ませていたのを、IDサーバーで組ませる事になるので、非常に敷居は高いでしょうが）

今は車作ってるんだ、そんなにすぐには転職でないんだよ、ごめんな

面白いスレ立てましたね

まあ、元スレであんまり技術的な話をするのもナンですし、予想通り「ボクの分からない話するな＞＜」な人が
噛みついてきてましたので（何故かこのスレにも迷い込んでますが:P ）良い仕事をされたと思います。

Quote:

---

Originally Posted by btk

・通信帯域の話
noton-notonさんの書き込みで個人的に一番気になったのは、Layer4以下の考慮が一切なかった点です。
構造体への配列検索でさばけるだろ！ってのはネットワークのキャパシティプランニングがまったく考慮されてないので、いまいまのサーバtoサーバでそれできんのかなぁ。と。

---

noton-notonさんの案に沿うなら、キャッシングの為に高速なストレージは必須だと思います（≒おカネがかかってしまう）
そこをケチるなら、通信帯域は想定しなければならない。noton-notonさんのアイデアの矛盾点ですね。

Quote:

---

Originally Posted by btk

上記内容を実装するのであれば、通常LAMP構成でDB（MySQLか、今ならMariaDBでしょうか、もしくはオラクルの商用版とか使ってるんですかね？）を使用すると思うのですが、構造体への配列検索てのはCやC++での実装を想定してるのでしょうか？まぁここの開発ならやりかねんような気もしますが。。

---

FF11の頃からキャラクタデータの保持にはRDB使ってなかったようですし
バックエンドは3層になっているのではないかと思います

[A.ゲームと通信するフロントエンド]　⇔　[B.ログアウト後のセーブ領域]　⇔　[C.課金情報系]

Aの箇所にRDBを使う意味合いは無いと思いますよ。速度的にもデータのライフサイクル的にも。
FF11の頃はテキストベースだったそうですが、今ならNOSQLのKVSとかじゃないですかね？Cassandraみたいな。
でもそーいうのはカネかかるんですよね・・・

Quote:

---

Originally Posted by Zhar

noton-notonさんの案に沿うなら、キャッシングの為に高速なストレージは必須だと思います（≒おカネがかかってしまう）
そこをケチるなら、通信帯域は想定しなければならない。noton-notonさんのアイデアの矛盾点ですね。

---

矛盾点というか、考慮しないといけないとこじゃないかなぁと個人的にとても思うとこですね。
もちろんお金で解決できるならそれに越したことはないですが＾＾；

Quote:

---

Originally Posted by Zhar

FF11の頃からキャラクタデータの保持にはRDB使ってなかったようですし
バックエンドは3層になっているのではないかと思います

[A.ゲームと通信するフロントエンド]　⇔　[B.ログアウト後のセーブ領域]　⇔　[C.課金情報系]

Aの箇所にRDBを使う意味合いは無いと思いますよ。速度的にもデータのライフサイクル的にも。
FF11の頃はテキストベースだったそうですが、今ならNOSQLのKVSとかじゃないですかね？Cassandraみたいな。
でもそーいうのはカネかかるんですよね・・・

---

ほーほー。11のころはぼくはまだこんなこと知らないがきんちょだったのでとても興味深いですね！テキストベースですか、、
はい、Aの箇所にRDBを持ってくる意味がないは同意です。というかクライアントと通信するところにDB持ってくるはいろんな意味でナイですね。
現状の構成としてはBの部分（ざっくりバックエンドと表現しましょう）とゲーム中もやりとりがあるハズと思っているので、そこにDC内募集時に使用されるRDB、もしくはNoSQLやKVSの類でしょうね。あるいは独自実装の何かでしょうが。
Cassandraが出るなら、redisでもmemcachedでもmongoDBでもなんでもよさげですねー。
用途+通信頻度+冗長性可用性を考慮して、あとは設計する人の趣味になりますねここはｗ

技術屋じゃないのでさっぱりわからないのですが

ぜひ、開発チームの参考になるような案を練って頂きたい


ところで

ＣＦ先に「酒場」や「カフェ」のようなものを用意してそこに集まって今までどおりの募集というのはできそうでしょうか？
（一応書いてみる

イメージはいろんなファンタジー、異世界ものである「冒険者ギルド」(ＦＦ14内とは違う)みたいなものをイメージしてるのですが
（ドラクエ３のルイーダの酒場が一番近い

サーバ越しのPT募集は今の仕組みのまま実装するのは難しい。と言われている以上、
それほど負荷はない「はず」といくら言っても意味が無いと思うので、出来る限り現行の仕組みに載せられそうな代替案を妄想。

・まずは現行はこうなっているのかなという図

http://img2.finalfantasyxiv.com/acci...389db39e80.png

(1)とあるクライアントがWorld1からCF申請
(2)World1からCFサーバに申請依頼が送られる(Enqueue)
(*)※既にWorld2からCF申請している人とは生存確認(KeepAlive)
(3)CFサーバ内でPTが揃い次第、IDサーバにインスタンスエリアを確保(Dequeue)
(4)各クライアントをIDサーバに繋ぎ直させID開始

実際にはIDサーバなんてものはなくWorld内にエリアを確保するとか、
Worldサーバ越しにIDサーバへ通信しているとかかもしれませんが、
大まかには上記のような構造になっているのかと思います。
(括弧内の英語はざっくりと何してるかのイメージを書いているだけです)

既存のPT募集はあくまでWorld内で事前にPTを組ませるだけなので、そこで組んだPTは一つのWorld内で完結しており、他Worldサーバとの通信は全くありません。
サーバ越えのPTを事前に組ませるには、そこにチャットやキャラクター情報のやり取りを発生させないといけないので、
そこが「現行の仕様では実現不可能」な部分になるのではないでしょうか。

【提案】
ここに新たに募集サーバ(PT募集の情報を管理するサーバ)を追加。
（このサーバは簡易なHTTP通信のみを行うためゲームサーバに比べスペックは低めでOK）
また、FFXIVクライアント上にパーティ募集サーバへアクセスするためのHTTP通信機能を追加し、ゲーム内から透過的にパーティ募集掲示板へアクセス出来るようにする。
（PS3,4とかだと難しいかもしれませんが、裏でブラウザ機能を使うとかで実現出来ないか……）

続きます

・パーティ募集サーバを使用した際の図

http://img2.finalfantasyxiv.com/acci...90696776f7.png

(a)クライアント2が募集サーバへパーティ募集を依頼
(*)この時点で申請を出したクライアントがCFサーバの隔離空間（通常オートマッチングは行われない）を作り、待機
(b)CFサーバは隔離空間の状況を募集サーバへ定期的に報告（非リアルタイム）
(c)クライアント1が募集サーバを閲覧し、気に入った募集があればそのキーを持って参加依頼（隔離CF空間への参加申請）
後は通常と同じ流れ。隔離空間内にPT人数が揃えばIDへご案内（シャキーン）

パーティ募集の情報は全て募集サーバ上にあるため、どのWorldから申請された募集であっても閲覧するだけなら特にWorld間通信を必要としません。
募集条件の閲覧はもちろん、ID突入までの一時的なチャット機能を持つことで擬似的にWorld間チャットを実現。攻略に関する相談等が行えます。
（実際にはそれぞれのPCと募集サーバ間でやり取りしているだけなのでWorld越しにチャットを行っている訳ではなく、ゲームサーバに負荷はかけない）

HTTPに拘る理由は無いのですが、Webであれば携帯から募集掲示板をチェックし、気に入る募集があればインして参加。という事も出来て面白いかなと。

[メリット]
・既存のCFの仕組みに乗っけるので、大きな改修は必要ない（はず）
・追加サーバが比較的安価なサーバだけで良いので、コストがある程度抑えられる（はず）
・募集掲示板がゲームサーバから切り離されているため、ゲーム外からも閲覧が行える

[問題点]
・リアルタイムに募集状況を表示しているわけではないため、実際に参加申請したら入れなかったという可能性がある
・募集主が募集を取り下げると、参加申請そのものが無かったことになってしまう（参加者側は、急にCF申請取消が発生する）

[最大の問題]
「わかりづらい」「ロビーサーバーの方が楽だろ」と言われると反論の余地が無い（汗

なんとな～く妄想したまでなので、何か発想のヒントにでもなってくれればと……