아마존 Route 53,,,
왜 이름이 저럴까?
이 부분은 DNS 에 관한 부분인데 DNS Port # 가 53이라고 해서 저렇게 이름 지었다고 한다 ㅋㅋ;;
뭐하튼 레츠고

DNS

Host 이름을 서버 IP 주소로 번역한다는것이다.
아마 Backend 개발을 한번이라도,,, 배포를 해본 분들이라면 금방 이해할수있는 개념인데 Public IP 가 있을때 DNS를 통해서 Public IP 로 접근이 아닌 DNS 주소로 접근할수 있게 된다.

http://api.www.example.com. 이있을때
맨 뒤에있는 . 을 root
.com 까지 TLD
example.com 까지 SLD
www.example.com 까지 Sub domain
api.www.example.com 까지 FQDN 으로 전체 도메인 이름이 된다고 한다.

How DNS Works

이렇게 된다.
Local -> Root -> TLD -> SLD 순으로 물어보고 Example.com 에 대한 Public IP 주소를 가져올수있게된다.

Amazon Route 53

그래서 Amazon Route 53 은 또한 Domain Registrar 이라고한다.
그리고 Amazon Route 53 은 고가용성,확장성 완전 관리되어지고 Authoritative 한 DNS 라 하는데 Authoritative 는 DNS Record 를 Update 할수 있다는 의미이다.

Route 53 - Record Type

A 는 IPv4 주소로 Mapping
AAAA 는 Ipv6 주소로 Mapping
CNAME 은 호스트 이름을 다른 이름과 매핑한다고 한다.
CNAME 은 DNS namespace 의 Top node 에는 생성을할수없다고한다
그 예로 example.com 은 못만드는데 www.example.com 은 된다고 한다..
이게 뭔소린가 싶음
NS는 서버의 DNS 이름 or IP 주소라고 한다.

Route 53 - Hosted Zones

record 의 컨테이너라고 한다.
도메인과 서브도메인으로 가는 Traffic routing 방식을 정의한것이라고 하는데.
public Hosted Zone 이랑 Private Hosted zone 이 있다고 한다.
Private Hosted Zone 은 공개되지 않은 도메인 이름을 지원하고 VPC 만이 URL 을 Resolve 할수 있다.

이부분은 좀더 공부

Records TTL(Time to Live)

Client 가 Amazon Route 53에 DNS 요청을하면 TTL과 함꼐 Public IP 를 반환한다. 그떄 TTL을 캐시에 저장하고 다음에 재요청이 들어온다면 그냥 Route 53 에 요청을 보내지 않고 캐시에서 바로 보낼수 있다.

결국 TTL 은 말 그대로 살아있는 시간이라는것.
만약 이 TTL 을 24시간으로 한다면 요청하는 횟수는 줄어들수 있지만 실제 Instance 에서 변경된 값을 받지 못할수있다. Cache 에 저장된 값을 가져오기때문

반대로 TTL 값을 짧게 지정한다면 너무 많은 요청 횟수가 생길꺼지만 가장 최신 값을 가져올수있다는 장점도 있다.
그냥 상황에 맞게 사용하면 된다고 한다.

TTL 은 모든 Record 에 필수라고 한다.
Alias 제외.

CNAME vs Alias

AWS Resource 들은 AWS Hostname을 노출하게 된다.
보유한 도메인에 호스트 이름을 매핑할수 있는데 myapp.example.com 을 LB에 매핑하는것이다.

CNAME 은 아까 설명한것처럼 호스트 이름이 다른 호스트 이름으로 라우팅 될수 있는것이다.
app.example.com 도메인이 test.anything.com 으로 라우팅될수있다는것.
근데 CNAME 은 root 도메인 이름이 아닐떄만 가능해서 example 앞에 뭐가 붙어있어야한다. app.example.com 이런것처럼..

그리고 Alias 는 호스트 이름이 AWS resoure로 라우팅 될수있따고한다.
LB나 CloudFront 같은것으로!

Alias는 root,non root 둘다 작동한다. example.com을 사용해서 aws resource로 향할수 있게한다.

이런 Alias 는

Elastic Load Balancer
CloudFront Distributions
API Gateway
Elastic Beanstalk environments
VPC Interface Endpoints
Global Accelerator accelerator
동일한 호스트 존의 Route 53

로 라우팅 될수 있다고 한다.

Route 53 - Routing Policies

Route 53이 DNS 쿼리에 응답하는것을 돕는다고 한다.
DNS 는 Traffic 을 Routing 하지 않는다고 한다. DNS querie 에 대해서만 응답한다고 한다.

Simple

말처럼 가장 simple한 방법이다.
example.com 물어보면 11.22.33.44 를 알려주는것.
근데 Mulitple value를 설정할수도 있다.
그럴떈 랜덤으로 하나를 골라서 client 에 반환한다고 한다.

Weighted

요청의 일부 비율을 특정 리소스로 보낸다고한다.

instance 가 3개가 있고 각각 70,20,10 의 가중치를 가지고 있을때 (특정 값)/전체값으로 나누어서 그 확률로 접근을 할수 있게 한다고 한다.

여기선 상태확인또한 가능하다고한다.

지역간의 LB,새로운 application 테스트할때 유용하다고 한다.

모두 0이면 다 같은 확률로 접근.

난 여기서 LB 와 차이점이 뭔가가 궁금해짐

로드 밸런서(Load Balancer)와 가중 라우팅(Weighted Routing)은 모두 네트워크와 웹 서비스에서 트래픽을 관리하고 분산시키는 데 사용되지만, 그들 간에 몇 가지 중요한 차이점이 있습니다.

기능:

로드 밸런서: 로드 밸런서는 여러 대상 서버 간에 들어오는 요청을 분산하여 각 서버가 균형있게 작업을 처리할 수 있도록 돕는 장치 또는 시스템입니다. 주로 서버 부하 분산 및 장애 조치를 위해 사용됩니다.
가중 라우팅: 가중 라우팅은 특정한 요청 또는 트래픽에 대해 서로 다른 서버에 가중치를 할당하여 트래픽을 분산하는 방법입니다. 이를 통해 특정 서버에 더 많은 요청을 보내거나 특정 서버를 피할 수 있습니다.
적용 영역:

로드 밸런서: 주로 서버 부하 분산 및 고가용성을 위해 사용됩니다. 서버의 상태를 모니터링하고, 트래픽을 관리하여 네트워크 리소스를 최적으로 활용합니다.
가중 라우팅: 주로 특정한 비즈니스 요구 사항에 따라 트래픽을 조절하고 특정 서버로의 요청을 유도하기 위해 사용됩니다.
트래픽 분산 방식:

로드 밸런서: 주로 Round Robin, Least Connection, IP Hashing 등의 알고리즘을 사용하여 트래픽을 분산합니다.
가중 라우팅: 서버별로 가중치를 할당하여 트래픽을 분산합니다. 이를 통해 서버에 따라 트래픽의 비율을 조절할 수 있습니다.
유연성:

로드 밸런서: 다양한 서버 환경에서 사용 가능하며, 대부분의 네트워크 장비 및 서비스에서 제공됩니다.
가중 라우팅: 특정한 비즈니스 논리에 따라 트래픽을 제어하기 위해 보다 세부적인 설정이 필요합니다. 주로 클라우드 서비스나 DNS 서비스에서 제공됩니다.
요약하면, 로드 밸런서는 서버 부하 분산과 고가용성을 위해 사용되는 반면, 가중 라우팅은 특정한 비즈니스 요구 사항에 따라 트래픽을 조절하기 위해 사용됩니다. 또한 로드 밸런서는 트래픽 분산에 더 많은 옵션을 제공하는 반면, 가중 라우팅은 서버별로 가중치를 조절하여 트래픽을 분산합니다.

그렇다고 합니다.

Latency based

지연시간이 짧은 Resource 로 redirect 한다.
말그대로 us-east-1 에 있는 ALB, ap-sotueast-1 에 있는 ALB 가 있을때 지연시간 짧은 곳으로 연결해준다고 한다.
지역은 VPN 을 사용해서 간다고 한다.

Gelocation

실제 위치를 기반으로한다.
사용자의 실제위치임.
만약 프랑스면 11.22.33.44 , 독일이면 55.66.77.88 , 그 밖 기본들이라면 12.521.63.123 이런식으로 지역에 따라서 Routing policy 를 정할수 있다.

Geoproximity

지리기반으로 Traffic을 resource 로 routing 하는것이다.
편항을 줄수있다는 말인데 이건 사진을 보는게 빠르다.

이렇게 현재 US East 의 편항이 없을때 맨 왼쪽이고 줄이거나 늘려서 그 범위를 맞출수있다.

Geoproximity 는 편향을 늘리고 줄려서 한 region 에서 다른 region 으로 Traffic 보낼때 유용하다.

IP based Routing

사용자마다 각자의 IP 가 있다.
그 IP에 따라서 Routing 해주는것이다.

Multi-Value

Traffic 을 다중 resource로 routing 할때 사용한다.
최대 8개가 반환될수있고 Simple에서도 봤던 Multi value와는 다르게 Simple은 Health check가 없어서 반환되는것이 정상이 아닐수가 있는데 여기선 정상임이 보장된다.

Route 53 - Health Checks

만약 Weighted Policy 로 2 ALB 를 연결했다고 생각해보자.
A는 70,B는 30의 확률로 접근이 될것이다.
근데 만약 A가 불가능하다면 이것이 잘 돌아가나?
그렇지않다. 그래서 상태확인이 필요한것.

Health Checks - Monitor an Endpoint

15개의 Health Checker 가 Endpoint 를 체크해주는것이다.
기본은 3개고 만약 1개의 checker 가 Instance 에 request를 /health 로 날릴수있고 자신이 설정한 값 대로 체크가가능(짧을수록 비싸진다고함)

그리고 전체의 checker 중에서 18% 이상이 정상이라면 정상이라고한다..
2xx or 3xx status code 라면 정상이라함.

Calculated Health Checks

여러개의 확인 결과를 하나로 합쳐서 보는것이다.

Private Hosted Zones

Public Hosted zone 과 다르게 개인 or VPC를 통해서 접근이 가능해서 Private Endpoint 에 접근이 불가하다.
그래서 이떄는 cloudwatch Metric 만들어서 Health Checker 와 그것을 연결하고 모니터하면 된다.