ISUCON本戦に出場して、惨敗してきた
11/8(土)に渋谷のLINEで開催された、ISUCONの本戦に出場してきました。
まず、とっても楽しいイベントを開催してくださった運営のLINE、Cookpad、テコラスさんに御礼申し上げます。ホントに楽しい1日でした。ありがとうございました!
めっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっちゃ、悔しい思いをしたので、この悔しさを忘れずに来年へ向けて気を引き締めるために、技忘録。
結果
まず、結果から。30チーム中、29位と惨敗しました。failしてないチームの中ではダンラスです。
優勝チームの61万点から比べたら、う◯こみたいなもんですね。
事前準備
本戦のレポートの前に、事前にやった準備について少し触れておきます。予選が終わってから チームメートである @_taketake と @zimathon の3人でふりかえりを行い、以下の点について準備をしようと話していました。
- 前日飲みに行かない
- 事前に役割分担決める
- 前日にある程度タイムスケジュールを作って共有しておく
- レギュレーションを熟読する
- 短い単位で共有しながら都度軌道修正して進める
- ルールをしっかりと確認する
- ファシリテーター決める
- 挑戦する言語を絞っておく
- ベンチの特性を早めに知る
- failを恐れない大胆な判断を本戦でもする
- ボトルネックが何かをしっかり確認する
- キリの良いタイミングで再起動する
- 予選ど同様のフォーメーション(に近い形)で作業する
- 2013の本戦と今回の予選まとめを読みながら、手を動かして復習する
- 計測ツールとか計測の仕方とか決める(環境次第)
- 構成を把握する時間をはじめに取って、その後共有して役割分担する
- 今回の予選の他チームのやったことを情報収集する
くらいのTryが上がっていたのですが、事前に準備する時間がほとんど取れず、結果的にできたのは
- 前日飲みに行かない
- 今回の予選の他チームのやったことを情報収集する
- ルールをしっかりと確認する
くらいで、ほぼ達成できませんでした。この時点で悔しいです!!
当日・開始まで
モニタを持ち込む必要があったのと、事前準備ができていない自覚はあったので、当日朝8:30に会社に集合して、持ち物を準備しつつ作戦会議をしました。直前すぎますね。
そして、集合時間の10:00に間に合うように会社を出て渋谷ヒカリエへモニタを持って移動。移動中にDSub-Thunderboltのケーブルを忘れるという失態を犯し、開店直後のビックカメラへ突撃して調達してから会場であるLINEのカフェテリアへ入りました。ここからして既に平常心ではなかったかもしれないです。
本戦のシステム、サーバ構成
- 動画広告配信システム
- サーバは3台構成でどう使っても良い。使わなくても良い。
- ISUCONで強いと言われているオンメモリDB(Redis)を既に使っていて、RDBは使っていない
- サーバはAWSのt2.micro相当で結構貧弱
- 予選同様にRubyを選択
といった感じ。
午前
競技開始の11:00からお昼の13:00までの間は
- まずは構成を把握する
- レギュレーションを把握する
- マニュアルを精読する
- サーバのスペックを確認する
- 初期実装でベンチを動かしてスコアを見る
- OS設定、ミドルウェアの設定を確認する
といった足回り的な部分を見つつ、サクッとできる対応をやろうと話していました。ただ、出題側の @mirakui さんはじめ、参加者の皆さんもブログで書かれている通り、用意されたサーバ3台はすべてメモリが1GBしかなくて、且つデータがRDBではなく、オンメモリDBであるRedisに載っていて、更に5MBくらいある動画データもRedisに入るという初期実装だったので、ベンチマーカーが走るとメモリがスワップしてしまい、繰り返しベンチを実行するとスコアが安定しないというトラップがあって「初期実装でベンチを動かす」という部分でスコアが安定せずに「う〜ん。。。。。」となってしまいました。
OSのファイルディスクリプタの設定や、ユーザポートの設定なども予選ではできていましたが、うまくできませんでした。ちょっとキンチョーしてたのかもしれないです。
午後
弁当食べながらも「う〜〜〜〜〜ん。。。」は続いていて、これを安定させないと、対応方針が決まらないなぁ、と考えながらもちょっとずつコードを見て手を入れていこうと思い、 @_taketake とベンチを安定させるアクションをしつつ、 @zimathon とコードを見るみたいな状態で中盤は過ごしていました。
予選ではしっかりコミュニケーションをとりつつ、対応策をバーっと出した上で「じゃあ、これ俺やります」とかって話しつつ、施策を試しつつ、1箇所でベンチを走らせるみたいなアクションができていたのですが、本戦ではほぼコミュニケーションはとらずに各自悩む、みたいな感じになってしまって、チーム競技のアンチパターンみたいな状態でした。
直前会議では自分がファシリテーターをすることになっていたので、これは完全に自分に責任があります。チームメートには本当に申し訳ないと思っていますし、反省点です。
結局、手を入れはじめたのは17:30頃
結局、ベンチは安定しなかったので
- Redisに乗っている動画データを別箇所に配置
- ファイルI/Oで管理していたログファイルをRedisかメモリに載せる
といった施策をコードに入れはじめたのが夕方以降になってしまい、その頃にちょうど準優勝チームの「33万点」がランキングに現れ、自分たちがうまく行っていなかったこともあって、ちょっと「もう、厳しいなぁ」と思ってしまい、攻めきることができませんでした。
懇親会で @tagomoris さんに話を聞いたら、「あの33万点が出たことで、ネットワーク帯域を使わずにスコアを伸ばす方法があるはず」と確信して、秘孔探しを最後まで諦めなかったってお話を聞いて、さすがはV2を達成するチームのメンバーだと思いました。
結局、ベンチの実行オプションもベストの指定ができずに、初期実装を下回る超低空飛行なスコアで終戦しました。
まとめ
- 経験のないシステムをしっかり把握することは難しい
「動画広告配信システム」と聞いて、「動画!?」とか「広告!?」という印象を抱いてしまいましたが、本戦が終わってから落ち着いて考えてみると、なんのことはない、管理画面からの広告入稿と、動画≒静的コンテンツを配信するだけのシステムでした。
- 本戦独特の雰囲気に飲まれてしまった
予選はオンラインだったので、会社でいつも仕事してる感覚で対応できたので、いつもどおりの平常心で作業ができましたが、本戦はアウェーゲームという感覚で、ちょっとキンチョーしてました。これは本戦に1度でも参加しないとわからないことだと思います。
- 低スペックのサーバとベンチのスコアに惑わされた
自分の中では、これが一番キツかったです。メモリスワップによって、ベンチが安定せず、「う〜〜〜〜ん。。。」を繰り返してしまいました。先にできることがあったのに、ムダな努力で時間を費やしてしまって、本当に悔しいです。
- 準備大事
アクセスログを解析するツールや、サーバのスペックを出力するツール、各種ミドルウェアの設定ファイルなど、事前に準備できるものはたくさんあったのですが、しっかり準備ができませんでした。来年へ向けて社内用のGitHubにリポジトリを作って整理していこうという話になっています。
- コードの問題に気づいても、対応策をパパっと書けない
初期実装状態でアプリのコードの問題には感づいたが、どう直せばいいのか、パッと出てきmせんでした。会社ではWindowsメインでいじっているので、普段からOSSに囲まれた構成でやっていないと、パパっとコマンドが出てないです。
- Cache-Control
ベンチマーカーに対してキャッシュが効くとはまったく考えていませんでした。動画広告を受けるクライアントであることを考えれば、思いついた気もしますが、あの雰囲気でちょっとキンチョーした状態でその発想は、正直いまの自分の実力では厳しいなぁ、と思いました。完敗です。
いや〜〜、ホントに悔しいのですが、自分の実力を知る良い機会になりました。こんなに悔しい気持ちは久々なので、1年間、修行を積んで基礎力をつけて、来年ISUCONに再挑戦します。絶対本戦に出場します。