ISUCON14をRubyで参加してきた(12443点)
はじめに
2回目のISUCONに参加してきました!
最終スコアは12443で834組中(多分)103位。
言語別Ruby9位でした!
前回は振るわない結果でしたが、その反省を活かして成長できた部分がありました。一方で、まだまだ改善の余地を感じる結果となりました。
ブログを書くまでがISUCON!ということで書いていきたいと思います。
事前準備
本番2ヶ月前から毎週30分集まって過去問を各々解いていく形で学習を進めました。
AWSで過去問環境用サーバーを構築していたのですが、毎回過去問の環境を立ち上げるところなどで時間を取られて、やっと集中できてきたなと思ったときには終わってしまっていました。
本番直前に3時間取って本番想定の練習をしたのですが、これが一番勉強になったかもしれないです。まとまった時間をとって練習するの結構大事です。
個人としては前回の反省を活かして、インフラ面で貢献できるように下記のような準備をしていきました。
- Memcachedでキャッシュできるようにする
- 複数台構成(Appサーバー2台, DBサーバ1台)で動くようにする
- アプリケーションのエラーログを出力できるようにする
- ベンチマークからのリクエストを再現するためにcurlコマンドの生成をできるようにする
当日
自分は主に開発環境づくりやインフラ面を担当しました
10:00~
サーバー1台で作業を進めました。
VSCodeのリモートで入ってLiveShareでチームで共有しながら作業しました。
初動は環境を構築するスクリプトを準備していたので、システム構成を確認しながらスクリプトを実行して環境を構築していきました。
その間に他のメンバーは今回のお題のアプリケーションを読み込んでいきます。
11:30~
環境がととのってきたので、ベンチマークを回して、リクエストログやスロークエリを解析して、処理時間がトップのものを改善していきました。
最初は全くIndexが無いので、基本的なIndexを追加していくと順調にスコアがあがっていきました。
/api/initialize
などの初期化処理のリクエストを簡単に実行するスクリプトを書いて、動作確認しながら実装できたのはテンポよくできてよかったです。
また、重いリクエストがあるAPIの中で改善できそうなクエリをチューニングしていくことをしました。
キャッシュが問題なさそうなところは、キャッシュにしていくことで少しずつですがスコアがあがっていきました。
12:30~
わかりやすいチューニングを終えて/api/chair/coordinate
のAPIが処理に時間がかかってそうということで改善に着手しました...が、ここが鬼門でした...
UUIDをつかっていたので、あ、今年話題になってたやつ!と思って、IDの生成方法を変えるも改善せず...
いろいろ試行錯誤しましたが、7千点台から上がらず時間が過ぎていきました...
16:30~
16時位になって、複数台構成に変更していく作業に入りました。
先に複数台構成にすると、ボトルネックの調査がしづらくなるということでこの時間から着手することにしていました。
最初はdbを別サーバにしたのですが、それだと対してスコアは上がらず。
APP2台、DB1台の構成にしたら12000点台になりました。
やっと1万を超えられてメンバーと盛り上がりました!
再起動テストや環境チェックをして、失格にならないことを入念にチェックして終わりとしました。
振り返り
ライドチェアサービスは笑いました(笑)
動画のクオリティもめっちゃ高かったです。
前回できなかった、キャッシュ機能を入れたり、複数台構成にすることはできたので、前回よりは成長できたかなと感じました。
Discordで他参加者の感想を眺めていて、APIを改善するときにアプリやベンチマークの仕様に注目されていたのがわかりました。
機能のふるまいそのままで改善するのではなく、仕様を満たすように機能を変えることでスコアをあげてるようでした。
その視点が今回は足りてなかったです。
業務にも通じるパフォーマンスチューニングの基本的なところだなと思いました。
まとめ
ISUCON楽しかったです!
今回のISUCONを高得点出るまで改善しつくて引き出しを増やし、初動を早められるようにスクリプトをブラッシュアップしていこうかなと思いました。
次も参加します!
株式会社ウェイブのエンジニアによるテックブログです。 弊社では、電子コミック、アニメ配信などのエンタメコンテンツを自社開発で運営しております! ve.jp/service/
Discussion