Ingress のレートリミットと DDoS 緩和: ingress-nginx から Gateway API までの実践ガイド

[トークンバケット]                    [リーキーバケット]

 補充レート r ──> ( バケット容量 b )    リクエスト ──> ( キュー容量 b ) ──> 流出レート r ──> 処理
              │                                  │
   リクエスト到着時にトークン 1 個消費    キューが満杯ならリクエスト破棄(drop)
   トークンがなければ拒否(reject)        一定速度でのみ流出する

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: auth-ingress
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/limit-rps: "5"
    nginx.ingress.kubernetes.io/limit-burst-multiplier: "2"
    nginx.ingress.kubernetes.io/limit-connections: "10"
    # 信頼できる内部レンジは制限から除外
    nginx.ingress.kubernetes.io/limit-whitelist: "10.0.0.0/8,192.168.0.0/16"
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /auth/login
            pathType: Prefix
            backend:
              service:
                name: auth-service
                port:
                  number: 8080

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  # 信頼するプロキシレンジ(例: クラウド LB の CIDR)
  proxy-real-ip-cidr: "130.211.0.0/22,35.191.0.0/16"
  use-forwarded-headers: "true"
  compute-full-forwarded-for: "true"

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  limit-rate: "0"                 # レスポンス帯域制限(バイト/秒)、0 は無制限
  limit-req-status-code: "429"    # デフォルトの 503 の代わりに 429 Too Many Requests を返す
  limit-conn-status-code: "429"

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: api-ratelimit
  namespace: production
spec:
  rateLimit:
    average: 100      # 平均毎秒 100 リクエスト
    burst: 50         # 瞬間 50 バーストを許容
    period: 1s
    sourceCriterion:
      ipStrategy:
        depth: 1      # X-Forwarded-For の末尾から 1 番目の IP を使う

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limiting-redis
  namespace: production
plugin: rate-limiting
config:
  minute: 60
  policy: redis
  redis_host: redis.production.svc.cluster.local
  redis_port: 6379
  fault_tolerant: true

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: api-route
  namespace: production
spec:
  http:
    - name: limited
      match:
        hosts:
          - api.example.com
        paths:
          - /api/*
      backends:
        - serviceName: api-service
          servicePort: 8080
      plugins:
        - name: limit-count
          enable: true
          config:
            count: 200
            time_window: 60
            rejected_code: 429
            policy: redis
            redis_host: redis.production.svc.cluster.local
            redis_port: 6379

                          [ クライアントトラフィック ]
                                  │
                ┌─────────────────┼─────────────────┐
                ▼                 ▼                 ▼
        ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
        │ ingress pod1 │  │ ingress pod2 │  │ ingress pod3 │
        │ メモリカウンター│  │ メモリカウンター│  │ メモリカウンター│
        │  上限 100      │  │  上限 100      │  │  上限 100      │
        └──────────────┘  └──────────────┘  └──────────────┘

  意図した上限: 100 RPS   →   実際の許容: 最大 300 RPS (ポッド数 x 100)

- アトミックカウント: INCR + EXPIRE または Lua スクリプトで race condition を排除
- fault tolerant モード: Redis 障害時にリクエストを止めるか(fail-closed)通すか(fail-open)決める
- キー有効期限: ウィンドウ単位でキーが正確に失効するようスライディング/固定ウィンドウを選択
- レイテンシ予算: Redis 往復が p99 レイテンシに与える影響を計測

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: partner-api
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/limit-rps: "20"
    # ホワイトリストレンジはレートリミットを回避
    nginx.ingress.kubernetes.io/limit-whitelist: "203.0.113.0/24,198.51.100.10/32"
spec:
  ingressClassName: nginx
  rules:
    - host: partner.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: partner-service
                port:
                  number: 80

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  use-geoip2: "true"
  # 特定の国だけ許可または遮断するポリシーは server-snippet で記述

[インターネット]
   │
   ▼
┌──────────────────────────────────────────────┐
│  クラウドエッジ (CDN / Anycast / スクラビング)    │  <- L3/L4 ボリューメトリック防御
│  - SYN フラッド、UDP アンプ、大容量パケットを吸収    │     (AWS Shield, Cloud Armor など)
└──────────────────────────────────────────────┘
   │  (正常に近いトラフィックのみ通過)
   ▼
┌──────────────────────────────────────────────┐
│  Ingress 層 (ingress-nginx / Gateway)          │  <- L7 アプリケーション防御
│  - エンドポイント別 RPS、コネクション制限、WAF ルール │     (レートリミット、ボット遮断)
└──────────────────────────────────────────────┘
   │
   ▼
┌──────────────────────────────────────────────┐
│  アプリケーション (サービス/ポッド)                │  <- ビジネスロジッククォータ
│  - ユーザー別クォータ、冪等性、サーキットブレーカー    │
└──────────────────────────────────────────────┘

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  client-header-timeout: "10"
  client-body-timeout: "10"
  keep-alive-requests: "100"
  worker-shutdown-timeout: "30s"

[ボット識別シグナル]
  - User-Agent の欠落または異常なパターン
  - クッキー/セッションを維持しないステートレスな繰り返しリクエスト
  - JavaScript チャレンジを通過できない
  - TLS フィンガープリント(JA3/JA4)が既知のボットツールと一致
  - 異常に均一なリクエスト間隔(人間にはジッターがある)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: bot-protect
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/server-snippet: |
      if ($http_user_agent = "") {
        return 403;
      }
      if ($http_user_agent ~* "(curl|wget|python-requests|scrapy)") {
        return 403;
      }
spec:
  ingressClassName: nginx
  rules:
    - host: www.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

# hey で同時 200、合計 20000 リクエストを発射
hey -z 30s -c 200 https://api.example.com/api/items

# 拒否率を確認するためレスポンスコード分布を集計
hey -z 30s -c 500 https://api.example.com/auth/login \
  | grep -A20 "Status code distribution"

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: production
spec:
  parentRefs:
    - name: prod-gateway
  hostnames:
    - api.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080

[観測指標]
  - 429/503 レスポンス比率(全体に対する)
  - 拒否されたリクエストの IP/パス/User-Agent 分布
  - バックエンドの p50/p95/p99 レイテンシ変化
  - Ingress ポッドの CPU/メモリ/コネクション数
  - upstream 5xx 比率(上限が効果的か判断)

1. 観測モード: 上限を非常に高く設定し拒否なしでメトリクスのみ収集
2. ベースライン把握: 普段のピーク RPS、p99、正常なバーストパターンを分析
3. 保守的な適用: 普段のピークの 3〜5 倍を上限に設定
4. 漸進的な強化: 拒否率とユーザー影響を見ながら上限を調整
5. エンドポイント差別化: ログイン/決済は厳格、静的参照は緩く

[落とし穴 1] X-Forwarded-For 未設定
  → すべてのリクエストが LB の IP 1 つにカウントされ全体が一斉に遮断される
  → proxy-real-ip-cidr と use-forwarded-headers を必ず併せて設定

[落とし穴 2] per-pod カウントをグローバルと誤解
  → 上限 100 なのにポッド 3 個で実際は 300 まで許容される
  → レプリカ数で割って設定するか中央カウンター(Redis)を導入

[落とし穴 3] ヘルスチェック/プローブがレートリミットに引っかかる
  → kubelet プローブやモニタリングが 429 を受けてポッドが落ちる
  → 内部レンジを whitelist に追加

[落とし穴 4] 拒否コードを 503 のまま放置
  → クライアントがサーバー障害と誤認し無限リトライ → 悪循環
  → 429 + Retry-After でバックオフを誘導

[落とし穴 5] L7 でボリューメトリックを防ごうとする
  → パケットがノードまで入り NIC/conntrack が先に飽和
  → ボリューメトリックはクラウドエッジで吸収

[落とし穴 6] 上限を低く設定しすぎる
  → 正常ピークでも 429 が発生しユーザー離脱
  → 観測モードでベースラインからまず計測

# Ingress コントローラーのログから limiting 関連メッセージを確認
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller | grep -i limit

# 実際に適用された nginx 設定を確認(生成された limit_req ゾーンを検証)
kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- \
  cat /etc/nginx/nginx.conf | grep -A3 limit_req_zone

# 特定 IP から見えるレスポンスコード分布を素早く点検
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/auth/login
done | sort | uniq -c

[ ] エンドポイント別に上限を差別化して設定したか(ログイン厳格、参照緩く)
[ ] X-Forwarded-For 信頼レンジ(proxy-real-ip-cidr)を正確に指定したか
[ ] 拒否レスポンスを 429 + Retry-After に設定したか
[ ] ヘルスチェック/モニタリング/内部レンジを whitelist に入れたか
[ ] per-pod vs Redis カウント方式を意図どおり選択したか
[ ] レプリカ数変動(HPA)がグローバル上限に与える影響を考慮したか
[ ] L3/L4 ボリューメトリック防御をクラウドエッジに配置したか
[ ] slowloris 対策にタイムアウトを短く設定したか
[ ] 429/503 比率とバックエンドレイテンシをダッシュボードで観測中か
[ ] 負荷テストで上限の動作を事前検証したか
[ ] Gateway API マイグレーション経路を検討したか