社内 ISUCON に参加した
今週火曜に開催された社内向け ISUCON に参加してきた。これが、まあなんともなかなかに堪える体験だった。
〜開催日
個人では本家 ISUCON のまとめページにある解説や参加した方々のエントリを眺めて押さえるべきポイントを知ることから始めた。
チームメンバーでは1週間前くらいからちょいちょい集まって、誰がどこのレイヤを担当するか、Ruby・PHP のどっちの実装を使うか、ハマりそうなポイントはどこか、等々話したりした。
アプリケーションのレイヤを担当することになったのと、「実装は Ruby で」となったので、使われるであろう Unicorn の設定ファイルを準備したり、stackprof の使い方を見たり、よくあるアプリケーションの変更ポイント（セッション活用のパターンや N+1 問題が仕込まれるパターンなど）を抑えたりした。
「まあこれくらいやればそれなりには貢献できるだろ」とその時は思っていたけど、今にしてみれば何を根拠に、という気持ちだ。
当日
お昼ごろ、お題のアプリケーションやインスタンスが配布され、試合開始となった。アプリケーションは Slack を模した、10個くらいの action を持つチャットアプリだった。
それから5時間奮闘したのだけど、結果から言うと、全員チューニングがほとんどできないまま5時間が過ぎ、Fail した。
何が起きたかというと、開始してデプロイ環境を作り変更を加え始めたあたりで謎の 500 エラーが頻発するようになり、終ぞその原因を突き止められないまま終了時間になった、といった具合。
何が問題だったのか
利用するであろうツールの素振りをしていなかった・足りていなかったことも問題だったけど、それよりもチームとしての取り組み方に大きな問題があったように思う。そのことについて、以下にもう少し掘り下げて書こうと思う。念のため言うと書いたことは自分や取った行動の話で、メンバー全員が取っていたわけではありません。
・共有なしに変更を行った
変更者以外が変更を知らなかったために、それに起因する問題の原因特定が遅れたことが何度かあった。
どのレイヤの変更にしても、共有 -> 変更のフローを守っていれば、問題の原因の切り分けが格段に楽になっていたことと思う。
・変更の正しさよりもチームの快適さを優先した
メンバー間の空気が悪くなることを恐れて、チームとしてすべき意思決定を断念したタイミングがあった。これは特に良くなかったと思う。
実際の場面を挙げると、初期実装に使われていた puma はメンバー全員が不慣れであり、使用経験者が複数人いる Unicorn にすべき、という提案をしたが、他方の意見に納得することなしに puma 続投を決定してしまった。後日、500 エラーが出ていた原因の一旦は puma にあったことが明かされた。悩んだ岐路と最も困らされた原因のポイントが一致したことは偶然ではあったけど、慣れたツールを使うことで原因の特定がしやすくなったのではとは思う。
そもそもこのイベントに参加している以上、チームとして再優先すべきは最終スコアを伸ばすことであり、そのためには一時的な反感を買っても（当然言葉は吟味した上で）意思を伝え続けるべきだったと思う。
・変更の吟味をしなかった
改善のポイントは膨大にある一方で、それに使える時間は短い。その中で、効果の大小や最終的な状態を十分に考慮せずに変更を行ってしまった。
改善できそうなポイントを探し、期待できる効果の大きさや予想される所要時間からやれるものを割り振って進めるのが良かったのだと思う。
本家 ISUCON で上位になった方々の参加エントリを見ても、各自が手当たり次第改善しまくったのではなく、チームで選択した改善を丁寧に重ねていったチームが多いように見える。
といった初 ISUCON 記でした。精神的に大変負荷のかかったイベントでした...ｗ 開催翌日までダウナー人間でしたが、今となってはとてもよい経験だったように感じます。
次回開催があったとき、もしくは本家 ISUCON に出場するときにはかなりのやっていきを見せつけられるよう、今からアレをコレしていこうと思います。
