面接問題：突然のAPIトラフィック10倍スパイクでシステムをダウンさせないための対策

問題

How would you handle a sudden 10x spike in API traffic without your system going down?

解答

10倍スパイクへの対応は 事前設計（防ぐ）と 緊急対応（受け流す）の両軸で考える。

事前設計：スパイクが来ても壊れない仕組み

1. Auto Scaling（自動スケーリング）
   → CPU/リクエスト数が閾値を超えたらサーバーを自動追加
   → AWS: ALB + ECS Auto Scaling / EKS HPA
   → 起動時間: EC2(数分) < コンテナ(数秒)

2. キャッシュ層（最大の効果）
   → Redis/Memcached でよく読まれるデータをメモリキャッシュ
   → CDN で静的コンテンツ・API レスポンスをエッジキャッシュ
   → Cache Hit Rate 90% なら DB のリクエストを 10分の1 に削減

3. Rate Limiting
   → 異常なリクエスト（ボット・DDoS）をエッジで弾く
   → 1ユーザーあたりの上限を設定して公平性を保つ

4. 非同期処理
   → 即座に返せるものと時間がかかるものを分離
   → 重い処理は Queue（SQS/Kafka）に逃がして Worker が非同期処理

緊急対応：スパイク発生時のトリアージ

Step 1: 計測（何が詰まっているか）
  → モニタリング（Datadog/CloudWatch）でボトルネック特定
  → DB コネクション枯渇？ CPU？ 外部 API の応答待ち？

Step 2: 即時対処
  → コンテナ・インスタンスを手動でスケールアウト
  → Read Replica に読み取りトラフィックを逃がす
  → キャッシュの TTL を一時的に伸ばす
  → 重要でない機能を一時的に無効化（機能フラグ）

Step 3: Circuit Breaker
  → 外部サービスが詰まったら早期に失敗を返す
  → Cascading Failure を防ぐ

アーキテクチャ例

            [CDN]
              ↓
Client → [Load Balancer] → [API Servers (auto-scale)]
                                    ↓
                            [Redis Cache] → [DB Read Replica]
                                    ↓
                            [Message Queue] → [Worker]
                                                 ↓
                                          [DB Write Primary]

面接でのポイント

• 事前設計（普段から対応できる設計）と緊急対応を区別して話す
• キャッシュが最も効果的な対策であることを強調
• 数値感覚を示す：「キャッシュヒット率90%で DB リクエストを10分の1に」
• 「まずモニタリングで状況を把握してから対処する」姿勢を示す