新卒文系エンジニアIsucon6に参加してみた
Isuconとは
お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル、それがISUCONです。
環境
ルール
- 制限時間
- 10時〜18時
- 出場チーム
- 300チーム以上
- チームメンバー(p-team)
チーム名簿だけ見れば気持ち悪い団体ですが偉大な先輩方2人と参加しました。
結論
これまでパフォーマンスの部分をあまり意識せず開発してきた身なので まぁ無理だと思って終了間際にスーパーで買ってきた92円のカップやきそば ×3 を振舞うことを念頭において参加 結論から申し上げるとやはり無力でした。 大きな課題はパフォーマンス部分もそうですがmysqlの氷山の一角部分しか知っていなかったことが明らかになりました。
Isucon(午前)
環境構築から
enomotodev先輩がAzureを起動・設定してデプロイする
鍵のバトンを渡されtakedajs先輩とsshで接続しにいく
その間にenomotodev先輩はnginxにてphpが動くように構築
自分とtakeda.js先輩はソースを見たり、gitbucketとsourcetreeの連携させたバージョン管理の設定をする。
無事scpコマンドでローカルに落とせたソース。
ブランチを切り、いざソースを見てみることに
以下が本問題のソース(今大会にて実装したソースです)
え〜と、isuda?isutar?
なにがなんやら
view側ではhtmlではなくphpテンプレートであるtwigが使われていること
php側でisudaとisutarというファイルが似たソースがあること
一通り眺めてみると何やらmysqlの設定を見つけ
とりあえずmysqlに入ってみる
構造はシンプルであるがとりあえずdumpをとっておく
無事とれたのを確認しdumpファイルを見てみるとIndexがついていないことが明らかに。
これはかなりの効果が出るのではないかと判断し、いろんな施策を考える。
とりあえずなんやかんやで午前の部はなんとか7位までつけたところでお昼休憩へ
Isucon6 (午後)
あれ?俺ら7位、いけるんじゃね?となった午前の部
から一転
構築された環境で様々な施策を打つことに
ただよくわからない
自分は「mysql パフォーマンス」などパフォーマンスに関わることを知ることからスタート
とりあえずInnoDBのメモリやQueryのデータ量などを知ることができたがここからどうパフォーマンスをどう上げるか
takeda.js先輩は細かい施策をどんどん実行していく。enomotodev先輩はAPIの改修という大きな施策を打ち出す。
自分はtakedajs先輩の出した施策からインフラ側をチューニングする
特にmysqlのInnoDBのログファイルサイズを変更するために そのままの変更ではエラーが出るので
この施策だけで心肺蘇生法のような緊張感に包まれる。(多分自分だけ)
とにかくソースを見てもよくわからないので簡単な施策、計測、やきそばのタイミングを中心に行ってみた。
施策を打ち出すことができない無力さに心が折れかけるもなんとかパフォーマンスを元の状態までもっていくことに成功
ここでtakeda.js先輩の施策が当たる。
SQLのクエリのチューニングを行い、パフォーマンスが10000を超えかなり上がる。
それ以降は大きな施策を打ち出すことができなかったがベストスコアを更新していく
自分は17時以降はやきそばのチューニングにとりかかる
むしろ16時以降はやきそばのことしか考えてなかった。
結局最終結果は14620とtop10にはまだまだ遠い数字となりました。
ただ課題は明確にわかったのと外の世界のエンジニアのすごさに圧巻されたこと。
正直isuconは自分にとっては早かったが良い経験になりました。
これまでパフォーマンスにあまり興味を持てなかったが今回でもっと知りたくなったし、ソースを組む段階からパフォーマンスを意識した開発ができることが大切であると実感させられました。
来年はphpより高速な言語でベストを更新できるようになること 施策を生み出し自分がボトルネックに気づくことができることが来年に向けての課題となりました。
そのためにmysqlの根本的なところ(リレーショナルデータベースの本買いました)を理解しレベルアップしていくしかないと感じました。
それにしても学生で一般も交えた中でも上位のチームがあってとてもすごいとしか言いようがなかった。
みなさまおつかれさまでした。