2022年8月16日 導入 ソーティについて

[16BEAT]

あまりに腹がたったので書き込み

ソーティの登録をして待ちほぼなしのはずなのに
まったく入れません。U1が0組、U2が10組なのを確認済

10分たっても入れない状態で、あとから来たPTが申請の気配
自分より後の番号が即占有されてはいっていきました。

どうなっているんだ・・・・と思って数分まったらソロのモンクがきました
申請してすぐに自分よりあとの番号が（つまり申請したモンク）が入っていきました

そこから10分まっても入れないのでエリアチェンジしてログアウト


はっきりいいます


入りやすいようにやっているという開発の言葉は


おおうそです！！！！！！！！！！


いいかげんにしろ

[noli]

思うに、プレイヤーを楽しませるために提供されるものがコンテンツだ。
手間がかかるからと中途半端なものを提供されるのを、私は納得したくない。
ずっと前から準備してたんだろう。
私から見れば「避けがたい悪手」なんだが、何が起こるのか目に見えてるなら、まともに対策してから実装してくれという話なんだ。

それについては、まったく仰る通りです。
ただ、個人的には開発さんに同情する気持ちもあります。

ソーティで使用するレイヤーエリア、ラ・カザナル外郭[U]は、
「スカーム：カザナル」や「ベガリーインスペクター」でも使用しています。

# ソーティが混雑するとベガリーに入りにくくなるので、
# 同じサーバーで同居もしてるようですけども

報酬は全然違いますけど、
コンテンツの内容的には極端に違うというほどでもないので、
いわば「無難であろうやり方」だったのではないかと思われます。

ゆえに、8月のソーティのリリース直後に起きたような、
数々の異状が起きるとは予想していなかったのだと思います。
スカームやベガリーでは大丈夫だったのに、
ソーティでは何故この有様になっちゃったんだろう、と。

もちろん、
プレイヤーからすればそんなことを言い訳にしてほしくないわけですが、
では今回の状況を回避できたかと言えば、
おそらく相当に難しかったとぼくは考えています。

これまた言い訳にはならないんですが、
実運用での状況を再現することは、
費用と人員を費やしても難しい場合があるからです。

そして、開発さんが「無難であろうやり方」というつもりであったなら、
余計にリスクの予測と回避は難しくなりますから。

追記：
　この投稿を読み返すと、推測を前提にしすぎですね。。
　実際、そんなところじゃないかなと思ってはいますけども。

[noli]

全体のキャパシティという、話の基準になるものを私は知らないので、教えて欲しい。
非公開情報だと思っているんだが、余裕のある、例えば100を全体にして50:50が考慮されず、いきなりカツカツの20を1:19にする話が進んでいる。
余裕が有るのか、それともどの程度無いのか、こっちには本当の所は分からないと、話が成り立たないと思うが。どうだろう？

Arequsさんが書かれているように、これは本筋ではないんですよね。
とはいえ乗り掛かった舟なので、回答いたします。

絶望的な長さになってしまったので、
先に結論としては ↓ 3行になります。

・何よりまず異状の原因特定が必要
・分けるとか分けないとか、悪手とか判断可能になるのはその次の段階
・事実を整理してから理詰めで考えてみると、分けないのが悪手とも言えない

細かい説明は、この後の折りたたみになります。
短くまとめる時間がありませんでした。すみません。
暇な時にでもお読みください。

20とか1:19というのは、話を分かりやすくするための例えです。
実際の処理リソース事情が具体的にどのようなものであるか、
ぼくも分かりません。

ですが、Arequsさんの言う「別コンテンツに分けろ」というのは
リソース運用の「方式」についての指摘に当たります。
そして方式の是非については、具体的な情報がなくとも抽象化して論じることは可能です。
今回のケースでは、具体的かつ事実に基づく数字を引用して説明しますけども。

そして、Arequsさんは「既存に増設するのは悪手」と断じておられたので、
ぼくは「そうとも限らない」という意見を出しました。

# 先の投稿で計算リソースという言葉を使いましたが
# 処理リソースと呼ぶほうがより分かりやすそうなので改めます

--

で、処理リソース云々の話をする前に、
事実関係を整理しますね。

8月のソーティ実装時点では、
「ラ・カザナル内郭[U]」が2エリア宛がわれ、
1エリアあたり15から20組程度のパーティが入場できていました。

そして9月の調整により、自動突入が撤廃され、
突入エリア振り分け方法が調整され、
余計なレイヤーエリアの生成もやめるようになったとのことですが、
しれっと1エリアあたりの上限が10組程度に変更されています。

ここまでは開発さんから公表されたり、
プレイヤー側からも確認可能な事実です。

9月の調整前は、チャットが猛烈に遅延したり、
パーティリストが正常に更新されなかったり、
落とされたメンバーがパーティに復帰できなかったりと、
ゲーム進行そのものに異状が見られました。
そうした異状を回避するために、
エリアあたりの入場数を減らしたのかもしれません。

この辺りで推測が混ざってきますが、
実際に起きた事実を並べていくと、
レイヤーエリアを処理するサーバーと
チャットなど他の処理を担当する他のサーバー間で、
連携不全が生じているようにも見受けられます。

また、開発さんからの
第62回もぎたてヴァナ・ディールのスレッドの、
ソーティに関する記述の中に、
「なぜ発生するかを調査しつつ」という表現があるのですが、
これは異状の原因が特定できていないまま、
9月の調整に踏み切ったように受け取れます。

これらのことから、
当初は1エリア15から20組程度は処理できると見積もっていたが、
原因未解明の異状により1エリア10組程度しか処理できない状況にある、
という観測がプレイヤー側からでも可能です。

1エリア10組で2エリアあるので、
先の投稿では全体キャパで20組という例を用いました。
突飛な数字を持ってきた、というわけではありません。

なので、「いきなりカツカツの20」というより、
異状の原因特定ができておらず、とりあえず処理できてるのが20なので
「現状に基づくと20」だったりします。

# 残念なことに、16BEATさんの投稿にもあるように、
# 20をしっかり回せてるかすら怪しかったりしますが。。

--

次に、1:19という例えについてですが、
これは50:50でも10:10でも問題なく説明できます。
ぼくの主観とか妄想に左右されることのないロジックの話であり、
パラメータに左右されるものではないからです。

先の投稿の時点では、
1:19のほうが極端で分かりやすかろうと思ったのですが、
10:10で説明したほうが良かったですね。

ということで、
10:10で前回より分かりやすそうなパターンを用いて説明してみます。
（1:19でも50:50でも通用する内容ですが、
　10:10のほうが分かりやすいはずです）

「+2用」と「+3用」でコンテンツを分けて、
処理リソースをそれぞれ10ずつ割り当てたとします。
「+2用」に5組、
「+3用」に20組が入ろうとすると、
「+2用」では5組すべてが入れて、
「+3用」では10組入れて10組待ちます。
「+3用」は混んでいても、
「+2用」は影響されることなく待たずに入れます。

ところが「+2用」と「+3用」を分けず、
処理リソース20すべてを割り当てた場合、
コンテンツを分けた場合と同様に
「+2用」に5組、
「+3用」に20組が入ろうとすると、
「+2用」と「+3用」は同じ列に並ぶほかなく、
どうやっても5組の待ちが発生します。
もし、「+3用」の20組の後ろに「+2用」の5組が来てしまったら、
「+3に巻き込まないでくれよ」と言いたくなりますよね。

となると、
やっぱりコンテンツを分けたほうが良い手なんでしょうか。
「+2用」と「+3用」が互いに巻き込まれない、という点では優れますし、
上の例の「+2用」のように上限に達しない場合はスムーズに入れます。

ですが、
上の例だとコンテンツを分けた場合、15組が入れて、10組が待ちます。
分けない場合、20組が入れて、5組が待ちます。

処理リソース1で1時間あたり1組を処理できるとすれば、
コンテンツを分けた場合は1時間で20組処理できない場面が生じますが、
分けない場合は誰が来ようと毎時間20組を処理し続けることが可能です。

とはいえ、コンテンツを分けないで20組超が来れば、
「+2」「+3」のどちらが目的だろうと強制的に待たされるわけで、
そこがネックとなるわけですけども。

--

処理リソースをどれだけ効率的に使えるか、という観点では、
コンテンツを分けないほうが常に処理リソースを使いきれる、
という評価もできるわけです。
半面、コンテンツを分ければ、
処理リソースを使いきれない場面が生じるものの、
分けない場合よりも短い待ち時間で入れるチャンスが生まれやすい、
ということでもあります。

あるいは、コンテンツを分けた上で、
処理リソースが余っている時は、
足りないほうへ融通してやるようにすればいいでしょうか。
でもそれだと「+2用」と「+3用」のサイズが動的に変動するようになり、
コンテンツを分けない場合と同様の挙動になってしまいます。

それとも、処理リソースを100とか1000とか用意すればいいでしょうか。
それが「可能であれば」その通りなんですが、
事実関係のところで書いたように、
そもそも1エリアに15から20組入れたら異状が起こって、
その原因特定もできていないまま、
1エリア10組程度しか入れてない状態、というのが現状なんですよね。

ですから、まずは異状の原因特定を終わらせないと、
たとえ処理リソースを増強し、多数のレイヤーエリアを稼働させたところで、
まともに動くかどうかの確証もない見切り発車になってしまいます。

--

「+2用」と「+3用」でコンテンツを分けることで、
8月に発生していた異状を回避できて、
スムーズな入場を実現できる可能性もあります。
ですが、

「なんか異状が起きてて1エリア20組もまともに動かない状況で、
　原因特定もまだなんですけど、
　今からコストかけてコンテンツを分けて、
　それでもダメなら、うまく動くか確証ないですけど、
　処理リソースを増強してみまーす」

みたいな報告を、開発さんの上席である吉田さんにしたら、
たぶん普通にブチギレられると思うんですよね。
順序おかしいでしょと。
ガチで心配されるかもですが。

今でもリソース使い切れてるか怪しいのに、
リソース使い切れない場面が起きる方式にしちゃうぜ、
ってことでもありますし。

--

繰り返しになりますが、まとめると、

・何よりまず異状の原因特定が必要
・分けるとか分けないとか、悪手とか判断可能になるのはその次の段階
・事実を整理して理詰めで考えてみると、分けないのが悪手とも言えない

ということになります。

そんな感じのことを考えてたので、

対策してから、というのはその通りだと思います。
ですが、既存に増設とかはあまり関係ないと思います。

と書きました。
説明を短くまとめられそうもないので端折っちゃいましたが、
さすがに雑すぎましたね。。

[Rincard]

しかしラ・カザナル内郭にあった赤い四角の床や壁面転送装置や、最奥の坂にぽつんとあった白い小さな四角い転送装置は、結局ソーティではギミックに組み込まないんでしょうか。
敵から逃げたり敵の部屋に送り込んだり、狭い小部屋群を迷路にみせかけたりできる面白い装置だなぁと思ったりもしたものですけど。

[Iride]

ソーティの登録をして待ちほぼなしのはずなのに
まったく入れません。U1が0組、U2が10組なのを確認済

10分たっても入れない状態で、あとから来たPTが申請の気配
自分より後の番号が即占有されてはいっていきました。

どうなっているんだ・・・・と思って数分まったらソロのモンクがきました
申請してすぐに自分よりあとの番号が（つまり申請したモンク）が入っていきました

順番待ちシステムのコンテンツ
アンバス、メリポ消費のBF、オーメン等で同じ現象わりと頻繁にあるのに
話題にならないなぁって思っていました。

そこまで気にはしてませんでしたが
現在のソーティの待ちを考えると
10分待ってるのに後から来た人が先に入ってしまうのは
流石になんとかしてください…てなりますね。
これって不具合なんですかね？

[16BEAT]

順番待ちシステムのコンテンツ
アンバス、メリポ消費のBF、オーメン等で同じ現象わりと頻繁にあるのに
話題にならないなぁって思っていました。

そこまで気にはしてませんでしたが
現在のソーティの待ちを考えると
10分待ってるのに後から来た人が先に入ってしまうのは
流石になんとかしてください…てなりますね。
これって不具合なんですかね？

いまだに納得できない案件ではありますが、どこかの企業をまねしてなぜなに分析を自分なりにしてみました。
１．なぜ０組待ちなのに待ち時間が発生したか＞＞＞Ｕ１とＵ２のふりわけで１０組待ちのＵ２に適用された。それにより排出者待ちとなったため待ち時間が発生した。Ｕ１が０組なのにそちらにふりわけない時点でアウトですね。

２．なぜ後続のＰＴが申請してすぐ入っていったのか＞＞＞Ｕ２に待ち１、Ｕ１が待ち０の状態になっていたのでＵ１が適用されすぐ入室できた。その後にやってきたモンクさんも同じ内容です。

わたしは前回の投稿後から３０分ほどたった後に再び登録申請したところ、今度はＵ１にやはり空きがあったのですぐに占有ができました。１回目と２回目の違いはＵ１の占有数が０組だったかそうでないかです。Ｕ２はあいかわらず満席に近い状態でした。




満席でない状態でいいかげんな振り分けを行う不具合が発生しているのは間違いありません

[myajira]

インスタンスエリア作成が順番になされるわけですが、逆にそのインスタンス削除処理がどのタイミングで行われるのか、インスタンス管理サーバー内にキャッシュみたいなのが残ったままになり重くなるのでどこかで初期化処理が入るかもしれません。

たとえば、本来はU1とU2で空きがあるほうに申請されるが、あるタイミングでカザナルU1が重くなりすぎたため、U1の新規申請を一旦停止して、全てU2で受け付ける。現在進行中のU1プレイヤーが全て排出したら、一旦U1をフラッシングに入る。
この時点で、U1内は0団体、U2内が10団体となります。ここで新たにソーティ申請した場合、U1がフラッシング中であるため、U2で申請を受け付ける。U2内部にはまだ10団体いるため、突入待ちとなる。
その後にU1のフラッシングが完了、次に申請した団体はU1に振り分けられ、空きがあるのでインスタンス作成。残り9団体も順次U1に入っていく。さっきU2に振り分けられた団体はまだ突入できず。ようは、

1階のトイレが掃除中だったので2階のトイレに並んでたら、並んでる間に1階の掃除が終わってあとから来た人がそっちに入って行った

という可能性が考えられます。
まあ、そういう処理が行われてるかはわかりませんが、サーバーのシステム的に仕方のない現象かもしれないので、安易に不具合扱いはできないな、と。
突入待ちの団体はどちらかに申請して2列で待つんじゃなく、一列に並んで空きが出た方に順番にお通しするシステムになれば、申請ナンバー順位に入れるんですけどね。ただ、そうするとまた別の重さが発生しそうで悩ましい。

[Mithranest]

オデシーでもありますよね、自分の番号はとっくに過ぎて後の番号がどんどん入っていく
申請しなおしたらすぐ入れたこともあります。
入り口１と２への振り分けが空いてるかじゃなくランダムなんでしょうかね？

[Arequs]

複雑な処理をせず、交互に別の待機列に割り振ってるとかだろ？
乱数なんて難しくて開発には作れんだろうし。

[Mithranest]

2待ちで20分待ちました