[Infra Ops] 트래픽 제어와 이벤트 기반 연계 구조

# /etc/nginx/nginx.conf 또는 /etc/nginx/conf.d/rate-limit.conf

http {
    # -- Rate Limit Zone 정의 --
    # $binary_remote_addr: 클라이언트 IP (바이너리 형식, 메모리 절약)
    # zone=api_limit:10m: 'api_limit'이란 이름, 10MB 공유 메모리 (약 16만 IP 저장 가능)
    # rate=10r/s: 초당 10개 요청 허용
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

    # 로그인 같은 민감한 엔드포인트는 더 엄격하게
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;

    server {
        listen 80;

        # -- API 엔드포인트에 Rate Limiting 적용 --
        location /api/ {
            # burst=20: 순간적으로 20개까지 큐에 대기 허용
            # nodelay: 큐 대기 없이 즉시 처리 (burst 초과분은 429)
            limit_req zone=api_limit burst=20 nodelay;
            limit_req_status 429;     # 초과 시 반환할 상태 코드

            proxy_pass http://backend;
        }

        # 로그인은 더 엄격하게
        location /api/login {
            limit_req zone=login_limit burst=3 nodelay;
            limit_req_status 429;
            proxy_pass http://backend;
        }

        # Rate Limit 초과 응답 커스터마이징
        error_page 429 @rate_limit_exceeded;
        location @rate_limit_exceeded {
            default_type application/json;
            return 429 '{"error":"too_many_requests","message":"요청 한도를 초과했습니다. 잠시 후 다시 시도하세요.","retry_after":1}';
        }
    }
}

import time
import requests

def call_api_with_retry(url, max_retries=5):
    for attempt in range(max_retries):
        try:
            response = requests.get(url, timeout=10)

            if response.status_code == 429:
                # Retry-After 헤더가 있으면 그 시간만큼 대기
                retry_after = int(response.headers.get('Retry-After', 0))
                wait_time = retry_after if retry_after > 0 else (2 ** attempt)
                print(f"Rate limited. Waiting {wait_time}s (attempt {attempt + 1})")
                time.sleep(wait_time)
                continue

            return response

        except requests.exceptions.Timeout:
            wait_time = 2 ** attempt  # 1, 2, 4, 8, 16초
            print(f"Timeout. Waiting {wait_time}s (attempt {attempt + 1})")
            time.sleep(wait_time)

    raise Exception(f"API 호출 실패: {max_retries}회 재시도 초과")

// webhook 수신 핸들러
const processedEvents = new Set();  // 실제로는 Redis나 DB 사용

app.post('/webhook/payment', async (req, res) => {
    // 1. 즉시 200 OK 응답 (2초 제한 준수)
    res.status(200).json({ received: true });

    // 2. 이후 비동기로 실제 처리
    const eventId = req.headers['x-event-id'] || req.body.event_id;

    // 3. 중복 체크 (멱등성)
    if (processedEvents.has(eventId)) {
        console.log(`중복 이벤트 무시: ${eventId}`);
        return;
    }

    // 4. 서명 검증 (발신측에서 제공하는 시크릿 사용)
    const signature = req.headers['x-webhook-signature'];
    const expectedSig = hmac('sha256', process.env.WEBHOOK_SECRET, JSON.stringify(req.body));
    if (signature !== expectedSig) {
        console.error('서명 불일치 — 위조 요청 차단');
        return;
    }

    // 5. 처리 완료 기록
    processedEvents.add(eventId);

    // 6. 실제 비즈니스 로직 (비동기)
    await processPaymentComplete(req.body);
});

[결제사]  POST /webhook/payment   (X-Signature · X-Event-ID · JSON)
   │
   ① 수신        게이트웨이가 POST 접수 → 원문(raw body) 그대로 보존
   │              → 파싱·재직렬화 전에 보존해야 서명이 맞음
   │
   ② 서명 검증    같은 시크릿으로 raw body에 HMAC 재계산 → 상수시간 비교
   │              불일치 → 위조로 보고 거부(4xx), 이후 단계 안 감
   │
   ③ 재전송·멱등  타임스탬프 허용오차(±N분) 확인 + 이벤트 ID 중복 조회
   │              이미 처리한 ID → 처리 건너뛰고 곧장 2xx
   │
   ④ 큐 적재      검증 통과분을 메시지 큐에 넣음 (무거운 처리 분리)
   │
   ⑤ ACK         2초 안에 2xx 반환 → 발신측 타임아웃·재전송 차단
   ▼
   ⑥ 비동기 처리  워커가 핸들러 실행 → 성공 시 이벤트 ID 저장(멱등 확정)
[내부 처리 완료]