カード明細ページで参照できる画像を増やしました

プレミアムサイン付き画像、お仕事画像(クエスト画像)、透過画像をカード一覧のカード明細ページで見られるようになりました。

お仕事画像とは

お仕事画像は、マイページでアイドルの短冊をクリックすることにより、表示することのできるアイドル画像のことです。

マイページ表示例

または「新お仕事」を選択している場合に、画面遷移時にも表示されます。

カード明細ページでの表示

カード明細ページで、カード画像上部にあるタブを選択することで表示を切り替えることができます。

例:[すくx2あかりんご]辻野あかり+

なお、ほとんどの R は、お仕事画像が透過つき PNG 形式で提供されます。これはRの背景がCu/Co/Paそれぞれで共用であるためです。

例:辻野あかり+

イベントのパワー持ちカードを管理するようにしました

パワー持ちの特技を一覧で見られたらいいのになあー
フリトレ履歴も主にトレードするのはパワー持ちばかりだし、いちいち名前検索するの面倒だし勝手に絞り込みができたら楽だなあー

と自分で使っていて思いましたので、さっそく追加してみました。

できるようになったこと

上記ツイートにも記載のあります通り:

パワー持ちカードを取得可能なイベント

現在開催中の第42回ロワイヤルからです。

実装自体は前イベントの秋のぜいたくグランピングアイプロの時点で終わっていました。ですが、イベント終盤にリリースして変なバグを踏みたくないなーということで安全策を採り、アイプロの終了直後にリリースしたところ、なんとMobage側の仕様としてイベントの終了後はパワー持ち一覧のページを取得できなかった…(仕様不理解によるバグを踏んだ)

おかげでアイプロのパワー一覧を取得できず、しかも開発環境のDBを運悪く洗い替えてテスト時のパワー持ちカード一覧データも残っておらず…

それら都合により、パワー持ち一覧を取得できるのは、現在開催中の第42回拓海ロワイヤルからとなっています。

最近検知されたカード画像の変更

ご利用ありがとうございます。
「アイドルマスター シンデレラガールズ」運営事務局です。

9/8 15:00頃、アイドルの画像を一部変更いたしました。

アイドル画像の一部変更について(Mobage)

というお知らせがmobage版シンデレラガールズで通知されました。これに触発されましたので、ボーダーbotが最近検知した「カード画像の変更」について以下にまとめました。本件はボーダー観測に何一つ関係がないことから、この開発ノートに書いておきます。

ImageMagickの使い方把握ついでにアニメーションGifの比較も作りましたので添えておきます。各カード画像は、「修正前」「修正後」「比較アニメーションGif」の順に並んでいます。

なお、デレマスボーダーbotは、画像に差異がないかを定期的に確認しています。6,544カード全種類を一気にチェックするのはMobage側にかける負荷が高いため、「リーダーに設定されている数が多いカード」を優先してチェックするアルゴリズムになっています。

※注意:以下の変更内容は、今回のお知らせで修正対象となったもの以外も含まれていると思います。検知が最近になっただけで、かなり前に修正されたものも混じっているかもしれません。

[ゴーフォーヴィクトリー]仙崎恵磨

CardHash: 1a488f8bab8e0efae8f777f10b21dc6a

[センター・キャプテン]愛野渚

CardHash: 868c92e18aa41e24a61546b2100548b5

[センター・キャプテン]愛野渚+

CardHash: 701f66d34f5d7d58aa7d977ca3450565

[ブレイブステージ]緒方智絵里

CardHash: 17dfc3a665a0263e5b922f1c47a7667b

[碧眼の姫君]メアリー・コクラン

CardHash: 990199c5bd44be16361a787dda7e5ec2

[くのいち忍ドル]浜口あやめ+

CardHash: 159060b683d4e8bea49d2c90753f61c7

[貴婦人のたしなみ]和久井留美+

CardHash: ad621fe47393a5bcba98b5729077ac4e

喜多日菜子

CardHash: 35ed8cc4e33cec53aea016cb9e2f0f22

[大傾奇娘]丹羽仁美

CardHash: 26b2a0c90723a9b074e65e4ecb2c937e

[大傾奇娘]丹羽仁美は、人間の目だとほとんど差がわかりません。

[大傾奇娘]丹羽仁美+

CardHash: f04628745ca35b5896d03126fcdbed8d

[色づき紅葉・スマイル]佐々木千枝

CardHash: 7d617c6da4e598221715f638460b14b4

私見ですが、[色づき紅葉・スマイル]佐々木千枝は右に余白ができているので、運営がなにか間違えてている気がします。

Cinderella API v2 リリース

Cinderella API v2 (APIv2) をこの度リリースしました。これまで提供してきた、Cinderella API v1 (APIv1) の後継となります。

APIv2 の狙い

Cinderella API は地味な機能ですが、いまでは複数の Web サイト(道場リストなど)や、複数の Discord bot などで利用して頂いています。

デレマスボーダーbotのデータは、なるべく多くのプロデューサーの方々に、多様な形で利用していただきたいと思っています。CSV はそのひとつです。その中にあって、 API も、Web ポータルと同等に重要な機能として取り扱っています。

この度、APIv1 の利用状況を踏まえつつ、APIv1 では不十分・不親切だった点を改善してより利用しやすい形に設計し直したものが APIv2 です。

APIv2 の新機能

  • フリートレード履歴を取得できるようになりました。リアルタイムに準じたフリートレード履歴を提供します。期待される更新までのdelayはおよそ2分程度です。
  • ダブル特技の深化を踏まえ、カード API ではメイン特技・ダブル特技の詳細な効果を出力するようになりました。編成の組み合わせ検討などに利用することができます。

プロデューサー・プロダクションごとの時速も出力する計画はありますが、時速出力は場合によっては将来的になくなる可能性があるため、いまのところは実装していません。

APIv1 から改善された点

  • APIv1 では、検索パラメータの不足や誤りがある際に、400 Bad Request が返却されたり 404 NotFound が返却されたりと一貫性がなく、かつ NG である理由がわかりませんでした。
    → APIv2 では、パラメータ問題発生時のステータスコードは 400 に統一されるとともに、メッセージでNG事由が返却されるようになりました。
  • 利用状況を踏まえ、頻繁にアクセスされるAPIは積極的にキャッシュするようになりました。道場 API 、カード API などの利用率の高い API は、 APIv1 よりも高速に提供されます。
  • Key 名称が可変値になっている Hashmap(IDictionary) 形式の object は非常に扱いづらかったため、これらは全廃しました。これにより、 jq コマンド等での利便性が向上しました。(実はこれは製造時の誤りだったので、できればさっさと直したかったのですが、あまりにも破壊的な変更となるため運用後にはもう変えられませんでした)

APIv1 の取り扱いについて

  • deprecated (非推奨) になりました。
  • 引き続き利用することはできます。すぐに APIv1 が使えなくなるわけではありません。
  • 原則として、 APIv1 は不良があった場合でも今後は改善しません。また、将来的な他機能変更などに巻き込まれて利用不可能になった場合、対応するかどうかはわかりません。
    (APIv2 と APIv1 の両方をメンテナンスするのは大変なので…)
  • APIv1 を利用したアプリを作成・運用されている方々におかれましては、可能であれば、 APIv2 への切り替えをお願いできればと思います。出力内容は類似していますので、ほとんどの場合、大きな修正にはならないと想定しています。

利用にあたってのご意見、こういう API があったら便利なのに…というご要望などがありましたら、 Twitter: @imcgborder までお寄せください。

デレマスボーダーbotの機能追加・拡張は、(現時点においては)これが最後の予定です。しばらくは既存機能の改善と保守に努める予定です。

Cinderella API v1 の制限追加について

要約

Cinderella API v1 (以下APIv1)に、新たな2種類の利用制限を設けます。

  1. 以下の条件いずれかを満たした場合、HTTPステータスコード 429 [too many requests] が返却されます。この制約は APIv2 と共通です。
    • 高頻度でアクセスした場合。目安としてアクセス間インターバル5秒未満。
    • 応答サイズ(Content-Lengt)が数MBを超えるアクセスを連続して行った場合。
  2. 「プロデューサー検索」および「プロダクション検索」での検索時の最大応答件数を、2000 件に制限します。

これらの制約はすべて適用済です。

影響を受けるのは APIv1 利用ユーザのうち1%程度です。

経緯

かんたんに箇条書きで記載しておきます。

  • 昨今、Web ポータルを含めた pink-check.school 全体のアクセス数は伸び続けている。8月は昨年比で3倍近くの利用があった。
    (ゲームの状況的にも伸びる要素が思いつかないですし…理由はまったくわかりません)
  • そのため、最近は Web サーバのリソース使用率が比較的高い状態で推移していた。CPUが1コアのWebサーバは、Load average が常時 1.0 くらいに達している。通常、PMFやアニバーサリーアイプロの期間中は平時比でさらに3倍近いアクセスがあるため、現状のサーバリソースでは耐えられないかもしれない。
  • Web サーバを一段階スケールアップすれば問題は解決するが、これ以上、観測と直接関係ない部分を財布で殴るのは避けたい。毎月かかる固定費はこれ以上増やせない。
  • サーバへのアクセス数は Web ポータルと APIv1 でほぼ同じだが、使用されているリソース量を計測したところ、およそ 2:7 で APIv1 の方が負荷が高いと推測できる結果が取れた。
  • APIv1 の利用状況を調査したところ、極一部のクライアントが、高頻度で、しかも数十MBの応答が必要なアクセスをしていることがわかった。これら資源を過剰利用しているアクセスを分散させることができれば問題はほぼ解決すると想定した。(⇒利用制限 1. )
  • そもそも、プロデューサー(現在638,731件)やプロダクション(同44,314件)の全量を返却できてしまう APIv1 の実装が悪い。(⇒利用制限 2. )

API はなるべく多くの方に活用して頂けるよう門戸を開いていますが、限られたリソースで提供していることをご理解いただき、配慮したアクセスをお願い致します。

なお、全量取得のためには CSV を準備しています。こちらは静的処理ですので比較的低負荷です。1日1回の更新ですのでリアルタイム性はありませんが、カレントデータである必要がない大量データの取得には、ぜひこちらも活用してください。

カード一覧の刷新 ―ダブル特技が検索できるようになりました

修正点の要約

カード一覧ページの”ここ”が新しくなりました。

  1. アイドル一覧を刷新し、アイドルから各アイドルの個別カード一覧を表示できるようになりました。これまでのアイドル一覧は、各アイドルの最新のSR+に遷移していました。
  2. カード詳細検索ページを刷新し、ダブル特技を条件に検索できるようになりました。これまでのカード詳細検索は、ダブル特技の有無は検索できましたが、ダブル特技を条件(特技範囲など)とした検索が容易にはできませんでした。

いずれの機能もお気づきの点やご意見、なんかバグってんぞなどがありましたら、Twitter: @imcgborder までお寄せください。

↓↓↓ここから下はクッソ細かい、作り手本位の話なので読む必要はありません。

1. アイドル一覧

昨今の利用状況を探ったところ、カード一覧ページは、カードの詳細検索機能よりもアイドル一覧機能の方が多く利用されていました。カードの能力値や特技での検索よりも先に、「あのアイドルのカード」という条件でカードを探しに来るユーザの方が多かったものと思われます。

もともと、ボーダーbotを利用するユーザはアイドルより特技やステータスの方を気にするだろうという想定で作っていましたが、昨今の利用状況に合わせてアイドル一覧を優先表示するように変更しました。

また、これまでのアイドル一覧は、直接各アイドルの最新SR+にしか遷移できませんでした。もし目当てのカードが最新以外のカードの場合、遷移としては、①アイドル一覧で探したいアイドルを選択 → ②個別カードページで一番下に移動 → ③「同アイドルカード」の一覧から必要なカードを探す、という過程をとる必要がありました。

これはちょっと遷移数が多すぎましたので、アイドル一覧でアイドルを選択するとモーダルウィンドウ上で直接にカード一覧を参照できるようにしています。

本当は Fantasia さんの「アイドルで検索」のように、アイドルを選択するとカード一覧が最下部に表示されるという仕組みで最初は実装したのですが、やってみるとアイドル数は 212 人もいるし、最大で 55 枚(※1)も同アイドルにカードがあるシンデレラガールズでは、画面内遷移の移動量が多くてなんかいまいち…ということで路線変更してモーダルにしてみました。

※1 2020/8/21時点で最もカード数が多いアイドルは、大槻唯の 55 枚です。次点は白坂小梅の 52 枚です。一番少ないのはルーキートレーナー・サイネリア・桜井夢子の2枚です。カードが一番多い子と一番少ない子はいつもテストに使っています。

2. カード詳細検索

2019年6月以降、かつてはアイドルプロデュースで選択可能な特技としてしか用意されていなかったダブル特技が、ガチャおよびイベント上位で配布されるカードにも実装されるようになりました。

それから約1年が経ち、ダブル特技を持ったカードの数は 143 枚にまで増えました。まもなく10年目を迎えるmobage版シンデレラガールズにおいて、これらダブル特技を手持ちのカードと組み合わせてより高い発揮値を狙うことが、新しい遊び方の様式のひとつになっていると思います。

また、2020年6月より月末ガチャにおける特技効果向上がメイン特技ではなくダブル特技において行われたことから、これからはダブル特技で検索を行いたいと利用ユーザも増えるだろうと想定しています。

ボーダーbotはダブル特技が実装された当日に、ダブル特技での検索をグリッド内で行えるようにするなどの改善を重ねてきました。そこからさらに一步進めて、現下におけるゲームの遊び方に追随していくために、今般、メイン特技と同等の高度な検索が行えるように変更しました。

現在はWebページのみの改良ですが、現在開発中の Cinderella API v2 ではダブル特技の出力内容を改善する予定です。

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

プロデューサーごとの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の説明もたまに残していければと思っています。