これは 農工大アドベントカレンダーの記事です。
はじめに
先日、バックエンドのチューニングをしてパフォーマンスの向上を競うコンテストに参加しました（身バレ防止のため正式名称は伏せます）。
当時はバックエンドのチューニング経験が全くなく、「何をしたらいいか本当にわからない」という状態で飛び込みました。
しかし、その「訳も分からず参加した経験」が、現在開発中のアプリケーション（自作楽譜管理アプリ）で意外なほど生きていることに気づきました。
今回は、その体験談と、「技術的に理解していなくてもイベントには出るべき」という学びを共有したいと思います。
コンテスト参加時の状況
知識ゼロからのスタート
私を含め、チームメンバーにも深い知識を持っている人はいませんでした。「まあ、ゆるく参加しよう」というスタンスで、文字通り手探りのスタートでした。
具体的には、AIに「バックエンドのチューニングって何すればいいの？」と聞きながら、見よう見まねで少しずつ設定をいじる程度でした。
結果は散々で、ワースト3位でした。
上位チームのスコアには遠く及ばず、圧倒的な実力差を見せつけられました。
上位チームのアプローチ
コンテスト後の解説で、1位のチームのアプローチを聞きました。
彼らは以下のようなことをしたといっていました。
- 並列化処理
- リソース割り振りの設定
- 徹底的なキャッシュ戦略
- 全データをメモリ上に乗せるインメモリ化
特に驚いたのは、全データをメモリに格納するという手法です。
新しいデータは追加されないという制約だったので今回の場合はかなり有効でした。
sqlクエリより、配列に格納したもからカスタマイズしたアルゴリズムで取得するほう圧倒的に早かったようです。
こんなの実践で使えるのかよ！とずるをしてるみたいに感じてしまってちょっと苛立ちました笑笑
クライアントでのインメモリ活用
現在、nuqsよさそうでも触れた「自作楽譜管理アプリ」のモダン化改修を行っています。
その中で、コンテストで聞いた手法がすごく使えるのではないかと思いました。
nuqsを使用して即時検索を採用しているので、データフェッチの回数がかなり多くなると予想できます。DBは無料のsupabaseを使用しているので、少しパフォーマンスが気になります。
そこで、
部分集合のクエリであれば、一度取得したデータをローカルメモリに格納しておき、DBサーバーへのフェッチを避ける
という方法をとれるのではないかと思いました。
コンテストでの「全データをメモリに乗せる」というアプローチから得たもので、実戦で使えないとずるだ！と思っていましたが、使えました。多分コンテストに出ていなかったら考えつかなかったです。
とりあえず参加してみる
何にもわからない状態でもコンテストに参加して、試行錯誤したうえで、上位の人の解答を得ることですごく勉強になりました。
「まだ分からないから勉強してから...」ではなく、とりあえず参加して玉砕してくる
というのもよいかもしれません。