上位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まで確保した。