本番で失敗しないために何ができるか
takonomura氏：ここまで、どういうふうにして時間を効率的に使っていくかという話をしたのですが、ここからは本番で失敗しないためにどういうことを考えているか、みたいな話をします。
というのも、最初にソロでやっていく上でのデメリットとして「視点が少ない」ということを挙げたんですが、ソロだとほかの3人チームとかよりもちょっとしたミスが命取りになりやすいと個人的には思っています。
なので、そういうものをいかに解決していくかというか、そういうことにならないようにしていくかをいろいろと考える必要があります。
その上ですごく重要なこととして、競技時間中は冷静じゃなくなるんですよね。自分は毎年そうなのですが、ソロで参加していると誰かに相談することはまったくできないので、時間の制限もあって、どんどん冷静じゃなくなります。そうなってくるとどんどんミスもしやすくなってしまって、どんどん悪循環に陥ってしまうと個人的には思っています。
ふだんの開発はそういうことになることはあまりない気がしていて。今までの自分の感覚的に、障害対応をしている時に近いのかなと思ったりします。
時間の制限があって「早く直さなきゃ」と思っているような障害対応みたいな状況と、ISUCONの競技時間中は、なにか近いものがあるんじゃないかなと思っていて、そういうところからノウハウが活かせるんじゃないかなと考えています。
できる限り冷静に保つように努力をするために、深呼吸をするとかいろいろあると思うのですが、深呼吸をしてもどうしてもいつもより冷静じゃないことはあると思うので、そういった時でも本来の自分のパフォーマンスを発揮できるようにいろいろと準備しておく必要があるかなと思います。
さまざまなプランを考えておく
そのために1つやれることとして思っているのは、さまざまなプランを考えておくことだと思います。想定外のことは、パニックになったり冷静じゃなくなる要因の1つだと思っています。
例えば過去のISUCONであった話だと、「nginx」じゃないからアクセスログの設定方法が違って、うまくアクセスログの集計ができなくて困っちゃうということがあったり、MySQLだと思ったらSQLiteも使っているせいでスロークエリログが吐けないとか、いろいろあると思うんですよね。
そうなると、どうしたらいいかわからなくなって、なにも手がつけられなくなるみたいなことがあると思いますが、「そういうのがあるかもしれない」という可能性だけでも考えておくのは、すごく重要だと思います。
なので、例えばスロークエリログが吐けなかった場合には、なんとかして近いログをアプリケーション側から吐けるような方法を考えておくとかをしておけば、MySQLでもSQLiteでもPostgreSQLでも、なにが来てもある程度近いものが取れるようにしておくという考え方ができると思うんですよね。
すべてに対して準備をしておくのはなかなか難しいと思うし、不可能だとは思いますが、いろいろと考えておいて、「こういうふうにしたらそういう場合でもどうにかなるんじゃないか」みたいなことを考えておくと、気持ちが楽になって、本番でできるかぎり冷静な対処ができるようになる要因なんじゃないかなと思っています。
メモを用意する
次に重要だと思っているのが、メモを用意することです。これはISUCON10で自分が優勝した時に一番気をつけていたことかなとも思います。「冷静じゃない時でもメモのとおりに動けばなんとかなる」みたいなレベルのものを用意しておくことが重要かなと思っています。
このあたりは障害対応用にSREとかでRunbookを書いておく文化があるらしいのですが、そういうのとかからも着想を得ています。「とにかく手順どおりに進めばなんとかなっていくように」ということをいろいろと考えていたりします。
冷静じゃない時に読むことを前提に書くので、「ふだんできることもできなくなっている時に読むもの」と思って書いています。なので、当たり前のことも全部書きます。
例えば、「ベンチマーク後に計測結果を見ましょう」。「そりゃそうでしょう」と思うと思いますが、冷静じゃないとそういうことができなくなるので、全部書いておきます。
あとは、よくあるミスも全部まとめておくようにしています。例えばGo言語だと、mapの初期化を忘れて、makeを忘れたせいでnilでpanicを起こすみたいなことが、けっこう自分はやりがちだったんですよね。
そういうのはエラーが出ちゃえばすぐ直せるので難しい問題じゃないのですが、そういうのも書いておくことで、冷静じゃない時にそれを見ながらコードを書けば、ちょっとでも気を配れるようになって、ミスを減らすことができ、時間の短縮にもつながると思うので、こういうことがけっこう重要になってくるんじゃないかなと思っています。
そういうメモをいろいろと書いておいて、競技時間中はとりあえずメモを読むことを癖にしました。ベンチマークを流し始めた瞬間にとりあえずメモを一瞬見てから計測結果を見るようにするとか、本当に細々としたタイミングでとりあえずメモをちらっと見るだけでもけっこう効果があったりするので、そういうのが重要かなと思います。
具体的にどういうメモを書いていたか
（スライドを示して）具体的にどういうメモを書いていたかということで、これは一例ですが、自分はやることのチェックリストをいろいろと書いてあります。
事前の準備の部分でも、GitHubのリポジトリを作成したかどうか、レギュレーションを確認したかどうか、Slackに通知やリマインドの設定をしたかどうかみたいなのものを、1個1個チェックボックスをつけながらやるみたいなことをやっています。
競技が始まった初動の部分でも、「SSHの設定をしました」「サーバーの初期セットアップのスクリプトを流しました」「初回のベンチマークを実行しました」「当日のマニュアルを読みました」みたいなことを1個1個チェックボックスをつけながらやることをやっています。
あと、再起動試験はけっこう忘れがちだと思うので、自分は終了1時間前ぐらいのタイミングで、Slackのリマインドを使って「再起動試験しましょうね」ということを流すようにしています。
それが流れたら、チェックリストを基に、サーバーが複数台ある場合は順番を変えながら再起動しても問題がないかとか、再起動した直後にアプリケーションが正常に動いているかという動作チェックをやってみるとかを必ずやるようにしています。
あと書いてあるものとしては、例えばベンチマーク後に確認する項目として、これはけっこう重要だと思っているのですが、当然のように計測結果をいろいろ見るんですが、メトリクスのどこを最初に見るかをいろいろと書いてあります。
例えば、とりあえず最初にエラーログを見て、エラーが出ているんだったらそれを最初に直しましょうとか、CPUの使用率を見て使用率が異常に高かったら、まずデータベースなのかアプリケーションなのかをチェックして、アプリケーションだったらプロファイルを見にいって、というフローみたいな感じにして、なにを見ていけばいいかをまとめておいています。
これは冷静じゃないとそのとおりに見ずにボトルネックを見逃したりするので、けっこう重要かなと思います。
先ほど言った、改善点の優先順位みたいな話もありますね。
あとは改善に使えそうなテクニックとして、「N+1を直しましょう」ということが書いてあったり、並列化できるものは並列化しようとか、キャッシュがどうとかというのも、全部当然のことではあるのですが、当然のことも全部書いておいています。どうやって直そうか悩んだ時は、それらを見るみたいなことをやっていました。
自分に1番合った戦い方を探すのが本当に大事
最後にまとめです。もう1回繰り返しにはなるのですが、自分に1番合った戦い方を探すのが本当に大事だと思います。今回発表した内容は、自分がソロで戦う時にどうしたら良かったかという内容なので、人によっていろいろと（合う合わないは）違うとは思いますが、いろいろな人のやり方を参考にしながら、自分に合ったものを探していくのが重要かなと思います。
当日パニックにならないためにも、先ほど言ったようにメモを書いておくとか、いろいろと事前準備をしておくのがすごく重要になってくると思うので、練習とか効率化も含めてやっていきましょう。
みなさん、優勝を目指してがんばりましょうということで、発表を終わりたいと思います。ありがとうございました。
