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 / Scrubbing)        │  ← 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 하나로 카운팅되어 전체가 한꺼번에 차단됨
  → 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 마이그레이션 경로를 검토했는가