[DeepDive🤿] 정답 없는 아키텍처? 내가 이해한 Route 53 & ELB 글로벌 분산 전략

한유진·2025년 11월 15일

DeepDive

목록 보기

2/4

DeepDive 주제

💡 Route 53과 ELB를 활용해 글로벌 트래픽을 분산 처리하는 방법을 설명하고, 지연(latency)·가용성(availability)·비용(cost) 관점에서 어떤 설계 전략이 최적일지 서술하시오.

주제를 보고 든 생각

Route 53은 DNS니까 얼마나 빨리 IP값을 주느냐에 따라 트래픽분산에도 영향을 미친다는건가?
Route 53보다는 ELB가 트래픽 분산처리에 더 많은 힘을 쓰지 않을까?
어떤 방법들이 있을까..?
지연,가성비,비용은 trade-off관계일텐데 각 관점에서는 어떤 설계를 선택해야할까?

0️⃣ 키워드 정리

Route 53

AWS의 DNS(Domain Name System) 웹서비스로 가용성과 확장성이 뛰어난 클라우드 기반이다.
트래픽 라우팅 가능 + 특정 포트에 대한 모니터링도 가능

ELB

트래픽을 여러 대상에 자동으로 분산시켜 안정적인 서버 환경을 만드는데 도움을 주는 서비스
로드 밸런스 + (Route53 기반의)헬스 체크 + 고정 세션 + SSL 암복호화

지연(latency)

데이터 패킷이 네트워크나 시스템 내에서 한 지점에서 다른 지점으로 이동하는 데 걸리는 시간적 지연을 의미

가용성(availability)

서비스의 지속적인 작동을 보장하는 능력

비용(cost)

시스템 설계~유지보수 등 전체 수명 주기 동안 발생하는 금전적 지출

Trade-off 관계

어떤 속성을 향상시키면 다른 속성이 악화되는 관계
ex)
- 지연 ↔ 가용성 : 가용성을 늘리기 위해 복제본을 많이 만든다면, 지연시간이 늘겠지?
- 비용 ↔ 가용성 : 가용성을 늘리기 위해 복제본을 많이 만든다면, 비용이 많이 들겠지?

지연·가용성·비용 관점에서의 설계?

설계시에 어떤것을 우선시하고 어떤것을 포기할지를 근거를 가지고 판단하여 설계해라!

1️⃣ 글로벌 트래픽 분산 처리 방법

왜 글로벌 트래픽 분산이 필요한가?

요새는 글로벌 사용자를 가진 서비스가 많아지면서, 지역별 네트워크 지연, 장애 상황에 대한 가용성, 그리고 비용 등 이들 사이에서의 균형을 찾는 아키텍쳐가 필수적이다.
AWS의 Route 53과 ELB는 이러한 문제를 해결하기 위한 핵심 서비스로, 전 세계 사용자에게 가장 빠르고 안정적인 엔드포인트 를 제공할 수 있게 해준다.

“Route 53의 라우팅 정책 + ELB의 멀티리전 아키텍처”

Route 53 = “전 세계 사용자 → 어느 리전의 ELB한테 보내줄지”를 결정하는 레벨
ELB = “해당 리전 내부에서 어떻게 부하를 나눌지” 결정하는 레벨

Route 53의 라우팅 정책

정책 = Route 53이 ‘어떤 IP를 반환할지 선택하는 규칙’
즉, 같은 도메인이라도 어떤 기준으로 ‘다른 리전/서버’로 보낼지 결정하는 규칙을 Route 53에게 알려주는 것.

사진은 Route 53이 도메인의 트래픽을 라우팅하는 방법이다. 6번이 라우팅 정책과정이 동작하는 시점이다.

라우팅 정책	한줄 정리	작동방식	최적의 시나리오	특징
단순 라우팅	1대1 라우팅	도메인 이름에 연결된 단일 리소스의 IP 주소를 응답	- 단일 웹서버	- 가장 기본 - 설정 간단 - 장애조치 없음
가중치 기반 라우팅	비율에 따라 라우팅	여러 IP 주소에 대해 설정된 가중치에 따라 IP 주소를 응답	- 블루/그린 배포 - 다중 리전 배포	- 리소스당 1~255 가중치 지정 - 점진적 마이그레이션 용이
지연 시간 라우팅	최소 지연 시간 제공 리전으로 라우팅	지연 시간이 가장 적은 Region의 리소스 IP 주소를 응답	- 글로벌 사용자 기반 애플리케이션	- AWS 리전 간 지연 시간 측정 - 사용자별 최적 성능 제공 - 자동 트래픽 재분배
장애 조치 라우팅	기본 리소스 장애 시 백업으로 전환	기본 접근 리소스를 Primary, 장애 발생한 경우 접근할 리소스를 Secondary로 설정하여 상태에 맞는 리소스 IP 주소 응답	- 고가용성이 중요한 애플리케이션	- 활성/비활성 구성 -자동 장애 감지 - 상태 확인 통합
지리 위치 라우팅	사용자의 국가/지역 기반 라우팅	사용자의 위치 정보에 따라 응답할 IP 주소를 결정 ex) 한국은 무조건 서울 리전 IP응답	- 콘텐츠 현지화 - 규제 준수 - 지역별 서비스 제공	- 대륙, 국가, 미국 주 단위 구성 - 지역별 사용자 경험 최적화 - 규제 요구사항 충족
지리 근접 라우팅	지리적으로 가까운 리전의 리소스 응답	사용자 위치에서 가장 가까운 리전 선택하여 IP 응답 ex ) 한국에 있어도 일본 리전이 더 가까우면 일본 리전 IP 응답	리소스가 여러 지역에 분산된 경우	- bias(+/-)로 “거리 계산” 조정 가능 - Traffic Flow 시각적 편집기 필요
IP 기반 라우팅	사용자 IP 주소 범위에 따른 라우팅	사용자의 IP 주소(= 어느 ISP, 어느 국가, 어느 네트워크에서 접속했는지) 기반으로 어느 리전의 IP 주소를 줄지 결정	ISP 또는 기업 네트워크 기반 라우팅	- CIDR 블록으로 IP 범위 지정 - 통신사별 최적화 - 기업 네트워크 특화 라우팅
다중 응답 라우팅	최대 8개의 건강한 레코드 반환	여러 리소스에 대해 Health Check를 수행하고, 정상인 리소스 중 최대 8개의 IP 주소를 응답	간단한 DNS 기반 로드 밸런싱	- 여러 값을 무작위 순서로 반환 - 상태 확인 통합 - 기본적인 장애 조치

ELB의 트래픽 분산 방법

ELB가 하는일
- 여러 대상(Targets: EC2 인스턴스, 컨테이너, IP 주소 등)에 트래픽을 나눠주고
- 각 대상의 상태(헬스 체크)를 모니터링해서 정상인 대상만 트래픽을 보내는 것.

방법	설명	비고
다중 AZ(Availability Zone) 지원 및 AZ 활성화	- 각 AZ마다 노드가 생기고, 장애나 트래픽 증가 시 다른 AZ 노드가 대응 가능
교차 영역 로드 밸런싱(Cross-Zone Load Balancing)	- 여러 AZ에 있는 타겟에 균등하게 요청 보냄	- AZ간 리소스 비율이 달라도 고르게 분산 가능 - ALB는 기본으로 활성화되어있음 - AZ별로 사용하는 EC2 개수에 차이가 있는 경우 사용하면 좋은 기능
헬스 체크(Health Checks) 기반 트래픽 라우팅	- 인스턴스의 상태를 자동으로 감지하여 정상인 인스턴스에만 트래픽 보내줌	- 장애 전파를 방지하여 고가용성 확보 가능 -default : 활성
자동 확장/축소(Auto-scaling)	- 인스턴스(컴퓨터) 수를 자동으로 늘림 - 트래픽이 증가하면 타겟이 늘어나고, ELB는 자동으로 분산을 지원	- ELB사용하면 보통 같이 설정함 - default : 없음
로드 밸런서 용량 단위(LCU) 예약	최소 용량을 예약함으로써 에기치 못한 트래픽 급증에도 안정성을 유지하는 기능	- 자동 확장/축소 기능과 결합할때 효과적임 ex) CPU 임계값(35%) 초과 시 Scale up, 12시간 쿨다운 후 CPU 15% 이하로 유지될 경우 Scale down - 이벤트/프로모션처럼 예상 급증 트래픽에 대비하는 기능 - default : 비활성
영역 전환(Zonal Shift)	특정 AZ에서 문제가 발생하였을 때 신속히 대체 영역으로 트래픽을 자동 재배치	- 평소에는 위의 방법들로 트래픽 분산처리를 진행하다가 특정 AZ에 문제 발생시 장애조치를 위한 기능 - default : 비활성

ELB의 종류

종류	특징
Application Load Balancer (ALB)	- Layer 7 (HTTP/HTTPS) - URL 경로 기반, 호스트 기반 라우팅 가능 - 대부분의 웹 서비스/REST API에서 표준 선택
Network Load Balancer (NLB)	- Layer 4 (TCP/UDP) - 고성능 게임서버, 금융, 실시간 서비스에서 사용 - EIP사용 가능
Gateway Load Balancer (GWLB)	- Layer 3 - 트래픽이 EC2에 도달하기 전에 먼저 트래픽 검사/분석/인증/로깅할 수 있음 - LB기능 보다는 트래픽 체크용
Classic Load Balancer (CLB)	- 가장 초기 형태 - 하나의 주소에 하나의 대상그룹으로 밖에 못감 → 구조 복잡해질수록 비용증가

2️⃣ 글로벌 환경에서 지연·가용성·비용 관점에서의 아키텍쳐는?

정답은 없는듯.. 그냥 제 생각입니다!
지연 최적화 관점(글로벌에서도 지연없는 실시간성 서비스)
- Route 53 “지연 시간 라우팅” : 사용자를 물리적으로 가장 가까운 리전에 연결
- ELB
  - 웹서비스 라면 ALB
  - 고성능 네트워크 트래픽이라면 NLB
  - 다중 AZ → 가용성도 극대화됨
  - 헬스체크
  - 자동 확장/축소 → 트래픽 폭증시 인스턴스 부족하면 지연되니까
  - LCU 예약 → But 비용 증가
  - 영역 전환 → 장애대응
가용성 최적화 관점(글로벌 장애에도 죽지 않는 서비스)
- Route 53 “장애 조치 라우팅”
- ELB
  - 다중 AZ → 글로벌이면 더더욱 필요하지 않을까
  - 교차 영역 로드 밸런싱 → 특정AZ의 과부하를 막기위해
  - 헬스체크 필수 → 장애 대응을 위해
  - 자동 확장/축소 → 트래픽 폭증 시 서버 부족 = 시스템 다운방지를 위해
  - LCU 예약 → “예상 트래픽 폭증 대비” 가용성 강화 기능
  - 영역 전환 → 교차영역 LB + Health Check로 잡히지 않는 AZ 레벨 장애를 해결을 위함
비용 최적화 관점(필요한 만큼만 쓰는 비용 효율적인 글로벌 서비스)
- Route 53 “가중치 라우팅” : 라우팅 정책 중 “비용을 직접적으로 통제할 수 있는 유일한 정책”
- ELB
  - 헬스체크 → 비용 거의 없음, 오류를 줄여 비용 절감효과를 위해
  - 자동 확장/축소 → 트래픽적으면 인스턴스 개수 줄일 수 있음
  - LCU 는 선택적으로 → 대형 이벤트 트래픽이 예상될때만 켜둔다(장애비용이 더나감)
3개 다 고려해본다면?
- Route 53: Traffic Flow로 “Latency + Weighted + Failover”를 조합
- ELB : 다중 AZ + 자동 확장/축소 + 헬스 체크 + 영역 전환

📌 마무리

Route 53은 글로벌 트래픽을 어느 리전에 보낼지 결정 서비스
ELB는 선택된 리전 내부에서 실제 애플리케이션 트래픽을 안정적으로 분산하는 서비스
결국 글로벌 트래픽 분산 전략은 이 두 계층을 어떻게 조합하느냐에 따라 지연·가용성·비용 간의 트레이드오프를 최적화하는 작업이다.

📝 회고

오늘은 Route 53의 다양한 라우팅 정책과 ELB의 동작 방식을 좀 더 깊게 이해한 날이었다.
단순히 “DNS → 로드밸런서” 구조라고만 생각했는데, 각 정책과 기능이 지연·가용성·비용 관점에서 언제 어떻게 쓰이는지, 또 두 서비스를 어떻게 조합해야 글로벌 트래픽을 제대로 분산할 수 있는지 흐름이 잡힌 것 같다.
전체적으로 네트워크 아키텍처를 구성할 때 어떤 기준을 가지고 선택해야 하는지 감이 조금은 더 생긴 하루였다.

✅ 추가로 더 알아보면 좋을것들

글로벌 규모에서는 Global Accelerator, CloudFront(캐싱/CDN), AWS WAF & Shield(보안), NLB 기반의 초저지연 로드밸런싱, Multi-Region Active-Active 구조, Global Database(Aurora Global DB) 같은 요소들도 트래픽 분산과 안정성 확보에 중요한 역할을 한다고 한다.