CDN과 로드밸런싱

const cdnArchitecture = {
  // POP (Point of Presence): 에지 서버가 배치된 물리적 위치
  pops: ["Seoul", "Tokyo", "Singapore", "Frankfurt", "Ashburn", "..."],

  // 에지 서버: 각 POP에 위치한 캐시 서버
  edgeServer: {
    role: "사용자에게 가장 가까운 응답 지점",
    cache: "오리진 응답을 로컬에 저장",
    ttl: "Cache-Control 헤더에 따라 캐시 유효 기간 결정",
  },

  // 오리진 서버: 실제 콘텐츠가 존재하는 원본 서버
  originServer: {
    role: "캐시 미스 시 콘텐츠를 제공",
    location: "특정 리전 (예: us-east-1)",
  },
};

// Unicast vs Anycast
const unicast = {
  ip: "93.184.216.34",
  location: "미국 동부 (단일 서버)",
  routing: "모든 사용자가 이 서버로 접속",
};

const anycast = {
  ip: "104.16.132.229", // Cloudflare 에지 서버
  locations: [
    "Seoul POP에서 이 IP를 BGP로 광고",
    "Tokyo POP에서 이 IP를 BGP로 광고",
    "Frankfurt POP에서 이 IP를 BGP로 광고",
    // ... 300+ POP
  ],
  routing: "BGP가 네트워크 홉 수 기준으로 가장 가까운 POP을 선택",
};

// 서울 사용자: 104.16.132.229 -> Seoul POP
// 베를린 사용자: 104.16.132.229 -> Frankfurt POP
// 같은 IP, 다른 물리적 서버

const cacheHierarchy = {
  // 1. Edge Cache: 사용자에게 가장 가까운 POP
  edge: {
    count: "300+ POP",
    hitRate: "대부분의 인기 콘텐츠는 여기서 해결",
    problem: "POP이 너무 많으면 각 POP의 캐시 히트율이 낮아짐",
  },

  // 2. Shield (Mid-tier Cache): 리전별 중간 캐시
  shield: {
    count: "10~20개 리전",
    role: "같은 리전의 에지 서버들이 오리진을 중복 호출하는 것을 방지",
    // 서울, 부산, 오사카 POP이 모두 Tokyo Shield를 거쳐 오리진에 접근
  },

  // 3. Origin: 원본 서버
  origin: {
    role: "Shield에서도 캐시 미스일 때만 접근",
    benefit: "에지 + 쉴드가 대부분의 트래픽을 흡수해 오리진 부하 최소화",
  },
};

const l4LoadBalancer = {
  layer: "Transport (TCP/UDP)",
  decisionBasis: ["소스 IP", "소스 포트", "목적지 IP", "목적지 포트"],

  // HTTP 헤더, URL, 쿠키 등은 볼 수 없음
  cannotSee: ["URL 경로", "Host 헤더", "쿠키", "HTTP 메서드"],

  pros: [
    "매우 빠름 (패킷 수준에서 처리, TLS 복호화 불필요)",
    "프로토콜에 무관하게 동작 (HTTP, WebSocket, gRPC, DB 등)",
    "높은 처리량 (수백만 동시 연결 가능)",
  ],

  cons: [
    "HTTP 내용 기반 라우팅 불가",
    "세밀한 트래픽 분배 어려움",
  ],

  examples: ["AWS NLB", "HAProxy (TCP 모드)", "IPVS (Linux 커널)"],
};

const l7LoadBalancer = {
  layer: "Application (HTTP/HTTPS)",
  decisionBasis: [
    "URL 경로 (/api/*, /static/*)",
    "Host 헤더 (api.example.com vs www.example.com)",
    "HTTP 메서드 (GET, POST)",
    "쿠키, 인증 토큰",
    "요청 본문 (content-based routing)",
  ],

  pros: [
    "콘텐츠 기반 라우팅 (마이크로서비스에 필수)",
    "URL 재작성, 헤더 조작 가능",
    "캐싱, 압축, WAF 등 부가 기능",
    "A/B 테스트, 카나리 배포 가능",
  ],

  cons: [
    "L4보다 느림 (TLS 종료 + HTTP 파싱 필요)",
    "HTTP/HTTPS 트래픽만 처리",
  ],

  examples: ["AWS ALB", "Nginx", "Envoy", "Cloudflare Workers"],
};

const algorithms = {
  // 1. 라운드 로빈 (Round Robin)
  roundRobin: {
    method: "서버 목록을 순서대로 돌아가며 선택",
    pros: "구현이 단순, 서버 성능이 균일할 때 효과적",
    cons: "서버 성능이 다르면 느린 서버에 과부하",
    example: "요청 1 -> A, 요청 2 -> B, 요청 3 -> C, 요청 4 -> A ...",
  },

  // 2. 가중치 라운드 로빈 (Weighted Round Robin)
  weightedRoundRobin: {
    method: "서버마다 가중치를 부여, 가중치 비율로 분배",
    useCase: "서버 성능이 다를 때 (A: 4코어, B: 8코어)",
    example: "A(weight=1): 33%, B(weight=2): 67%",
  },

  // 3. 최소 연결 (Least Connections)
  leastConnections: {
    method: "현재 활성 연결이 가장 적은 서버를 선택",
    pros: "서버 부하를 동적으로 균형 배분",
    useCase: "요청 처리 시간이 들쭉날쭉할 때",
    example: "A(연결 5), B(연결 3), C(연결 7) -> B 선택",
  },

  // 4. IP 해시 (IP Hash)
  ipHash: {
    method: "클라이언트 IP의 해시값으로 서버를 결정",
    pros: "같은 클라이언트는 항상 같은 서버로 (세션 유지)",
    cons: "서버 추가/제거 시 대부분의 매핑이 변경됨",
    example: "hash(192.168.1.10) % 3 = 1 -> 항상 서버 B",
  },

  // 5. 일관된 해싱 (Consistent Hashing)
  consistentHashing: {
    method: "해시 링 위에 서버와 요청을 배치, 시계 방향으로 가장 가까운 서버 선택",
    pros: "서버 추가/제거 시 재배치되는 키가 최소 (1/N)",
    useCase: "분산 캐시, CDN, 세션 스토어",
  },
};

// 포워드 프록시 vs 리버스 프록시
const forwardProxy = {
  position: "클라이언트 앞단",
  role: "클라이언트를 대리해 외부 서버에 요청",
  examples: ["기업 프록시 (인터넷 접근 제어)", "VPN"],
  // 클라이언트 -> [프록시] -> 서버
  // 서버는 프록시의 IP만 알고, 클라이언트 IP를 모름
};

const reverseProxy = {
  position: "서버 앞단",
  role: "서버를 대리해 클라이언트 요청을 처리",
  features: [
    "TLS 종료 (SSL offloading)",
    "로드밸런싱",
    "캐싱",
    "압축 (gzip, brotli)",
    "보안 (WAF, rate limiting, DDoS 방어)",
  ],
  examples: ["Nginx", "Caddy", "Envoy", "Cloudflare"],
  // 클라이언트 -> [리버스 프록시] -> 서버
  // 클라이언트는 리버스 프록시의 IP만 알고, 서버 IP를 모름
};

const healthCheck = {
  // 능동적 (Active) 헬스체크
  active: {
    method: "로드밸런서가 주기적으로 서버에 요청을 보내 확인",
    interval: "5~30초마다",
    endpoint: "/health 또는 /readyz",
    threshold: "연속 3회 실패 시 비정상 판정",
    // 서버가 200 OK를 응답하면 정상
    // 타임아웃이나 5xx 응답이면 비정상
  },

  // 수동적 (Passive) 헬스체크
  passive: {
    method: "실제 트래픽의 응답을 모니터링",
    trigger: "5xx 에러 비율이 임계값 초과 시 비정상 판정",
    // 별도 요청 없이 실제 트래픽으로 판단
  },
};

// AWS ALB 헬스체크 설정 예시
// Target Group -> Health checks
// Protocol: HTTP
// Path: /health
// Healthy threshold: 3 (연속 3회 성공 시 정상)
// Unhealthy threshold: 3 (연속 3회 실패 시 비정상)
// Timeout: 5초
// Interval: 30초

// Cloudflare 동작 흐름
const cloudflareFlow = {
  // 1. DNS: Cloudflare 네임서버 사용
  dns: "ns1.cloudflare.com / ns2.cloudflare.com",

  // 2. Anycast: 300+ POP에서 동일 IP 광고
  anycast: "가장 가까운 POP으로 자동 라우팅",

  // 3. 에지에서 처리
  edgeProcessing: [
    "DDoS 방어 (L3/L4/L7)",
    "WAF (웹 애플리케이션 방화벽)",
    "Bot 관리",
    "TLS 종료",
    "캐싱 (정적 리소스)",
    "이미지 최적화 (Polish, Mirage)",
    "Brotli 압축",
  ],

  // 4. 캐시 미스 시 오리진에 요청
  originFetch: "Cloudflare -> 오리진 서버 (오리진 IP는 외부에 노출되지 않음)",

  // 응답 헤더로 캐시 상태 확인
  headers: {
    "CF-Cache-Status": "HIT | MISS | EXPIRED | DYNAMIC",
    "CF-Ray": "요청 추적 ID (디버깅용)",
  },
};

// Vercel의 인프라 구조
const vercelInfra = {
  // 정적 리소스: 글로벌 에지 캐시
  staticAssets: {
    path: "/_next/static/**",
    caching: "Cache-Control: public, max-age=31536000, immutable",
    serving: "에지 서버에서 직접 응답 (오리진 접근 불필요)",
  },

  // ISR (Incremental Static Regeneration)
  isr: {
    firstRequest: "오리진에서 생성 후 에지에 캐시",
    subsequentRequests: "에지 캐시에서 응답, 백그라운드에서 재검증",
    header: "X-Vercel-Cache: HIT | STALE | MISS",
  },

  // 서버리스 함수 (API Routes, SSR)
  serverless: {
    region: "설정된 리전에서 실행",
    // vercel.json에서 리전 지정 가능
    config: '{ "regions": ["icn1"] }', // 서울 리전
  },

  // 미들웨어: 에지에서 실행
  middleware: {
    location: "CDN 에지",
    useCase: ["A/B 테스트", "지역 기반 리다이렉트", "인증 체크"],
    latency: "~0ms (사용자에게 가장 가까운 에지에서 실행)",
  },
};

const cacheInvalidation = {
  // 1. TTL 기반: 시간이 지나면 자동 만료
  ttl: {
    header: "Cache-Control: public, max-age=3600",
    pros: "설정이 간단",
    cons: "TTL이 끝나기 전에는 업데이트 반영 불가",
  },

  // 2. 콘텐츠 해시 (가장 권장)
  contentHash: {
    example: "app.d8f3a2b1.js",
    header: "Cache-Control: public, max-age=31536000, immutable",
    // 파일 내용이 바뀌면 해시가 바뀌어 새 URL이 됨
    // 이전 파일은 자연스럽게 만료
    // Next.js가 기본적으로 이 방식을 사용
  },

  // 3. Purge API: 수동으로 캐시 삭제
  purge: {
    cloudflare: "API로 특정 URL 또는 전체 캐시 퍼지",
    // POST https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache
    // { "files": ["https://example.com/logo.png"] }
  },

  // 4. stale-while-revalidate
  swr: {
    header: "Cache-Control: public, max-age=60, stale-while-revalidate=3600",
    // max-age 동안: 캐시에서 바로 응답
    // max-age 이후 ~ SWR 기간: 캐시된 (stale) 응답을 반환하면서 백그라운드에서 재검증
    // SWR 기간 이후: 새 요청으로 오리진에서 가져옴
  },
};

const checklist = {
  cdn: [
    "정적 리소스에 콘텐츠 해시 적용 (Next.js는 기본 제공)",
    "Cache-Control 헤더 적절히 설정",
    "이미지 최적화 (WebP/AVIF, next/image 사용)",
    "DevTools Network에서 X-Cache / CF-Cache-Status 확인",
  ],

  loadBalancer: [
    "헬스체크 엔드포인트 (/health) 구현",
    "세션이 필요하면 서버 외부 저장소 사용 (Redis 등)",
    "Graceful shutdown 구현 (SIGTERM 핸들링)",
  ],

  debugging: [
    "curl -I 로 캐시 헤더 확인",
    "dig / nslookup 으로 DNS 확인",
    "traceroute 로 네트워크 경로 확인",
  ],
};

const fullRequestPath = [
  "1. 브라우저 DNS 캐시 확인",
  "2. OS DNS 캐시 확인",
  "3. 재귀 리졸버에 DNS 질의 (Anycast)",
  "4. DNS 응답: 가장 가까운 CDN POP IP",
  "5. CDN 에지 서버에 TCP + TLS 연결",
  "6. 에지 캐시 확인",
  "   - HIT: 바로 응답 (여기서 끝)",
  "   - MISS: 다음 단계로",
  "7. Shield 캐시 확인",
  "   - HIT: 에지에 캐시 후 응답",
  "   - MISS: 다음 단계로",
  "8. 로드밸런서가 오리진 서버 선택",
  "9. 오리진 서버가 응답 생성",
  "10. 응답이 Shield, Edge를 거치며 캐시됨",
  "11. 사용자에게 최종 응답 전달",
];