Route 53 라우팅 정책
Simple
example.com -> 192.0.2.1 (단일 IP)
Plain Text
복사
•
특징
◦
Health Check 연결 불가
◦
단일 레코드에 여러 IP 지정 가능
→ 클라이언트가 랜덤 선택 (Simple Multivalue)
Weighted — A/B 테스트
Weighted 라우팅은 단일 도메인 또는 서브 도메인에 여러 리소스를 연결하고, 각 리소스로 라우팅되는 트래픽 비율을 지정할 수 있다. 로드 밸런싱이나 새 버전 소프트웨어 테스트 등 다양한 목적에 유용하다.
example.com
├── v1 (가중치 90) → 90% 트래픽
└── v2 (가중치 10) → 10% 트래픽
가중치 0 = 트래픽 중단 (레코드 유지하면서 트래픽 0)
모두 가중치 0 = 균등 분배
Plain Text
복사
•
활용
◦
Blue/Green 배포 전환 (90→50→0 점진적 이동)
◦
신규 리전 트래픽 점진적 증가
Latency — 가장 빠른 리전으로
Latency 라우팅 정책은 여러 AWS 리전에 리소스가 있고, 가장 낮은 지연 시간을 제공하는 리전으로 트래픽을 라우팅하려 할 때 사용한다.
서울 사용자 → 측정된 지연 시간 기준 → ap-northeast-2 (서울 리전)
미국 사용자 → 측정된 지연 시간 기준 → us-east-1 (버지니아 리전)
Plain Text
복사
•
주의:
◦
지리적으로 가까운 리전이 항상 정답은 아님
◦
실제 네트워크 지연 시간 기반 → 측정값에 따라 달라짐
Latency vs Global Accelerator
둘 다 “가장 빠른 엔드포인트”가 목적이지만 GA는 TCP/UDP L4 고정IP, Route 53 Latency는 DNS 기반 L7
Failover — Active-Passive DR
Failover 라우팅은 리소스가 정상일 때 해당 리소스로 트래픽을 라우팅하고, 첫 번 째 리소스가 비정상일 때 다른 리소스로 라우팅한다.
Primary (Active): ap-northeast-2 ALB ← Health Check 연결 필수
Secondary (Passive): us-east-1 ALB ← Primary 장애 시 자동 전환
Plain Text
복사
•
DR 전략 연결:
◦
Pilot Light / Warm Standby → Failover 라우팅 조합
◦
Primary 헬스 체크 실패 → Secondary로 자동 DNS 전환
Geolocation vs Geoproximity
Geolocation 라우팅은 DNS 쿼리가 발생한 사용자의 지리적 위치를 기반으로 트래픽을 처리할 리소스를 선택한다.
Geoproximity 라우팅은 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 라우팅하며, Bias 값을 지정해 특정 리소스로 더 많거나 적은 트래픽을 보낼 수 있다. Geoproximity 라우팅을 사용하려면 Route 53 Traffic Flow를 사용해야 한다.
Geolocation | Geoproximity |
사용자 위치 기반 | 리소스 위치 기반 |
국가/대륙 단위 | 국가 대륙 단위 + Bias로 영역 조정 가능 |
엄격한 규칙 (반드시 그 리전) | 동적 트래픽 이동 가능 |
GDPR 등 규정 준수 | 트래픽 비율 조정 |
기본값 레코드 필요 | Traffic Flow 필수 |
•
예시
◦
Geolocation: “한국 사용자는 반드시 서울 리전으로”
◦
Geoproximity: “서울 리전 Bias +25 → 더 넓은 범위 커버”
특정 국가 사용자를 특정 리전에 고정 → Geolocation
리전 간 트래픽 비율을 유연하게 조정 → Geoproximity + Bias
규정 준수(데이터 국경)가 목적 → Geolocation
Summary
정책 | 기준 | 핵심 키워드 |
Simple | 단순 1:1 | 단일 리소스, Health Check 없음 |
Weighted | 가중치 비율 | A/B 테스트, 트래픽 점진적 이동 |
Latency | 네트워크 지연 | 가장 빠른 리전으로 |
Failover | 헬스 체크 | Active-Passive DR |
Geolocation | 사용자 위치 | 국가/대륙 기반 엄격한 라우팅 |
Geoproximity | 리소스 위치 + Bias | 트래픽 비율 동적 조정 |
Multivalue | 랜덤 + 헬스 체크 | 최대 8개 정상 레코드 반환 |
CloudFront vs Global Accelerator
CloudFront | Global Accelerator |
L7 (HTTP/HTTPS) | L4 (TCP/UDP) |
콘텐츠 캐싱 | 캐싱 없음 |
동적/정적 콘텐츠 최적화 | 모든 TCP/UDP 트래픽 |
IP 변동 (CDN 도메인) | 고정 Anycast IP 2개 |
엣지 캐시 200+ 위치 | AWS 글로벌 네트워크 경유 |
HTTP 에러 응답 커스텀 | 헬스 체크 + 자동 Failover |
Lambda@Edge 지원 | 게임/IoT/VoIP 최적화 |
•
공통점:
◦
글로벌 사용자 지연 시간 감소
◦
DDoS 보호 (Shield Standard 포함)
◦
AWS 글로벌 네트워크 활용
정적/동적 콘텐츠 캐싱, CDN → CloudFront
고정 IP 필요, TCP/UDP, 게임/IoT → Global Accelerator
HTTP API 응답 캐싱 → CloudFront
멀티 리전 Failover + 고정 IP → Global Accelerator
ELB 비교
ALB (Application LB) | NLB (Network LB) | GWLB (Gateway LB) |
L7 (HTTP/HTTPS) | L4 (TCP/UDP/TLS) | L3 (IP) |
경로/헤더 기반 라우팅 | 초저지연, 고성능 | 서드파티 가상 어플라이언스 |
WebSocket 지원 | 고정 IP / EIP 할당 가능 | Network Firewall 연동 |
Lambda 대상 그룹 가능 | 초당 수백만 요청 처리 | 트래픽 검사 (IDS/IPS) |
WAF 연결 가능 | WAF 연결 불가 | 보안 어플라이언스 연동 |
사용자 인증 지원 | 온프레미스 노출 가능 |
NLB 특징:
고정 IP → 파트너사/방화벽 IP 화이트리스트 등록 필요 시 필수
Preserve Client IP → 실제 클라이언트 IP 유지
TCP 프로토콜 지원 → 게임서버, 미디어 스트리밍
WAF 적용 → ALB
고정 IP 필요 + 초고성능 → NLB
서드파티 방화벽/IDS 경유 → GWLB
Lambda를 백엔드로 사용 → ALB
RDS Multi-AZ vs Read Replica
Multi-AZ | Read Replica | |
목적 | 고가용성 (HA) | 읽기 성능 확장 |
복제 방식 | 동기 복제 (Synchronous) | 비동기 복제 (Asynchronous) |
Standby 읽기 | (Standby는 대기만) | (읽기 트래픽 분산) |
Failover | 자동 (60~120초) | 수동 Promotion 필요 |
리전 | 동일 리전, 다른 AZ | 동일 리전 또는 크로스 리전 |
엔드포인트 | 단일 엔드포인트 유지 | 동일 리전 또는 크로스 리전 |
RPO | 거의 0 (동기) | 수 초 지연 가능 (비동기) |
주요 용도 | 프로덕션 HA 필수 | 보고서, 분석, 읽기 부하 분산 |
•
크로스 리전 Read Replica:
→ 다른 리전 재해 시 수동으로 Primary로 Promote
→ Aurora Global DB가 더 빠른 대안 (RPO < 1초)
자동 Failover, 다운타임 최소화 → Multi-AZ
읽기 트래픽이 너무 많음 → Read Replica
두 기능 동시에 → Multi-AZ + Read Replica 함께 사용 가능
Multi-AZ Standby에서 읽기 가능한가? → 불가 (함정)
ElastiCache Redis vs Memcached
Redis | Memcached | |
데이터 구조 | 복잡한 자료구조 지원
(List, Set, Hash, Sorted Set) | 단순 Key-Value만 지원 |
영속성(Persistence) | (스냅샷, AOF) | |
복제/HA | | |
자동 Failover | | |
Pub/Sub | | |
트랜잭션 | | |
멀티 스레드 | (Single Thread) | (Multi Thread) |
수평 확장 | Redis Cluster Mode | (샤딩 간단) |
크로스 리전 복제 | (Global Datastore) | |
Memcached가 적합한 경우
•
가장 단순한 모델이 필요할 때
•
여러 코어나 스레드를 가진 대형 노드를 실행해야 할 때
•
수요 증가에 따라 노드를 추가/제거하며 스케일 아웃이 필요할 때
Redis가 적합한 경우
•
문자열, 해시, 리스트, 집합, 정렬된 집합 등 복잡한 데이터 구조가 필요할 때
•
데이터 영속성이 필요할 때
•
읽기 집중 애플리케이션을 위한 Read Replica 복제가 필요할 때
•
자동 Failover가 필요할 때
캐싱 전략
1.
Lazy Loading (Cache-Aside)
앱 → 캐시 조회 → Miss → DB 조회 → 캐시 저장
•
장점: 실제 요청된 데이터만 캐시
•
단점: 첫 조회 지연 (Cache Miss)
2.
Write-Through:
앱 → DB 저장 + 동시에 캐시 저장
•
장점: 캐시 항상 최신 상태
•
단점: 쓰기 지연, 안 읽힐 데이터도 캐시
세션 데이터, 단순 캐시, 멀티 스레드 성능 → Memcached
리더보드, 정렬, 실시간 분석, 영속성 필요 → Redis
Multi-AZ HA 필요 → Redis (Memcached는 HA 없음)
크로스 리전 복제 → Redis Global Datastore
Auto Scaling
스케일링 정책
1.
Target Tracking (목표 추적):
“CPU 사용률을 70%로 유지해”
→ AS가 자동으로 인스턴스 수 계산 및 조정
→ 가장 단순하고 권장되는 방식
Plain Text
복사
2.
Step Scaling (단계 조정):
CPU 70~80% → +2대
CPU 80~90% → +4대
CPU 90%+ → +6대
→ CloudWatch Alarm 기반, 세밀한 제어
Plain Text
복사
3.
Scheduled Scaling (예약):
매일 09:00 → 최소 10대
매일 18:00 → 최소 2대
→ 예측 가능한 트래픽 패턴
Plain Text
복사
4.
Predictive Scaling (예측):
ML 기반 과거 패턴 분석 → 사전 스케일 아웃
→ 블랙프라이데이처럼 예상되는 급증 대비
Plain Text
복사
Warm-up & Cooldown
•
Cooldown Period: 스케일 아웃/인 후 다음 스케일링까지 대기 시간
기본값 300초 (5분)
→ 너무 짧으면 과도한 스케일링 반복
•
Instance Warm-up: 새 인스턴스가 트래픽 받을 준비 시간
→ Warm-up 중인 인스턴스는 AS 지표에서 제외
Summary
개념 | 한 줄 요약 |
Route 53 Geolocation | 사용자 국가/대륙 기반 엄격한 라우팅. 규정 준수 목적 |
Route 53 Geoproximity | 리소스 위치 + Bias로 트래픽 동적 조정. Traffic Flow 필수 |
Route 53 Failover | Active-Passive. Health Check 기반 자동 DNS 전환 |
Route 53 Weighted | 가중치 비율 분배. A/B 테스트, 점진적 트래픽 이동 |
CloudFront | L7, 캐싱 CDN, WAF 연동, Lambda@Edge |
Global Accelerator | L4, 고정 Anycast IP 2개, TCP/UDP, 캐싱 없음 |
ALB | L7, 경로 기반, WAF 연동, Lambda 대상 가능 |
NLB | L4, 고정 IP, 초고성능, WAF 불가 |
GWLB | L3, 서드파티 어플라이언스 연동, IDS/IPS |
RDS Multi-AZ | 동기 복제, 자동 Failover, Standby 읽기 불가 |
RDS Read Replica | 비동기 복제, 읽기 부하 분산, 수동 Promote |
Redis | 복잡 자료구조, 영속성, HA, Pub/Sub, Global Datastore |
Memcached | 단순 KV, 멀티스레드, 수평확장 간단, HA 없음 |
Target Tracking | 목표값 유지 자동 조정. 가장 권장 방식 |
Predictive Scaling | ML 기반 사전 스케일 아웃 |
