■ ボトルネックマップ（リトルの法則で分析）

1. CDN層: CloudFront → 問題なし（Cache Hit Rate 85%）
2. Web層: 20タスク × 100同時接続 / 50ms = 40,000 RPS → 余裕あり
3. API層: 15タスク × 50同時接続 / 80ms = 9,375 RPS → 余裕あり
4. DB層: コネクション500 / 15ms = 33,333 QPS → 余裕があるように見えるが
   → CPU 75%で実質半分以下。重いクエリが原因
   → ★ ボトルネック #1: 未最適化クエリ
5. Redis: Hit Rate 62% → 38%がDBに到達
   → ★ ボトルネック #2: キャッシュ戦略の不備
6. OpenSearch: 検索クエリ p95 800ms → インデックス最適化必要
7. フロントエンド: LCP 5.8s, バンドル1.5MB
   → ★ ボトルネック #3: フロントエンド未最適化

改善優先順位:
1. DBクエリ最適化 + キャッシュ改善 → p95を1.8s→500msに
2. フロントエンド最適化 → LCPを5.8s→2.5s以下に
3. セール対策のスケーリング計画

改善ポイント:
1. 商品詳細のTTLが短すぎた（30秒→5分に延長）
2. カテゴリ一覧がキャッシュされていなかった
3. 人気検索クエリのキャッシュ追加（全体の60%のトラフィック）
4. TTLにジッター追加（±20%）でサンダリングハード防止

期待効果: Hit Rate 62% → 92%
DB QPS: 現在の38%がキャッシュヒットで8%に → DB負荷75%減

■ セール想定トラフィック
通常ピーク: 30,000 RPS
セールピーク: 90,000 RPS（3倍を想定）
フラッシュセール（瞬間最大）: 150,000 RPS（5倍）

■ 負荷テスト計画
Phase 1（1ヶ月前）: ベースライン測定
  - 現状の限界点を特定（Break Point Test）
  - 各レイヤーの飽和点を測定

Phase 2（3週間前）: 最適化後の検証
  - DB最適化・キャッシュ改善後のパフォーマンス確認
  - 目標: p95 500ms で 50,000 RPS 達成

Phase 3（2週間前）: セール想定テスト
  - 90,000 RPS の定常負荷テスト（30分）
  - 150,000 RPS のスパイクテスト（5分間）

Phase 4（1週間前）: Soak Test
  - 50,000 RPS × 4時間の耐久テスト
  - メモリリーク、コネクション枯渇の検証

■ スケーリング計画
Web: 20 → 60タスク（事前スケール）
API: 15 → 45タスク
DB: r6g.4xlarge にスケールアップ + Read Replica 2→4台
Redis: 3→6ノードにスケールアウト
CDN: キャッシュTTL延長（セール期間中）

■ オートスケーリング
- 事前スケール: セール開始1時間前にmin instancesを引き上げ
- 動的スケール: CPU 60%超過で追加スケールアウト
- max instances: Web 100, API 80

実施スケジュール:
Week 1: P0施策（バンドル最適化 + 画像最適化） → スコア65想定
Week 2: P1施策（CSS/ISR/CLS修正） → スコア80想定
Week 3: P2施策 + 検証 → スコア90+想定