[SAA] Route53

Notation

• Domain 등록 대행자: Route53, 가비아, GoDaddy 등등
• DNS 레코드: DNS를 처리하는 방식 지침 (종류: A / TXT / CNAME / NS / AAAA)
• Zone File: DNS 레코드를 담은 파일
• 네임서버: DNS 쿼리를 처리하는 서버
• TLD(Top Level Domain): .com / .org / .kr 등등..
• SLD(Second Level Domain): naver.com / gmail.com 등등..
• 프로토콜(https) - 서브도메인(kangwlgns) - SLD(tistory) - TLD(.com) (https://kangwlgns.tistory.com)
• 루트도메인 = SLD + TLD

DNS 동작

1. DNS를 줘서 IP를 달라고 요청
2. 로컬 DNS 서버 확인. 있으면 IP 반환
3. 로컬에 없으면 Root DNS server(로컬이 주소를 앎)에서 확인. 있으면 IP 반환
4. Root DNS Server에 없으면 알맞는 TLD DNS server(Root가 주소를 앎)에서 확인. 있으면 IP 반환
5. TLD DNS server .. 이하 생략

---

Route53

• 고가용성, 확장성
• 완전 관리형
• 사용자가 DNS 레코드 업데이트 가능
• 도메인 등록 대행업체 역할도 함 (가비아가 더 싸면 거기서 사면 된다.)
• 리소스에 대한 헬스 체크 진행
• AWS에서 유일하게 100% 가용성 보장

레코드

• 도메인에 접근하는 트래픽을 어떻게 라우팅할지 결정
• 구성요소
  • 키 - 도메인 또는 서브 도메인명
  • 레코드 타입(Route53에서는 A / AAAA / CNAME / NS만 지원)
  • 값 - IP 또는 다른 도메인 이름 등등
  • 라우팅 정책
  • TTL(time to live) - Resolver가 레코드를 보존하는 기간

레코드 타입

• A
  • 호스트명과 ipv4를 연결.
  • 가장 기본적
• AAAA
  • 호스트명과 ipv6를 연결
• CNAME
  • 호스트명과 호스트명을 연결
  • 대상 호스트는 반드시 A 혹은 AAAA 레코드여야 한다.
  • CNAME은 최상위일 수 없다. (대상이 IP가 아니기 때문)
  • 그러므로 서브 도메인으로만 생성할 수 있다.
• NS
  • 호스트존 네임서버를 위한 타입
  • 도메인 내부 트래픽 라우팅을 관리
  • 특정 네임서버를 갖는 쪽으로 라우팅한다.

Hosted Zone

• 도메인과 서브 도메인에 대한 트래픽 라우팅 관장
• public Hosted Zone: 인터넷 상에서 들어오는 트래픽에 대한 라우팅 레코드 정의
• private Hosted Zone: 한개 또는 여러 개의 VPC 내부망에서 트래픽 라우팅 레코드 정의
• 0.5달러

Record TTL

• DNS 정보(record)에 대한 클라이언트의 캐싱 시간
• 높은 TTL
  • 24h 이상
  • Route53 트래픽 감소 및 비용 감소
  • 그러나 캐싱이 늘 그렇듯이 변경에 대한 반영이 늦음
  • 액세스 로그를 확인해서 기존 DNS의 요청이 끊긴 것을 확인한 후에 변경할 수 있다.
• 낮은 TTL
  • Route53 트래픽 증가
  • 레코드 변경을 자주해야하거나 변경이 필요한 경우 사용이 용이 (ex. 레드그린 배포)
  • 비용이 많기 때문에 필요할 때만 낮추자.
• Alias 레코드는 적용되지 않음
• TTL은 레코드별로 필수적으로 적용해야 함.

Alias vs CNAME

• AWS 리소스 중 자체적으로 AWS 호스트명을 가지는 경우가 있음 (ex. RDS, ELB 등등)
• 얘네가 너무 리소스같으니까 가리려는 목적으로 나온 것이 Alias
• CNAME
  • 다른 도메인을 바라보는 호스트이름
  • 서브 도메인에만 적용 가능
• Alias
  • AWS 리소스에 대한 별칭 생성이 목적(이름 세탁하기)
  • 루트 도메인과 서브 도메인 모두 적용 가능
  • 자체적으로 헬스체크
  • IP 변경을 자동으로 인지
  • Route53 비용 별도 청구 X
  • 항상 A / AAAA 레코드임
  • TTL 별도 지정 불가
  • 같은 hosted zone 내부의 record까지도 타깃으로 적용 가능
  • EC2에는 사용 불가

---

헬스 체크

• HTTP 헬스 체크는 public 리소스에서만 사용 가능
• 헬스 체크를 통해 자동화된 DNS Failover 가능 (동작하지 않는 리소스 대신 대체 가능한 녀석 불러옴)
• 헬스 체크는 cloudwatch metric으로 확인 가능
• VPC 바깥에서 동작함 (router 또는 방화벽을 적절히 설정해야 헬스 체크를 받을 수 있음)

헬스 체크 역할

• 엔드포인트에 대한 헬스 체크 진행
  • 15개의 헬스 체커가 기본적으로 3번 시도함 (한번이라도 성공하면 됨)
  • 30초 단위로 체크
  • HTTP / HTTPS / TCP 기반으로 헬스체크 진행
  • 18% 이상의 헬스 체크가 통과하면 healthy로 판단
  • 헬스 체크 진행 위치 설정 가능
  • 2xx, 3xx인 경우만 pass로 판정
  • 첫 5120 바이트 이내의 텍스트를 기반으로 p/f 판정 가능
• 다른 헬스 체크 모니터링 (계산된 헬스 체크)
  • 여러개의 헬스 체크 결과를 묶어서 하나로 관리
  • OR / AND / NOT 구문을 사용
  • 256개까지의 하위 헬스 체크 모니터링 가능
  • p/f를 몇개 이상 통과했을 때 healthy로 판단할 수 있는지 셋팅 가능
  • 전체 헬스체크가 실패하기 전 사이트 관리에 사용 가능
• Cloudwatch를 통해 모니터링 가능
  • private network 내부에 존재하는 리소스에 대해 헬스체크하기 위한 방법
  • Cloudwatch metric과 cloudwatch alarm을 기반으로 헬스 체크를 설정

---

라우팅 정책

• DNS 쿼리에 대해 Route53이 응답하는 방식
• 로드 밸런서의 트래픽 라우팅은 부하 분산이 목적이라면, 라우팅은 라우팅 테이블에 가깝다.

라우팅 정책 종류

• simple
  • 단일 리소스에 대한 라우팅
  • 동일 DNS에 여러개 레코드 설정 가능
  • 여러 값이 매핑 돼있다면, 클라이언트가 랜덤하게 하나 선택
  • Alias가 설정된 경우, 하나의 리소스만을 지정해야 함.
  • 헬스체크 불가능
• Weighted
  • 비중에 따른 정책
  • 요청에 대해 % 단위로 특정 리소스에 할당
  • 각 레코드에 상대 비중을 둔다. (비중의 합이 100은 아님)
  • 각 레코드는 모두 같은 이름과 타입이어야 한다.
  • 헬스 체크 가능
  • 리전간 로드밸런싱하거나 신규 애플리케이션을 테스트할 때 사용
  • 0%으로 설정하면 라우팅 안함
  • 모든 레코드가 0%이면 동일한 비율로 요청 분산
• Latency
  • 적은 지연시간이 있는 리소스로 리다이렉트
  • 지연시간이 중요한 서비스에 적절
  • 사용자와 리전간의 트래픽에 기반
  • 물론 지역성이 아닌 지연시간에 의존하기에 지역이 멀더라도 지연시간만 적다면 리다이렉트함.
  • 헬스 체크 가능
• Failover
  • 하나의 메인 엔드포인트
  • 메인이 실패하는 경우 서브로 라우팅 전환
  • 장애 대응을 위해 구성
  • 동일 스펙 서버를 여러 개 띄우는 것이 아닌, 서비스가 정상적이지 않을 때 일시적으로 보여줄 페이지를 띄울 때 사용.
• Geolocation
  • 지연 시간과 관계 없이 지역에 따라 라우팅
  • 리전에 속하면 그곳으로 바로 보냄
  • 땅 덩어리가 넓으면 주에 따라 위치를 지정
  • 매칭되지 않는 경우 요청을 보낼 기본 레코드를 생성해야 함.
• Geo proximity
  • 지역보다는 거리 기반으로 라우팅
  • 지정된 bias를 기반으로 세밀하게 라우팅 가능
  • 지리적 리전의 사이즈를 조정하려면 bias 값(-99 ~ 99) 지정
  • 클라우드 환경 + 온프레미스를 동시에 운영하는 경우에도 사용 가능
  • AWS 리소스의 경우 리전 기반으로 라우팅
  • AWS 리소스가 아닌 경우 위경도 좌표를 입력해서 라우팅
  • Route53 Traffic Flow 기능을 사용해야 함(비용 별도)
• IP 기반 라우팅
  • 사용자 IP 주소를 기반으로 라우팅
  • 사용자 IP CIDR를 입력
  • 성능 향상 및 네트워크 비용 감소를 위해 설정
• 다중 응답 라우팅 정책
  
  • 트래픽을 여러 리소스로 라우팅하기 위해 사용
  • 여러개 값과 리소스 반환
  • 헬스체크와 함께 사용 가능
  • 최대 8개의 healthy 상태 리소스 반환 가능
  • ELB 대체 목적으로 사용하지 말것