[SAA] 3. Route53

• udemy 강의 기준 sec10까지의 내용 정리 
• 전체 내용을 정리하기보단, 몰랐었던 내용과 정리하고 싶은 부분들을 중점으로 정리합니다 
• 공부하면서 들었던 짧은 생각과 고민도 정리합니다 
• 틀린 내용이 있다면 댓글로 알려주세요 감사합니다 

---

section 10.

section 10에서는 Route 53에 대해서 다룬다. 웹 서버를 배포하면서 도메인 연결할때 한번쯤은 써본 AWS 서비스라고 생각된다. 하지만 이전에는 DNS 등에 대한 지식이 미흡한채로 개발을 진행했었는데 이번 기회를 통해 어떤식으로 DNS 쿼리가 이루어지는지, name server는 무엇인지 등등에 대한 다양한 지식을 학습할 수 있었다. 

 

DNS? 

먼저 DNS란 무엇인지 기초적인 내용을 정리해보겠다.

 

DNS는 어떻게 작동할까? 

1. DNS는 먼저 웹 브라우저(클라이언트)가 example.com이라는 사이트에 접근하고 싶을때, local DNS 서버에 example.com의 주소를 알고 있는지 묻는다. 만약 알고 있다면 사이트의 ip주소를 보내준다. -> Non-Authoritative 응답 
2. 만약 모른다면 Root DNS Server에 example.com을 알고 있는지 묻는다. 그러면 .com과 같은 TLD(Top Level Domain)의 정보를 보내준다. 
3. 다음으로 TLD DNS Server에 example.com의 정보를 알고 있는지 묻고, 그러면 exmple.com의 NS(네임서버)의 정보를 보내준다. 
   • Name Server?
     • 도메인 이름과 IP 주소 매핑 정보를 가진 서버
     • DNS 쿼리에 응답하는 실제 물리적/가상 서버
     • root name server, tld name server, sld name server(=authoritative DNS server) 
4. 다음으로 SLD(Second Level Domain) DNS Server(=Authoritative DNS Server) 에 example.com의 정보를 알고 있는지 묻고, 서버는 example.com의 IP주소를 알려준다. 그 후, 로컬 DNS 서버에 해당 도메인의 정보를 저장하여(TTL동안 저장됨) 웹 브라우저(클라이언트)로 전달을 해줌으로써 도메인 사이트에 접근할 수 있게 된다. -> Authoritative 응답 

왜 이 순서(root->tld->sld)로 묻냐면, DNS는 오른쪽부터 왼쪽으로 읽는 순서이기 때문이다. .com -> example -> www 순으로 읽는다고 생각하면 이해하기가 편하다. 

 

 

Route 53 

Amazon Route 53은 고가용성, 고확장성, 완전관리형, Authoritative DNS(=사용자가 DNS 레코드 업데이트 가능하다는 의미)이며, Domain Registrar이기도 하다. 또한, Route 53는 AWS에서 유일하게 100% SLA(Service Level Agreement)를 제공하는 서비스이다(DNS 쿼리는 절대 실패하지 않고, 실패 시 AWS가 크레딧 보상, 완벽한 가용성 보장을 한다는 의미이다). 

 

Record

특정 도메인으로 트래픽을 어떻게 라우팅하는지의 방법을 정의한다. 각 레코드는 도메인/서브도메인 이름, 레코드 타입, 값, TTL, 라우팅 정책을 포함하고 있다. 

레코드 유형은 다음이 존재한다 

• A: 호스트네임을 IPv4로 매핑한다 
• AAAA: 호스트네임을 IPv6로 매핑한다 
• CNAME: 호스트네임을 다른 호스트네임으로 매핑한다 
  • 타겟이 되는 다른 호스트네임은 A or AAAA 레코드여야만 한다 
  • DNS namespace or zone apex의 상위 노드에 대한 CNAME 생성이 불가능하다! 
    • ex. www.example.com에 대한 CNAME은 생성이 가능하지만, example.com에 대해서는 생성이 불가능하다  
    • DNS namespace? : 도메인 이름의 전체 계층 구조를 의미 
    • Zone Apex? : Root domain과 같은 것. 서브 도메인이 붙지 않은 도메인을 일컫는다 
      • ex. example.com은 zone apex지만, www.example.com은 아님 
• NS: 호스팅 존의 이름 서버 
  • 트래픽이 도메인으로 라우팅되는 방식을 제어하고, 호스팅 존에 대한 DNS 쿼리에 답할 수 있게 해준다 

 

Hosted Zone 

도메인, 서브도메인으로 가는 트래픽의 라우팅 방식을 정의하는 레코드를 위한 컨테이너를 호스팅 존(Hosted zone)이라 부른다. 크게 2가지 유형이 존재한다. 호스팅존은 매달 0.5달러를 지불한다. 

1. Public Hosted Zones
   • 인터넷에서 접근이 가능한 public domain names에 대해 트래픽을 어떻게 라우팅할지를 명시한 레코드들을 포함하고 있음
2. Private Hosted Zones
   • 1개 이상의 VPCs 즉, private한 domain names에 대해 어떻게 트래픽을 라우팅할지에 대해 명시한 레코드들을 포함하고 있다 

 

CNAME vs Alias

AWS resources 중에는 로드밸런서, 클라우드프론트 등과 같이 AWS hostname을 노출하는 resources가 존재한다. 예를 들어

lb1-1234.us-east-2.elb.amazonaws.com 등 이런 형식인데, Alias와 CNAME은 호스트네임을 이러한 AWS 리소스로 가리키도록 도와줄 수 있다.
CNAME은 오직 루트 도메인이 아닌 도메인(example.com이 아닌, www.example.com)만에 대해 CNAME을 만들 수 있다.  

그 반면, alias는 루트 도메인뿐만 아니라 루트 도메인이 아닌 도메인에 대해서도 가리킬 수 있다. 무료이며, 자체적으로 상태 확인(헬스 체크)가 가능하다. 또한 호스트네임을 AWS 리소스에 매핑하는데 사용되며, 자동적으로 리소스의 IP 주소에 변동이 있을때 이를 알 수 있다. Alias의 레코드는 항상 A/AAAA 타입이다. 그러나, TTL을 사용자가 설정할 수 없다(이는 Route 53이 자동으로 설정한다). EC2 DNS 이름에 대해서는 Alias 레코드 타겟이 되지 못하니 기억하자! 

 

Routing Policies 

라우팅 정책은 Route 53이 어떻게 DNS 쿼리에 응답할지를 정의한다. 이 라우팅 정책에는 여러가지 옵션들이 존재한다. 

1. Simple
   • 일반적으로는 트래픽을 단일 리소스로 보내는 방식이지만, 같은 레코드에 대해 여러개의 값으로 명시해줄 수 있음 
   • 같은 레코드에 대해 여러개의 값을 클라이언트가 받는다면, 클라이언트는 이들 중 하나를 라우팅에 적용한다 
   • Alias가 적용된 경우는 오직 단일 리소스로만 트래픽이 라우팅된다 
   • health check가 안된다! 
2. Weighted
   • 각 특정한 리소스에 대해 요청의 비율을 명시해둔 것으로, 가중치 값이 클수록 해당 특정 리소스에 라우팅될 확률이 높다
   • DNS 레코드들은 모두 같은 이름과 유형이어야한다 
   • 가중치들의 합은 무조건 100이 될 필요가 없으며, 만약 어떤 가중치의 값이 0이면 해당 리소스로는 트래픽을 보내지 않는다 
   • 만약 모든 레코드들의 가중치값이 0이면, 모든 레코드들에 대한 트래픽 라우팅을 동등하게 보낸다 
   • 리전 사이에서 로드 밸런싱을 할때, 새 애플리케이션 버전을 테스트할 때 사용된다 
3. Failover
   • 재해 복구를 위한 옵션이다 
   • 만약 primary ec2 와 secondary ec2가 존재한다면, primary 에 대한 Health check가 실패시 자동으로 secondary ec2로 유저 요청을 라우팅하도록 한다 
4. Latency based
   • 지연시간이 중요한 경우, 지연시간이 가장 짧은 가장 가까운 리전으로 리다이렉트되도록 한다 
   • 지연시간은 유저와 AWS 리전 사이의 트래픽을 기반으로 한다 
   • health check 사용이 가능하다 
5. Geolocation
   • latency-based와는 다르게, 유저의 위치를 기반으로 라우팅한다 
   • 대륙, 국가, 미국 주 등과 같이 지역을 명시하고 그 외의 지역들에 대한 default 레코드를 생성한다 
   • health check 사용이 가능하다 
6. Multi-Value Answer
   • 여러개의 리소스들로 트래픽을 라우팅할때 사용하며, Route 53은 여러개의 values/resources를 리턴해준다 
   • 클라이언트는 최대 8개 정도의 records를 받고, 이 중 하나를 선택하게 된다 
   • health check 사용이 가능하다 -> 최대 8개까지의 healthy records가 각 Multi-value 쿼리로부터 리턴될 수 있다 
   • multi-value는 ELB를 대체할 수 없다. 왜냐하면 이는 클라이언트 측면에서의 로드 밸런싱이기 때문이지, 서버 측면의 로드 밸런싱이 아니기 때문이다. 
   • simple routing과 다른 점 
     • simple 도 마찬가지로 여러개의 레코드 값들을 클라이언트가 받을 수 있으나, 리턴받는 값들 중 하나는 unhealthy일 가능성이 있다. (simple은 health check 사용이 불가능하다) 
     • 그러나 multi-value answer의 경우 마찬가지로 여러개의 레코드 값들을 클라이언트가 받지만, health check 사용이 가능하기 때문에 받은 8개 중의 레코드들 중 1개 또는 최대 8개의 레코드가 healthy일 것을 알 수 있기 때문에 client가 항상 안전한 쿼리를 가질 수 있게 된다 
7. Geoproximity (using Route 53 Traffic Flow feature)
   • 유저들과 리소스들의 지리적 위치를 기반으로 리소스들로 트래픽을 라우팅한다 
   • 사용자가 정의한 편향값(bias)에 따라서 리소스들로 트래픽을 얼마나 더 이동시킬지를 설정할 수 있다 
   • 1-99의 편향값은 그 리소스에 대해 더 많은 트래픽을 보내도록 하며, 
   • -1- -99는 그 리소스에 대해 트래픽을 덜 보내도록 한다 
   • 타겟 리소스들은 AWS resource가 될 수 있고(이 경우 AWS 리전으로 명시해야함), non AWS resource도 될 수 있다(이 경우 위도, 경도를 명시해야함)
   • geoproximity 설정을 사용하기 위해서는 Route 53 Traffic Flow를 사용해야만 한다 
8.  IP-based Routing 
   • 라우팅은 클라이언트의 IP 주소에 근거하여 이루어진다 
   • 클라이언트들에 대한 CIDRS의 목록을 정의하고, CIDR에 따라 어느 로케이션/엔드포인트로 보내야하는지 정한다 
   • 예를 들어, 특정한 IP 주소들에 대해 특정한 엔드포인트로 라우팅해야할때 사용할 수 있다 
   • 성능을 최적화하고, 네트워크 비용을 감소시키는데 유용하다 

 

Route 53 Health Checks 

DNS에 대한 장애조치를 자동화할 수 있도록 헬스 체크(상태확인)가 가능하다. health checks는 CloudWatch metrics와 통합이 가능하며, 3가지 정도의 방법이 존재한다 

1. Monitor an Endpoint
   • 약 15개 정도의 글로벌 health checkers가 endpoint의 상태를 확인한다 
     • HTTP, HTTPS, TCP 프로토콜을 지원 
     • healthy/unhealthy의 임계값이 3 (디폴트값) 
     • health checkers의 18% 이하가 endpoint가 healthy하다고 보고하면, route 53은 이를 healthy하다고 판단하며 그 외는 unhealthy라고 판단한다 
     • route 53이 어떤 로케이션을 사용하면 될지 고르는데 도움을 줄 수 있다 
   • Route 53 health checkers로부터의 요청을 받을 수 있도록 Route, firewall을 설정해야한다 
2. Calculated Health Checks
   • 여러개의 health checks의 결과들을 하나의 health check로 결합한다 
   • OR, AND, NOT 사용이 가능하며 
   • 256개까지의 child health checks를 사용 가능하다 
   • 얼마 정도의 health checks가 pass해야 부모도 pass할 수 있는지를 명시한다 
3. Private Hosted Zones 
   • Route 53 health checkers가 VPC 외부에 존재한다. 따라서 private endpoints나 on-premises resource에 대해서는 상태 확인 검사를 하기 위해 접근이 불가능하다 
   • 그 대신, CloudWatch Metric을 만들어 이를 CloudWatch Alarm과 연결함으로써, alarm을 체크하여 상태확인을 할 수 있다 

 

 

---

 

일단은 Route53에 대해 정리를 해보았다. 

나머지 섹션들에 대한 내용들도 차차 정리할 것이지만, 강의를 들은 순서대로 정리하기보다 덤프 기출 문제를 풀면서 헷갈리거나 몰랐던 내용들을 위주로 더 정리할 것 같다.