Load Test Perspective - bianchiidentity/isucon12 GitHub Wiki

負荷試験の観点

Home · アプリ全体の地図 · ベンチと改善時の制約 · 計測記録

利用者の一連の操作を、同時に増やしても正しく完了できるかを見る試験、と考える。 個々のAPIが速くても、CSV更新・閲覧・請求の結果が食い違えば改善として成立しない。

このページの根拠は公開マニュアル、アプリの仕様書、初回の実行ログのみ。 ベンチマーカーのソース・検証用JSON・内部アルゴリズムは参照しない。 ログで実際に見えたことと、そこから考える仮説を分ける。

利用者として考えると何を確かめたいか

sequenceDiagram
    participant A as SaaS管理者
    participant O as テナント管理者
    participant P as 参加者
    participant S as ISUPORTS
    A->>S: テナントを作る
    O->>S: 参加者と大会を作る
    O->>S: CSVで結果を登録・更新する
    P->>S: 大会一覧・戦績・ランキングを見る
    O->>S: 一部の参加者を失格にする
    P->>S: 失格後は参加者APIを利用できない
    O->>S: 大会を終了する
    O->>S: 終了後の入稿は拒否される
    O->>S: テナントの請求を見る
    A->>S: テナント横断の請求を見る

これは仕様から整理した操作の関係。内部でこの順番に1本ずつ実行する、と断定したものではない。

仕様から必ず守ること

観点 利用者から見た期待 改善で気をつけること
テナントの分離 自分の団体の情報を見る キャッシュキーにテナントを含め、別団体のデータを混ぜない
認証・権限 不正な認証を拒否し、役割で操作範囲を分ける 速くても認可を省略しない
入稿と閲覧 登録・更新した結果がランキングと戦績に現れる 最新CSV、重複行、同点順、ページングを保つ
失格 当人が参加者向けAPIを利用できなくなる 認可のキャッシュと状態変更の反映を確認
大会終了 以後は結果を入稿できず、請求に反映される 終了判定と集計を食い違わせない
初期化 毎回、期待される初期状態から始められる 追加したDB・キャッシュも初期化する
ブラウザー 静的画面とログインが動く ベンチ結果だけでblackauthやUIを削らない

CSVの重複・同点・請求の細部は アプリ仕様、 反映猶予の対象は ベンチと改善時の制約 を確認する。 3秒の猶予は指定された操作と参照先の組み合わせに限り、全更新を遅延させてよいという意味ではない。

初回ログから見えた3段階

対象：サーバー内の /home/isucon/bench-results/20261010-first.log。 UTC 2026-10-10、Go初期実装、同一サーバー実行、計測追加前、最終スコア1854・エラー0。

時刻 ログに出たこと 読み取れる範囲
04:18:40〜04:18:45 初期化200、実装言語go 起動ログから初期化成功まで約4.46秒。処理内部の時間内訳は不明
04:18:45〜04:19:03 整合性チェック開始・成功 今回のチェックは約18.07秒。何を網羅したかは個々のログで確認
04:19:03〜04:20:03 負荷走行開始・終了、参加者や大会の増加 60秒の走行中にも状態と負荷が増えた
04:20:04 PASSED: true、Error 0 (Critical:0)、SCORE: 1854 今回は成功。全ケース・全実行条件の正しさを保証する結果ではない

整合性チェックで観測できた内容

ログに出た操作・結果 確かめていると考えられること
有効期限切れ・不正RSA鍵・不正な認証方式のJWTで401 正しいログインと不正なログインを区別する
存在しないテナント・参加者で認証失敗 JWTだけで架空の団体・人として利用できない
不正なテナント作成で400、存在しない大会・参加者で404 受け付けてはいけない入力と存在確認
CSV列の順序違い・余計な列・存在しない参加者で400 形式と参照先の検証
CSV入稿と同時にランキング取得200 更新と閲覧が重なった場合の整合性を気にしている可能性
ページングあり・なし、最大100件のランキング取得 上限・順序・ページ境界
戦績取得、スコア未登録参加者のランキングアクセス 「スコアがない」状態でも成立する処理
失格済み参加者のランキング取得403 状態変更後の認可
大会終了後の入稿400、請求情報取得 終了に伴う操作制限と集計
初期データの請求確認、テナント請求の最大10件表示 初期値と一覧の整合性
index.html・JS・CSSの確認 APIだけでなく静的配信も維持する

この401・403・400・404は意図した失敗を確認するログであり、最終エラー数0と矛盾しない。 「入稿と同時に取得200」だけでは中間状態をどう検証したかは分からない。 本文に書かれていないチェックや、その厳密な判定式は推測で補わない。

初回のJS・CSSログには ._ で始まるファイル名も出ていた。 配信対象の選び方は不明だが、ログに現れた配信物を無確認で削ると互換性が変わる可能性がある。

負荷走行中のログから立てる仮説

観測 仮説 次に見るもの
大会作成と参加者増加のログが複数回出る 書き込みが読む側の負荷増加にも関係している可能性 入稿・作成と閲覧の時刻、APIごとの累積時間
参加者向けworker追加が6・13・12人などの単位で出る 今回の実行では並行する閲覧側が増えている 走行後半の待ち時間・CPU・DB使用率
人気テナントを示すラベルと新規テナント作成が出る 既存の重い団体と新しい団体の両方を扱う可能性 ホスト別のHTTP集計とテナント別データ量
管理者請求・テナント請求に関するログが出る 閲覧や登録だけ速くしても集計経路が残る可能性 請求API、SQL集計、同じ値の再計算

「速くなれば必ずこの条件で負荷が増える」「何人追加すれば何点」は、このログだけでは分からない。 負荷増加の内部条件、リトライ方針、乱数の分布、内部スコア変数の意味は未確認。 公開ログのシナリオ名をそのまま内部実装の仕様とは扱わない。

攻略の読み替え

参加者は返答を待ってから次の操作へ進むかもしれないし、独立して増えるかもしれない。 内部が見えない状況では、APIを速くした結果として何が変わったかを観測する。

改善の仮説 成功なら期待する観測 伸びなければ確認すること
ランキングを軽くする 同じ条件でランキングの時間が減り、成功処理が増える 閲覧記録・ロック・別APIが次の制約になっていないか
CSV入稿を軽くする 入稿時間と閲覧の待ちが減る 更新の整合性とCriticalエラーを維持できたか
請求の繰り返し計算を減らす 請求の累積時間やSQL負荷が減る キャッシュが古くないか、別経路へ負荷が移ったか

最初の一手は、同じ条件のベンチにCPU・HTTP・SQLの観測を重ねること。 どこを変更するかは アプリ全体の地図 の候補と計測を照らして決める。 負荷の正確な内部ルールを当てるより、利用者の操作全体を正しく軽くする。

根拠