サーバ統廃合に伴う一部機能縮小について

先に申し上げると、今回はほとんどの方には影響がないと思います。

要約

  1. デレマスボーダーbotは、基準順位(*)ではなく、かつイベントの最終結果ではないイベントポイントのデータを保持しなくなりました。このため、当該データはCinderella APIでデータが取得できなくなりました。
  2. 毎10分のプロデューサーの観測範囲(ポイント取得対象の順位)を10,000位以上→8,000位以上に縮小しました。

※基準順位:イベント報酬が切り替わる順位。ボーダーbotでは、プロデューサーであれば1位、10位、100位、200位、300位、1000位、1500位、2000位、3000位、4000位、7000位、10000位、15000位、20000位を指す。

1. 過去イベントの基準順位以外の推移情報は取得できなくなりました

デレマスボーダーbotは、これまで過去のイベントの推移を含め、イベント開催中の10分ごとのすべてのイベントポイントを保持してきました。これらの過去のイベントのポイント推移は、Webポータル上では基準順位のみが参照できるようになっていましたが、Cinderella APIでは例外的に順位またはMobageId/ProductionIdを指定することにより取得が可能になっていました。

しかしながら、最終結果という一断面だけでなく、データサイズの嵩む推移情報も保持することはデータベースサーバへの負荷が大きく、永くボーダーbotの課題となっていました。一断面あたり2MBくらいなので大したことはないように見えますが、これが7日間のイベントとなると 2MB * 1時間に6回更新 * 24時間 * 7日間 = 2GB となります。かつ中間がある場合は二重に保持する必要があります。JAMに至ってはイベント全期間にわたり四重になっていました。

過去の推移情報を持つと、データが重なることで金太郎飴のように長くて太いデータになります。それが7年近く溜まり続けたことで、最近は取り扱いに難儀するようになっていました。イベントポイントテーブルのインデックスがメモリに乗らなくて性能劣化を起こしていましたし、メンテナンスも時間がかかっていました。

そのため今般、思い切って過去のイベントポイントはデータベースサーバから削除しました。厳密には、Webサーバが参照している自前のMariaDBからGCP BigQueryに移行したのでデータそのものは残ってはいますが、WebサーバからBigQueryは参照しないようにしています。事実上、一般のユーザの皆様はもう過去ポイント推移情報に触ることができません。

この対応により、APIで取得できるイベントポイントは下表のようになりました。

データ日時基準順位基準順位以外
最終結果より前の日時参照できる参照できる→参照できない(今般変更)
最終結果参照できる参照できる

ただし、開催中のイベントのデータは基準順位以外もフルデータを保持しています。イベント終了後に全プロデューサー・プロダクションのポイントを取得したあと、推移情報を削除する仕様になっています。もし基準順位以外の推移情報を必要とされる場合は、必ず開催中にCinderella API経由で取得するようにしてください。

2. 毎10分のプロデューサー観測範囲を8,000位に縮小

先般プロデューサー観測範囲を10,000位に拡大したばかりですが、すべてのサーバの効率化を目指し統廃合を行った結果、10分ごとに取得できる範囲が少なくなりました。

そのため、目下の需要や利用状況も考慮し、8001位~10000位間の観測を取りやめています。

今後

今後、フリートレード履歴機能およびイベントポイントの10分速/30分速/時速/24時間速計測にも、効率化を目指し手を入れようと思っています。

Cindrella API (v1/v2) の利用規制が強化されました

この記事は、デレマスボーダーbotのAPI「Cinderella API」を利用している開発者向けの記事です。デレマスボーダー bot の Web ポータルの利用者、あるいは Twitter (@imcgborder) の利用者にはあまり関係がありません。

なにが変わったのか(要約)

  • Cinderella API (v1/v2) は、短時間に多くのリクエストを行うと HTTP ステータスコード 429 [Too Many Requests] を返すという制限(仕様)が以前より存在します。この制限が 2021-02-08 から強化されました。以下、この 429 が返ることを「利用規制」と呼びます。
  • サーバにかける負荷が多い API ほど、利用規制が早くかかるようになりました。(具体的な利用規制に至る閾値は公開しません。負荷状況を見て動的に変更しています)
  • 判定はIP単位で行っています。(IPv6も判定しています)
  • 特に Cinderella API v1 は、 v2 より著しく早く利用規制されるようになりました。したがって、現在 Cindrella API v1 を利用しているサービスの開発者様におかれましては、早めに v2 への移行をご検討ください。

ここまでに至る経緯

Cinderella API は、アクセス先こそ Web ポータルと同一ですが、処理自体は Web ポータルとは分離していました。API 処理を専門に担当するサーバを準備し、処理していました。

↑変更前は Web サーバと API サーバは分離していました

昔は Web ポータルと API は同一サーバで処理していましたが、Cinderella API は道場サイト、Discord、フリトレ観測などで多数利用いただいており、平均 75,000 /日のリクエストがあります。バランサーで打ち返しているものは含んでいませんので、実際のリクエストはもっとあるでしょう。

このリクエストをWebポータルと同じサーバで処理すると、Web ポータルの表示が遅延するなど影響が出てしまうことから、ある程度アクセスが増えた時期より API 専用のサーバを立ち上げて分離していました。

しかしながら今般、運用費用の圧縮のため、 API 専用のサーバを閉塞し、Webポータルと同一のサーバで処理するように変更しました。(つまり昔の姿に戻しました)

↑変更後は Web サーバと API サーバは統合しました

統合したからといってサーバのスペックを引き上げたわけではないため、当然ながら、これまで受け止めていたすべてのリクエストをさばくことはできません。

Webポータルの表示を優先するため、また Cinderella API をなるべく多くの方に公平にご利用いただくために、従来は一律緩い制限としてきた API の利用規制を強化することになりました。

※余談:本当は Azure Functions (AWS の Lambda みたいなやつ)に移したら無料ないし低価格でできちゃうんじゃないかな~と思って試したのですが、実際やってみたらクラウド破産しそうなのでやめました。いちいちデータがでかいんだよこのアプリ…

主な変更点

  • 処理負荷に応じた API 利用規制を実装しました。
    • 道場 API のような負荷の低い API は緩い利用規制になっています。また、道場 API は大抵のアクセスは nginx のキャッシュで返しているため、そこまで影響はないと思います。(ただし道場 API v1 は後述の一律規制の影響を受けます)
    • 逆に、プロデューサー検索・プロダクション検索・フリートレード履歴検索などの高負荷の API は従来より厳しい利用規制がかかるようになりました。
    • イベントポイントなどは、検索レンジを広めにとった場合に早く利用規制がかかります。基準順位のみを取得する場合は利用規制が比較的緩くなっています。イベントポイントのレコードは7億件あるため、データへの触り方によっては負荷が大きいのです。
    • 特に、検索結果のサイズ(JSONの出力件数)が大きいほど早く利用規制がかかります。
  • Cinderella API v1 は、v2 に比べて最適化が進んでおらず、内部負荷が高いことから、 v2 より早く利用規制がかかるようになりました。
  • Web ポータル側の負荷が高い場合、これまでの API への個別のアクセス状況に関わらず、すべての Cinderella API の利用が一律規制されるようになりました。この場合、 v1 から先に規制されます。
  • 異常な API への高頻度アクセスを行うユーザを IP 単位で時限的に自動拒否するようになりました。
    • 「同じプロダクションの明細情報を毎分取得し続けてもしょうがないでしょ?? 更新されるタイミングはイベント終了時ぞ??」というようなアクセスがあるので…
  • 利用規制された場合は、一定時間が経過すると再度利用できるようになります。また、すべてのAPIが利用できなくなるわけではなく、異なる種類のAPIは利用できます。

なお、現時点では Cinderella API のみの利用規制になっていますが、今後の状況によっては Web ポータルにも導入します。といいますか、すでに緩めの利用規制は Web ポータルにも入っています。

おわりに

利用者の方々には急な変更にはなってしまい恐縮です。

限られたリソースのなかで、なるべく多くの方にすべてのサービスを公平に利用していただけるようにしたいと考えています。ご理解をお願いします。

10分毎の観測対象プロデューサが10000位まで拡がりました

仕様変更箇所

これまで、ボーダーbotが10分毎に観測するプロデューサー順位は4000位まででしたが、1/20頃より、これを10000位まで拡大しました。(issue #26)

仕様変更により新たにできるようになったこと

イベント明細で表示される「上位プロデューサースコア」が10000位まで表示されるようになりました。

②10000位以内に一度でも入ったプロデューサーは、プロデューサー別の明細ページで、イベントpt推移グラフが表示されるようになりました。

第7回ミュージックJAM 1/21 14:20時点で8001位のプロデューサーの明細。これまではこのプロデューサーはグラフが表示されませんでした。

副次的効果として改善されたこと

これまでプロデューサーごとの速度計測において30分速が時速より値が大きい(速い)、10分速が30分速より値が大きい(速い)といったケースがありましたが、これが緩和されます。

ボーダーbotのプロデューサーごとの10分速/30分速/時速/24時間速(以下、「P速度」)は、計算にあたり、観測の始点となる時間の観測データに当該プロデューサーが存在していた場合に限り、そのプロデューサーのP速度を算出します。

つまり、これまでの仕様では、1時間前に4000位以内に存在するプロデューサーは時速を算出できましたが、1時間前に4000位未満だった場合は時速が計算できませんでした。もちろん1時間前の4000位を最低値として時速を想定することはできましたが、「正確でない値は記録せず不明として扱う」という思想で最近は実装しているので、このケースではP速度の時速が存在しないものとして扱っていました。

この仕様により、イベント終盤に一気に走ったプロデューサーは、イベント終了の30分前には観測されていたが1時間前には未観測というケースがあり、「時速より30分速のほうが速い」という状態を生んでいました。

今般に修正により、観測範囲が広がりました(上記グラフで言えば青い点線が下がりました)ので、従来よりもP速度の計算が正確になる効果も期待されます。

カードごとのフリートレード価格や取引量などを出力するようにしました

※この記事における「価格」とは、フリートレードにおけるカードの交換に必要なスタドリの量を指すものとします。

概要

  1. カード一覧の「詳細検索」でフリートレードの価格や取引量などにより検索を行えるようにしました。カードごとの結果も一覧に表示されます。
  2. カードの明細ページでフリートレードの価格や取引量、および価格推移を表示するようにしました。
  3. Cinderella APIv2 でも同等の情報を取得できるようにしました。

システム的な変更点

デレマスボーダーbotはこれまでフリートレードの履歴を取得して表示してきました。今般、これを一段進めて、フリートレードの最新価格や平均価格を計算するようにしました。毎10分ごとに全カードの取引情報を再計算しています。

平均の算出にあたっては、大きく外れた価格(具体的には「突然のスタ2000取引」など)を含んでしまわないよう、直近100トレードの正規分布における2σを超える取引内容は外れ値とみなし、排除したうえで算出しています。

カード一覧の詳細検索の変更点

カードの詳細検索で、カードごとのフリートレードの最新価格や平均価格を基に検索ができるようになりました。

検索結果で、カードごとのフリートレードの価格や取引量を参照できます。(グリッドの右側にありますのでスライドしてください)

参照できるのは以下の情報です。

  1. フリートレード可否(フリトレ制限されているカードか)
  2. 直近価格
    • 通常カード
    • プレミアムサイン付きカード
  3. マニーでの取引実績の有無
  4. 平均価格
    • 全体
    • 通常カード
    • プレミアムサイン付きカード
    • およびプレミアムサイン付きカードと通常カードの差額
  5. エナ/スタ比率
  6. 成立件数/日 (※出品件数ではありません)

想定している用途として、「極小以上のダブル特技を持つカードが欲しいができればスタドリ300本以下で探したい」あるいは「ある程度廉価で成立件数の多いカードでエナスタ変換をしたい」といったケースで役立つと思います。

こういう情報も出してほしいというご要望があれば、コメントいただければ検討します。ただし、出品情報を取得する予定はありません。

カード明細での表示

カード一覧と同様の情報をカードの明細ページでも表示します。ここでは、一覧の詳細検索で表示していた情報に加え、取引履歴の明細と価格推移を表示します。

[陽の照らす先へ]十時愛梨+の表示例

APIでのフリートレードの価格や取引量の取得

Cinderella APIv2 のカード /api/v2/cards/[cardHash?] で、カード一覧と同様の情報を取得できるようになりました。

カード明細で表示されている、カードごとの過去の履歴(推移)も別途実装予定です。実装しましたら、改めて記載します。

年間集計結果を見られるようになりました

Webポータルに年間集計結果を追加しました

イベント一覧、イベント参加プロデューサー数、全プロデューサのイベント参加状況などの集計結果を見られるようになりました。現時点では、2019年・2020年の集計結果を参照することができます。

本機能は常設です。いつでも見ることができます。

ただし、2021年のイベントが始まっても、2021年の結果はまだ見ることはできません。データは年末に作成されます。

プロデューサーごとの集計結果をCSV/JSONでダウンロードできるようになりました

プロデューサー毎の年間集計結果を取得できるAPIを、Cinderella API v2 に「プロデューサー年間集計結果 /api/v2/producers/[mobageId]/annuals」として追加しました。プロデューサーごとの入賞回数や、年間の増加レベル・ファン数を取得することができます。

この API では mobageId の指定が必須になっています。つまり、1プロデューサーごとの情報しか取得することができません。

全プロデューサー分の集計結果を一括で取得したい場合は、ダウンロードページから、 JSON または CSV で全量をダウンロードできるようになっています。年間の集計結果は一度作成した後は永遠に変化しませんので、APIではなく、固定のダウンロードデータでの提供のみとします。(ダウンロードの方がAPIより負荷が低いのです)

【期間限定】プロデューサーごとの2020年振り返り機能

プロデューサーごとの明細ページに2020年の結果を振り返ることができる機能を追加しました。

本機能は2021年1月10日までの限定公開です。プロデュース結果・イベント参加結果の振り返りにお使いください。

2020年のボーダーbotの改善点まとめ

新年あけましておめでとうございます。

2021年のデレマスボーダーbotも引き続きよろしくお願いいたします。

2020年のボーダーbotの改修履歴、および今後の改修予定は下記の画像を参照ください。この開発ノートにこれまで記載してきた内容と重複しますので、詳細は割愛します。

上位Pポイント一覧における時速上位5名の計算方法が変わりました

どのツイートの話?

これ↓の「上位P pt一覧」と先頭行に記載のあるツイートです。

なにがどう変わったか?

時速上位P 5名の算出方法が以下のように変わりました。

  • 旧仕様:出力時間(毎時00分)に観測したプロデューサーの時速のうち、上位5名。
  • 新仕様:出力時間(毎時00分)を起点に、直近1時間に観測したすべての時速のうち、プロデューサーごとにグルーピングして最大の時速を抽出する。そのうちの上位5名。(ただし1時間前の00分において観測したものを含まない片端入れとする)

????なにいってんだこいつ??????感があると思いますので、下記の画像の説明をご参照いただくのが一番よいかと思います。

狙いは画像にも記載しておりますが、「なるべく正しい値を」かつ「仕様の範囲内でなるべくお名前を出せるように」が目的です。

先日からちょいちょい変えている、10分速~24時間速のデータの持ち方・データの見せ方を最適化していく流れのひとつとして実装しました。

ラストスパート時間の10分速ツイートに変更はありません

イベント終了直前3時間の間は時速に代わり10分速を出力しています。この処理への影響はありません。

厳密には10分速も新仕様になっていますが、10分速の場合は計算対象となる期間が1つしかないことから、結果が従来と同じです。

ツイート添付の画像への影響はありません

ツイートに添付されている画像は、これまでと同様に00分を基準とした時速です。これを最速時速に変える予定はありません。順位一覧においては、最速より最終時点における値が見たいというケースの方が断然多いでしょう。

10年目のシンデレラガールズへ向けて

9thアニバーサリーアイプロおつかれさまでした。


このデレマスボーダーbotも、あと約2ヶ月で5周年を迎えます。もともとは200位と2000位の時速や10分速を10分ごとにツイートするだけの簡単な機能からスタートしたボーダーbotが、ここまで大掛かりなシステムになるとは思っていませんでした。

初期はこの↓スティックPC1本で運用し、データはmicroSDに保存していました。のどかな時代でした…

現在では7台の各種サーバで運用し、レコード数はポイント情報を中心に約9億、総容量はバックアップも含め1.7TBのシステム規模になっています。


今後ももう少し、機能追加を続けていく予定です。準備中のものは複数ありますが、そのなかでも直近で目処が立っているのは以下のとおりです。

  1. 2020年の結果振り返り機能(12月30日頃~ 期間限定公開の予定)
    • 2019年も実施しましたが、今年は全体結果とプロデューサ個人の両方の結果をWebポータル上で表示できるようにする予定です。
  2. 上位Pポイント一覧の上位P時速(5位まで表示)を、00分基準の順位だけでなく直近60分間の最大時速に変更(2021年12月に実装予定)
  3. 観測範囲の4000位→7000位への拡大(2021年1Qに実装予定)

2019年12月30日のMobage版シンデレラガールズの縮小以降、復刻とそれ以外の通常をイベントを別けて比較できるようにするなど、ボーダーbotも適宜状況に合わせて仕様や運用を変更してきました。

10年目のシンデレラガールズにおいても、最新のイベント環境やプレイスタイルの変化に合わせ、既存機能も含めて修正を続けていくことで、ヘビープレイヤーから初心者まで活用できるボーダーbotを目指していきます。

データベースサーバ容量枯渇の障害原因と対応

未来の自分が忘れそうなので、障害発生の原因と対応を記載しておきます。

なぜこの↓障害が起きたのか

経緯

  • もともとデータベースサーバの空き容量は60GBくらいだった。(※データベースサーバにはMariaDBしか入っていません)
  • 容量増加が250MB/日なのでこのままだと半年くらいで枯渇しちゃう…ということで、非正規型で抱えていたイベントポイント増加量(各順位・各プロデューサーの10分/30分/60分/24時間速)のデータを正規化して保持するよう変更し、容量を確保する作業が裏で進行していた。この作業では中間作業データを一時的に作成する必要があり、30GBくらい必要となった。これで残り容量も30GBになった。⇛作業①
  • これとは別に、各観測サーバで受信した当日のHTML等を一時的にデータベースサーバに格納するバッチジョブがあり、これが20GB/日を一時的に消費する。ただし、すべてのバッチジョブの終了時に20GBのデータは解放され、削除される。⇛作業②
  • 障害発生の前日(11/17)に作業②のバッチジョブが、データベースサーバへのデータ書き込みに後続する処理で失敗した。このバッチジョブは失敗しても翌日に2日分を処理すれば影響がないため、特に通知をしない実装になっていた。20GBのデータは削除されずそのまま放置され、これで残り容量が10GBになった。
  • 障害当日(11/18)に作業②が走り、すべての容量を使い果たし、データベースサーバの容量が枯渇してMariaDBが停止。全機能が停止した。

原因

  1. 容量が限られていることがわかっていたのに作業①の中間作業データを本番データと同じストレージに配置した。
    Block storage(有償の追加ストレージ)を別途借りて中間作業データを配置することも検討したが、わずかな追加費用をケチったのと、マウント作業を面倒くさがった。(この結果、もっと面倒なことになった…)
  2. 作業②で失敗した場合にデータが放置される。また、通知されないので失敗に気づかない。

対応/再発防止

  1. 巨大な中間作業データは本番のストレージ上に作らない。Block storage を一時的に追加で借りてマウントし、create table 時に data directory を指定して Block storage 上につくるようにする。作業が終わったらアンマウントして捨てる。<作業手順の改善>
  2. 作業②のバッチジョブ失敗時はデータ消去を試みるように仕様を変更した。また、データ消去にも失敗した場合はアラートを保守端末に通知するようにした。<実装の改善>
  3. そもそもデータベースサーバの空き容量が少なすぎる。<環境要因の排除>
    ⇛イベントポイント増加量の保持方法の正規化により、30GBのデータベース容量を削減し、空き容量を約90GBまで確保した。

プロデューサー明細の改善、およびイベントポイント増加量を詳細に表示するようになりました

9周年に合わせた更新…というほど大規模なアップデートではないのですが、いくつか不便だった点を補う機能を追加しました。

1. プロデューサー明細で見られる情報が増えました

①過去イベントの成績上位が10件以上見られるようになりました

これまでは過去イベントの成績上位は10件しか表示されませんでしたが、表示できる限りたくさん見られるようになりました。

②イベント種類ごとの成績をより詳細に見られるようになりました

これまではイベント種類ごとの200位入賞などの割合を棒グラフで見ることしかできませんでしたが、より詳細な成績を見ることができるようになりました。

具体的には、イベント種類ごとの以下の情報が参照できます。

  • 最高順位をとったイベント
  • 10分速/30分速/時速/24時間速の最高値
  • 10分速/30分速/時速/24時間速の走行時平均値(0ptを除いた平均値)
  • イベントアクティブ時間の合計(観測した際にポイントが増えていた時間の合計。単位は分)

③イベントごとのイベントポイント増加量を詳細に見られるようになりました

プロデューサー別詳細ページの下部にある「イベント別順位・スコア」で、新たに以下の情報がイベント別に見られるようになりました。

  • 10分速/30分速/時速/24時間速(最高値)
  • 10分速/30分速/時速/24時間速(走行時平均値)
  • アクティブ時間(観測した際にポイントが増えていた時間の合計。単位は分)

2. イベント明細ページでも、4000位以上のPのポイント増加量が見られるようになりました

イベント明細ページの「上位プロデューサースコア」で、時速だけでなく各種のイベント増加速度を参照できるようになりました。プロデューサー明細ページで1人ずつ確認することなく、一括で確認できます。特定の高順位(1桁など)を狙う際に利用するシーンを想定しています。

特に、「順位に着目したポイント増加量」と「プロデューサーに着目したポイント増加量」を別けて表示するようになりました。

9thアニバーサリーの表示例

新たに参照できるようになったのは、以下の項目です。

  • 10分速/30分速/時速/24時間速(プロデューサーに着目した増加値)
  • 10分速/30分速/時速/24時間速(順位に着目した増加値)
  • 10分速/30分速/時速/24時間速(プロデューサー/現イベント内最高値)
  • 10分速/30分速/時速/24時間速(プロデューサー/過去同種イベント最高値)

Cinderella API v2への反映タイミング

上記の各種情報は、Cinderella API v2でも参照できるようになります。12月上旬の追加を予定しています。追加時は本エントリーに記載予定です。

2020-12-04に追加しました。

  1. 「イベント順位情報」のレスポンスデータに、増加ポイントを追加しました。
  2. 新たに「イベントポイント増加量 (/api/v2/events/gainpoints)」を新設しました。

なお、Cinderella API v1への追加はありません。