イベントの連続入賞回数を表示するようにしました

プロデューサーごとの2枚取り・1枚取りの連続入賞回数を表示するようにしました。

↑赤枠のように表示されます

ただし、「ドリームLIVEフェスティバル 新春SP (2018)」(2018-01-10) については、2000位までの情報をボーダーbotが持っていないため、ここが事実上の判定限界になります。そのため、当該イベント以降すべて連続している場合は、以下のような表示になります。

判定対象となるイベントは、総合ランキングのみです。


<2020-08-06 追記>

最長入賞回数も見たい!というご意見が見えたので入れてみました。


<2020-08-06 追記2>

ドリームLIVEフェスティバル 新春SP (2018)」も1000位の情報までは残っているので、それ以前のイベントも含め、記録にある限りは連続入賞回数を増やすようにしました。

ただし、情報として完璧ではない(本当は入賞しているにもかかわらずカウントされない可能性がある)ので、直近から当該DLFまで入賞が続いている場合は「○○○回以上」と表示されます。

トップページでイベントノルマ値を参照できるようになりました

プロダクション・ミニチームイベントにおける「ノルマ」の参考値を、トップページで参照できるようになりました。

↑画像赤枠部分

計算式は以下のとおりです:

  • PMF:プロダクション11位のpt ÷ 40
  • DLF/TBS:ミニチーム101位のpt ÷ 5
  • ぷちコレ:ミニチーム101位のpt ÷ 10

※いずれも小数点第1位切り上げ

プロダクションではいわゆる「10社ノルマ」、ミニチームでは一般に 1+1 と呼ばれているものにおける、それぞれ標準的なノルマの参考値となります。当然ではありますが、実際に所属されているプロダクション・ミニチームにおいてノルマが設定されている場合、この参考値とは異なる値を取ることがありますので、あくまでも参考としてお使いください。

なお、トップページの更新間隔は10分ごとです。目安として、末尾が1の分(01分、11分、21分…51分)に更新されます。ただし、キャッシュの影響で1分ほど遅れる場合があります。

明日 7/29 を目処に、毎時出力しているイベントポイントツイート(の画像)にも同じ値が載る予定です。


<2020-07-30追記>

載りました。

障害発生時における挙動・ポリシーについて

7/26現在、デレマスボーダーbotではフリートレード履歴の取得が遅延する障害が発生しています。現時点では障害原因の除去は終了しており、取得できなかった分のフリートレード履歴をできる限り取得する回復動作が行われています。おそらく7/27中には回復すると見込んでいます。

↑障害時はこんな表示を各ページの上部に出すようにしています。ある程度遅延が続くと自動的に表示されます。

この post は新機能や上記障害対応そのものについての内容ではなく、現時点におけるデレマスボーダーbotの障害発生時における挙動・ポリシーについて説明してみようと思います。

ボーダーbotのシステム構成

ボーダーbotは全部で7台のシステム+作業用の保守端末で構成されています。

このうち観測(データ取得)に関係するサーバは、制御サーバとデータ取得サーバ、そしてデータを入れているデータベースサーバの3つです。イベントのポイントを取得するときの流れは以下のようになっています。

  1. 制御サーバがデータベースサーバを参照し、次に取得する必要のある情報を決定する。(例:そろそろイベントxxの総合ランキングポイントが更新される時間だ。まだ未取得なので観測しよう。と決定する)
  2. 取得タスクの優先度・取得期限を決定し、制御サーバ内のキューに登録。(例:取得範囲は個人1~2500位とし、200位や2000位は優先で取得しよう。と決定する)
  3. 制御サーバ内の別スレッドにおいて、登録されているタスクのうち優先度の高いキューから選別を行い、一番空いているデータ取得サーバに対してデータ取得を指示する。
  4. データ取得サーバが指示されたページを取得して解析。解析結果を制御サーバに返す。
  5. 制御サーバは受け取った結果をデータベースサーバに保存する。

これをずっと繰り返し、イベントポイントを取得しています。

構成図を見るとデータ取得サーバのみ3台のクラスタが存在します。これはある一定量以上の通信を「同一 IP から」 Mobage 側に行わないようにするために行っています。結果としてここだけ HA 構成になりました。すこしだけ”闇”になるのであまり深くは記載しませんが、外部へのアクセスを複数のグローバルIPから行えるよう工夫されています。

話がずれるものの大事なことなので記載しておきますが、複数台構成とはいえ、パラレルアクセスにより相手サービスに集中的な負荷を与えてしまうことがないよう、制御サーバーでキューと優先度の管理が行われています。総体としてのボーダーbotから Mobage ないし各種の外部 API へのアクセスは、一部の極僅かな例外を除いては、シリアルアクセスを保ち、かつ適切なアクセス間隔を保つよう厳格に制御されています。

この制御サーバの動作はボーダーbotの中枢であり、4年間にわたって改良を続けています。この詳細な動作を説明すると数記事に渡ってしまいますので、今回はデータ取得サーバ3台を1台の制御サーバが司っていることを伝わればよいかなと思います。

サーバごとの障害影響と縮退運転

ボーダーbotは全体としては HA 構成ではありません。データベースサーバと制御サーバは単一障害点であり、どちらかの機能が停止すると基本的にはボーダーbotの全機能が停止します。ツイートもWebも止まったときは、だいたいここがシステム障害で死んでいます。先日あった事例では、 SSD が満杯になって全機能が止まりました(文字に起こすとなんとしょうもない…)。

Webサーバとツイート画像生成サーバでの障害発生時は、それぞれWeb・ツイート出力のみが停止します。

問題はデータ取得サーバで、これだけは3台あるために特殊な動きをします。このサーバは1台が死んだ場合でも他が生存している場合は、一部の機能を制限しつつ稼働を止めないようにする「縮退運転」を制御サーバが行います。

今回の障害は、このデータ取得サーバのうち1台が、サーバ(VPS)を借りている業者(Linode)の収容器の故障により一時的に停止したことで発生していました。

こういった機材故障やアプリ障害以外にも、ボーダーbotから見た対向システム要因によるものがあります。イベント最終盤など特定の条件において、Mobage 側からの平均応答時間が連続して著しく遅延したり、Gatewayエラーなどのいわゆる「白画面」が頻発した場合です。このような状況でボーダーbotが負荷をかけ続けることは好ましくないと思われるため、過負荷と思われる状態を検知すると、制御サーバは一時的な「縮退運転」モードに入ります。

縮退運転時における優先機能

制御サーバは障害または過負荷検知により縮退運転を迫られた場合、以下の優先度で機能を活かそうとします。(上を優先して活かします)

  1. イベントポイント観測(100位、200位、300位、1000位、2000位、4000位など。ここでは「基準順位」と言います)
  2. カード情報更新(※新しいカードの追加を検知した場合)
  3. イベントポイント観測(基準順位以外)
  4. 最終イベント結果取得(プロデューサー・プロダクション情報更新)
  5. 道場情報更新
  6. フリートレード履歴取得

データ取得サーバが1台故障した時は 4. 5. 6. が行われなくなります。2台故障時や Mobage 側の過負荷検知時は 3. も停止します。

デレマスのイベントポイントは10分ごとに更新されますが、これは観測側の視点に立った場合、当該イベントポイントの取得は10分間しか許されておらず、そのタイミングを逃すともう二度と正確な値を取得することができなくなることを意味します。したがってボーダーbotは、この10分の間に重要度の高い順に必要なポイントを抜き取ることに主眼を置いて実装されています。

特に基準順位のイベントポイントは非常に重要であり、1999位のような報酬に関係しないイベントポイントは取得できなくともそれほど影響はありませんが、200位や2000位のイベントポイントを取得できなければボーダー観測情報を提供することができません。そのため、どのような場合あれ基準順位のイベントポイント観測は成功するまで何度も試み、1. が成功しない限り 2. が行われないようになっています。

それに対して最終イベントポイントやフリートレード履歴といったものは、一時的に取得できなかったとしても、期限内であれば障害の回復後に再度取得してもタイムラグ以外に問題が起こりづらい種類のものです。道場情報もそれほど最新情報が要求されるわけではありません。縮退運転せざるを得ない場合には、これら遅延が許される処理を率先して後回しにしています。

ボーダーbotはいまやたくさんの役割を持つようになりましたが、最も重要なのは基準順位の観測です。2016年に始まったときから今に至るまで、この点が変わることはありません。

もっとも、カリビアンクルーズアイプロお仕事体験♪のように、障害が解決できないと 4. がまるごとスキップされて最終結果取得が間に合わなくなる事故が起きることもあったりします。もちろんこの場合も、ボーダーbotとしては最終結果より推移情報が全てにおいて優先するので致し方ないのですが…

たまにボーダーbotが「基準順位のポイントツイートは出ているのに、上位P 個人800位までのポイントツイートを出力しない」いう挙動をしていることがありますが、これは過負荷検知などにより 3. が止まっているときに起こります。基準順位以外の情報が欠けているので、ツイートが作成できず出力をスキップしている状態です。

さいごに

今回、フリートレード履歴の取得が遅延している理由について説明しつつ、どういう優先度でデータを取得しているか記載してみました。

いま現在は制御サーバ内に、優先度低いラベルがついたフリートレード履歴取得タスクが積み上がった状態になっています。より優先度の高い PMF51 のイベントポイントを取得しつつ、また Mobage 側への過剰な負荷を避けるため間隔を保ちつつ、緩やかにタスクが消化されています。もしフリートレード履歴をお使いの方がいまこれを見ていましたら、いましばらくお待ちください。

デレマスボーダーbotは、ミリオンボーダーbotさんやナナシスイベントボーダーbotさん、matsurihi.meさんなどを参考にして作ったものですし、特に最初期はミリオンボーダーbotさんの解説を読み込んでから作った経緯もあります。この開発ノートには、(PMFなどで)時間のある際に、誰か/なにかの参考になるよう、このボーダーbotの説明もたまに残していければと思っています。

上位プロデューサー一覧画像をイベント明細ページで見られるようにしました

イベント個別の明細ページから上位プロデューサーの一覧画像を見られるようになりました。

↓の赤枠部分です。

上位プロデューサーの一覧画像は毎時(ラストスパートでは10分ごとに)出力していますが、上位4枚の画像しかツイートには出力していません。もしツイートしている分より下が見たいという場合は、これを使ってください。

フリートレード履歴の正式版をリリースしました

永らく beta 版として提供してきたフリートレード履歴ですが、この度のアップデートで正式版としてリリースしました。

正式版の新機能

  1. すべてのフリートレード履歴を取得するようになりました。これまではアルゴリズムの都合により、一定の割合で、時間あたり取引量が多いアイドルのフリートレード情報を見逃す可能性がありました。
  2. 上記に関連しますが、フリートレード履歴の「流し」行為に対して一定の耐性を持つようになりました。同一カードの取引が大量かつ短時間に行われた場合、beta 版では当該履歴に空白期間が発生しましたが、正式版では急激なトレード成立にある程度まで耐えられるようになりました。(※注1)
  3. 新たにカード別のフリートレード成立件数を見られるようになりました。
  4. 上記 1. 2. はCSVにも適用されます。全量の履歴取得は引き続きCSVをご利用ください。
  5. 上記新機能は7月のある時期から適用しています。beta 版時代の過去分にまでさかのぼって全量を取得するものではありません。

※注1 Mobage版デレマスのフリートレード履歴は、カードごとの履歴一覧ページに表示されてない分も含めてある一定期間は取得できます。しかし実際には、同一カードごとに最大履歴数が設定されており、同一カードで集中的なトレードが行われると短期間で当該カードの過去履歴の参照ができなくなります。

不具合や改善要望等ありましたら Twitter: @imcgborder までリプライください。

過去イベント比較ツイート画像に前イベ最終pt×比率を追加

過去イベントとの比較ツイート画像に、過去イベント最終結果pt×対過去イベントpt比(画像の [E] 列)を追加しました。

あれば便利なのはわかっていたのですが、「イベントptのボーダー予想」と勘違いされるとよくないなと考えてこれまで追加してきませんでした。まだヘッダ部分を改良したり説明を付加したり、改良の余地がありそうですので、逐次実施していきます。

Webポータルの表示速度改善

Webポータルが遅い(表示がもっさりしている)というご指摘を受けて調査したところ、イベントによっては終了間際のラストスパート時間にイベントページに集中的なアクセスがあるようで、この負荷が全体を引っ張り、平均応答時間が5秒を超えている時間帯があることがわかりました。

これまであまり Web ポータルの速度については考慮してきませんでしたが、5秒はちょっと腹立ちますし、APIにも影響が出ていたので改善してみました。

  1. リバースプロキシを設置してほぼ全てのリクエストを Cache-Control の max-age 期間だけキャッシュするようにしました。実はこれまではすべてのアクセスを Kestrel で動的処理していました。これには画像も含まれます。おそいですね。
  2. トップページ、イベントページ、道場リストはアクセス頻度が高いため、表示する ViewModel データを、次のイベントスコア更新タイミングまでの間、シリアライズして Redis にキャッシュするようにしました。
  3. イベントデータなどの各ページで共通的に使うマスタ情報も、 シリアライズして各ページ間で横断的にキャッシュするようにしました。
  4. 特定ページでしか使っていないライブラリ (Handsontable等) は、使用しているページでのみ取得するようにしました。

ボーダーbotのWebサーバはケチっていて、CPUも1コアしかないのである程度諦めはあります。いまのところ時間あたりで平均応答が 2秒を超えたケースは直近2週間で一度もなかったようなので、とりあえずこれで様子を見ます。

ツイート画像スタイルの刷新

2019年1月以来となる、ツイッター画像の全面的な変更を行いました。まだ一部のツイート画像は古いスタイルのままですが、漸次的に変更していきます。

変更前後の比較

変更前

変更後

※画像は改修中のものです。

変更のねらい

これまでにDMないしリプライでユーザから頂戴したご指摘を分析して対応しました。

1. 総合ランキングの上位報酬が判りやすいヘッダ画像にした

ボーダーbotのツイートにおいてご指摘が最も多いのは、「上位報酬が間違っている」です。ぶっちぎりで多いです。

しかしボーダーbotは総合ランキングの上位報酬カードは自動取得するようになっており、上位報酬が誤取得されるケースはほぼありません。ではなぜこの指摘が来るかというと、中間ランキング期間中には、ヘッダーに中間ランキングの上位報酬を出力していたためです。中間ランキング期間中は中間終了日を基準に出力した方がランナーは嬉しいだろうという前提で作られていました。

おそらく、利用しているユーザの一定数はそもそも中間イベントの存在を認識しておらず(または少なくとも重要視しておらず)、出力されている上位報酬の画像と想定している(=いま狙いに行こうとボーダーbotを参照している)上位報酬が異なったことが、この指摘につながったものと考えています。

これまでも注意書きなどを追加するなど小手先の改善を続けてきましたが、本格対応として、これまで上位報酬のミニアイコンを焼き付けていたヘッダーを、イベントトップ画像を背景にするよう変更しました。そのうえで、各ランキングの上位報酬アイドルはヘッダ外の本文中に貼り付けるようにしました。

実はイベントトップ画像と上位報酬は同一とは限りません(ex. 花見DEドリームライブフェスティバル)。とはいえ、少なくとも中間上位報酬ではなく、イベント中のメダル報酬SRなどのアイドルがトップ画像には設定されるため、問題ないだろうと思います。

2. 画像サイズをPCではなくスマートフォンに最適化した

ボーダーbot Webポータルの広告解析から、50%のユーザがアスペクト比 9:19.5 / 9:21 などの大型スマートフォンを利用してボーダーbotを見ていることがわかりました。スマートフォン・タブレットの割合は80%弱に上ります。(PCは残りの2割しかいない)

Redmi note 9sなどの最近のミドルレンジスマホにおいても縦長液晶の製品が増えていることから、横に延ばすよりは縦に延伸する画像に変更することにしました。

3. ミュージックJAMの並走4ランキングに対応した

イベント中に4つのランキング(総合+3つのステージ)が同時に並走するミュージックJAMに対応しました。

4. 日本語を解せないプロデューサーからの問い合わせを軽減する

これまでの設計方針として、「関連する内容はなるべく1枚の画像に集約したほうが、ヘビーユーザには使いやすいだろう」という想定で出力する画像をデザインしてきました。私はそれなりにヘビーにイベントを触っていますし、ボーダーbotも活用するなかで、その方が便利だったからです。

しかし、ボーダーbot利用者の15%は海外の(おそらくそのほとんどは日本語ネイティブではない)ユーザです。DeepLやGoogleで翻訳可能なWebポータルと異なり、ツイート画像は日本語を現地の言語に変換することができません。

1枚の画像に複数の内容が出力されている場合、日本語を読めない海外ユーザにはなにが複数載っているのか理解しがたいようで、「これはなんなのか」という問い合わせが来ることがあります。

現実問題として海外ユーザからの問い合わせは、日本語に翻訳したうえで送っていただいたとしても回答に体力がかかります。データの誤りなどへのご指摘はありがたいですが、同種の質問DMへの回答時間は削減したいのが正直なところです。

「1画像には1つの情報のみ」「比較は同時に1イベントのみ」に分離することで、文字を読まなくとも”なんとなく”なにが出力されているのかわかりやすいようにしました。

5. データの正確性を保証しない旨の追加

たまにmobageからのデータ取得タイミングによっては、値が不正確なことがあったり、データの欠損により新旧イベント間比較の結果が一時的に誤っていることがあるので、正確性が保証されない旨の記載を末尾に追加しました。

お叱りをいただいたことがありますので、これは「逃げ」として追加しています。

今後

  • UIの変更なので、おそらく見やすさとしては前の方がよかった~という意見もあると思います。私も前の方が良かったなと思う部分がまだあります。
  • とはいえ、誤解されづらくて、比較的はじめての方にわかりやすくて、かつ問い合わせが減るようになることが目下の優先事項です。

ボーダーbotの更新情報を記載するようにしました

4年以上にわたって改修と仕様変更とmobage側の変更への追随を続け続けた結果、デレマスボーダーbotの仕様はつぎはぎだらけになり、極めて複雑怪奇になりました。

最近はあとから質問を受けたとしても、いつどんな仕様になったかまったく覚えておらず、gitのコミットログを追わないと経緯も実装もわからないことが増えてきました。

つきましては、せめて更新情報くらいはきちんと残しておくべく、本ブログに修正内容をなるべく載せていく運用にしようと思います。

UIやツイートなど外から見える部分にとどまらず、おそらく一般ユーザにはあまり関わらないであろう内部変更についても、可能な範囲で記載していくことにします。