先日、「第二回 社内ISUCON」を開催したので、運営視点でその様子をレポートします！
あいさつ
こんにちは。@uryyyyyyyです。 最近はデータ分析を担うチームのマネージャーをしています。
今回の社内ISUCONでは、主催者として運営を主導していたので、本記事では社内ISUCONの全体像をお届けできればと思います。
※本記事は、Yahoo! JAPANさん作のこちらのISUCONリポジトリの解法に言及します。ご注意ください。
社内ISUCONについて
ISUCONとは（公式サイトより引用）:
お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル、それがISUCONです。
オプトテクノロジーズでは、業務時間を丸一日使った社内ハッカソンを定期開催しています。 運営によって設定されたテーマに沿って、業務を改善するツールや、試してみたかった技術を用いて謎のネタアプリなどを作っているのですが、 今回は以前人気だった社内ISUCONを再び開催することにしました。
ちなみに、前回のISUCONの様子はこちらからご覧頂けます。 tech-magazine.opt.ne.jp
企画〜準備
問題/ポータルサイトの用意
前回の記事と同様ですが、運営チームによる準備も時間に限りがあるため、問題の各言語の実装/ポータル/ベンチマーカー、をゼロから作るのは難しいと判断し、過去問や他社さんで実施されている問題をパクることにしました。
選定の基準としては、
- インフラ準備などの手順がまとまっていて再現できること
- 古すぎないこと（環境を再現出来なかったり、トラブルシュートに難航する恐れがあるため）
- 多様な言語で実装されていること
です。 オプトテクノロジーズでは各チームで技術選定を自由にさせていることもあり、入社してくる方の好みやプロダクトで用いられる言語も様々です。今年でいうと、 Scala/PHP/Ruby/Python/JS/Golangあたりは揃えておきたい感じでした。
色々見た結果、Yahoo! JAPANさん作のこちらの問題がバランスが良さそうだったのでお借りすることにしました。ありがとうございます (*_ _)ペコリ
https://github.com/yahoojapan/yisucongithub.com
portalサーバーと問題のruby実装だけ少し手直しが必要でしたが、他は問題なく動いてベンチマーカーも良く出来ていたのですごく助かりました。
また、Scala / Python実装がなかったので、それぞれ Play framework / Flaskにてゼロから作ることにしました。
それらを踏まえてこちらで手直ししたリポジトリも公開しているので、もしご興味があれば使ってみてください。
レギュレーションやその他の調整
前回の社内ISUCON実施後の感想アンケートで、
- 「DBのレコードを空にする、などといった(無茶な)チューニング方法は如何なものか」
- 「スコアの算出基準が不明」
という声がありました。 また運営側の思想としても、デグレを起こすパフォーマンス・チューニングは如何なものか、という思いがあり、今回は「ベンチマークでアラート（本来の操作が出来ないなど）が出るとスコアが0点になる」という仕様にしました。
また、ベンチマークが404を返すと点数が下がる仕様なのですが、デフォルトではfaviconへのリクエストが404になっておりそこを直すだけで点数が上がるようです。これは本質的では無いと判断したため、デフォルトでfaviconを返すように調整しました。
最後に、優勝チームには賞品が掛かっているため、問題の出典がわからないように画像を差し替えたり Y! などの文字を変えたり、レギュレーションドキュメントを作り直したりしました。
インスタンス準備
今回はAWSにてインフラを用意したのですが、やったこととしては以下です。
- 問題用サーバーのAMI化
- 万が一インスタンスを壊してもやり直せるように
- AMIへの固定IP付与
- 再起動時にpublic IPが変わるとベンチの設定が面倒なため
- 動作確認用に各種portを開けたSGの作成
- 各チームそれぞれでSGまでいじると、運営側で制御不能になる恐れがあるため、事前に整備
- （read onlyなAWSアカウント作成）
- AWSコンソールから各種メトリクスを見れたら楽な場合もあるので一応。
開催までの流れ
前日まで
毎回ハッカソンには景品を出しているのですが、今回はこちら！ババン！
参考画像は担当者の好みです。
また組織の文化醸成も目的にあるため、今回は1人での参加はNGにして事前にチーム組成を促しました。
結果として、
- 事前に過去問などを眺めたり準備してくるガチのチーム
- 慣れてない人たちが集まる初心者チーム
- Goでのチューニングを試してみたいチーム
など多様なチームに分かれました。 （お盆に近いため、参加出来ないメンバーも一定数いました。。）
当日（ルール説明）
9:30(JST) 集合 にて、各種アナウンスです。
などを一通り行って質疑に答えたら、後はチームに分かれてチューニング開始です。
説明が一通り終わって、スタートした様子
勝負服で戦いに挑む参加者も
作業中の様子
各自、好きな場所でがんばります。
自席で頑張るチーム
こちらはPythonチーム
こちらは優勝候補のチーム
どのエンドポイントを重点的に直すか考えている様子
こちらは仙台チーム
結果発表
17:00(JST) に各インスタンスを停止し、結果発表へ。 順番にベンチを実行している間、各チームからチューニングしたところを発表してもらいます。
順番にベンチマークを走らせていきます
Pythonで色々チューニングするよりGoの初期実装の方が速かったとか
結果はこのような形に
最終的には、優勝候補と噂されていた「敗北を知り隊」が2位の点数を2倍ほど引き離して優勝しました！
以下がチューニングしたことです。
- 足回りを整えた（デプロイスクリプトとか）
- DBのindexを貼った（tweets の user_id, created_at）
- MariaDBのチューニング（cpuは使い切れているが、メモリが余りまくりなのでメモリをもっと使えるような設定）
- nginxのチューニング（プロセス数auto, 静的ファイルをnginxから直配信）
- optomoを統合してモノリシックにした
- friendsテーブルを正規化した
- ユーザ名問い合わせをメモ化
- 全文検索indexを入れようとしたけど正しく検索できないキーワードとかあったのでlike検索に戻した
- search内でユーザ名をループ毎に問い合わせしていた箇所をキャッシュ
- その他アプリの細かいチューニング（keepaliveやローカルcache等）
振り返り
去年と同じく「スコアの計算方法がわからない」「速くなってるはずなのに点数が変わらない」との声をいくつか頂いていました。（後者はおそらくworker processなどの調整が不十分で同時アクセスに耐えられていなかったものと想定されます。）
次回実施するときは、スコアの算出方法はシンプルなもの、例えば「リグレッションを起こしたら0点。そうでなければ用意したシナリオが全部成功するまでの所要時間」などにしたいと思います。
また運営側からも、「次回はSPAやDockerなどを盛り込んだ構成にしたい」「ミドルウェアを入れ替えるなどしやすい問題にしたい」など意見が出たため、来年は自分たちでISUCONの問題を作りたいと目論んでいます。
最後に
長くなってしまいましたが、社内ISUCONの様子をお届けしました。 オプトテクノロジーズでは定期的にこのような催しは続けていくつもりなので、もし興味をお持ちいただけましたらこちらよりお声がけください。
