ISUCON 初参加の振り返りといくつかの気を付けたいポイント – ISUCON13参戦記
目次
はじめに
この記事は、ニフティグループ Advent Calendar 2023 13日目の記事です。
こんにちは!
ニフティ不動産 のバックエンド開発を担当している kinari と申します。
この記事では今後 ISUCON に初参加する方に向け、再起動試験などの気をつけた方がいいポイント6つをお伝えできればと思っております。
想定する読者層 🙋
- ISUCON13 で再起動試験に失敗した人
- ISUCON にまだ参加したことないけど参加してみたい人
- ISUCON で 0 点を叩き出す方法を知りたい人
マッチしない読者層
- ISUCON 自体の説明を期待している人
- ISUCON13 の技術的な解説が知りたい人
先に結論
以下気をつけたい 6 つのポイントです!
- 当日まで
- 全員が最大限バリューを発揮できる言語を決めておく
- デプロイフローを決めて準備しておく
- しっかり寝ておく
- 当日
- 戦略を立てる時間を設ける
- 仕様をしっかり読む
- 再起動試験は`$ sudo reboot` を実施する
改めて
11 月 25 日に開催された ISUCON13(”いい感じにスピードアップコンテスト”の略)に、弊社メンバーでチームを組んで参加してきました。(チーム名: 頂で寿司を食べたい)
最高スコアは 16,292 点、最終スコアは 0 点という結果でした。(ISUCON13 受賞チームおよび全チームスコア : ISUCON公式Blog より)
チームメンバーは以下の通りです
- @kinari321 (私)
- ISUCON 初参加
- 入社3年目
- ニフティ不動産でバックエンド開発を担当
- @SoraY677
- ISUCON 2度目の参加
- 入社3年目
- ニフティ不動産・ニフティ温泉でフロントエンド開発を担当
- @at-blau
- ISUCON 初参加
- 入社5年目
- システム開発部部長
当日までに気をつけたいこと
当日までの準備でも気をつけたいポイントがあります!それは以下の3つです。
- 全員が最大限バリューを発揮できる言語を決めておく
- デプロイフローを決めて準備しておく
- しっかり寝ておく
全員が最大限バリューを発揮できる言語を決めておく 🗣️
弊チームは Go 言語を採用しました。ただ、今思うと Node.js の方が良かったのではないかと考えています。
理由は、ISUCON13 参加を決めた当初、元々 Go 経験者が1人 + Go やってみたい勢2人でチーム構成されていました。ただ、開催 2 週間前に急遽メンバー1人が入れ替わることになってしまい、結果的に Go よりも Node.js の方がチーム全員のバリューが発揮できる状態になってしまいました。
開催 2 ヶ月前から ISUCON 用に Go でコツコツ練習してきたため、そのまま Go 言語で本番に挑んだのですが、今思うと多くのメンバーが慣れた Node.js を選択した方がよかったと残念に思っています。
デプロイフローを決めて準備しておく 🔄
ISUCON はいかにデプロイ頻度高く、ベンチマークを多く回せるかが勝負です。
実際、今年優勝したチームも非常に多くのベンチマークを回していたようです。
ISUCON13で優勝しました(チーム NaruseJun)
自分たちはあらかじめ自作の Makefile を作成し、本番に臨むことで大きく詰まることはありませんでしたが、この準備がないともっと点数が伸びなかっただろうなと考えています。(実際 0 点でしたが…)
しっかり寝ておく 🛌
今年開催された、ISUCON 夏祭り 2023 でも言及されていました。
前日は夜更かしせず、ぐっすりと寝て起床成功を果たしましょう!
当日気をつけたいこと
この記事の中で自分がもっとも伝えたいことは「再起動試験は $ sudo reboot を実施する」ですが、他にも2つあります。
- 仕様をしっかり読む
- 戦略を立てる時間を設ける
- 再起動試験は $ sudo reboot を実施する ⭐️
仕様をしっかり読む 📖
各所ブログで散々言われていることですが、仕様が第一です。
弊チームも、まず環境を立ち上げてから、次に全員でしっかり仕様の読み合わせる時間を設けました。
実装的に問題なくても、「それ仕様に書いてなかった?」と会話できたのはよかった点だったと考えています。
戦略を立てる時間を設ける 🚩
点数が振るわなかった理由の一つには、戦略ミスがあると考えています。
前日までは「ちゃんと点数と修正コストが見合うところから着手していこう」と話していました。
ただし、実際本番になると各々が修正したい箇所の作業に集中してしまい、全体としてどこの修正コストが低いのか見えない状況になってしまいました。
これを防ぐためにも、途中でも構わないので、チーム全体で修正方針を調整できる時間を設けられれば良かったと考えています。
再起動試験は $ sudo reboot を実施する ⭐️
最後に、最も大切な 0 点にならない方法についてです。
本番当日、弊チームが行ったことは各種サービスの再起動でした。
$ sudo systemctl restart {serviceName}
$ sudo systemctl restart mysql
$ sudo service nginx restart
ただし、本来実施する必要があったのは、下記コマンドでした。
$ sudo reboot
これらのコマンドの違いですが、前者はOSの再起動を含んでいません。(PC で Google Chrome を終了したとしても、PC 自体の終了はできていないのと同じですね)
ISUCONの審査過程では、前者のコマンド相当の
- OS 再起動後もアプリケーションが正常に動作するか
- データは消えていないか
- 加えたはずの変更が元に戻ってしまっていないか
などの確認が入るのですが、これに相当する試験が実施できていませんでした。
その理由なのですが、「デプロイフローを決めて準備しておく」の中でも言及したとおり、自作の Makefile を作成していたのですが、その中に再起動コマンドもあらかじめ準備してしまっていたため、当日気づくことができませんでした。残念!
再度まとめ
再度まとめです!
計6つの気をつけたいポイントがありました!
今後参加される方の参考になれば幸いです。
- 当日まで
- 全員が最大限バリューを発揮できる言語を決めておく
- デプロイフローを決めて準備しておく
- しっかり寝ておく
- 当日
- 仕様をしっかり読む
- 戦略を立てる時間を設ける
- 再起動試験は`$ sudo reboot` を実施する
感想
今回、ISUCON13 への参加を通して ISUCON 自体の印象がガラリと変わりました。
参加前までは、「強い人じゃないと参加しちゃダメなのかな…」「たった 1 日で何か学ぶことがあるのか…」と半信半疑でした。しかし、今回の参加を通して次のことを学ぶことができました。
- Web 全体で自分の弱点はどこなのか気づくことができた。今回だと DNS 周りの知識が不足していることがわかった
- 遅いかどうかを感覚で判断せず、客観的な数値から判断することの大切さを噛みしめることができた
- ISUCON は初心者でも全然参加してよい
最後に
最後までお読みいただきありがとうございました!!
よければこちらも覗いてもらえると幸いです 👀
掲載内容は、記事執筆時点の情報をもとにしています。