API負荷試験の事前調査結果と試験計画をドキュメント化する

[taminororo]

背景

45th は9月前半の技大祭本番で稼働し、8月中に引き継ぎを完了させる必要がある。本番投入前に API がアクセス集中に耐えられるかを確認する負荷試験を計画しており、その前段として API の実コード調査と試験計画の設計を行った。調査結果と試験計画（ドラフト・未実行）を docs/development/load-test-plan.md として追加する。

文書に含まれる内容

• 全74エンドポイントの棚卸し（controller/usecase の対応、認証要否、呼び出し元の実態）。認証チェックは次の3箇所のみであることを網羅確認済み

// api/lib/internals/controller/mail_auth_controller.go:68  (WebSignOut)
// api/lib/internals/controller/mail_auth_controller.go:78  (WebIsSignIn)
// api/lib/internals/controller/user_controller.go:97       (GetCurrentUser)
accessToken := c.Request().Header["Access-Token"][0]

• rescues 統一/個別エンドポイント並存の実態確定（移行途中ではなく「作成・閲覧=統一（mobile）、ステータス更新=個別 PUT（GAS）」の分業。個別系の残り17ルートはデッド）
• 本番構成の整理と「共有 Patroni クラスタに向けた試験は実施せず、隔離DBのみで試験する」方針の技術的根拠（DB接続プール上限未設定を含む）
• 技大祭当日の実利用に基づく負荷シナリオ（朝の一斉アクセス／日中定常／GASバッチ併走）と優先度
• k6 による段階昇圧（50→600 VU）、p95/p99 の pass/fail 基準、内部直結（Track A）vs 検証用トンネル経由（Track B）の切り分け設計
• 試験実行・事前修正・別トラック対策の後続 issue 提案

完了条件

• docs/development/load-test-plan.md が develop にマージされる
• 試験の実行そのものは本 issue のスコープ外（文書内の提案に基づき別 issue を起票して行う）

[taminororo]

SeeFT-stg実測結果について

インフラ班がSeeFT-stg環境（共有DB基盤上に作成した専用DB seeft_load_db）でシナリオ①（GET /shift-cards）の再試験を実施しました。詳細な実測結果はNotion側に記録するため、ここには要点のみ残します。

• シフトデータの分布を現実的な形（1日50件→date_id 1〜4に12件ずつ）に修正
• pgbouncer導入により500エラー率が大幅改善（400人負荷で3.0%→0%）
• N+1修正（PR fix: shift-cardsのGetUsersByShift呼び出し回数を削減しN+1を解消 #438）は、pgbouncer導入後もなお独立して効果あり（400人負荷で150.36→196.80 req/s、平均応答2.40秒→0.61秒）

確認事項: 本試験は2.4節が明示的に避けるべきとした共有DB基盤に対して実施されており、隔離DB環境の整備方針からは外れています。今後のTrack A/B試験（issue 3・4）着手前に、隔離DB環境の整備を完了させるか、共有基盤を使う場合の例外承認・資源監視のルールをMTで確認する必要があります。

詳細な実測表・分析はNotionを参照してください（リンクは追記予定）。