こんにちは、CRM事業部門のid:ahogappaです。 前回の記事の通り、先日行われたISUCON12にメンバーとして参加してきました。
私はISUCONに参加したことがなく、いつか参加したい！ と思っていたところ、heyがスポンサーになるということなので参加しました。
ISUCON開催前
ISUCON初参加ということもあり、何はともあれ練習をしようと思いました。そこで、素振りを兼ねていわゆる「ISUCON本」を読みながらパフォーマンスチューニングの基礎を勉強していきました。
これを読破したあとは「完全に理解した」気持ちだったのですが、開催直前にISUCONを題材にした解説本が出るということは、今回はこの本に載っていないような問題が出るのではないか、と勘繰っていました。
また、チームとしても過去問を行いチューニングの流れを確認しました。 事前練習はさくらのクラウドさんの無料クーポンが配布されていたのでこちらを参考に練習環境を作り実施しました。
コミュニケーション手段としてScrapboxを使いメモをまとめ、Discordを使い連携をとりました。 また、サーバーの出力をDiscord Bot経由で共有するスクリプトの用意などをしました。
ISUCON開催当日
競技がスタートしてまずは教科書どおりのチューニングから始めました。我々のチームはRubyを選択したので「Pumaの設定をちゃんと書く」「limitを書く」「indexを貼る」など明らかに問題がある箇所をざっと直していきました。
他に実施した具体的なチューニングとして、
- DBの機能を使いユニークなIDを生成している箇所はざっとSecureRandom.uuidに書き換えた。
- visit_history の不要な行、INSERT の削除。
うまくいかなかった点として、
- Pumaの設定に関しては事前に作っておいた設定ファイルがあったが、コピー&ペーストでは動かず少しアレンジが必要だったためバタバタした。
- Discord Botのスクリプトをきちんと管理しておらず、結果的に練習環境から引っ張ってきたため、無駄に時間をとってしまった。
これらはやはり練習不足な部分であるので、きちんと本番を想定した練習が必要だと思いました。
SQLiteどうするか
ここまでのチューニングでappからDBアクセスへとボトルネックが移っていきました。どうやらSQLiteで構成されているデータの取得条件が複雑なのとN+1になっているのでそこを修正すればよいということはわかったのですが、どうチューニングすれば良いのか見当もつきませんでした。
さらに、MySQLへ移行させるような思わせぶりなスクリプトが用意されていたりしましたが、そのままでは使えずinitializeで時間がかかりすぎてしまっていました。 SQLiteの部分に関しては結局最後まで手付かずだったので、ここがボトルネックとなりスコアが思うように上がりませんでした。
インスタンスどうするか
今回の問題はインスタンスを３台もらいそれを自由に配置可能でした。なので1台をapp、もう1台をMySQLに割り当てるのは開始直後に修正したのですが、もう1台を最後まで使い切ることができませんでした。これを使い切ることでもう少しスコアをあげられたのかなと思います。
感想戦
予選終了後、ISUCON予選者用のDiscordサーバーでは感想戦が行われており、さまざまなアイデアが出てきて非常に面白かったです。
特に問題のSQLiteをどうするかについては各チームで対応が異なっていたため、非常に興味深かったです。 必要なデータのみをあらかじめ取得しておき、初期化時にそれを投入するというのが一番シンプルで良いチューニングだなと思いました。
インスタンスの割り当てについても各チームで方針があり、MySQLを2台で分散運用したり、逆にappを2台で運用したりするチームがあり戦略を垣間見られました。
参加した感想
残念ながら我々のチームは予選敗退という結果でしたが、ISUCONを通してパフォーマンスチューニングの勘所はもちろん、クエリやDBの設定、ログの解析方法などの知識を吸収できました。 終わってからアイデアが思いついたり、感想戦を聴きながらあそこはこうすればよかったのか、など非常に悔しい思いをしたので、来年も参加したいです！
