サマリ

今回は二度目のRubyで挑戦。僕は最近はGoばかり書いていますが、アプリメイン担当のメンバーが直近Rubyを書いていたのでRuby採用。僕も読めないわけではないのでセーフ。

追記 2024/12/11 言語別TOP10チームにランクイン

Rubyを利用した64組中7位になっていました。これは嬉しい。

当日の朝、コメダ珈琲で身体の暖気をするついでになんとかスクリプトを動かそうとしたのだが、1年というときを経てツール郡はバージョンアップされていることに気づき、それに自分が対応するだけの時間がないことを悟る。

暖気中 pic.twitter.com/oLd8Txn4vR
— oʎЯꓕɅ (@3s_hv) 2024年12月7日

そもそもこれは、右も左もわからん！という初回参加時につくったものだったので「今日はベストエフォートだしアドリブでやるか」と潔く諦めた。

セットアップ系は手順に慣れた人が一定手間を省きたい時に使えば良く、その繰り返しポイントを今回しっかり覚えられたので良かったと思う。

それと、すでにある程度作られたconfigを~~コピペ~~デプロイしないことで、NginxやMySQLの設定内容をじっくりその頭で考える機会にもなるか〜と思っていた。

できるだけ作業した内容をTimestampつきでObsidianに書き込んでいたものを貼る。他のチームはもっと進捗出てたんだろうなと終わってから思ったので、やはりその手間はなるべく自動化して短縮したい。

 初期スコア（Go)
    **Marked At:** 2024-12-08 10:14:20.436
    **Score:** 1106
    **Score Breakdown:** base=1106, deduction=0

 Ruby
    **Marked At:** 2024-12-08 10:18:43.669
    **Score:** 718
    **Score Breakdown:** base=718, deduction=0

毎回alpのコマンド忘れる
ltsv形式じゃなくてjsonにすればよかった
デプロイスクリプトといいつつ、これはgit pull→ログを消して→再起動してというのを忘れるので一式あるとやっぱ楽だなって思った
スロークエリが出たあたりから、Index貼る人とコードを改善する人。僕はインフラ周りのリソースをチェック
Indexが付与されたあとも、mysqlにかかる負荷が高かった（はず。記憶の中では）
マッチングがどうしても遅いし、それがいつまでもボトルネックになっていることはわかっていた
- なんらかの方法で高速マッチすればいいと踏んで、キャッシュテーブルを入れるかと思ってRedisを検討した。
Redisは不発（時間コストと見合わない）だったので、さっとやめてリソースボトルネックを解消する方向へ
App 2, DB 1構成に変更して、Nginxのworker connectionsを倍。サーバからいらないミドルウェアを殺したあたりでCPUのガン詰まりは減った
- ついでにスコアも伸びた
それでもmysqlのコネクションがMax越えてハングしてたので、そのあたりの設定を変えてみる。

14:40から17:00当たりまで空白の時間になっているが、これはログの分析や突破口を探していたりアプリケーションをいじっていたりしてた。調査が立て込むと何してるか書き忘れていて良くない

全体的に落ち着いていた。浮足立つ感じがなかった
アプリ側の修正にも積極的に踏み込めた。Rubyが得意な訳では無いのでChatGPTのおかげではある。とはいえ「これはこうなんじゃないの？」と思える勘所が増えていて嬉しい
的外れかどうかはともかく、何か打ち手を考えてすぐに手を動かすに至ったのは以前にはなかった行動。前はうーんと悩んでいるうちに終わってた
インフラ周りの「この状態ならこれをいじろう」という部分の予測と結果がきちんと成立するようになっていた。恥ずかしながら前は当てずっぽうだったはず
- 点数が伸びた理由を説明できるかどうかは本当に大事だね
ベンチのログやマニュアルから、ユーザの不満をなんとかすべきと思って手をつけられていたのはよかった。

今回でいうと、ライドシェア固有の部分を修正するに至らなかった。一般的なIndexやインフラリソースなどで手一杯
- サービスの特性を理解して、そこに踏み込めると良い
- そのためには一般的な部分をいち早く察知して全部さっさと直せる手速さがいる
- 手速さは一定自動化できる→俺は次からセットアップスクリプトをつくる！