ISUCON 9 予選にチーム「ソレイユ」 (@osyoyu , @KOBA789 , @s4ichi ) で参加し、28位で予選初突破を果たしました。
このメンバーで ISUCON 5 から予選への挑戦を続けていて、参加5回目にしてようやく本選への切符を手にした形です。
4度も予選敗退を繰り返しているうちに、ISUCON の本選に出場したいという気持ちは強くなるばかり。
時間の経過とともにメンバーのそれぞれが日常で取り組んでいる課題や業務の領域が ISUCON で扱われるそれに近づいているのにもかかわらず、思うような成績を残せないことに対する焦りを感じることもありました (ISUCON 7: 42位, ISUCON 8: 45位) 。
我々にとっては予選こそが ISUCON であるという状況は長く、本選は手の届かない夢の舞台、という感じです。
文章にしちゃうとちょっと格好悪いね。
そんなわけで、チームとして初めて予選を突破できたのは、大げさなようですが、悲願の達成そのもの、というわけです（他の2人も似たような思いをもっていると信じています）。
正直、どんな気持ちでいればいいのかまだよく分かっていないですが、とにかく楽しみな気持ちでいっぱいです。
さて、そんなことを書きつつ、5年前の我々はひどいものでした。
N+1 クエリを解消できないどころか SQL もろくに書けない、キャッシュと称してグローバル変数 $cache を導入する、途中で仮眠を開始する、競技終盤で飛び出す「で、Ruby ってどうやってデプロイするんだっけ？」*1 。
こんな有様でも面白くて仕方ないんだから、ISUCON っていうのは本当に凄いですね。
転機は2017年、KOBA789 の就職とともにあったように思います。
メンバーの1人が学生でなくなったことで学生枠での出場権利こそ失ったものの、これはマイナスどころか圧倒的なプラスでした。
DWH チームで SQL をバリバリ書くようになった彼が N+1 クエリを手際よく倒していく様は、その前の年の状況を踏まえるとまさに感激もの。
時期を同じくして我々も同じ会社にアルバイトとして入社し、production レベルのコードやインフラを見る機会が一気に増え、それぞれの実力を伸ばしていきました。
しかし、ISUCON の参加者も年々増え、問題の難易度も上がり、逃げ続ける予選突破ラインを成長で追う我々、という構図がありました。
ISUCON 7 や 8 では top tier どころか 2nd tier にも入れないもどかしさを感じるようになり、次こそは……！ という悔しさは強まる一方。
こんな道を歩んできたチームなので、過去最大の規模であった ISUCON 9 において本選に行けるチームにまで育ったことを誇りに思います。
来月の本番では存在感を示せるチームでありたいものです。
さて、悔しさとか言いつつ、我々は昨年度までは事前準備をせず、実力ってやつに任せてとりあえず殴ってみるタイプのチームでした。
業務や研究を通じての成長でとりあえずぶつかってみる、というほうが適切でしょうか。
実力だけで予選を通過できたらそりゃ格好良いけど、そろそろ本選に出てみたいよね、真面目に準備すれば予選ぐらいは余裕で突破できんじゃない？ やってみるか、との空気がチーム内でにわかに高まり、各種ツールを作り込み、過去問を使った素振りを行いました。
無事その成果が発揮されてホッとしている、というのが正直なところです。
本音のところでは、これだけやれば予選もけっこう余裕で通過できるんじゃない？ なんて話もしていたのですが、結局 10,090 点 / 28位 とかなりギリギリでした。
今年の問題は過去最大級によく作り込まれていて、必死になりながら楽しめました。運営の方、ありがとうございます。
というわけで、これが今のところの率直な気持ちです。本稿の残りは事前準備として作り込んだツールのまとめです。
ソレイユとして出場した過去5回の予選は本当に楽しい記憶ばかり。
このチームで本選を戦えることを僕は本当に嬉しく思っています。出るからには勝ちたい、とも。
優勝するぞ！ 対戦よろしくお願いします！
ここからは事前準備の自慢記事。
一部、というか半分以上は @s4ichi の参加記 と @KOBA789 の参加記 (予定) に詳しいので、そちらも参照。
blog.s4ichi.com
< ここに KOBA789 パイセンの参加記が入る予定 >
作り込んだツールを整理するとだいたいこんな感じ。
isumon
各ホストのリソースからベンチマーク に返っている HTTP ステータスコード の割合まで、全てが一目瞭然になっている Grafana ダッシュ ボード。名前の由来は 社内にある InfraMonitor 略して imon をもじった isu + monitor 。そのまますぎ？
s4ichi パイセンの記事 に様子が詳しく書かれている。
isukekka
ベンチマーカーによるリクエス トを検知して、ベンチマーク 中の alp や pt-query-digest を自動で取って GitHub Issue にしてくれるかっこいいやつ。
そのうち KOBA789 パイセンによる詳細な解説があがる予定。
isukit
Itamae でまとめあげられたプロビジョニングキット。
ISUCON 8 で OS が CentOS であることが告知されたとき、慣れない OS でハマって事故死するよりは、ということでちょっとしたものを準備した。
これが割と便利だったので、今回は Itamae でいい感じになった。
isumon の各種ダッシュ ボードを含め、Slack とか Issue で夢を語っていたら @s4ichi パイセンがどんどん実装してくれて最高だった。
dotisu / 通称「実家」
我々のチームはすべてのコードの編集を本番サーバーで行う (ISUCON 7 , ISUCON 8 ) 。
この「サーバーサイドプログラミング」スタイルにおいては、快適なターミナル環境を整えることはチームの生産性、ひいてはスコアに直結する。
しかしながら、1台のサーバーを共有しているがため、張っている alias や $PS1 が衝突して困るという問題もまたあり、昨年までは自分が割を食うという形で解決した。多分。
今年は自分の zshrc に寄せたものを作って素振りに持ち込んだところ、まあまあ強めの反発を食らってしまった。残念。
しかし我々はエンジニアなので、エンジニアリング™で解決することができ、これがその結果当日持ち込まれた ~/.zshrc 。
if [[ -n ${WATASHI} ]]; then
source ${HOME}/dotisu/${WATASHI}.zshrc
fi
SSH 越しに WATASHI 環境変数 を送ると自分の zshrc が読み込まれる、という体験は大変好評で、「実家」「これじゃないと作業できない」「これだよこれ」などの喜びの声が聞かれた。
UNIX ユーザーの概念は、まだない。
メンバー3人それぞれに対応する WATASHI 環境変数 をつけて ssh している様子。それぞれに対応する zshrc が自動で読み込まれている。
mamiya.sh （デプロイスクリプト ）
ソレイユ的にはおなじみ、デプロイスクリプト であるところの mamiya.sh *2 。
1台目で実行すると、2, 3台目に rsync でいい感じにファイルを撒いてくれて、全台でsystemd restart も行ってくれる便利なやつである。
本番中に書いても別に良いのだけれど、やっぱり事前に作ったやつを持ち込むのが精神的にも時間的にも楽。
ISUCON 8 予選で使ったバージョンの出来がそれなりに良かったため、ほぼそのまま itamae に投入。
MySQL 8 へのアップグレード練習GA を迎える前から ISUCON でなんとか使おうとして、ビルド失敗、datadir 読めない、アプリからつながらない、と様々な失敗で時間を溶かした苦い思い出しかない MySQL 8 氏。
通算3度目の挑戦では、今回は確実なアップグレードを果たすために my.cnf を整えて準備し、叩くだけで MySQL 8 が入る itamae の cookbook も持ち込んだ。
default-authentication-plugin = mysql_native_password はだいじ！
MySQL 5.x の purge や新しい libmysqlclient を使うように mysql2 gem を再ビルドする必要があるなど、地味なハマりポイントが多いので手順書としてまとめておいた。
結果としては本番中に10分足らずで 5.7 を置き換えることができ、大成功であった。
MySQL 8.0 にしたことがどれほどスコアに直接響いたのかは計測していないのでわからないが、RDBMS に詳しい氏である @KOBA789 が MySQL 8.0 を散々褒めていたので良かったのであろう。
本番中に行ったチューニングについては @s4ichi の参加記 に詳しいので、そちらを見てください。
これは画像。
