会社でやった社内ISUCONに参加して、得るものをが色々あったので書きます。
社内でやったISUCONの内容について
以下のような変則的ルールでやりました。
- 問題は[ISUCON8を使用。（前日まではISUCON9を使用する予定でしたが、当日に変更）
- 問題自体を事前に見て準備するのOK。
- 予選突破者のブログを見て真似したりするのはNG。
- エンジニア8人が3つのグループに分かれて競う。
- 社内に2人しかいないフロントエンドエンジニアは同じチームにならないようにするなど、得意分野が同じ人間が集中しないようにはなっていた。
- 使える時間は4時間。
- コードをAlibaba Cloudに置き、終了時点のスコアで勝敗を決める。
- その他レギュレーションはISUCON公式に準拠。
ISUCONが開催された理由
「社内エンジニアのトラブルシューティング力を磨く」
主な目的はこれだと思っています。普段触らない領域（僕にとっては「デプロイの仕組み」や「ミドルウェアの使いどころ」など）を触るという目的も勿論あると思いますが。 開催を決めたCTOの考えと僕の解釈が混じっていますが、概ね合っているはず。
その背景を説明します。
弊社にはエンジニアが8人いて、以下のような内訳になっています。
- CTO : インフラに強い
- プロダクトオーナー : インフラに強い
- サーバーサイド方面に強い人 : 4人
- フロントエンド方面に強い人 : 2人（僕はここ）
プロダクトオーナーが開発以外の業務で多忙だったり、CTOのトラブルシューティング力が高いことも手伝い、障害の対応がCTO任せになっているという現状があります。任せきりになってしまった結果、他の人間のトラブルシューティング力が上がらない。でも、障害本番にいきなり投入するのもリスクが高いです。
また、アプリケーションエラーの解消（エラーの通知はSlackに通知するようにしています）も特定の人だけがやる状況が続いてもいました。
そこでISUCONでトラブルシューティングの経験を積んで、普段のトラブルシューティングに活かすとっかかりを掴もうという話になりました。
ISUCONをやった感想
4時間色々ともがきましたが、自分の無力さを味わう苦い思い出になりました（このブログもハイネケンを飲みながら書いています）
- 環境構築からつまづく。
- 同僚にdockerで動く環境を作ってもらうも、ベンチマークが上手く動かない。
- 監視ツールの使い方が分からなくて困惑する。
- チーム内の作業分担が上手く出来なくて、バタつく隙間時間が生まれる。
- ボトルネックのあたりを付けるのが大きく遅れた。DBとPHPのどっちに注力するかを決めるべきだった。
- コード上のボトルネックを見つけるも、対応策を考えるのに時間がかかってしまった。
傍から見たら何をやっているのかって感じかもしれませんが、こういう状況でした。
ISUCONから得たもの
- 時間の使い方をより意識する必要があった。
- 4時間しかないので、やることを絞らないと何も出来ずに終わる。
- Goのビルドツールだったり、H2O だったりと自分が知らなかったものを知れた。
- ansibleのようなデプロイツールにはもっと慣れた方が良い。
- 時にはダイナミックなアプローチが必要だと感じた。
- ボトルネックになっているクエリがあるなら、テーブルの構成から見直して改善するようなアプローチは想像出来ていなかった。
- 疑似体験とはいえ、時間制限を設けてISUCONの問題に取り組めたのは良い経験になった。
- 実際にやるまでは、ISUCONがどういうものなのかを肌で感じられていなかった。
- 問題の実装を読んでいくのは勉強になる。
- ほぼ実戦と言えるアプリケーションコードを読める機会は多くないので尚の事。
まとめ
色々書きましたが、来年のISUCONに挑戦する熱意が湧くくらいには刺激的な経験ができてよかったです。 自分の力不足を思い知らされたので、そこは地道にやっていこうと思います。
