ISUCON11予選に参加して敗退しました

ISUCON11予選に参加して敗退しました。

ISUCON9と10に引き続き、チームオガヨシで出場しました。前回に引き続き、インフラを主に担当しました。

結果は、失格でした。失格理由は、「環境情報の確認に失敗: セキュリティグループへのルールの追加」でした。参考スコアは40,506点でした。

実装はGoを選択しました。

サーバーの構成は最終的に以下のようになりました。

・Web + App
・DB
・App (/api/condition/)

計測は以下のサービスを利用しました。

・NewRelic
・pt-query-digest

以下、個人的なふりかえりを書いていきます。

準備

前回はアプリケーションへの貢献ができませんでした。その反省を踏まえて、アプリケーションを含む、総合的な練習を中心に行いました。

前回まではRubyで参加したのですが、今回はGoで参加することにしました。そのため、過去問を解きながらGoの勉強もしました。

10:00

基本的なサーバーの設定をしました。deployスクリプトを作り、共有しました。その他諸々の準備をしました。

11:00

MariaDBのプロセスがCPUを使っていることがわかったので、DBを2台目に分離しました。

DBを分離するときにグローバルIPを指定して、セキュリティグループにインバウンドのルールを追加してしまいました。そのままチェックせずに最終的に失格になります。

12:00ごろ

/api/trendが重いということがわかっていたので、その対策を話していました。改善余地の大きそうな箇所だったので、ここに全力を注ぐことになりました。

3人でこの問題に対処していましたが、私はサービスとコードのキャッチアップが足りず、あまり貢献することができませんでした。

13:30ごろ

/api/trendにあまり貢献できそうなことがなかったので、別のことをやることにしました。

遅ればせながら、pt-query-digestの設定をしました。

15:00ごろ

アプリケーションがCPUを使っていたことが分かっていたので、アプリケーションサーバーを2台にしました。

/api/conditionを3台目で処理することにしました。

16:30ごろ

innodb_buffer_pool_sizeなどを中心にDBのチューニングをしました。

logを非表示にしました。

18:45

終了

ふりかえり

参考スコアは40,506点で、失格を無視した順位としては、前回に比べると高くなりました。

セキュリティグループのインバウンドのルールを追加して失格になってしまいました。設定後に環境情報の確認をすべきでした。常識的なインフラの設定ができるようにならないといけません。

アプリケーションの改善に入るときにはマニュアルとコードを読み、サービスを把握してから入るべきでした。また、解説を読むとチームでも打てていない手が多くあったので、自分で改善ができるように実力を高めていきたいと思いました。