社内ISUCONを開催しました! ( 解答例あり )
浅井 勇樹
はじめに
こんにちは!リクルートマーケティングパートナーズ リファラルGの浅井です。リファラルGでは組織活性を目的として社内イベントの運営や勉強会のサポートを行っています。その取組の一環としてリクルートマーケティングパートナーズとQuipperのエンジニアを対象にISUCONを開催しました!
ISUCONとは?
Iikanjini Speed Up Contest(いい感じにスピードアップコンテスト)の略です。チーム対抗でお題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです。
開催のきっかけ
リファラルGでは組織活性のアイデアを常に探しています。そんなある日、とあるメンバーが定例ミーティングにて「社内ISUCONやりたいっす」と呟いたのがきっかけです。その場で開催が決定し、プロダクトディベロップメント部1)リファラルGが所属する部署であり、リクルートマーケティングパートナーズの約100人規模のエンジニア組織を超えて、同じフロアにいるQuipperをも巻き込んじゃおうということになりました。
プロダクトディベロップメント部では、カンファレンスへの出展や勉強会、月例会の開催などのために年間を通して大幅な予算を確保しているため、イベント費用の問題もすぐにクリアすることができました。
概要
日時
12/15 (金) 13:00~19:00 + 懇親会
今回は業務時間内に開催しました。理由としては、組織をあげて大々的に公言することでより参加しやすく、またじっくりと取り組める時間を確保することで満足度の高いイベントになると考えたためです。
参加人数
17人(6チーム)
出題
AWSのc3.large
インスタンスを1チーム1台ずつ割り当て、問題はPixiv社で行われた社内ISUCONの問題をお借りしました。この問題はIscogramという画像投稿型のSNSサービスを題材としています。画像の一覧画面や詳細画面、画像の投稿機能、コメントの投稿機能などからなるサービスです。Ruby、Go、Node、PHPの4種類のアプリケーション実装が予め用意されています。今回はRubyを5チーム、Goを1チームが採用しました。
賞品
優勝賞品として話題のGoogleHomeMini、特別賞として当日発表の賞を1つ用意しました。
競技中の様子
競技開始です。スタート直後から皆さん超真剣です。
短期決戦のためお菓子やドリンクも用意しました。糖分の摂取もこれでバッチリです。
スタート直後はもくもく開発する雰囲気でしたが時間が経つに連れて会話が活発になっていきました。
予め用意されていないKotlinでの実装を試み、疲弊しているチームも。
競技中に全チームのスコアを見ることができるため、どこかのチームがスコアを更新する度に会場内に「おー!」という声が上がり盛り上がっていきました。結果発表まで順位がわからないように、最後の1時間は他チームのスコアを見れないようにしました。
結果発表
約6時間の戦いを終え、最終結果は以下のようになりました。
どのチームも開始1時間くらいからスコアが伸び始め、開始3時間あたりから1位が頻繁に入れ替わるようになり白熱していきました。コンスタントに改善点を見つけスコアを伸ばしていった「STEP休暇とります」チームが優勝しました。
今回は通常のISUCONよりも開催時間が短く、通常のスコアよりも少し低めの結果となりました。結果発表後でもインスタンスを触ってもよいことにしたのですが、懇親会中にさらに大きくスコアを伸ばして悔しがっているチームもいました。
各チームの解答
スコアのグラフを見ながらどこでどんな対策をしたかを全てのチームに発表してもらいました。インタラクティブな雰囲気で活発に意見交換がされ、新たな知見を得た参加者も多かったようです。
効果の高かった解答をいくつか紹介したいと思います。
DBにインデックスを追加する
基本的にDBにはインデックスが追加されていない構成になっています。インデックスの追加はパフォーマンスチューニングの王道ですね。ほとんどのチームがこの対策で一気にスコアを伸ばしました。
N+1問題を解消する
アプリケーションコード内には多くのN+1問題が存在しています。こちらも王道ですね。この問題もほとんどのチームが対策していました。
DBに保存されている画像ファイルを静的ファイルに書き出す
画像がDBに保存されているため、画像へのアクセス毎にDBに負荷がかかります。DBにある画像データをファイルに出力し、画像のアップロード時にもファイルに出力するようアプリケーションを変更する対応をしていました。
画像ファイルに対してcache-controlを有効にする
上記の対策と合わせて効果があるのがこの対策です。ベンチマーカーが同じ画像を何度も読み込むため、キャッシュさせることで全体の読み込み時間を大幅に改善することができます。
MySQLTunerが教えてくれたところを治す
約半数のチームがMySQLTunerを採用していました。普段の業務でパフォーマンスチューニングを行っているかどうかがこういうところで現れますね。
懇親会
結果発表には再集計が必要なのでその間に懇親会を開催しました。ISUCONという共通の話題があることで懇親会も大いに盛り上がっていました。また、今回ISUCONに参加できなかったエンジニアも懇親会から参加できるようにしました。
表彰
優勝チームにはGoogleHomeMiniが贈呈されました。STEP休暇制度2)3年ごとに最大連続28日間の任意休暇を取得できる制度です。リフレッシュしたり、短期留学などの学習機会にしたりと有効に活用していただくために、休暇付与と同時に30万円の手当を支給します。を利用しGoogleHomeMiniで遊び倒して頂きたいです。
そしてもう一つ特別な賞を用意しました。最もスコアの低かったチームに対してシステムパフォーマンスに関する書籍が贈呈されました。これがなんと優勝賞品より高価な品となっています。これを読んで次回ISUCONに備えてください!
参加者の声を眺めながらまとめ
感想
- 初めてのISUCONとっても楽しかったです!!
- チームメンバーが自分とは違ったバックグラウンドを持っているのでとても勉強になった。他のチームの知見もとても参考になった。
- リクルートマーケティングパートナーズとQuipperで交流できたのが良かった。ISUCONという共通の話題があったので話しやすかった。
- チームを超えた交流ができたので参加した甲斐がありました!
- 普段あまり触れることのないアプリケーション層以下のチューニングに挑戦できて楽しかった。
- 普段はWebアプリを書いているが、ミドルウェアのチューニングまでは意識するのとなかったので勉強になった。
改善点
- チームはランダムに決めたほうが楽しいかもしれない。
- やはりサーバサイド寄りの人に偏っていたので、もっと幅広い人が参加できるとよかった。
- 時間が限られていたのでパフォーマンスチューニング以外の準備がされていたり、もしくは事前準備の期間があるとより良かった。
- レギュレーションについてはもう少し早く説明してもらえた方が良かった。
開催前はどうなることやら不安でいっぱいでしたが、結果的にほぼ全員から楽しかったという意見を頂きホッとしました。参加者の殆どが「ISUCON楽しそう!」という好奇心で参加し、もれなくISUCONを楽しんで帰ってもらえたと思います。今回はそれ以上に、交流できて楽しかったという意見がとても多く嬉しく感じています。メンバー決めがお見合い状態になってしまいやむを得ずランダムに組んだチームがあったのですが、そのチームの交流に対する満足度が非常に高かったのが印象的でした。
また賞品を用意していたために、参加者がこの問題を既に解いたことがあるかもしれないという不安に常に襲われていました。そこは運良く誰も解いたことがなく結果オーライでしたが、賞品を用意する場合は公平性を保つためにより気を使う必要があると感じました。
心残りがあるとすれば、思ったよりも参加者が集まらなかったことです。最低でも20人、あわよくばもっとと考えていましたが、結局17人の参加となりました。そこは業務時間内での開催が裏目に出てしまったと思います。1ヶ月前には日時を確定したのですが、それでも業務の都合で参加できず残念がっている人も少なくありませんでした。そして案の定モバイルアプリやWebアプリのエンジニアの参加が少なかったことです。仕方ないと言えば仕方ないのですが、今回の参加者にとってはとても満足度の高いイベントになったため、それを更に広げていければと考えています。またエンジニアに限らず、エンジニアではない人も参加し協力して何かに取り組むようなイベントがあったら楽しいのではないかという野望も見えてきました。
大好評につき終了した社内ISUCONですが、これには飽き足らず次なるイベントを開催し組織活性を加速していきます!