Upgrade to Pro — share decks privately, control downloads, hide ads and more …

インターンでハチナイのAPIを高速化しました!

akatsukinewgrad
December 17, 2021
940

 インターンでハチナイのAPIを高速化しました!

akatsukinewgrad

December 17, 2021
Tweet

Transcript

  1. 自己紹介 ▣ 長谷川 貴斗 ▣ 京都大学大学院 情報学研究科 数理工学専攻 M1(23卒) ▣

    先月10月にアカツキの就業型インターン(Ruby on Rails, 八月のシンデレラナイン)に1ヶ月参加 ▣ アカツキインターンでの担当業務 □ 管理画面の開発 □ バリデーションの追加 □ 新規機能開発 □ APIの高速化← ▣ 趣味 □ 喫茶店(モス,ドトール,近所)で読書 □ お絵描き 2
  2. APIが返却するデータ ▣ 返却するデータは大きく分けると □ マスターデータだけで計算できるもの ▪ チャプターはボーナス期間中か □ ユーザーデータが計算に必要なもの ▪

    チャプターはクリア済か ▣ マスターデータ □ 選手情報,能力値やスカウトの開催時期など ▣ ユーザーデータ □ ミッションのクリア状況や獲得経験値など 6
  3. なぜ遅いか ▣ preload □ クエリの使用回数を減らすために関連づけられたレコードを一括で読み込む □ いわゆるN+1問題を解消するのによく使われる ▣ 遅い理由 □

    レコード数が多いものでは20000ほどもあり,preloadするとそれぞれに対 してActiveRecordインスタンスが生成.さらにそれぞれのレコードに対して カラム数分だけActiveRecord::AttributeMethods関連オブジェクトのメ ソッドが呼ばれたりして.生成コストが高くなる つまり,レコード数が多い時preloadはそれなりに重たい. 10
  4. APIが返却するデータ(再掲) ▣ 返すデータは大きく分けると □ マスターデータだけで計算できるもの ▪ チャプターはボーナス期間中か □ ユーザーデータに紐づくもの ▪

    チャプターはクリア済か ▣ マスターデータ □ 選手情報,能力値やスカウトの開催時期など ▣ ユーザーデータ □ ミッションのクリア状況や獲得経験値など 13
  5. まとめ ▣ 「N+1問題」を起こさないのは基本 ▣ 「ActiveRecordインスタンスの生成コスト」はそれなりに高い ▣ 変更される頻度が低いデータはキャッシュに持たせるという解決策 をとった. - Future

    Work ▣ 技術の選定(たとえばErlangだとプロセスをまたがる場合でも内蔵 のオンメモリDBが使えたりするらしい...) ▣ joinとかpluckを使ってActiveRecordインスタンスを生成しない みたいな方法もあったのかも 18