📝
ISUCON公開パフォーマンスチューニング！ イベントレポート
オープニング – “作業机の上” をそのまま配信した90分
2025 年 5 月 27 日、オンラインで開催された 「ISUCON公開パフォーマンスチューニング！fujiwara氏&そーだい氏ログ取得〜N+1まで全部見」 は、タイトル通り“全部見せ”の濃密な90 分でした。 モデレーターは株式会社 overflow CTO の大谷旅人さん、そしてステージに立ったのは ISUCON4 度優勝の fujiwara さんと、PostgreSQL コミュニティを牽引する そーだい さん。 画面共有は開始直後から VS Code と top コマンド、そして MySQL へのログインプロンプト。余計なスライドは一切なく、「現場そのもの」を覗き込む体験が始まりました。
1. まずは“土俵”を読む – マニュアル精読の鉄則
マニュアルは仕様と競技規約の二段構えISUCON14 の問題は「自動運転イスによる配車サービス」。登壇者はマニュアルを読み進めながら「スコア算出ロジック」「データ初期化方法」「使用可能言語切り替え」の節を声に出して確認。 特に fujiwara さんが強調したのは 初期化手順の把握。「データを壊して戻せなくなると、8 時間が灰になる」——ISUCON常連らしい重みのある注意でした。
仕様書は“外部設計”として読むルールを読み終えたらブラウザで動作確認。位置情報は緯度経度ではなく盤目座標、ユーザー評価が売上とスコアを左右する——仕様書に書かれた一文一文がそのままチューニングのヒントになることを、デモ中に何度も思い知らされます。
2. 初期スコア測定と “三種の神器” のセットアップ
ベンチマーカー実行別ホストからベンチを流し、初期スコア 952pt を記録。
top画面の CPU 使用率は MySQL が 160 % を常時占有。ALP で Nginx アクセスログを集計まずアクセスログを JSON フォーマットに変更し、ALP を投入。呼ばれまくっていたのは
/api/chair/notification。1 リクエストあたりの平均は 112 ms と軽めだが、呼び出し数が圧倒的で合計待ち時間がトップに。MySQL Performance Schemaテーブル別 I/O とステートメント統計を即席ビューにリプレースし、「ライド」と「ライドステータス」テーブルが読み取り回数ダントツであることを可視化。
ここまでの準備を 「午前中の 2 時間で終わらせたい」 というのが二人の共通見解でした。
3. インデックスで一気に 2,800 pt へ
ライドテーブルクエリ：
SELECT * FROM ride WHERE chair_id = ? ORDER BY updated_at DESC LIMIT 1;→chair_id, updated_at DESCの複合インデックスを追加。ライドステータステーブルクエリ：
SELECT * FROM ride_status WHERE ride_id = ? ORDER BY created_at DESC LIMIT 1;→ride_id, created_at DESCインデックスを追加。
再ベンチの結果、スコアは 1200 → 2800pt。top 上では MySQL が 180 % から 160 % 程度へ低下し、アプリケーション側プロセスが CPU を使える余地が増えたことが数字にも表れます。
4. N+1 解消――“呼ばせない” 選択肢
大量アクセスの次に現れたボトルネックは N+1 クエリ。 GetLatestRideStatus() をループ内で呼ぶ設計を読み解き、「評価が付くのは完了済みライドだけ」というドメイン知識を利用して以下の改修を実施。
// Before
for _, r := range rides {
st := GetLatestRideStatus(ctx, r.ID)
if st.Status != "completed" { continue }
// ...
}
// After
for _, r := range rides {
if r.Evaluation == nil { continue } // 完了ライドのみ処理
total += *r.Evaluation
}追加クエリをゼロに抑えたことで MySQL の I/O はさらに減少。ただしスコアは 2800 → 2600pt と一時的に下降。「速くしただけではスコアは伸びない」という ISUCON らしい落とし穴を体現する瞬間でした。
5. ドメインロジックに踏み込む – マッチングアルゴリズム改良
スコア低下の原因は 利用者の不満率。 /internal/matching エンドポイントは 500 ms ごとに 1 件しか割り当てを行わず、待機行列が解消されないまま利用者が離脱していたのです。
リミット解除と一括処理
LIMIT 1を外し、オープンなライドを全件取得ループで椅子を次々にアサインし、まとめてコミット
500 ms 毎に “まとめて捌く” 方式に変更すると不満率は 76 % → 33 % に急落。並列トラフィックは増えるが、先に施したインデックス最適化が効いて MySQL は安定稼働。
最終スコア追加のインデックスを数本張り、ベンチ 3 回。結果は 3,500pt に到達。 これでも決勝ラインには届かないが、「4000pt 台へはインデックス貼り切れないと無理」というリアルな相場感を共有してくれました。
6. Q&A ハイライト – トッププレイヤーの“行間”
質問 | fujiwara さん / そーだい さんの回答 |
|---|---|
本番で最優先する作業は？ | 「初期化手順を一度通して “壊しても戻せる” ことを確認する」 |
PostgreSQL に移行した理由は？ | そーだい「縛りプレイもあるが『MySQL じゃないと勝てない』思い込みを壊したかった」 |
マニュアルは何回読む？ | fujiwara「詰まるたびに戻る。ヒントは必ず仕様書にある」 |
準備に使うツール | ALP / Performance Schema / Slow Query Log / 再起動スクリプトは“即書ける”状態にしておく |
残り1時間あれば？ | 「巨大集計クエリ（観光名所）を潰し、マッチングにさらに手を入れて 1 万点狙う」 |
7. DevRel 視点で見えた“持ち帰れる技術”
ログ→ボトルネック→改善 のサイクルを “自動化スクリプト” で最短化
ドメイン理解がチューニングの鍵。コードより先に仕様を疑う習慣が成果を分ける
ALP や Performance Schema の “視える化” は実務チームの共通言語になる
「速くすれば勝てるわけではない」——サービス指標と技術指標を結び付ける思考
総括 – 現場で効く“筋肉痛”を味わおう
ISUCON のチューニングは、単なる性能改善にとどまらず 「ユーザー体験を数値で計り、改善策をコードで示す」 という総合競技です。 今回の公開デモは、トップ層が
競技環境を最速で“自分の作業机”に変える
ログと統計で事実を掴む
ドメインを理解して “仕様から逆算” する
——この三段歩法を息をするように繰り返していることを教えてくれました。
感想：伸びしろを数値で感じる90分
ふたりがスクリプトを叩くたびにスコアが跳ね、ミスをすれば下がる。その起伏をリアルタイムで眺めるうちに、「改善余地＝伸びしろ」が数字として迫ってくる感覚を味わいました。 ISUCON は“筋トレ”に例えられることがあります。今回のデモはまさに、トップアスリートのセットメニューを間近で見せてもらった時間でした。
次にコンソールを開くとき、私たちはきっと 少しだけ重いウェイトを持ち上げられる──そう確信できる、実務直結型のイベントでした。
Yardでは、AI・テック領域に特化したスポットコンサル サービスを提供しています。
興味がある方は、初回の無料スポットコンサルをお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...