AWS SAA : Route 53

DNS

호스트 이름을 대상 서버 IP 주소로 변환해주는 Domain Name System

DNS의 원리

1. Root DNS Server (Managed by ICANN)에 호스트 이름 물어봄 → TLD DNS Server에 물어보라는 답변을 받음
2. TLD DNS Server (Managed by IANA)에 호스트 이름 물어봄 → SLD DNS Server에 물어보라는 답변을 받음
3. SLD DNS Server (Managed by Domain Registrar)에 호스트 이름 물어봄 → 서버 IP 주소를 결과값으로 받음
4. 호스트 이름과 서버 IP 주소를 매핑한 결과를 캐싱한 뒤 사용자에게 알려줌
5. 사용자는 해당 서버 IP 주소로 접근할 수 있게 됨

DNS 용어 정리

• Registrar : 도메인 이름을 등록하는 곳 (Route 53, GoDaddy ,,)
• DNS Records : (A, AAAA, CNAME, NS, …)
• Zone File : DNS records 를 가지고 있는 것
• Name Server : DNS 쿼리를 실제로 해결하는 서버
• FQDM (Fully Qualified Domain Name) 의 계층적 구조
  • Root : (.)
  • Top Level Domain (TLD) : (.com., .us., .in.)
  • Second Level Domain (SLD) : (.amazon.com.)
  • Sub Domain : (.www.amazon.com.)
  • Domain : (api.www.amazon.com.)
  • Protocol : (http)

 

Route 53

고가용성, 확장성을 갖춘 완전히 관리되고 권한 있는 DNS

→ 권한 있다 = DNS를 완전히 제어할 수 있음

DNS 레코드들을 정의하고, 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의

각 레코드의 구성

• Domain / SubDomain Name
• Record Type
  • A : hostname - IPv4 매핑
  • AAAA : hostname - IPv6 매핑
  • CNAME : hostnameA - hostnameB 매핑
    • ex) app.mydomain.com → blabla.anything.com
    • 루트 도메인이 아닐 때만 가능 (ex. something.mydomain.com)
  • Alias : 호스트 이름이 특정 AWS 리소스로 향하도록 만듦
    • ex) app.mydomain.com → blabla.amazonaws.com
    • 루트 및 비루트 도메인 모두 가능 (ex. mydomain.com)
    • DNS의 확장 기능
    • 리소스
      • ELB, CloudFront Distributions, API Gateway, Elastic Beanstalk environments, S3 Websites, VPC Interface Endpoints, Global Accelerator, Route 53 record in the same hosted zone
      • EC2 DNS 이름은 리소스 대상이 아님
      • S3 bucket도 리소스 대상이 아님
    • 리소스의 IP 주소가 변경되면 자동으로 감지
    • 리소스는 IPv4, IPv6
    • TTL 설정 불가
  • NS : Hosted Zone을 위한 Name Server → DNS 이름이나 IP주소를 실제로 해결. 트래픽이 도메인으로 라우팅되는 방식을 제어
• Value : IP주소
• Routing Policy : Route53이 DNS 쿼리에 대답하는 방법
  • Simple
    • 일반적으로 사용하는 것으로, 트래픽을 단일 리소스로 보내는 것
    • 동일 레코드에 대해 여러 값이 존재할 수 있기에, 만약 여러 값이 리턴될 경우 클라이언트는 그 중 하나를 랜덤으로 선택
    • 상태 확인 불가
  • Weighted
    • 가중치에 따라 요청의 일부 비율을 특정 리소스로 보내는 것
    • 상태 확인 가능
    • 서로 다른 지역들에 걸쳐 로드 밸런싱을 하거나 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우에 사용
    • 가중치 0이면 특정 리소스에 트래픽 보내기를 중단할 수 있음. but, 모든 인스턴스에 대한 가중치가 0이면 동일한 가중치가 적용됨
  • Failover
    • Active-Passive
    • 주요 인스턴스에 대해 상태 확인을 연결해두고, 여기서 fail이 발생하면 보조 인스턴스로 연결
  • Latency based
    • 지연시간이 가장 짧은, 즉 가장 가까운 리소스로 보내는 것
    • 상태 확인 가능
  • Geolocation
    • 사용자의 실제 위치를 기반으로 하여 가장 가까운 리소스로 보내는 것
    • Default record를 반드시 생성해야 함
    • 상태 확인 가능
  • Multi-Value Answer
    • 다중 리소스로 라우팅할 때 사용
    • Route 53은 다중 값과 리소스를 변환
    • 상태 확인과 연결
    • 각각의 Multi-Value Query에 최대 8개의 정상 레코드 반환 가능
    • ELB와 유사하지만, 이를 대체할 순 없음
  • Geoproximity (using Route 53 Traffic Flow feature)
    • 지리 근접 라우팅 : 한 리전에서 다른 리전으로 트래픽을 보내는 것
    • 사용자와 리소스의 지리적 위치를 바탕으로 트래픽을 리소스로 라우팅
    • bias를 사용해 리소스에 더 많은 트래픽을 보내는 것
      • 특정 리소스에 더 많은 트래픽을 보내려면 bias를 증가시킴
    • 리소스 : AWS region이 명시된 AWS resource, 위도와 경도가 명시된 Non-AWS resource
  • IP-based
    • 클라이언트 IP 주소를 기반으로 정의
    • Route53에서 locations이나 endpoints에 대한 CIDR 목록을 정의. CIDR에 따라 트래픽을 어느 로케이션으로 보내야하는지 자동으로 정할 수 있음. → 성능 최적화, 네트워크 비용 절감
• TTL : DNS Resolver에서 레코드가 캐싱되는 시간
  • Time To Live
  • Alias record를 제외하고는 필수적으로 지정해야 함
  • 클라이언트에게 TTL(ex. 30초)동안 ‘레코드 타입, IP주소’를 캐시 요청 → DNS 요청 쿼리를 계속 자주 보내는 것을 방지.
  • TTL이
    • 너무 길 경우 : Route 53에 대한 트래픽은 적지만, 오래된 레코드를 가지고 있을 확률이 큼
    • 너무 짧을 경우 : Route 53에 대한 트래픽이 많지만, 최신 레코드를 가지고 있을 확률이 큼 → 레코드를 바꿔도 괜찮음

Hosted Zone : 레코드의 컨테이너

• 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식 정의
• 종류
  • 퍼블릭 호스팅 존 : 퍼블릭 도메인 이름을 살 때마다 만들어짐
  • 프라이빗 호스팅 존 : 공개되지 않은 도메인 이름으로, 가상 프라이빗 클라우드 (VPC)만이 URL을 resolve 할 수 있음

클라우드 쉘/터미널 에서 dig (mac) , nslookup (window) 명령어를 이용하여 호스트네임을 입력하면 레코드에 대한 정보가 추출됨

상태 확인 (Health Check)

: public resource를 위한 것

: 하나의 리소스에 장애가 생겼을 경우, 상태를 확인하고 다른 리소스에 보내기 위함

• Endpoint Monitoring (애플리케이션, 서버, 리소스)
  • 15개의 global healtch checker가 상태를 확인함
  • 18% 이상의 헬스 체커가 정상이라고 판단하면, 리소스는 정상임
  • HTTP, HTTPS, TCP 프로토콜 지원
  • 간격은 30초. (10초 설정 가능하나 비용이 더 듬)
  • 2xx, 3xx response만 상태확인 통과
  • 텍스트 기반 응답일 경우, 응답의 처음 5120바이트를 확인하고 응답 자체에 해당 텍스트가 있는지 보기 위함
  • 네트워크 관점에서 아주 중요함 → 상태 확인 작동이 가능하려면, 엔드포인트의 incoming requests를 허용해야 함
• Calculated Health Check (다른 상태 확인을 상태 확인)
  • endpoint(최대 256개)에 대한 상태 확인 결과들을 하나로 합쳐 줌
  • 하위 상태 확인을 바탕으로 상위 상태 확인을 정의
  • 이때, pass를 정하는 기준도 설정 가능
  • OR, AND, NOT을 활용함
• Cloudwatch Alarm (← private resource에 유용)
  • 개인이 리소스를 모니터링하는 것이 어려움 → CloudWatch 지표 사용
  • CloudWatch를 활용하여 private subnet 의 instance를 모니터링하고, 메트릭이 침해되는 경우 CloudWatch 알림을 보내짐. 알림이 보내지면 비정상이라는 뜻이므로 상태 확인이 fail로 간주