대규모 트래픽 처리 가이드 – 로드밸런싱·CDN·캐싱·오토스케일링

[단일 서버 트래픽 한계 시뮬레이션]

서버 스펙: 4코어 CPU, 16GB RAM
평균 요청 처리 시간: 50ms
이론상 최대 TPS: 4 × (1000ms / 50ms) = 80 TPS

동시 접속 1,000명 → 초당 요청 500건 가정
→ 처리 가능 범위 초과 → 큐 적체 시작
→ 응답 지연 급증 → 타임아웃 발생
→ 서버 메모리 고갈 → OOM(Out of Memory) → 프로세스 종료 ❌

요청 순서:   1    2    3    4    5    6
배정 서버:  A    B    C    A    B    C

현재 상태:  서버A(10개 처리중) / 서버B(3개 처리중) / 서버C(7개 처리중)
새 요청 → 서버B 배정 (최소 연결)

# Nginx 로드밸런서 설정 예시
upstream backend {
    # 가중치 라운드 로빈: 고사양 서버에 더 많은 요청 배분
    server 10.0.0.1:8080 weight=5;   # 5/8 비율
    server 10.0.0.2:8080 weight=2;   # 2/8 비율
    server 10.0.0.3:8080 weight=1;   # 1/8 비율

    # 헬스체크: 2회 실패 시 서버 제외, 30초마다 복구 확인
    keepalive 32;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_connect_timeout 3s;
        proxy_read_timeout 10s;
    }
}

[L7 로드밸런서 콘텐츠 기반 라우팅]

/api/user/*    → 사용자 서비스 서버군
/api/order/*   → 주문 서비스 서버군
/api/payment/* → 결제 서비스 서버군 (별도 보안 구역)
/static/*      → CDN 또는 정적 파일 서버

[CDN 없는 경우: 서울 사용자가 미국 서버 접속]

사용자(서울) ─────────────────────► 원본 서버(미국)
                  왕복 지연: ~200ms

[CDN 있는 경우: 서울 사용자가 국내 엣지 서버 접속]

사용자(서울) ──► 엣지 서버(서울 CDN PoP) ──► 원본 서버(미국)
                  캐시 히트 시 왕복 지연: ~5ms      (최초 1회만)

// Spring Boot + Redis 캐싱 전략 예시
@Service
public class ProductService {

    private final RedisTemplate<String, Product> redisTemplate;
    private final ProductRepository productRepository;

    // 캐시 우선 조회 패턴 (Cache-Aside / Lazy Loading)
    public Product getProduct(Long productId) {
        String cacheKey = "product:" + productId;

        // 1. Redis에서 먼저 조회
        Product cached = redisTemplate.opsForValue().get(cacheKey);
        if (cached != null) {
            return cached;  // 캐시 히트: DB 조회 없이 즉시 반환
        }

        // 2. 캐시 미스: DB에서 조회
        Product product = productRepository.findById(productId)
            .orElseThrow(() -> new ProductNotFoundException(productId));

        // 3. Redis에 저장 (TTL 10분)
        redisTemplate.opsForValue().set(cacheKey, product,
            Duration.ofMinutes(10));

        return product;
    }

    // 상품 수정 시 캐시 무효화
    @CacheEvict(value = "product", key = "#productId")
    public void updateProduct(Long productId, ProductUpdateRequest req) {
        productRepository.updateProduct(productId, req);
    }
}

[수직 확장 (Scale Up)]
서버 1대:  2코어 → 8코어 → 32코어
           8GB  → 32GB → 256GB
장점: 구현 단순, 코드 변경 불필요
단점: 한계가 명확(물리적 최대치), 단일 장애 지점(SPOF)

[수평 확장 (Scale Out)]
서버 1대 → 서버 4대 → 서버 20대 (필요 시 즉시 추가)
장점: 이론상 무한 확장, 장애 격리
단점: 상태 공유 문제(세션), 분산 설계 필요

[오토스케일링 동작 시퀀스]

① 메트릭 수집 (CloudWatch / Prometheus)
   CPU 사용률 85% 초과 → 경보 발생

② 스케일아웃 정책 트리거
   "CPU 80% 초과 5분 지속 → 인스턴스 2대 추가"

③ 신규 인스턴스 프로비저닝 (30초~2분)
   AMI 이미지 기반 인스턴스 생성
   → 헬스체크 통과
   → 로드밸런서 타깃 그룹에 자동 등록

④ 트래픽 분산 재조정
   로드밸런서가 신규 인스턴스 포함 분산 시작

⑤ 트래픽 감소 시 스케일인
   CPU 20% 미만 10분 지속 → 인스턴스 1대 제거
   (드레이닝: 기존 연결 처리 완료 후 제거)

# HPA 설정 예시: CPU 기반 자동 파드 확장
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3      # 최소 파드 수 (항상 3개 유지)
  maxReplicas: 50     # 최대 파드 수 (트래픽 폭증 대비)
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70   # CPU 70% 초과 시 스케일아웃
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80   # 메모리 80% 초과 시 스케일아웃

[동기 처리 – 한 줄로 선 기차]

요청 1 → 처리 → 응답
요청 2 →  (대기)  → 처리 → 응답
요청 3 →  (대기)       → 처리 → 응답
트래픽 급증 시: 대기열 폭증 → 타임아웃 → 서버 다운

[비동기 처리 – 메시지 큐 도입]

요청 1 → 큐에 저장 → 즉시 응답("접수완료") → 워커가 나중에 처리
요청 2 → 큐에 저장 → 즉시 응답
요청 3 → 큐에 저장 → 즉시 응답
트래픽 급증 시: 큐가 쌓이지만 서버는 여유 있게 순차 처리

// Kafka Producer: 주문 이벤트 발행
@Service
public class OrderService {

    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public OrderResponse createOrder(OrderRequest request) {
        // 1. 주문 DB 저장 (빠른 처리)
        Order order = orderRepository.save(Order.from(request));

        // 2. 재고 차감·결제·알림은 Kafka로 비동기 처리
        OrderEvent event = OrderEvent.builder()
            .orderId(order.getId())
            .userId(request.getUserId())
            .items(request.getItems())
            .build();

        kafkaTemplate.send("order-created", event);  // 큐에 발행

        // 3. 즉시 응답 (처리 완료를 기다리지 않음)
        return OrderResponse.accepted(order.getId());
    }
}

// Kafka Consumer: 재고 서비스가 비동기로 재고 차감
@Component
public class InventoryConsumer {

    @KafkaListener(topics = "order-created", groupId = "inventory-group")
    public void handleOrderCreated(OrderEvent event) {
        inventoryService.decreaseStock(event.getItems());
        // 처리 완료 후 다음 메시지 처리 (백프레셔 자동 조절)
    }
}

[읽기/쓰기 분리 아키텍처]

        애플리케이션 서버
              │
    ┌─────────┴──────────┐
    ▼                    ▼
쓰기 요청             읽기 요청
(INSERT/UPDATE)       (SELECT)
    │                    │
    ▼                    ▼
Master DB  ──복제──► Replica DB 1
                  ──복제──► Replica DB 2
                  ──복제──► Replica DB 3

[사용자 ID 기반 해시 샤딩]

사용자 수: 1억 명 → 4개 샤드로 분산

userId % 4 == 0 → Shard A (DB 서버 1)  user_id: 0, 4, 8, 12...
userId % 4 == 1 → Shard B (DB 서버 2)  user_id: 1, 5, 9, 13...
userId % 4 == 2 → Shard C (DB 서버 3)  user_id: 2, 6, 10, 14...
userId % 4 == 3 → Shard D (DB 서버 4)  user_id: 3, 7, 11, 15...

각 DB: 2,500만 건씩 분산 → 단일 DB 대비 1/4 부하

// Resilience4j 서킷 브레이커 설정
@Component
public class PaymentServiceClient {

    @CircuitBreaker(
        name = "paymentService",
        fallbackMethod = "paymentFallback"
    )
    @TimeLimiter(name = "paymentService")  // 2초 타임아웃
    public CompletableFuture<PaymentResult> processPayment(PaymentRequest req) {
        return CompletableFuture.supplyAsync(
            () -> externalPaymentApi.process(req)
        );
    }

    // 서킷 열림 시 폴백: 사용자에게 대체 응답 제공
    private CompletableFuture<PaymentResult> paymentFallback(
            PaymentRequest req, Exception ex) {
        log.warn("결제 서비스 장애 - 폴백 실행: {}", ex.getMessage());
        return CompletableFuture.completedFuture(
            PaymentResult.pending("결제가 지연되고 있습니다. 잠시 후 확인해주세요.")
        );
    }
}

[서킷 브레이커 3가지 상태]

CLOSED (정상)
  → 요청 통과, 실패율 모니터링
  → 실패율 50% 초과, 5초 지속
       ↓
OPEN (차단)
  → 모든 요청 즉시 폴백 반환 (서비스 호출 안 함)
  → 10초 대기 후
       ↓
HALF-OPEN (탐색)
  → 요청 일부만 통과 (복구 테스트)
  → 성공 시 CLOSED 복귀 / 실패 시 OPEN 유지

# Redis를 활용한 슬라이딩 윈도우 레이트 리미터
import redis
import time

class RateLimiter:
    def __init__(self, redis_client, limit=100, window=60):
        self.redis = redis_client
        self.limit = limit      # 60초당 최대 100회
        self.window = window

    def is_allowed(self, user_id: str) -> bool:
        key = f"rate_limit:{user_id}"
        now = time.time()
        window_start = now - self.window

        pipe = self.redis.pipeline()
        # 오래된 요청 기록 제거
        pipe.zremrangebyscore(key, 0, window_start)
        # 현재 요청 추가
        pipe.zadd(key, {str(now): now})
        # 윈도우 내 요청 수 조회
        pipe.zcard(key)
        # 키 만료 설정
        pipe.expire(key, self.window)
        results = pipe.execute()

        request_count = results[2]
        return request_count <= self.limit