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

[noton-noton]

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

このスレッドは、本当の負荷を暴く為にあるのではありません。
正確な事は判らない事は、わかった上でのスレッドです。＞※１参照

吉田Pがかつて何を想定した話か分かりませんが…以下

DCマタギをしない・グループ跨ぎもしない・相互閲覧する募集の数を減らす

これで幾らか減らす事が出来ると判断できます。
もしかしたら、前提条件が違えば、可能性もあるかもしれません。

その他に、募集データーのほうを参照するのではなく、傭兵（参加者）側を登録閲覧することで、
キャッシュを恩恵を大きくして負荷を減らせないか？　など

考えるのは、こういった方向性ではないですか？

場合によっては、設備の投資が必要かもしれませんが、過疎鯖問題の解決によって、過疎鯖への逆流が始まり、しいては土地問題も多少緩和するなど
設備投資を有効にすすめる手助けになるかもしれません。

ところでKeep-AliveがON必要な所はどこですか？
ご自分が出したのだから、きちんと説明して欲しいですね。
「負荷が増える」なんてのは誰でも言える事ですよ。

[Resha]

書いているないようさっぱりわからないのに
毎回覗いているます。

仕事でもないのに、こんなに真剣に考えてくれるユーザーがいるFF14ってすごいなって思います。
また、エンジニアってすごい人達だなって感心してしまいました！



運営さんも協力してくれるとイイですね！

[Paradice]

いやホント仕事でもないしなんかこれ以上は不毛になりそうなんでここまでにしておきますが

・負荷量について
負荷量を明確な数字を求めたのはnoton-notonさんご自身です
自分で出した話をと人に言うならそういうとこもすり替えないで下さいね

・Keep-Aliveについて
既に書いています。
付け加えるなら少なくともサーバからの開線要求を受け付けるなんて非セキュアなプログラムで作られてることはまずないでしょうね。

あと大前提として先にも書いてますが「負荷が許容範囲を超える」というのは他あろう開発が発した言葉からの類推です
その負荷がかかるのがどこ？っていうそこを考えずにプログラムを論じても「だから無理だって」と開発に一蹴されるだけだと思うってのがツッコミのポイントです
これが現状の立ち位置である以上、そんなことはないといくら言おうがそこは覆らないし
今あるものの負荷が下がる訳でもない
それをプログラムで実現しようとするならそれこそ再新生のレベルの見直しがいるのかと思いますので、
ならサーバを増強できる道=ワールド統合等で他から回せるリソースがないのか、
という様な方がまだ現実味があるんじゃないのかと思うということです

[noton-noton]

Paradice　さんへ

募集やCFのマッチングの部分については、今回の提案の変更で何かしかの「増える要素」があるかもしれませんが、
マッチングが終わった後の動作については、従来とかわらないですよね？
方法がどうあれ関係ないといえるのではないでしょうか？


・応募が増えたら通信量が増える
・マッチング成功数が増えたから通信量が増える　
当たり前ですから、こんなことを指摘されているわけではないでしょう？



案１では、PT募集からCFに自動登録する　という内容ですが、

・募集登録の部分では、キューにポストするデーターが数バイト増えるだけで、（APとCF間）通信も即遮断だから、ご指摘の部分は増えませんよね？
・マッチング動作も非同期で通信は発生しない
・マッチング完了後の話は、今回とは関係ない。

どこにシステムを揺るがすような、通信の飛躍的増加する要素があるのでしょうか？

＞負荷量を明確な数字を求めたのはnoton-notonさんご自身です
負荷量が増えることを問題にしているのはParadiceさんですから、できるだけ具体的にかつどの部分かを提示して欲しいと思います。
根拠があっての事でしょう。

＞セキュアな通信　付け加えるなら少なくともサーバからの開線要求を受け付けるなんて非セキュアなプログラムで作られてることはまずないでしょうね。
クライアントとAPの間の話は今回関係ありませんよね？
この部分は常時接続でしょうし。
クライアントに「ダイアログを開く命令」というのは、通信は確立されている中での「コマンド送信」ですよ。

＞その負荷がかかるのがどこ？っていうそこを考えずにプログラムを論じても「だから無理だって」と開発に一蹴されるだけだと思うってのがツッコミのポイントです
で、どこですか？
今回、明確に増える部分と理由を提示できていないのは、Paradiceさんでは？

どこが増えるかがはっきりすれば、このスレでどうすれば減らせるかという話にもつながりますので、是非お願いしたいです。



＞それをプログラムで実現しようとするならそれこそ再新生のレベルの見直しがいる
プログラムでできる事を、サーバーの増強で何とかするのを論じるのはナンセンスです。

[noton-noton]

用語解説のようなことをしてみます。

●APサーバー（アプリケーションサーバー）　
・ユーザーとのやり取りをおこなうプログラムが搭載されているサーバー
・ある程度以上の規模になると、複数台が用意される

仮に1台で１００ユーザーを相手にする場合、同時接続が３０００人の場合、３０台必要となります。
チョコボ鯖という名称で、各ワールドを語ることが多いので単独と思われている方もいるかもしれませんが。実際にはサーバー郡と言えるでしょう。

ゲームの場合は常時接続でユーザーからの命令を待ち続けます。また、キャラクターが存在するワールドからのデーターをクライアントに送信します。

[Sasameyuki_WHM]

光のエンジニア達が戦っていると聞いてc(`･ω´･ c)っ≡つ
応援してます！！

[btk]

こんにちは！よーやっと３連休です！('ω')ノ
ちょっと見れてなかった間にものすごく話が進んでておいつくのが大変だ。。＠＠

>notonさん
ご意見、ご提案ありがとうございます！
吉田P/Dの懸念であるDC内から同時アクセスのあるサーバを立てた場合に大量の参照が発生し、それに耐えられない可能性があるという説明について

・そもそも機能としての参照を制限する
・パッチ後や混雑時には利用できないようにする

という提案はとても理に適っていると思います。
3.0実装直後のいくつかのエリアのチャンネル化と同様の対応ですね。そもそも人が殺到するような状況であれば、この機能自体が必要ないというのはその通りかと思います。

その一方で、上記内容で実装された機能がほんとにユーザが必要としているものかどうか？の検討が必要とも思います。
技術的にこれなら可能だからといって実装したものがチガウソウジャナイ、だったら悲しいので。。
※そういう意味では、上述した一部エリアのチャンネル化もやはり一部ユーザから不満の声はあがりましたね。。

程度問題にもなるとは思いますが、この実装でどういった機能が提供され、それは本当に必要なものかどうかというのを利用するユーザ側の立場から考えてみたいとも思います。

＞スレットタイトルから、書き込みを遠慮されているのかもしれませんね。
そうかもしれませんね。ちょっと#1に補足しておきます(; ･`д･´)

[btk]

＞Paradiceさん
ご意見ありがとうございます！

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

そうですね、ここがまさに僕の考えていただから厳しいのでは？の部分です。
APサーバ <--> CF(あるいは募集)サーバ間の通信がKeepAliveである必要はないと思いますが、単純な参照数の増加がそもそもの懸念になると思います。

※KeepAliveが必須なのはあくまでクライアント <--> APサーバ間であり、既存のAPサーバ間 <--> 募集掲示板は一定期間でのポーリング+ユーザリクエストごとの通信だし
CFについてはちょっとわからない、、というかKeepAliveな気もしますが、今回新設される機能はあくまでも既存のCF機能を流用したCF2であり、KeepAliveではない実装にすればよい、という考え方もできるとは思います。
負荷をできるだけ減らすような実装の工夫が必要ですね。

[btk]

#言葉の定義#
ちょっと整理しておきましょう。
ワールド：Chocobo,Bahamut,Carbuncleなど、それぞれの実際のキャラクターが所属するプレイヤーにとっての世界。
CFグループ：Mana,Gaia,Elementalなど。いくつかのワールドを束ねたもの。だいたい１CFグループに10ワールドほどが存在し、CFではワールドを飛び越えてCFグループ内でのマッチングが行われる。
DC:データセンター。CFグループが稼働する物理的な存在。現在は日本DCと北米DCがあり、もうすぐ欧州DCができる。
#今回ぼくたちが欲しいのは[「ワールド跨ぎ = CFグループ内」のPT募集機能]という風に理解しています。DC跨ぐのはそもそも要求されてないし、物理的にもハードルが高いので考慮外ですかね。

ついでに。
サーバー：FFXIVプレイヤー的には上述した「ワールド」と同義（＝チョコボ鯖）。ただしこのスレッドではエンジニアとして「サーバ」が頻出するので補足しておきます。
基本的には、ホストOS（多くはLinux）が動いている１台のマシン（物理・仮想問わず）を指し、実装される機能ごとに複数のサーバが接続され、上述したワールドが構成されています。
notonさんの説明にある「APサーバー」もその一つで、実際にはAPサーバ（１台～必要なだけの複数台）が前面に立ちユーザからのアクセスを受け付け、それを裏側にいるデータベースサーバ、キャッシュサーバ、その他機能ごとのサーバとやり取りをしその結果をまたAPサーバ経由でユーザへ返却するという構成になっています（いるハズです）。１ワールドは複数台のサーバから構成されているということですね。

[TonPoo]

技術に詳しく無いヒトの感想です。

募集を仮想コンテンツとしてCFの処理フローに載せる方式だと理解しました。
その場合は、CFの作りがポイントだと思います。

もし、CFのマッチングがコンテンツを軸にする作り（コンテンツ毎にジョブ(プロセス)など）だった場合、
対応コンテンツ数を動的に変更できず、募集を仮想コンテンツとしてCFの処理フローに載せる方式は破綻する可能性があります。

だとすると、新規にサーバ跨ぎのPT募集を構築した方が、既存への影響も最小に出来るし、導入(運用)しやすいと思います。

もし、コストを重視するのであれば、零式と練習モード（実装検討中？）の各フェーズをCF対応コンテンツにしてもらえば、
サーバ跨ぎのPT募集（簡易版）と変わらない気がしました。