問題の内容

今回の課題はBeReal風（？）SNSのISURealという画像投稿SNSサービスでした。最初は国内で流行るが、海外でバズり、世界コンテストを行うという流れの中、いかに大量トラフィックを裁くかが課題でした。

インフラ構成としては以下のEC2インスタンスが5台。

• リクエストを受け付けるルーター（固定）
• asia/europe/americaの3リージョンに分かれたアプリサーバ
• asiaに配置されたDBサーバ

ルーター以外のEC2インスタンンスについては役割などを自由に変えてOK。ただし、インスタンス間の通信は必ずルーターを跨ぎ、リージョン間の通信には片道50msのレイテンシが乗ります。

問題の解き方

あくまで私たちがどう解いたかという話。

最初の1時間はサービスがどういうものか理解を進める傍らで、基本的な改善をAIに任せていました。

しかし2万点ほどで伸び悩み、基本的な戦略だけじゃダメだと気付きます。

AIに生成させたHTMLレポートを見ていると、asiaユーザーが200程度なのに対し、europe/americaのユーザーが10人前後と極端に少ない。また、ベンチマーカーが模擬する6日間、asiaユーザーの数の伸びも頭打ち。 ISUCON開始時に見た紹介動画との乖離にメンバーが気付いてくれました。

ここでようやく、単に速くするのではなくユーザー体験が大事なのだと気付かされます。あまりにレスポンスが遅かったりするとユーザーが離脱したり、インフルエンサーがバズらせてくれなくてユーザーが増えないのです。

メトリクスを見る目的はUXの向上だよと、同僚が言ってたのを思い出しました（今回は別チームに所属）。これに気付ける会話ができたので、いいメンバーに恵まれたなと思います。

そこで、とにもかくにも頭打ちを避けるアーキテクチャの変更を行うことにしました。

• 11時頃: スコアの高いeurope/americaの体験を改善
  • スコア変化: 2万→3万
  • 実施内容: europe/americaのAPI処理をasiaに移動しapp <-> DBの複数回通信によるレイテンシを下げる
  • 補足: アプリサーバーのCPUが飽和するので、画像URLの署名などの重い処理の軽減がセットで必要
• 13時頃: 継続してeurope/americaの体験を改善
  • スコア変化: 3万→7万5千
  • 実施内容: 画像をasia DBではなく、europe/americaに直接保存
• 14時頃: 全域的なユーザー数の伸びを改善
  • スコア変化: 7万5千→11万
  • 実施内容: 投稿画像（JPEG）の検証がCPU負荷になっていたので簡略化

ここから先はグラフを見ても分かるとおり、軽微な改善の連続となってしまいました。伸びこそ11万→16万と大きいものの、4時間かけててタイパが悪い……。

敵が50万点超えてるんだから、もっと大胆なことが必要なのにね。それぞれの案の予想スコアくらい出させてから決めればよかったかなと思います。

europe/americaにリードモデルやリードレプリカを置く案もあったのですが、初期状態構築に最大30分くらいかかると言われてひよったのが悔やまれます。サンドボックス環境でのテスト結果だと、40万点の予想だったらしい……。 1位目指すなら、強行してみればよかった。

AIの使い方

atusyのClaude Codeをメインに、各々が追加でAIを使っていました。メイン以外の結果は必ずメインに引き継ぐスタイル。

メインではオーケストレーター・サブエージェントを以下のように構成していました。サブエージェントを積極的に使うことで、作業を止めずにオーケストレーターと会話できてよかったです。

• オーケストレーター(Claude Code のメイン)
  • 人間への即答、進捗報告、エージェントの起動と再配置を受け持つ。
  • 自分では重い作業をしない。
• アナリスト(サブエージェント、常時数体)
  • pprof・alp・pidstat・ベンチ結果からボトルネックを探し、Issue に起票する。
• Issue エージェント(サブエージェント、最大 10 体前後)
  • git worktree で並列実装し、PR を出す。
  • サンドボックス EC2 で独自負荷をかけ、予想スコアを PR に書く。
• ゲートキーパー(サブエージェント、1 体)
  • PR を rebase して本番に入れ、公式ベンチを回す。
  • 勝ったら merge し、スコアをコミットメッセージと runs/progress.log に残す。
• 再起動テスター(サブエージェント)
  • 最新の main で再起動試験をして、壊れていれば修正 PR を出す。
• レポーター(サブエージェント)
  • HTML レポート(Claude Artifact)に、アプリ概要・構成・ベンチ傾向を随時書き足す。
  • 効いた施策と効かなかった施策も記録する。

特にHTMLレポートはClaude Codeならメールアドレス指定で共有できるので、チーム内での情報共有に役立ちました。

また、実装の簡易ベンチマークや、再起動試験には多少のお金がかかるのを承知でAWSにサンドボックス環境を別途用意しました。ベンチマークのジョブキュー待ちや、再起動試験への頑健性担保を行って進められるのは精神衛生によかったです。

ENJOY!!

1位の人はAIに任せて1日を終えたそう。凄い。

Opus 5.5で1億トークンだか使ったそうですが、compaction 1回とのことで、たぶんサブスクの範囲内。ということは、現実にも検証方法さえ用意できていれば、AIに改善させられる余地は大きそう。

一方で、UXはレスポンスの速さだけで決まるものではないので、機能や画面もからめた改善という観点では今回のように意見をがんがん出すのは有効だろうなと思いました。そのとき、(a) 改善案を思いつくか、(b) AI-friendlyに言語化できるか、(c) チーム内で認識を合わせられるかが大事だと思います。特にb, cについてはISUCONがとてもよいトレーニングになるなと感じます。

社内でもやってみたいなー。