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개 정상 레코드 반환 |
Global Accelerator vs CloudFront
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 기반 사전 스케일 아웃 |