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

[MisatoMisa]

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

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


ところで

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

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

構造とかは知らないですが、
サーバー跨ぎなモノだとPSO2の共通サーバーですかね。

チャレンジというコンテンツに特化した作りのようです。

※規模が違ったりで比べたりはハテナですが。

[noton-noton]

＞Seevさん
図入りの解説ありがとうござます。
その図を借りて、現状の解析と拡張したケースを説明したいと思います。

大量のキャッシュサーバーいるという指摘がありましたので、この部分についても考察したいと思います。

まず現状の募集用のサーバーについてですが上の図の（１）ワールドサーバーと同じ位置づけにあると考えられます。

さて、募集の附加情報情報が少し増えても、大きくは変わらず既存のままの構成で可能だと思われます。
（追加内容は、UIの画像の部分のコメント参照）

定期的に募集データーから、鯖間募集を希望しているデーターをピックアップするのですが、この処理はユーザーの通信とは非同期に行われます。

システムが定期的な処理をする為のAPサーバーが処理を実行します。
この処理はデーター量・アクセス頻度から、キャッシュは必要なく、随時変化するデーターですので有効ではりません。

必要な募集データを選択して、CFサーバーに登録します。
このときに、現行のCFのデーター形式に変更します。（これだけで１００％互換が取れるかはわかりませんが、多少の調整は必要でしょうね）

CF側から見ると、コンテンツマッチング処理開始前に、幾つかの募集が追加された形になります。

とりあえず、ここまでキャッシュ等のストレージは必要ないと思いますが如何でしょう？

[Alicia-Florence]

なるほど。全然わかんないけれど、面白いし凄いスレッドですね。

このまま建設的かつ専門的な議論を続けていって、
FF14のサーバー周りの担当エンジニアさんが「せっかく熱い議論をしてくれているのだから、参考にこれをどうぞ」と
議論の土台になるような情報をなにかしら提示してくれるような展開が生まれるといいですね。

ねぇ、そう思いませんか？Community Repさん？（チラッ）

[VESUR]

大変面白いスレッドですね。
私としてはCFシステムのクローンを作り母数が多い既存CFと母数が少ないハイエンド構成の様な作りが出来れば嬉しいです。
この話が結実すれば挑戦者が少ないとされる外国ユーザーにも光が当たることでしょう。
是非とも良い議論を！

[btk]

>Seevさん
サーバ構成図案についてありがとうございます！わかりやすいですね。なんだかとってもあっているような気がするぞｗ
#20,#21の図は、FFXIVクライアントから1DCの下の1ワールドへの接続ですね（CFサーバ・募集サーバは、DC内全ワールドサーバ共通）
※ここに記載されていないキャラデータが乗っかるDB群がや、処理の高速化のためのキャッシュサーバ群、および負荷分散&死活監視のLBがあると思いますが、この議論にはあまり関係ないので割愛でよいかと
※おそらくエリア単位でサーバ（あるいはエリアを保持するプロセス）を持っていると思われるので、図の緑部分のWorldサーバはエリアサーバ（ゲーム内各マップ）とみるのが妥当な気がします。※兼APサーバ

しかし、クライアントから直でhttpはセキュリティ的に無理な気がしますね。。これはDoS攻撃の格好の標的になる気が。。
なので、フロントのWorldサーバ（正確にいうと、その前面にあるLBと、きっとその前面にあるであろうIDS/WAFのようなもの）を経由してバックエンドへ通信させる必要はあるかと思います。
※吉田Pが負荷を懸念していたのはWorldサーバではなく、新規増設される募集サーバのDC内全ワールドからのアクセスだと思いますので、ちっとこれは難しい気がします。。

ちなみに、ケータイ（WEB)から確認できるってのは素晴らしーアイデアだと思います！
これ、いったいいつになるかわからんけど止まってるライブラエオルゼアの後継アプリに乗っけてほしいですねｗ

＞「わかりづらい」「ロビーサーバーの方が楽だろ」と言われると反論の余地が無い（汗
これは、HQヒロシの頑張り次第でどうにかなるハズ！ｗ

[btk]

>noton-notonさん
はい、noton-notonさんの説明について、「キャッシュサーバがどこに必要？」というのは疑問になるかと思います。
ただ、そもそもの前提なのですが新規増設されるワールド跨ぎのPT募集機能をCFへ乗せ換える、という処理がひっかかりますね、、
※自分が#12で書いている内容は、noton-notonさんの想像している構成とちょっと異なるもののような気がしてきました。
自分が考えているのは、Seevさんの#21の図をちょっと変えて、クライアントから直に募集サーバへ行くのではなく、あくまで募集サーバへのアクセスはAPサーバ（Worldサーバ）を経由する必要があると考えています。


ブレストと、推測を踏まえた提案が混じっている状況となってしまいっているので、いったん整理しましょうか。

★要件定義★
#3に書いた内容ですが、いったん「ワールド跨ぎの募集機能を実現する」ことのみフォーカスさせてください。
・DC内サーバ跨ぎで、現在のPT募集と同様の募集が行える
・DC内PT募集時は、PT募集欄にて「DC内で募集を行う」みたいなチェックボックスにピンつけるとDC内募集になる。チェック入れない場合はサーバ内募集
・検索条件の追加はいったん行わない（　※noton-notonさんのほうで条件を追加してもそんな変わらないのでは？とありますが、それは今後の拡張提案に含めさせてください）
・PT加入前は、サーバ跨ぎのTELLなどはできないので例えば新式でレベル不足なのですが～、みたいな相談は不可
・PT加入後は、サーバ跨ぎのPTチャットは可（できる、と信じたい・・・）
・通常のサーバ内PT募集同様、募集を出せば即DC内PT募集に反映される。訂正・取り下げも同様。

以下の内容について要検討 -> 拡張案として盛り込められたら！
・募集掲示板は、ゲーム外からも参照可能（->これ、書き込みも可能だとさらにいいな・・・）
スマホアプリ側のAPサーバ経由でいけるんじゃないか説が僕の中で浮上中

★問題を解決するために必要なこと★
1)既存構成に募集サーバを追加する場合、DC内全ワールドからの一斉アクセスに募集サーバが耐えられないという吉田P/Dの懸念を解消するような仕組みを提案する
2)もしくは、そもそも上記懸念が発生しないような構成を提案する
上記二つのどちらかが必要になると考えています。引き続きよろしくお願いします！

[TonPoo]

DQ10のサーバ側の概念が記載されているサイトがあったので貼っておきます。
同じ会社のMMOなので、似ている部分はあるんじゃないかなと思います。興味があったらどうぞ

http://gigazine.net/news/20120824-dr...age-cedec2012/

[noton-noton]

btk さんへ

全体的に、接続のほうから見た考察になっておられますね。
私は既存の「既に動いている部分を、できるだけ変更せずに」実現する事を考えています。
それは新たなハードウェアの追加をしなくても、実現できる為に一番近いからだと考えているからです。

＞クライアントから直に募集サーバへ行くのではなく、あくまで募集サーバへのアクセスはAPサーバ（Worldサーバ）を経由する必要があると考えています。

APサーバーが受け取った募集データは、ワールドサーバーに保管されると考えています。
そのプロセスの間に、ワールドAPサーバーのプログラムを経由するか、直接置かれるかは既存のシステムが採用してる方法で良いと思われます。


＞そもそもの前提なのですが新規増設されるワールド跨ぎのPT募集機能をCFへ乗せ換える、という処理がひっかかりますね、

乗せかえる処理をするのは、クライアントと非同期ですから、サーバー側のプログラムが余裕を持って処理することが可能です。
外部に対するアクセスは発生しません。
新規にキャッシュ機能が必要な要素は考えにくいです。
（※毎回変化するデーターで、かつ、外部との参照が伴わないなら、キャッシュは必要ない）

CFに処理を任せるのは、既にそこにワールドを跨いでマッチングする機能が備わっているためです。
CFのマッチング処理用のプログラムが採用している、データー構造にあわせるのが、工数がかからない方法論という事で提案させてもらっています。

[Zhar]

大量のキャッシュサーバーいるという指摘がありましたので、この部分についても考察したいと思います。

違いますよ。必要なのは「高速な」キャッシュです。
容量はコストに対する問題ではありません。むしろ大容量キャッシュが有効であればそれは大幅なコスト削減案になる。

今のnotonさんのアイデアであれば、ボトルネックはスピードに思えます。で、ハイエンドの世界だとほぼ速度＝値段なんですよね。
ここをどう解決するか？がポイントだと思います。私にはどうも良いアイデアは浮かびませんが・・・

CF側から見ると、コンテンツマッチング処理開始前に、幾つかの募集が追加された形になります。

だから、CF側から見ると、コンテンツマッチ処理の待ち行列をキャッシュする必要があるでしょう？ということです。
それを各ワールドサーバーに分散して処理するならば、今度は通信帯域が問題になる。
（それなりの情報量を相互にやり取りする必要があるため）

なので矛盾してないか？という指摘なのですが。
ちなみに、「高速キャッシュ」も「通信帯域」も、どっちもカネかかります。
（LANの高速化にしてもそれなりの機器が必要で、やっぱりお高いｗ）
そこらを上手く回避できるアイデアがあれば良いですが、今のnotonさんの案だと相互矛盾しているように思えますよ。


あと、上記とは直接関係ありませんが、処理をバッチ化することはあまり意味がないと思います。利便性が下がるだけで。
前のスレでも指摘したように、CPUパワーをケチっても仕方ないんですよ。そこのところは、普通にEDAで良いと思います。

[MisatoMisa]

http://www.cisco.com/web/JP/solution...reenix_cs.html

関係ないかもですが、スクエニはここのサーバーを使用しているかもです。
記事はネットワークですが。