来年の自分に込めてメモをとっています。
ロジックの修正
SP☆12参考表
iidxme/クリアランプマネージャの同期を切りました。
主にleggendaria周りの表記ゆれの対応が各サイトに異なってくると思ったので、その対応コストを減らすためです。
表記ゆれは既に公式とISTで戦っているので、各サイトの調査と調整をするのはしんどいです。
iidxmeの中の人は交流があるのですが、サイト上はこれだけど実際の筐体の表記はこれ、みたいなのをしてくれてたりするので、
そういった修正をこっちで賄うのもあれだし、相手にお願いするのも違うな、という部分です。
ISTは自分のサービスなのでどうとでもなる。
leggendariaの曲名を曲名+†に統一しました。
SP12参考表は☆12の中で曲が複数いることをあまり前提にしておらず、名前で判別しています。
作った当初からあった例外は白壁とギガデリですね。
今回leggendariaの対応を見る限り、曲名が公式では変わらなくなりましたが、参考表としては都合が悪いので末尾に†をつけています。
SPADAとかに出たleggendariaは†LEGGENDARIAだったりしましたが、そのあたりも全部†のみに統一しました。
ISTとの同期部分も少し手を加えています。
既存の実装ではスコアが0でも取得するようにしていたので、バージョンアップの初回同期時にスコア0という形で全楽曲の同期が行われていました。
これはもともと意図してそうしていたのですが、やはり気持ち悪いなと思ったので今回からはスコア0のものは同期しないように変更しました。
また上記のleggendariaの改名を行った関係上、譜面区分がleggendariaの場合はサーバ内で末尾に†をつけて同期する楽曲を探すように変更しています。
IST
結構大きく変わりました。
ついでに表記ゆれの諸々が直っていたので表記ゆれ周りの修正も行いました。
まずメインのleggendaria楽曲の区分変更についてはIST側でもNHAに加えてL譜面用の区分を持つことにしました。
こういうサイトを作っている人しか気づいていない部分かもしれませんが、Rootageまでは曲として別れていて、ある曲のANOTHERとしてleggendariaは存在していました。
IST上でも「Sigmund†LEGGENDARIAのANOTHERスコアデータ」という形で持っていたのですが、これを「SigmundのLEGGENDARIAスコアデータ」という形に変更し、
「Sigmund†LEGGENDARIA」という楽曲はサイトの管理上から削除した、という形になります。
ISTではざっくりいうと以下のような構成で楽曲とスコアの情報を管理しています。
- Music
- 楽曲のメタデータで、曲名、アーティスト名、ジャンル名など
- 曲名ぐらいしか表には露出していませんが...
- Chart
- 譜面データでもともとは譜面タイプとしてNORMAL/HYPER/ANOTHERの3種類がありましたが、今回LEGGENDARIA区分を追加
- SP/DPごとに分かれているので、基本的にはSP/DP * NHALで8種類まで譜面区分を持つような構成になっています
- 曲名の情報等は持っていないのでMusicと関連を持っており、ブラウザで閲覧するときに結合して表示しています
- ノーツ数などの管理もここで行っています
- 譜面データでもともとは譜面タイプとしてNORMAL/HYPER/ANOTHERの3種類がありましたが、今回LEGGENDARIA区分を追加
- Score
- 各ユーザのスコア情報でChartと関連を持っています
- バージョンごとにスコア情報を管理できるようになっており、あるChartのデータをユーザ及びバージョンごとに1つだけ持てるようになっています
今回は既存のLEGGENDARIA楽曲のChartのANOTHER区分のみを元の楽曲のMusicと紐付けるように変更しました。
裏側でトップランカーを出すためにもChart情報を参照しているので合わせて修正しています。
歴代スコアに関してはトップランカーのデータをあるタイミングで修正しているので、Rootageのトップランカー情報を収集した際にまとめて整理する予定です。
上記のような形で既存のleggendaria楽曲のユーザスコアを残しながら曲名の変更に対応しました。
この対応を行いながらRootageのスコアも送れるようにしています。
HVから利用し始める人がRootageのスコアを送った上でHVのスコアを送って比較するために、できればRootageとHVの互換性を維持したかったというのが狙いです。
Rootageではまだ†や†LEGGENDARIAという文字列がついた楽曲情報としてサーバに送られてくるため、サーバ側でRootageのスコアを受け取ったときに内部的に変換して保存する処理を入れています。
後述しますが、表記ゆれ周りもHVで色々直っていたのでこの作業は割と大変でした(10回ぐらい互換性維持やめようかな、と思った)。
表記ゆれに関しては自分が確認した限りではすべて直っているような気がしました。
過去にはスクリプト or CSVのときだけ曲名に?が入っていたり、スペースの量が違ったりといった症状がありました。
正確に言うとHVでもなぜか曲名の末尾に謎のスペースが入っている、といったことはあったのですがこれは軽微な対応で済むので表記ゆれとしてカウントしていません。
今回の更新で表記ゆれ周りの一斉整理も行いました。
楽曲名が違うと全然違う楽曲のスコアデータとして保存されてしまうような仕組みになっているので、表記ゆれ対応の際にデータをマージする必要があります。
このマージ処理が割とセンシティブな処理になるので、あまり積極的に対応していませんでした。
代表的な例でいうと火影、炎影問題があります。
これ確か今回で名前変わるの3回目ですよね？いい加減にしてほしい
イメージ的には炎影、火影という名前の2つで26のバージョンで同じ人がスコアを登録していた内容をマージするような処理になります。
もう少し細かく言うと炎影は24, 25, 26だけど火影だけ25で送られていたりするケースの楽曲もありました。
同じ楽曲としてスコアを保存するようにしないと、曲名をクリックしたときに表示される各バージョンの履歴データに出てこないのできちんとマージする必要があります。
基本的にはあるバージョンで火影と炎影のような2種類のスコアがあった場合には更新日が新しいものを優先するようなマージ処理を行っています。
ということで、今回の更新でleggendariaと表記ゆれの2つを対応しました。
表記ゆれに関してもRootageでは揺れたままのデータが送られてくるので、やはりRootageから来たデータに関してはサーバ内で変換して保存するようにしています。
leggendaria+表記ゆれの2種類に対応するのが精神的にかなり大変でした。
揺れていることは実際に送られてきたデータが登録された結果とにらめっこしないといけないので、主に確認作業が辛かったという感じです。
インフラ面
ここからはあまりIIDXに関するロジックの話はありません。
が、どちらかというと来年の自分へのコメントとしてはこちらのほうが重要です。
興味がある人向けに軽く前提をコメントすると参考表/ISTはGCPのGKEの上で動いています。
参考表、ISTともに結構レコードの更新、削除量が多かったので既存のnode poolのスペックではmigrate処理にかなり時間がかかるということがわかり、移行するタイミングだけ移行用のnode poolを確保しました。
ですが、実際にはローカルでmigrate処理を行って結果のDBをdumpしてGKE上でimportする形のほうが早く終わっていたと思います。
node poolを用意して行うとQA中に不具合を見つけたときに再度同じ処理をするイテレーションの間隔が長くなってしまい、あまり効率的ではありませんでした。
すぐ終わらない or 単純な処理で終わらないのであればローカルでmigrateしたほうが良い、というのを今回は感じました。
ISTのmigrate処理はGKE上で普段よりちょっと強めのVMを専有しても数時間かかっていましたが、手元のmac*1では10分程度で終わっていました。
ここの違いは多分確保しているdiskのサイズが小さくてiopsが遅いことがネックになっているのではないか、と思いましたがちゃんとメトリクスを見てはいません。
移行作業の際にはdatabaseに関しても専有node poolに移して行っていたので、移行のために一時的にpodを移動させる際にぶちぶち503が出てしまうのも地味にネックだなぁと感じました*2。
インフラ周りは最近VPSからGKEにしたこともあり、まだまだ503が出てしまうケースが潰しきれていないので今後の課題が多くあります。
以前と比べると不安定になった、という印象を抱かれてしまうだろうなと思っているので積極的に改善していきたいところです。
とはいえ、GKE移行は結構な工数を自分の中で取られており機能改善に着手できていなかったので、細かい機能改善があればそちらを優先的にやる、という心持ちです。