네트워크 기초 복습
네트워크 기초 복습¶
개요¶
이 문서에서는 시스템 설계에 필수적인 네트워크 개념을 복습합니다. DNS 동작 원리와 DNS 기반 로드밸런싱, CDN의 Push/Pull 모델, HTTP/2와 HTTP/3의 특징, 그리고 REST와 gRPC의 선택 기준을 학습합니다.
난이도: ⭐⭐ 예상 학습 시간: 2-3시간 선수 지식: Networking 폴더 기초
목차¶
1. DNS 동작과 로드밸런싱¶
1.1 DNS 동작 원리 복습¶
┌─────────────────────────────────────────────────────────────────┐
│ DNS 조회 과정 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Client │
│ │ │
│ │ 1. www.example.com? │
│ ▼ │
│ ┌───────────────────┐ │
│ │ Local DNS Resolver│ ← ISP 또는 8.8.8.8 (Google) │
│ │ (Recursive) │ │
│ └─────────┬─────────┘ │
│ │ 2. .com 어디? │
│ ▼ │
│ ┌───────────────────┐ │
│ │ Root DNS Server │ (a.root-servers.net 등 13개) │
│ └─────────┬─────────┘ │
│ │ 3. .com TLD 서버 주소 반환 │
│ ▼ │
│ ┌───────────────────┐ │
│ │ TLD DNS Server │ (.com, .org, .kr 등) │
│ └─────────┬─────────┘ │
│ │ 4. example.com NS 반환 │
│ ▼ │
│ ┌───────────────────┐ │
│ │ Authoritative DNS │ (example.com 담당) │
│ └─────────┬─────────┘ │
│ │ 5. A 레코드: 93.184.216.34 │
│ ▼ │
│ Client ◄───── IP 주소 반환 │
│ │
└─────────────────────────────────────────────────────────────────┘
1.2 DNS 기반 로드밸런싱¶
┌─────────────────────────────────────────────────────────────────┐
│ DNS 로드밸런싱 방식 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. Round Robin DNS │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ www.example.com → 192.168.1.1 │ │
│ │ www.example.com → 192.168.1.2 │ │
│ │ www.example.com → 192.168.1.3 │ │
│ │ │ │
│ │ 첫 번째 요청 → 192.168.1.1 │ │
│ │ 두 번째 요청 → 192.168.1.2 │ │
│ │ 세 번째 요청 → 192.168.1.3 │ │
│ │ 네 번째 요청 → 192.168.1.1 (순환) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 2. Weighted Round Robin │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 서버 A (Weight: 5) → 50% 트래픽 │ │
│ │ 서버 B (Weight: 3) → 30% 트래픽 │ │
│ │ 서버 C (Weight: 2) → 20% 트래픽 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 3. Geolocation DNS │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 한국 사용자 → 서울 서버 (ap-northeast-2) │ │
│ │ 미국 사용자 → 버지니아 서버 (us-east-1) │ │
│ │ 유럽 사용자 → 프랑크푸르트 서버 (eu-central-1) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 4. Latency-based DNS │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 사용자 위치에서 가장 지연이 낮은 서버로 라우팅 │ │
│ │ AWS Route 53, Cloudflare 등에서 제공 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
1.3 DNS 로드밸런싱의 한계¶
┌─────────────────────────────────────────────────────────────────┐
│ DNS 로드밸런싱 한계점 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. TTL로 인한 지연 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 서버 장애 시 TTL 만료까지 트래픽이 계속 전달됨 │ │
│ │ • 낮은 TTL = 빠른 장애 대응 but 높은 DNS 쿼리 부하 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 2. 클라이언트 캐싱 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 브라우저/OS가 DNS 결과를 캐싱 │ │
│ │ • 서버 측 변경이 즉시 반영되지 않음 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 3. 불균등 분배 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 대형 ISP의 DNS Resolver가 많은 사용자를 대표 │ │
│ │ • 해당 ISP의 모든 사용자가 같은 서버로 연결 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 4. 헬스체크 한계 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 실시간 서버 상태 확인 어려움 │ │
│ │ • 전용 로드밸런서보다 정교한 헬스체크 불가 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 해결책: DNS + L4/L7 로드밸런서 조합 사용 │
│ │
└─────────────────────────────────────────────────────────────────┘
2. CDN (Content Delivery Network)¶
2.1 CDN이란?¶
┌─────────────────────────────────────────────────────────────────┐
│ CDN 개념 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ CDN = 지리적으로 분산된 서버 네트워크 │
│ 정적 컨텐츠를 사용자 가까이에서 제공 │
│ │
│ ┌─────────────┐ │
│ │ Origin │ │
│ │ Server │ │
│ │ (원본 서버) │ │
│ └──────┬──────┘ │
│ │ │
│ ┌────────────┼────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Edge │ │ Edge │ │ Edge │ │
│ │ Server │ │ Server │ │ Server │ │
│ │ (서울) │ │ (도쿄) │ │ (뉴욕) │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 한국 사용자 일본 사용자 미국 사용자 │
│ │
│ 장점: │
│ • 지연 시간 감소 (가까운 서버에서 응답) │
│ • Origin 서버 부하 감소 │
│ • DDoS 방어 │
│ • 높은 가용성 │
│ │
└─────────────────────────────────────────────────────────────────┘
2.2 Push vs Pull CDN¶
┌─────────────────────────────────────────────────────────────────┐
│ Push CDN vs Pull CDN │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Push CDN (사전 배포) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Origin Server │ │
│ │ │ │ │
│ │ │ 관리자가 직접 업로드 │ │
│ │ ▼ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Edge 1 │ │ Edge 2 │ │ Edge 3 │ │ │
│ │ │ (서울) │ │ (도쿄) │ │ (뉴욕) │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ │ │
│ │ 특징: │ │
│ │ • 컨텐츠 변경 시 직접 업로드 │ │
│ │ • 모든 엣지에 미리 배포됨 │ │
│ │ • 첫 요청부터 빠른 응답 │ │
│ │ │ │
│ │ 적합: 변경이 드문 대용량 파일 (비디오, 게임 패치) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ Pull CDN (요청 시 캐싱) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ User Request │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────┐ Cache Miss? ┌─────────────┐ │ │
│ │ │ Edge │─────────────────────│ Origin │ │ │
│ │ │ Server │ ◄─────────────────── │ Server │ │ │
│ │ └─────────┘ Fetch & Cache └─────────────┘ │ │
│ │ │ │ │
│ │ │ 캐시된 응답 │ │
│ │ ▼ │ │
│ │ User │ │
│ │ │ │
│ │ 특징: │ │
│ │ • 첫 요청 시 Origin에서 가져옴 │ │
│ │ • TTL 기반 캐시 관리 │ │
│ │ • 운영 간편 (자동 캐싱) │ │
│ │ │ │
│ │ 적합: 웹사이트 정적 자원 (이미지, CSS, JS) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
2.3 비교 요약¶
| 항목 | Push CDN | Pull CDN |
|---|---|---|
| 배포 방식 | 관리자가 직접 업로드 | 요청 시 자동 캐싱 |
| 첫 요청 | 즉시 응답 | Origin 접근 필요 |
| 캐시 관리 | 수동 | 자동 (TTL) |
| 저장 비용 | 높음 (전체 배포) | 낮음 (필요시만) |
| 적합한 경우 | 대용량, 변경 드문 파일 | 자주 변경되는 컨텐츠 |
| 예시 | 게임 업데이트, 영화 | 웹사이트, API 응답 |
2.4 CDN 캐시 무효화¶
┌─────────────────────────────────────────────────────────────────┐
│ CDN 캐시 무효화 전략 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. TTL (Time To Live) 설정 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Cache-Control: max-age=3600 (1시간 후 만료) │ │
│ │ Cache-Control: s-maxage=86400 (CDN용, 1일) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 2. Purge (즉시 삭제) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 특정 URL의 캐시를 강제 삭제 │ │
│ │ • 긴급 수정 시 사용 │ │
│ │ • API 호출: POST /purge?url=... │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 3. Versioning (파일명에 버전 포함) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ /static/app.v1.js → /static/app.v2.js │ │
│ │ /static/app.abc123.js (해시 사용) │ │
│ │ │ │
│ │ 장점: 캐시 무효화 없이 새 버전 배포 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 4. Soft Purge (Stale-While-Revalidate) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 오래된 캐시를 서빙하면서 백그라운드에서 갱신 │ │
│ │ Cache-Control: stale-while-revalidate=60 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
3. HTTP/2와 HTTP/3¶
3.1 HTTP 버전 비교¶
┌─────────────────────────────────────────────────────────────────┐
│ HTTP 버전 진화 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ HTTP/1.1 (1997) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Request 1 ──────▶ Response 1 │ │
│ │ Request 2 ──────▶ Response 2 (순차적) │ │
│ │ Request 3 ──────▶ Response 3 │ │
│ │ │ │
│ │ 문제점: │ │
│ │ • Head-of-Line Blocking (HOL) │ │
│ │ • 연결당 하나의 요청 처리 │ │
│ │ • 우회: 도메인 샤딩, 스프라이트 이미지 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ HTTP/2 (2015) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────────── Single TCP Connection ─────────────┐ │ │
│ │ │ │ │ │
│ │ │ Stream 1 ═══════▶ ═══════▶ ═══════▶ │ │ │
│ │ │ Stream 2 ═══════▶ ═══════▶ ═══════▶ (병렬) │ │ │
│ │ │ Stream 3 ═══════▶ ═══════▶ ═══════▶ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ 개선점: │ │
│ │ • Multiplexing (하나의 연결에 여러 스트림) │ │
│ │ • Header Compression (HPACK) │ │
│ │ • Server Push │ │
│ │ • Binary Protocol │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ HTTP/3 (2022) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────────── QUIC (UDP 기반) ───────────────────┐ │ │
│ │ │ │ │ │
│ │ │ Stream 1 ═══════▶ (독립적, 패킷 손실 영향 없음) │ │ │
│ │ │ Stream 2 ═══════▶ │ │ │
│ │ │ Stream 3 ═══════▶ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ 개선점: │ │
│ │ • 0-RTT 연결 (재연결 시) │ │
│ │ • 스트림별 독립적 패킷 손실 처리 │ │
│ │ • Connection Migration (IP 변경 시 연결 유지) │ │
│ │ • 내장 암호화 (TLS 1.3) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
3.2 HTTP/2 주요 특징¶
┌─────────────────────────────────────────────────────────────────┐
│ HTTP/2 핵심 기능 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. Multiplexing │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ HTTP/1.1: ─────────────────────────────────────────── │ │
│ │ │ Req1 │ Res1 │ Req2 │ Res2 │ Req3 │ Res3 │ │ │
│ │ ─────────────────────────────────────────── │ │
│ │ │ │
│ │ HTTP/2: ─────────────────────────────────────────── │ │
│ │ │ R1│R2│R3│S1│S2│S1│R3│S3│S2│S3│ │ │
│ │ ─────────────────────────────────────────── │ │
│ │ (프레임 단위로 인터리빙) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 2. Header Compression (HPACK) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ HTTP/1.1: │ │
│ │ GET /page HTTP/1.1 │ │
│ │ Host: example.com │ │
│ │ User-Agent: Mozilla/5.0... (매번 반복, ~800 bytes) │ │
│ │ │ │
│ │ HTTP/2: │ │
│ │ • 정적 테이블 (자주 쓰는 헤더 미리 정의) │ │
│ │ • 동적 테이블 (세션 중 반복되는 헤더 저장) │ │
│ │ • 허프만 인코딩 │ │
│ │ → 85-88% 헤더 크기 감소 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 3. Server Push │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Client: GET /index.html │ │
│ │ Server: │ │
│ │ → Response: /index.html │ │
│ │ → Push: /style.css (요청 전에 미리 전송) │ │
│ │ → Push: /app.js │ │
│ │ │ │
│ │ 주의: 클라이언트 캐시와 충돌 가능, 신중히 사용 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
3.3 HTTP/3 (QUIC)의 장점¶
┌─────────────────────────────────────────────────────────────────┐
│ HTTP/3 (QUIC) 장점 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. 스트림별 독립적 처리 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ HTTP/2 (TCP): 패킷 손실 시 모든 스트림 대기 │ │
│ │ │ │
│ │ Stream 1 ═══╳══════════════════ (손실) │ │
│ │ Stream 2 ════════════════════ (대기) │ │
│ │ Stream 3 ════════════════════ (대기) │ │
│ │ │ │
│ │ HTTP/3 (QUIC): 손실 스트림만 영향 │ │
│ │ │ │
│ │ Stream 1 ═══╳══════════════════ (재전송) │ │
│ │ Stream 2 ═══════════════════════ (정상 진행) │ │
│ │ Stream 3 ═══════════════════════ (정상 진행) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 2. 빠른 연결 수립 (0-RTT) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ TCP + TLS 1.3: 2-3 RTT 필요 │ │
│ │ ┌────┐ ┌────┐ │ │
│ │ │ C │──SYN──▶│ S │ │ │
│ │ │ │◀SYN+ACK│ │ 1 RTT (TCP) │ │
│ │ │ │──ACK──▶│ │ │ │
│ │ │ │◀──────▶│ │ 1 RTT (TLS) │ │
│ │ └────┘ └────┘ │ │
│ │ │ │
│ │ QUIC (재연결): 0 RTT │ │
│ │ ┌────┐ ┌────┐ │ │
│ │ │ C │──DATA─▶│ S │ 즉시 데이터 전송 │ │
│ │ │ │◀──────▶│ │ (이전 세션 키 재사용) │ │
│ │ └────┘ └────┘ │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 3. Connection Migration │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Wi-Fi → LTE 전환 시: │ │
│ │ │ │
│ │ TCP: 연결 끊김, 재연결 필요 │ │
│ │ QUIC: Connection ID 기반, 연결 유지 │ │
│ │ │ │
│ │ 모바일 환경에서 큰 장점! │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
3.4 버전별 비교표¶
| 특성 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 전송 계층 | TCP | TCP | QUIC (UDP) |
| Multiplexing | X | O | O |
| HOL Blocking | O | 일부 (TCP) | X |
| 헤더 압축 | X | HPACK | QPACK |
| Server Push | X | O | O |
| 연결 수립 | 1-2 RTT | 1-2 RTT | 0-1 RTT |
| Connection Migration | X | X | O |
4. REST vs gRPC¶
4.1 개요¶
┌─────────────────────────────────────────────────────────────────┐
│ REST vs gRPC 개요 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ REST (Representational State Transfer) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ • HTTP 기반의 아키텍처 스타일 │ │
│ │ • JSON/XML 형식 │ │
│ │ • 리소스 중심 (URL + HTTP Method) │ │
│ │ • 상태 비저장 (Stateless) │ │
│ │ │ │
│ │ GET /users/123 │ │
│ │ POST /users │ │
│ │ PUT /users/123 │ │
│ │ DELETE /users/123 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ gRPC (Google Remote Procedure Call) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ • HTTP/2 기반 │ │
│ │ • Protocol Buffers (Protobuf) 직렬화 │ │
│ │ • 함수 호출 스타일 │ │
│ │ • 양방향 스트리밍 지원 │ │
│ │ │ │
│ │ service UserService { │ │
│ │ rpc GetUser(GetUserRequest) returns (User); │ │
│ │ rpc ListUsers(ListRequest) returns (stream User); │ │
│ │ } │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
4.2 상세 비교¶
┌─────────────────────────────────────────────────────────────────┐
│ REST vs gRPC 상세 비교 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 데이터 형식 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ REST (JSON): │ │
│ │ { │ │
│ │ "id": 123, │ │
│ │ "name": "John", │ │
│ │ "email": "john@example.com" │ │
│ │ } │ │
│ │ → 사람이 읽기 쉬움, 크기 큼 │ │
│ │ │ │
│ │ gRPC (Protobuf): │ │
│ │ message User { │ │
│ │ int32 id = 1; │ │
│ │ string name = 2; │ │
│ │ string email = 3; │ │
│ │ } │ │
│ │ → 이진 형식, 크기 작음 (10배 차이) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 성능 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ REST: │ │
│ │ • 텍스트 파싱 오버헤드 │ │
│ │ • HTTP/1.1에서 연결당 하나의 요청 │ │
│ │ │ │
│ │ gRPC: │ │
│ │ • 이진 직렬화로 빠른 파싱 │ │
│ │ • HTTP/2 Multiplexing │ │
│ │ • 7-10배 빠른 직렬화 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 스트리밍 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ REST: │ │
│ │ • 기본적으로 요청-응답 패턴 │ │
│ │ • 스트리밍 위해 SSE, WebSocket 필요 │ │
│ │ │ │
│ │ gRPC: │ │
│ │ • Unary: 단일 요청-응답 │ │
│ │ • Server Streaming: 서버가 여러 응답 │ │
│ │ • Client Streaming: 클라이언트가 여러 요청 │ │
│ │ • Bidirectional: 양방향 스트리밍 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
4.3 선택 기준¶
┌─────────────────────────────────────────────────────────────────┐
│ REST vs gRPC 선택 기준 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ REST를 선택할 때 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ✓ 공개 API (외부 개발자용) │ │
│ │ ✓ 웹 브라우저 직접 호출 │ │
│ │ ✓ 간단한 CRUD 작업 │ │
│ │ ✓ 디버깅 편의성 중요 │ │
│ │ ✓ 팀이 REST에 익숙 │ │
│ │ ✓ 캐싱이 중요 (HTTP 캐시) │ │
│ │ │ │
│ │ 예시: │ │
│ │ • GitHub API, Stripe API │ │
│ │ • 일반 웹 서비스 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ gRPC를 선택할 때 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ✓ 마이크로서비스 간 내부 통신 │ │
│ │ ✓ 고성능 필요 (낮은 지연, 높은 처리량) │ │
│ │ ✓ 실시간 양방향 통신 │ │
│ │ ✓ 강타입 API 계약 │ │
│ │ ✓ 다중 언어 환경 (코드 자동 생성) │ │
│ │ ✓ 네트워크 대역폭 제한 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • Netflix, Google 내부 │ │
│ │ • 실시간 게임, IoT │ │
│ │ • 모바일 백엔드 │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 하이브리드 접근 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 외부 API: REST (개발자 친화적) │ │
│ │ 내부 통신: gRPC (고성능) │ │
│ │ │ │
│ │ ┌──────────┐ REST ┌───────────┐ │ │
│ │ │ Client │─────────────▶│ API │ │ │
│ │ │ (Web/App)│ │ Gateway │ │ │
│ │ └──────────┘ └─────┬─────┘ │ │
│ │ │ gRPC │ │
│ │ ┌─────────────┼─────────────┐ │ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │Service │ │Service │ │Service │ │ │
│ │ │ A │ │ B │ │ C │ │ │
│ │ └────────┘ └────────┘ └────────┘ │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
4.4 비교 요약표¶
| 항목 | REST | gRPC |
|---|---|---|
| 프로토콜 | HTTP/1.1, HTTP/2 | HTTP/2 |
| 데이터 형식 | JSON, XML | Protocol Buffers |
| 스트리밍 | 제한적 | 네이티브 지원 |
| 코드 생성 | OpenAPI (선택) | 필수 |
| 브라우저 지원 | 완벽 | grpc-web 필요 |
| 학습 곡선 | 낮음 | 중간 |
| 성능 | 좋음 | 매우 좋음 |
| 디버깅 | 쉬움 | 도구 필요 |
5. 연습 문제¶
문제 1: DNS 로드밸런싱 설계¶
글로벌 서비스를 운영한다고 가정합니다. DNS를 활용한 로드밸런싱 전략을 설계하세요.
조건: - 3개 리전: 서울, 도쿄, 버지니아 - 평상시: 사용자와 가장 가까운 리전으로 라우팅 - 장애 시: 다른 리전으로 자동 전환
문제 2: CDN 전략 수립¶
온라인 비디오 스트리밍 서비스의 CDN 전략을 수립하세요.
a) Push CDN과 Pull CDN 중 무엇을 사용할지 결정하고 이유를 설명하세요. b) 새 콘텐츠 업로드 시 캐시 전략을 설계하세요.
문제 3: HTTP 버전 선택¶
다음 시나리오에 적합한 HTTP 버전을 선택하고 이유를 설명하세요.
a) 모바일 앱 (자주 네트워크 전환) b) 레거시 시스템과 통합 c) 이미지가 많은 뉴스 사이트
문제 4: REST vs gRPC¶
마이크로서비스 아키텍처에서 서비스 간 통신 방식을 선택해야 합니다.
상황: - 10개의 내부 서비스 - 서비스는 Go, Java, Python으로 작성됨 - 실시간 데이터 동기화 필요
정답¶
문제 1 정답¶
DNS 설정:
1. Geolocation DNS 사용
- 한국 → 서울 리전 IP
- 일본 → 도쿄 리전 IP
- 미국 → 버지니아 리전 IP
2. Health Check 설정
- 각 리전 헬스체크 엔드포인트 모니터링
- 실패 시 DNS에서 제외
3. Failover 설정
- Primary: 가장 가까운 리전
- Secondary: 두 번째로 가까운 리전
- 예: 서울 → 도쿄 → 버지니아
4. TTL 설정
- 낮은 TTL (60-300초)로 빠른 장애 대응
AWS Route 53 또는 Cloudflare 사용 권장
문제 2 정답¶
a) Push CDN 선택
이유:
- 비디오는 대용량이고 변경이 드뭄
- 첫 시청 시 빠른 응답 필요
- 인기 콘텐츠 미리 배포 가능
b) 캐시 전략:
1. 신규 콘텐츠:
- 업로드 후 주요 엣지 서버에 사전 배포
- 인기 예상 콘텐츠 우선 배포
2. 라이브 콘텐츠:
- Pull 방식 + 짧은 TTL
- 스트리밍 최적화 설정
3. 버전 관리:
- 콘텐츠 ID에 버전 포함
- 업데이트 시 새 URL 발급
문제 3 정답¶
a) 모바일 앱: HTTP/3
- Connection Migration으로 네트워크 전환 시 연결 유지
- 0-RTT로 빠른 재연결
- 배터리 효율 향상
b) 레거시 시스템: HTTP/1.1
- 광범위한 호환성
- 기존 인프라와 충돌 없음
- 필요 시 점진적 업그레이드
c) 이미지 많은 사이트: HTTP/2
- Multiplexing으로 많은 이미지 동시 로드
- 헤더 압축으로 효율성
- Server Push로 CSS/JS 미리 전송
문제 4 정답¶
gRPC 선택
이유:
1. 내부 서비스 통신
- 외부 공개 아님, 브라우저 지원 불필요
2. 다중 언어 환경
- Go, Java, Python 모두 gRPC 지원
- Protobuf로 코드 자동 생성 → 일관성
3. 실시간 동기화
- 양방향 스트리밍으로 실시간 데이터 교환
- Server Streaming으로 이벤트 푸시
4. 성능
- 서비스 간 고빈도 통신에 효율적
- Protobuf 직렬화로 네트워크 효율
구현:
- 공통 .proto 파일 관리
- 서비스별 gRPC 클라이언트/서버 코드 생성
6. 다음 단계¶
네트워크 기초를 복습했다면, 로드밸런싱에 대해 더 깊이 학습하세요.
다음 레슨¶
- 04_Load_Balancing.md - L4/L7 로드밸런서, 분배 알고리즘
관련 레슨¶
- 05_Reverse_Proxy_API_Gateway.md - 프록시 패턴
추천 학습¶
- Networking/12_DNS.md - DNS 상세
- Networking/13_HTTP_and_HTTPS.md - HTTP 상세
7. 참고 자료¶
RFC 문서¶
- RFC 7540 - HTTP/2
- RFC 9000 - QUIC
- RFC 9114 - HTTP/3
온라인 자료¶
도구¶
- WebPageTest - HTTP 버전 테스트
- Postman - REST API 테스트
- grpcurl - gRPC 테스트
문서 정보 - 최종 수정: 2024년 - 난이도: ⭐⭐ - 예상 학습 시간: 2-3시간