【ISUCON9】dockerのmysqlにmysqldumpslowがなくてLocalで触るのやめた
- 【性能】ISUCON9予選のLocal環境構築（DB部分:Docker-Compose） – HIRO Tracksの続きです
- ISUCON9をLocal（DB部分だけDocker）でやろうとしたけど、色々面倒なのでやめることにしました。
- 今後はAMIからAWSにEC2環境作ってやっていく予定。
[st-myblock id=”447″]
辞めた理由:mysqldumpslowが使えなかったから
スロークエリログを解析するためのツール「mysqldumpslow」がDockerのmysqlイメージ(8.0)になかったため。
※「イヤ、あるけど？お前の設定が足りてないだけだぞ」とかあればコメントください…こちらのdocker-compose.ymlでコンテナ立ち上げています
性能改善においてDB側のボトルネックと快適に戦うためのツールが使えないのはキツイな…と思い断念しました。
「LocalにMySQL入れれば良いじゃん」という意見もあるかもですが、それやるぐらいならお金かけてでもAWS上に開発環境作って触りたくなりました。LocalPCを汚したくない欲が勝っちゃった感じです。
断念した際の時系列
- 【性能】ISUCON9予選のLocal環境構築（DB部分:Docker-Compose） – HIRO Tracks の作業が完了し、ベンチマークが回せるようになった！
- ISUCON9 予選を全体1位で突破しました | takono.io 等、上位勢のブログを読むとスロークエリログの設定が必要らしい！※山根はSQL弱者かつSQL Server側の人間なのでmysql周り詳しくなく、この辺は初見でした
- 第131回 mysqldumpslowを使ってスロークエリログを解析してみる | gihyo.jp この辺読みながら設定し、スロークエリログをファイルに出せるようになった！
- スロークエリログのファイルだけだと見づらい（全SQLがベターっと書かれてる）ので統計情報を出したい！mysqldumpslowなるコマンドがあるらしい！
- 使えない…叩いてみてもcommand not foundだし、 Dockerコンテナに入って/usr/binみてもなさそう。（mysqldumpならある）
回避策でVagrant使おうとしたけど断念
ISUCON9 予選の過去問でNew Relicを使う – valid,invalid に倣ってVagrantでやろうかな…と思ったけどそれはそれで詰まったため断念（力尽きました）
反省（そもそもLocalで触ろうとしたことについて）
- そもそもISUCON、ひいては性能改善タスクを無課金Localで済ませようとするのが難しかったのかもしれん
もろもろ分からなかったこと
ISUCON触ってる時に、知識なさすぎて「？？？？」ってなることが多かったため、何がわからんのか言語化しときます
- ISUCONに慣れた言語がない（山根はJVM言語マン）
- 慣れたDBじゃない（SQLServer使いたい）
- Ansible周り
- インフラ構成管理できることはわかったけど、どう嬉しいものかイメージ湧かず
NextActions: AMIからEC2インスタンス作ってやってみる
大人しく課金します。以下サイトにAMIが公開されているので、これをもとにEC2作ってその中で色々触ってみようかなと。
GitHub – matsuu/aws-isucon: ISUCON過去問環境をAWSで再現するための一式まとめ
sshログインするだけですぐベンチマーク回せることは確認しました。
インスタンスタイプがt2.microだと910点、t2.largeだと2310点でした。
またmysqldumpslowも叩けること確認済み。
参考サイト
強いISUCONerたち。
ISUCON9 予選を全体1位で突破しました | takono.io
ISUCON9予選1日目で最高スコアを出しました | とーふとふのブログ