「ガンダムブレイカーモバイル」マルチミッション不具合について、素人の私が趣味で勝手に妄想してみる(^^;)
ブログ訪問ありがとうございます！
毎日楽しませていただいている「ガンダムブレイカーモバイル」なのですが、10/24、正確には10/25にから始まった不具合が続き、正常にプレイできない状態が継続しているようです。
そこで素人ながら「趣味でシステムの不具合を想像する私」が何が起こっているか勝手に妄想してみたいと思います（「時効警察はじめました」っぽい(^^;)）
ここから先に書かれていることは、素人の私による、素人の私のための妄想なので、信じないでください。よろしくお願いします<(_ _)>
まず10/24に発生していたサーバ高負荷についての妄想です
元々はこんな感じでシステムを組んでいたのではないでしょうか（現在まともなドローイングツールがないので拙い絵ですいません<(_ _)>）
同一のサーバ上に「通常の処理を行うサーバプログラム」と「マルチミッションのルームプログラム」を同居させた状態。
これは想像ですが、「ガンダムブレイカーモバイル」のイベントミッションなどは、バトル自体はデバイス（iOS/Android端末）上で行われていて、結果だけがサーバに送られてプレイヤー毎のデータを更新する形式ではないかと思います。ビルドなども同じだと思っています。
これに対して、マルチミッションはおそらくホストのデバイス上でバトルの処理が行われていて、各プレイヤーの操作や結果などをサーバ上のプログラムを介して、ゲストのデバイスに送信して表示させているのではないかと勝手に想像しています。
おそらくルーム毎にプロセスを起動して対応しているのではないでしょうか。
他のミッションに比べると、サーバに対して行われる通信データ量は膨大になり、そのデータ交換を行っているサーバ上のプログラムはかなりCPU性能を使っていたのではないでしょうか。
マルチミッションによる異常なまでのCPU負荷が同一サーバ上にある「通常の処理を行うサーバプログラム」にまで影響を及ぼし、いろいろな不具合を生じさせた。
これが10/24に起こったことではないかと勝手に想像しています
これに対して翌日対策を打ってきました。ここも想像ですが、システム構成をこんな感じに変えたのではないでしょうか。
物理的にも別サーバを立てて、マルチミッションの処理をそちらで行うように変更。
ログインやイベントミッションなどに影響が出なくなっているので、サーバ増設はしていると私は思っています。
対応の早さから考えると、開発陣は元々この構成で提案していたにもかかわらず、運用コストを渋った責任者が単一サーバでリリースするようにパワハラしたのかもしれません（妄想が膨らむばかり）。でも現実に問題が起こったので、元々開発陣が提案していたシステム構成を渋々了承した。もしかするとこんなドラマがあったかも。
※印象でしかありませんが、組織内はうまくいっていないように感じてます。
しかしながら、新たな不具合が発生します。
10/25にTwitterでつぶやかれていた不具合の多くはこんな感じでしょうか
・ルームが作成できない
・ルームが定員でないのに満員と表示されて入室できない
・「回線が切断されました」のメッセージが表示される
ごく僅かバトル中に不具合が発生したようなツイートも見ましたが、多くは上記３つになると思っています（これも情報が少ないので想像でしかないです）
個人的な意見ですが、β版リリースとして、専用ホームページや専用のTwitterアカウントなどを作って、広くプレイヤーから情報を集めるなどをすればよいと思います。
これらの不具合はマルチミッションを試みる人が多い時間帯に頻発し、少ない時間帯にはほとんど起こらないようです（私も今朝プレイしたのですが、全く問題ありませんでした）
不具合が認識されてから、１日以上経っても開発側からお知らせが出ていないことを考えるとまだ原因特定に至っていないのかもしれません。ということは
・増設したマルチミッションサーバ側のCPU負荷やメモリ使用量超過に起因していない
・サーバへの通信データ量には十分な余力があり、通信負荷による不具合とも考えられない
という感じなのかもしれません（これも想像です。既に原因特定し対策中の可能性は十分にあります）
蛇足ですが、25日夜にiOS版のアプリが緊急アップデートされました。不具合が解決したわけではないので、評判は悪かったと思うのですが、個人的には「既に判っている不具合の影響で新たな問題が発生している可能性を排除する」という意味で、不具合対策のセオリーを守っていると感じました（今までとトラブル対策している人が変わった感じがしました）
少し脱線しますが、私の昔話です。
今回の不具合から、遠い昔、まだシステムエンジニアだった頃、似たようなことが担当システムであったのを思い出しました。
販売拡大のため、プログラムを別のOS上に移植。移植自体は問題なく行うことができ、リリース直前に性能評価を行ったのですが、いきなり端末が接続できない不具合が発生。リリース日も迫っていたので、徹夜で対策を行った苦い経験。
この時、最初に疑ったCPU負荷やメモリ使用量などは全く余裕があり、ネットワーク負荷も装置を入れて測定したのですが、全然余裕でした。何が原因か全くわからない苦しみ。
試しに同じ負荷を元のOS側のシステムにかけてみると、全く問題なく動きます。迷宮に踏み込んでしまった感じ。
夜の１時過ぎに基本に返ろうと思い、TCP/IPの本を読み始めたのを覚えています。でも、この本がヒントを与えてくれました。
・サーバがセッションを確立し通信行うためのリソース（名前忘れました）があり、これはOS上のパラメータで一定量設定されている。
・通常は十分な量であり、使用が終わったリソースは順次解放され、再利用できるようになる。
調べてみると、問題が起こっている移植後のシステムではこのリソース使用状況が上限に達していました。さらに驚いたのは移植元のOS側では全然余裕があったことです。
この違いを確認していたら、移植元のOSでは使い終わった（通信が終了した）セッションのリソースは即時解放されて再利用可能。移植先のOSでは一定時間毎にまとめてリソースの解放を行う仕様になっているようでした。
短い時間に接続/切断を繰り返すと「セッションを確立し通信行うためのリソース（名前忘れたよ）」を消費して枯渇してしまうというのが原因でした。
メーカー側に問い合わせしましたが、OSの根幹部分なので、すぐには修正できないということで、開発者で検討した結果、なるべく「接続/切断を繰り返さない」ようにプログラムを改修することになった。と記憶しています（昔の話なので、記憶違いがあるかもしれません）
閑話休題。
今回の「ガンダムブレイカーモバイル」のマルチミッションの不具合も、「マルチミッションサーバ」側のセッション毎に使用される通信リソース不足を疑っています。昔の人ですし、OSもどんどん新しくなっていますし、全然的外れだとは思います。素人の妄想でしかないです(^^;)
でも妄想ついでにマルチミッションの仕様も想像しちゃいます。
１．イベントに入る段階。イベントのランクを選ぶまでは通常の処理を行うサーバプログラム（メインサーバ側）で実行
２．「ルームを作成する」を選択すると、メインサーバ側からマルチミッションサーバ側にリクエストが出され、ルームが作成される。ここで使える通信リソースがないと「ルームが作成できないエラー」が発生する。
３．「ルーム選択」を選択すると、メインサーバ側からマルチミッションサーバ側へ問い合わせが行われる。
４．「ルームに入ろうとする（ルームをタップする）」と、メインサーバ側からマルチミッションサーバ側の「マルチミッションのルーム」プロセスに新たに通信リソースを使って、ルームの空き状況について問い合わせが行われる。このタイミングで使える通信リソースがないと「ルームにはいれません。ルームが満員です」が表示される。
５．上記問い合わせの結果、ルームに余裕があり入室できると、デバイス（iOS/Android端末）からマルチミッションサーバ側の「マルチミッションのルーム」プロセスに新たに通信リソースを使って接続を行う（おそらくホストのルーム入室も同じ処理と想像）。このタイミングで使える通信リソースがないと「回線が切断されました」のメッセージが表示される。
６．マルチミッションサーバ側の「マルチミッションのルーム」プロセスとホスト＆ゲストのデバイスとの通信が確立すると以降マルチミッションサーバ側で問題なく処理が行われる。
実際のところはわかりませんが、こんな仕様かなと妄想しています(^^;)
妄想通りだとすると、マルチミッションサーバのCPU負荷もメモリ使用量もデータ通信量も全く余裕があるにも関わらず、通信ができない状態が継続して発生してしまいます。
さて、ここまで妄想を膨らませた結果、何が「通信リソース枯渇」につながると考えているかというと、「４．「ルームに入ろうとする（ルームをタップする）」と、メインサーバ側からマルチミッションサーバ側の「マルチミッションのルーム」プロセスに新たに通信リソースを使って、ルームの空き状況について問い合わせをする」ではないかと思っています。タイミング的に満室になるルームも多いはずなので、ほとんどのユーザが頻繁に行う操作であり、恐ろしい速度で通信リソースを消費しているのではないかと妄想しています。
この推測が万一当たっているならば、サーバを増強し分離したことによる不具合であり、プログラム構造を変更しないと対応できないのではないかと思っています。
さて、ここまで素人の私による、素人の私のための妄想にお付き合いくださり、ありがとうございました。長時間調査される不具合への妄想を膨らませたおかげで、個人的には楽しい時間を過ごさせていただきました（自分でも変な趣味だと思う）。
実際の不具合原因は他にあると思いますが、早期に原因が特定され、安定したサービスが実現できることを祈っています。
