ISUCON のルールと戦い方
読了目安 約3分
競技の形式と 8 時間の使い方、チーム内での役割分担を押さえます。
この章の目次
ISUCON では、他人が書いたアプリを渡され、制限時間内に速くします。 まずルールと、当日の動き方の定石を押さえます。
細かいルールは開催年ごとに変わります。 参加するときは必ずその年のレギュレーションを読んでください。
競技の形式
ISUCON は、チーム最大 3 人、競技時間 8 時間で行われます。 各チームには同じお題の Web サービスが動くサーバーが渡されます。 この最初の実装を参照実装と呼び、正しく動きますが意図的に遅く作られています。
スコアを決めるのはベンチマーカーです。 ベンチマーカーは運営が用意した負荷試験プログラムで、アプリへ大量のリクエストを送り、一定時間内にどれだけ処理できたかをスコアにします。 競技中は何度でも実行でき、以後これを「ベンチを回す」と書きます。
順位を決めるのは、競技終了後に運営が行う最終計測のスコアです。 上位チームには再起動試験もあります。 サーバーを再起動してもサービスが正常に動き、データが失われず、スコアが再現することを確認する試験で、通らなければ失格です。
ベンチマーカーは、レスポンスの内容が正しいかも検査します（投稿が一覧に出るか、他人のデータが見えていないか）。 速いが間違っているアプリは、エラーとして弾かれます。
8 時間の使い方
時間の使い方には定石があります。
- 最初の 1 時間：改善に手を付けない。コードを読んで全体像をつかみ、Git 管理下に置き、何も変えずにベンチを回して初期スコアを記録する
- 中盤の 6 時間：計測して、いちばん遅いところを 1 つ直して、ベンチを回す。このループは次章から Part 6 全体で練習する
- 最後の 1 時間：新しい変更は入れない。再起動してもサービスが動くことを確認し、最後のベンチを回して終わる
初期スコアは、以後の改善の効果を測る基準線です。 再起動試験があるので、「動いている状態を最終計測まで保つ」こと自体が得点行動です。
役割分担
分担には典型的な形があります。
- インフラ担当：サーバーやミドルウェアの設定、計測ツールの導入、デプロイの整備
- アプリ担当：Go コードの改善（N+1 の解消、キャッシュなど）
- SQL と計測の担当：計測結果の読み解き、スロークエリの特定、インデックス
Part 1 から Part 5 で身につけたのは、アプリと SQL の 2 つです。 計測ツールのセットアップはインフラ担当に頼み、自分は出力を読んで意思決定します。
動くものを壊さない
改善は 1 つずつ入れて、そのたびにベンチを回します。 複数の変更をまとめて入れると、スコアが動いたときにどれが原因か切り分けられないからです。 テストを書く で練習した動作確認を、ISUCON ではベンチマーカーが兼ねます。
変更は Git でコミットしておき、スコアが下がったら前の状態に戻します。 チームで 1 つのコードベースを触るので、Git 超入門 を先に読んでおいてください。
次章から、この戦い方の中心にある「計測」を練習します。