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

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

↑画像赤枠部分

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

  • 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のボーダー予想」と勘違いされるとよくないなと考えてこれまで追加してきませんでした。まだヘッダ部分を改良したり説明を付加したり、改良の余地がありそうですので、逐次実施していきます。