概要
そういえば #isucon 負けました
— ふるさっくす (@furusax) 2020年9月13日
というわけで、去年に続き会社の同僚と共にISUCONに参戦しました。今年はメンバーを変えて、かべさん(@kabesan)とたけちゃん(@ftaked)と3人で大きなかべさんチームとして出場です。
当日のリポジトリはこちらです。
やったこと
今年は主にインフラやミドルウェア周りを担当しました。
事前準備
各サーバーにインストールするツールの選定とレシピ作成をやりました。入れたのはISUCONで定番のalpにmyprofiler、特別ライセンスが入手できたNew Relicのエージェントあたり。New RelicのエージェントはUbuntuのバージョン毎にリポジトリが分かれているので、一応どのバージョンでもインストールできるようにレシピを書いたことが工夫した点でしょうか。会社で使い慣れているMItamaeを使いましたが、今思うと手元からSSHでレシピをプッシュできるAnsibleの方が良かったかもしれません。
当日
競技開始後はとりあえずインフラ周りの調査とツール類のインストール、GoコードのGitHub管理化、MySQLスロークエリログの設定をしました。サーバーが全部1コアしか無いのはさすがにちょっと面食らいました。
競技を始めてalpでアクセスログ解析をしてもこれといって特段悪い場所が見当たらず、どうしようかと頭を抱えました。New Relicやtopコマンドを眺めてるとMySQLによってCPUリソースを使い切ってるのが明らかだったので、とりあえずMySQLを別サーバーに逃しました。MySQLはサーバー設定もユーザーもデフォルトでlocalhostからしかアクセスできないように設定されてましたが、この辺はちょうどつい最近業務で同じような作業をしたのでスムーズに設定変更できました。別サーバーに移動してもまだ重い。データベースに2つしかテーブルが作成されておらず、更にテーブル間に一切リレーションがなかったので、もしかしてテーブル毎に別サーバーにしたら良いんじゃね？と思いつきます。Goのコードを見てくれていた @kabesan にDBを2つ使ってもらうよう実装をお願いし諸々頑張ったところ、スコアがちょっと伸びて一瞬だけ22位まで上がりました。
この時点でまだまだMySQLによるCPU負荷が高く、結局このまま最後までこの負荷を減らす方法を実践できず競技終了となってしまいました。最高スコアは1000ちょっとでした。
反省点
インフラ担当になったものの、圧倒的にインフラ側の知識が足りなかったと思います。 NginxのリバースプロキシやMySQLの設定変更みたいな簡単な作業はできましたが、パフォーマンス調整という意味では結局何もできませんでした。全サーバー通してメモリにはまだまだ余裕があった(各DBサーバーは30%前後、アプリサーバーは15%程度しか使ってなかった)ことから、もっとメモリ側に負荷を寄せる方法があったのでは？と思ってます。
まとめ
というわけで、大きなかべさんチームは予選突破という大きな壁を越えることができませんでした。残念。非常に残念。予選突破した人や運営の解説・講評を読んでオベンキョしようと思います。運営の皆様お疲れ様でした
