予選敗退から学ぶISUCONの正しい歩き方

34位でフィニッシュ。

isucon.net

棄権を合わせると予選突破に200イスコインちょっと足りなかった。 ハイスコアは9850だっただけにあと1つなにかできれば予選を突破できてたことになる。

当日の流れは id:sugyan さんが用意してくれてるのでそっちを読んでほしい。

memo.sugyan.com

ここからはただただ、自分に対する反省をまとめる。

主な担当であるインフラについての反省

　準備したつもりでも準備不足だった。 複数台構成、普段RDSやALBに甘えている弊害が出て、Nginxやアプリケーションの複数台構成のやり方を知っているが普段していないので詰まったって感じ。具体的にはMySQLに接続できなくて時間をかけた。

　あとnginxのチューニング、特にルーティングで配信をまとめるみたいなところもかなり時間をかけてしまった。 普段、S3とCFにURLをすれば良いって感じで生きてるとこういう細かいリバースプロキシの調整のときに設定方法が出てこない。 つまり「解決したい方法はわかっているが手段が無い」みたいな感じでかなり時間を取られた。 またもっとチューニング出来たはずで、それが出来てたら少なくとも200点は超えてたろうなと思う。

　あとpumaについて知らないことが多すぎた。 もっとメモリを使い切れるように調整したり、ワーカー増やしたりやれることはあった。 ここもチューニングしっかりできれば予選抜けれたと思う。

　そして1番の失敗はどういうアプリなのか、コードがどうなってるのかも全然見れてなかった。 そもそも複数台構成やNginxの設定に時間がとられて結局アプリの振る舞いやコードを見始めたのが16時過ぎの時点。 ほとんど、どういうアプリなのか知らないまま設定をしてた。 つまり午前中に複数台にできてある程度時間的余裕があればMySQL 8にあげてSKIP LOCKEDを試す、テーブル構造を大きく変えるようなチューニング、APIのリクエストの並列化などにもチャレンジできたかも知れない。

　時間の使い方に失敗したなと思うし、スピードはつまり経験値の差なので自分の能力不足だと思う。

MySQLについて

　DBのスペシャリストでありながら、全然役に立ってなかった。 あと から聴いた「innodb_lock_wait_timeoutを1秒にして、タイムアウトはすべて売り切れを返す」って発想、なぜ僕も出せなかったのか。と本当に反省しかない。 lockが問題になってるのもわかってる。しかし時間がないからテーブルの変更もできない。けどパラメータ一つ変えることに気付いていれば、この発想が出ていればもちろん予選を突破することが出来たし、「そーだいさんと組んだ意味」みたいなバリューも出せていた。 本当に悔しいし、情けない、けどこれを思いついた @netmark さんカッコ良すぎる。

　こういう発想と知識で問題を解決するのがISUCONだと思うし、カッコいいなと思った。

とにかく @matsuu さんの言ってたinnodb_lock_wait_timeoutの解法、俺も気づけたはずだし、めっちゃすげー isucon って感じの対応でそれが本当悔しくて、羨ましいし、すごい。

— そーだい@初代ALF (@soudai1025) September 8, 2019

ソフトウエアエンジニアとして

　一応コードをかけるエンジニアだと思ってるけど全然コード書くことなかった。 まず前述の通り、コード読み始めるのが遅かった。 もっと素早く準備していれば全然違ったし、インスタンス上げるの失敗問題の待ち時間の間とかでも出来ることがあったはず。 やっぱインフラ担当でもコードを読むべきだなって思うし、状況判断をしなきゃいけないリーダーだからこそ、やっぱコードの概要を知ってないといけなかった。

モニタリングの知識、準備が足りなかった

　結論、僕らの敗因はこれに尽きる。

負けはしたがアクセスログとクエリログを見てるだけでボトルネックが分かる時代の終焉を身をもって感じることができて学びがあったしこういう問題なら自分をアップデートして来年もう一度挑戦してもいいと思えた

— Ryuta Kamizono (@kamipo) September 8, 2019

　すでにSPAが当たり前になっている時代に、アクセスログやクエリログなどエンドポイントの振る舞いだけで戦おうとしすぎた。もっとMethod単位、いやもっと細かい粒度で分析を素早く出来る準備をして挑むべきだった。

　具体的にNewRericのようなAPMやDataDogのライブモニタや分散トレーシングの仕組みを活用できるようになること。 それによって、もっと素早く問題に気付き、効率よく問題を解決できたはず。

　今回、僕らは長年の勘に頼ったところが大きすぎて、手を打ったが意味がなかった施策が多かった（後々効いていくるようなモノもあったとは思うだろうけど） ISUCONは限られた時間で有効な施策を打つのが大事なので正しく把握して、正しく対応出来なかったのはインフラ担当でリーダーだった自分の準備不足だったなと思う。

反省点としてのまとめ

　memcachedやRedisの設定を結構念入りに先に調べてきたのだけど結局使わなかった。 それよりもやっぱもっと手前の部分に自分の足りないことが沢山あった。

良かったところもあるんじゃない？

　あると思うけど、それ以上に反省が多いので割愛する。

まとめ

　反省点が沢山あるってことは伸びしろがあるってことなのでまだまだ自分は成長できるって感じれるISUCONだった。 また id:kamipo さんと id:sugyan さんっていう贅沢なチームで出れたのは最高の経験だった。

　自分たちよりも遥かに高い技術力と発想と圧倒的成長で戦ってくる若者に対して、来年 そーだいなる壁 として戦えるようにこれから一年、自分を鍛える一年にする。

　ISUCONでの忘れ物は、ISUCONじゃないと取り戻せない。