ISUCON11予選に参加して敗退しました
ISUCON11予選に参加して敗退しました。
ISUCON9と10に引き続き、チームオガヨシで出場しました。前回に引き続き、インフラを主に担当しました。
結果は、失格でした。失格理由は、「環境情報の確認に失敗: セキュリティグループへのルールの追加」でした。参考スコアは40,506点でした。
実装はGoを選択しました。
サーバーの構成は最終的に以下のようになりました。
計測は以下のサービスを利用しました。
以下、個人的なふりかえりを書いていきます。
準備
前回はアプリケーションへの貢献ができませんでした。その反省を踏まえて、アプリケーションを含む、総合的な練習を中心に行いました。
前回までは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点で、失格を無視した順位としては、前回に比べると高くなりました。
セキュリティグループのインバウンドのルールを追加して失格になってしまいました。設定後に環境情報の確認をすべきでした。常識的なインフラの設定ができるようにならないといけません。
アプリケーションの改善に入るときにはマニュアルとコードを読み、サービスを把握してから入るべきでした。また、解説を読むとチームでも打てていない手が多くあったので、自分で改善ができるように実力を高めていきたいと思いました。