Flower Knight Girl(PC)：緊急メンテ祭り＠根が深そう

とりあえず、緊急メンテが続いていましたフラワーナイトガールですが、なんか、また止まりましたね…。んー、これ、多分、性能ネックなんじゃないかなぁという気が。
あくまで想像というか、妄想の域ですけど…。
まあ、そもそも、ログインしてゲームとして元々動いていたモノですので、コードのバグで動かなくなったとかでは無いでしょう。
改良という名の建て増しを続けていて、コードが少しずつ重くなっていて、ユーザーも多少は増えて…かつかつだったところをついに上限超えた感じかと。で、メンテ明けのログイン集中時に、性能足りなくてエラー吐き始めて、エラーからの再アクセスがさらにエラーを呼んでいたのでは無いかと…。で、そもそも、エラーの判定が早くて、すぐにリトライしてしまう仕様だったのを、多分、今日のメンテで少し重くなるけど、しっかりと通信のやり直しを行う仕様に変更したのじゃ無いかなぁと。これは、21:50頃にログインして触った感じ、以前よりクッソレスポンス悪い状態になっていたことからの推測。
つまり、通信エラーが起きるとすぐにセッション切って、再起動、一から認証やり直しでタイトルから読み込みというのはエラー処理は軽く済む分、通信エラーが多く発生すると連鎖的に負荷が大きい状態になりやすいと。特に、タイトルからの読み込み失敗、エラーのループは早いと1クライアント数秒くらいで発生してましたので、それが長時間のログイン不能、高負荷状態を発生していたと考え、コードの通信周りを1日かけて必死に弄ったんじゃ無いかなぁ、と。
で、22時より前倒しでメンテ終えていて21:40-22:00の間は動いていたのが、22時からログインし始めた人たちが来たら結局負荷に耐えられなくなった感じ…に見えます。
面白いのが、エラーメッセージが、エラーが発生しました再度読み込みますか？Yes/Noみたいなやつと、エラーが発生しました(再起動)、セッションが切れました(再起動)など、何パターンかみられるところですかね。
この辺はコードの問題もありますが、軽量化ができずに、通信のリトライなどによる確実化を行うのは負荷を増やすだけで、結局、サーバ増強して負荷分散する以外の解決手段は無いのですよね…。
ちなみに、ここで言う軽量化というのは、新しい要素を入れて処理は増えている中で、プログラム自体を最適化して処理を軽く済ますと言う意味での軽量化です。こういう軽量化は完全にソースコード書く人の技量というか、センスというか、そういうのに左右される、ごく一部の変態天才が持つ技能なので…。当然、大学院で情報系専攻している奴に希に居るかどうかレベルの存在で、本人の素の能力に加えて、そっち方面に力を入れる気が無いと生まれないタイプの天才(オタク)ですね。実物で知っているのは先輩に1人、後輩に1人レベルですね。え？私？いえ、全然無理ですけど。
なお、日本では、個人レベルでのそういう天才が報われるような企業の仕組みが全くなく、むしろ、やれる奴、使える奴という形で、同一賃金で割り増しで仕事が降ってくるだけ、評価は大してされない、ので素スペックがあったとしても、馬鹿馬鹿しくてそっち方面に力を入れようという人自体がまれという…。
なので、まあ、そういう方向での天才がコードをメンテしてくれるというのは、ブラゲ・ソシャゲ・ガチャゲ開発レベルの現場ではほぼ無理でしょう、ということ。

イメージ的には、ピーク時に100人アクセスする状況で、ログイン時の負荷が1人辺り3、ログイン後の負荷が1人辺り1で、最大150の処理能力持っていたのが、ログイン時にピークに近い負荷が来て、300の処理が発生。ゆっくり処理しながら普通にログインできたのが50人、継続してログイントライしてたのが50人、これで200の負荷。結局50捌ききれないので、ボロボロ落ちて、入れてもすぐにログインに戻されたりで、高負荷状態になっていたのでは無いかと。
で、これをログイン後の負荷を1人辺り1.2かかるようにしましたが、一度ログインできれば、比較的切断されにくいようにしました、と。そうすると、最初は300の負荷でも半分を処理して、その半分がログイン維持できていれば、残りの人間も順次ログイン完了して、100人がログイン後120の負荷で動くはず…という目算だったのでは無いかと。実際には、思っている以上に性能に余裕が無くて、重くした分だけ、状況が悪化したんじゃ無いかなぁ、と。
というか、まあ、ぶっちゃけ、設備投資の読み間違いの場合、すぐにサーバを割りませるかは、環境依存ですからねぇ。余所のクラウド借りているなら、お金払ってバーチャルマシン(論理的なPC)を増やして貰えば、良いだけですが自前でサーバ用意して動かしているとすると、すぐに増設は難しかったりしますからねぇ。
あとは、まあ、マシンスペックと書きましたが、問題がネットワーク回線負荷だった場合、さらに根が深い可能性がありますね。サーバ容量の場合、まだ、サーバ増設で対応できますが、ネットワーク容量の限界だった場合、回線自体を増設するのはさらに難しいのですよね…。まあ、そういう方向でのスケーラビリティの確保という観点でこそクラウドサービスが生きるんですけど。サービス品質とか、信頼性とか考えて設計しているとは思えない、スモールスタートで数打ちゃ当たる式の商売が、外部にお金払ってサービス受けているとは到底思えませんし…。

で、想像できる対処法としては…3つくらいにグループ分けして1時間ずつくらいずらして順次ログイン可能にするとかですかねぇ。多少の文句は出るでしょうけど、次回のアップデート時にはローテーションしてログイン時間をずらしていく形にすれば、不公平感も多少緩和しやすいでしょうし。

また、たまに入れるようになりましたね。多分、諦めた人がそれなりにいて、性能ネックが解消されてきているのかもしれません。そして重いのかイベントページ開こうとすると通信途絶しますが。
まあ、もう一徹頑張ったところで多分どうにもなりませんので、中の人は、諦めて寝たほうが良いでしょう。サーバの発注だけかけて。