- DNS(Domain name service)
URL <-> IP 변환- Domain Registrar: 도메인 이름을 등록하는 곳(Route 53, GoDaddy, ...)
- DNS Records: A, AAAA, CNAME, NS
- Zone File: 모든 DNS 레코드를 포함하는 파일
호스트 이름과 IP를 일치시키는 방법 - Name Server: DNS 쿼리를 실제로 해결하는 서버
- Top Level Domain(TLD): .com, .kr, .in, .gov, .org, ....
- Second Level Domain(SLD): google.com, amazon.com, ...
<FQDN(Fully Qualified Domain Name)>
Route 53
- Route 53: 고가용성, 확장성, 권한을 갖춘 DNS(도메인 레지스트라)
- 권한이란? DNS 레코드를 사용자가 업데이트 가능.
- route 53의 리소스 관련 상태를 확인할 수 있다.
- 100% SLA 가용성을 제공하는 유일한 AWS 서비스
서비스 수준 계약(SLA): 공급업체가 고객에게 제공하기로 약속한 서비스 수준을 명시하는 아웃소싱 및 기술 공급업체 계약 - DNS 레코드를 정의하고 정의한 레코드로 특정 도메인으로 라우팅하는 방법을 정의
- Route 53에서 기록하는 정보
- 도메인/서브 도메인 정보
- 레코드 종류
꼭 알아야하는 것: A, AAAA, CNAME, NS
고급 레코드: CAA, DS, MX, NAPTR, PTR, SOA, TXT, SPF, SRV- A 레코드
호스트 이름과 IPv4매핑 - AAAA 레코드
호스트 이름과 IPv6 매핑 - CNAME
호스트 이름을 다른 호스트 이름과 매칭
대상 호스트가 A나 AAAA레코드가 될 수 있다.
Route 53에서 DNS 이름 공간이나 Zone Apex의 상위 노드에 대한 CNAMES를 생성할 수 없다.
-> example.com에 CNAME을 만들 수 없지만 www.example.com에는 CNAME을 만들 수 있다. - NS
호스팅 존의 이름 서버
서버의 DNS 이름 또는 IP 주소로 호스팅 존에 대한 DNS 쿼리에 응답할 수 있다.
트래픽이 도메인으로 라우팅 되는 방식을 제어
- A 레코드
- 값
123.456.789.123 - 라우팅 정책
route 53이 쿼리에 응답하는 방식 - TTL
DNS 리졸버에서 레코드가 캐싱되는 시간
- 호스팅 존(레코드의 컨테이너)
도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의- 종류
- 퍼블릭 호스팅 존
퍼블릭 도메인 이름을 살 때마다 퍼블릭 호스팅 존을 만들 수 있다.
퍼블릭 존은 쿼리에 도메인이름의 IP가 무엇인지 알 수 있다.
ex) application1.mypublicdomain.com - 프라이빗 호스팅 존
공개되지 않는 도메인 이름을 지원
가상 프라이빗 클라우드(VPC)만 URL을 리졸브 가능.
ex) application1.compant.internal
- 퍼블릭 호스팅 존
- 종류
- Record TTL(Time To Live)
- TTL: 클라이언트에세 결과를 캐시하도록 요청
즉, 클라이언트가 TTL 시간 내에 재요청을 하거나 같은 호스트 이름으로 접속하면
클라이언트는 DNS에 쿼리를 보내지 않고 접속할 수 있다. - TTL을 높게 설정한 경우(TTL = 24h)
트래픽은 적어지겠지만 클라이언트가 오래된 레코드를 받을 가능성이 생긴다. - TTL을 짧게 설정한 경우(TTL = 60s)
DNS는 트래픽이 많이 발생해 비용이 많이 들게 될 것 이다.
레코드 변경이 빨라질 것이다. - 즉, TTL 설정은 상황에 따라 적합할지 다르다.
- TTL: 클라이언트에세 결과를 캐시하도록 요청
- CNAME vs Alias
로드 밸런서나 CloudFront등 AWS의 리소스를 사용하는 경우 호스트 이름이 노출되게 된다.
또한 보유한 도메인에 호스트 이름을 매핑하려고 할 수 있다.
그럴때 2가지 옵션을 사용한다.- CNAME(도메인 이름)
- 호스트 이름이 다른 호스트 이름으로 향하도록 한다.(app.example.com -> gogo.domain.com)
루트 도메인 이름이 아닌 경우에만 가능하기때문에 example.com앞에 무언가 붙어야 한다.
- 호스트 이름이 다른 호스트 이름으로 향하도록 한다.(app.example.com -> gogo.domain.com)
- Alias(AWS 서비스)
- 호스트 이름이 특정 AWS 리소스로 향하도록 한다.(app.example.com -> gogo.amazonaws.com)
Route 53 한정
루트/비루트 도메인 모두 작동한다.
도메인 이름을 통해 AWS 리소스로 향하게할 수 있기 때문에 유용하다.
무료이다.
자체적으로 상태 확인이 가능하다. - AWS의 리소스에만 매핑이 되어 있다.
DNS의 확장 기능으로 시중의 모든 DNS에서 가능하다.
만약 ALB에서 IP가 바뀌면 Alias는 이것을 바로 인식할 것이다. - CNAME과는 달리, Alias는 Zone Apec라는 DNS 네임스페이스의 상위 노드로 사용될 수 있다.
- AWS 리소스를 위한 Alias 레코드 타입은 A또는 AAAA이다.
- Alias를 사용하면 TTL를 따로 설정할 수 없다.
Route 53이 자동으로 설정해준다. - Alias 레코드의 대상
EC2 DNS 이름에 대해서는 Alias 설정 X- ELB
- CloudFront 배포
- API Gateway
- Elastic Beanstalk
- S3 Websites
S3 버킷 X - VPC 인터페이스 엔드포인트
- Global Accelerator
- 동일 호스트 존의 Route 53
- Alias 사용하기
만들어 놓은 도메인 -> 레코드 생성 -> Record type(A or AAAA), value옆에 있는 Alias 클릭 후 서비스/지역 선택
- 호스트 이름이 특정 AWS 리소스로 향하도록 한다.(app.example.com -> gogo.amazonaws.com)
- CNAME(도메인 이름)
라우팅 정책
- 라우팅 정책
라우팅 정책은 Route 53이 DNS 쿼리에 응답하는것을 돕는다.
여기서 라우팅은 인스턴스로 라우팅이아닌 DNS관점
DNS는 트래픽을 라우팅하지 않음.-> 트래픽은 DNS를 통과하지 않음
DNS는 DNS 쿼리에만 응답하고 클라이언트들은 이를 통해 HTTP 쿼리를 어떻게 처리해야 하는지 알 수 있게 된다.
DNS는 호스트 이름들을 클라이언트가 실제 사용가능한 엔드 포인트로 변환하는 것을 돕는다.- 지원하는 정책
- 단순 정책
- 트래픽을 단일 리소스로 보내는 방식
- 동일한 레코드에 여러 개의 값을 지정하는 것도 가능하다
DNS에 의해 다중 값을 받는 경우는 클라이언트 쪽에서 무작위로 고르게 된다. - 단순 라우팅 정책에 Alias 레코드를 함께 사용하면 하나의 AWS 리소스만 대상을 지정 가능
- 상태 확인 X
- 가중치 기반 정책
- 가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내게 함.
- 각 레코드에 가중치를 할당해 설정
트래픽의 양(%) = 해당 레코드 가중치 / 전체 가중치
합이 꼭 100일 필요는 없다. - DNS 레코드들은 동일한 이름과 유형을 가져야 한다.
- 상태 확인 가능
- 가중치 기반 정책 사용처
- 서로 다른 지역들에 걸쳐 로드 밸런싱
- 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우
- 가중치 0의 값을 보내면 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있다.
만약 모든 가중치 값이 0이면 모든 레코드가 다시 동일한 가중치를 갖게 된다.
- 장애 조치 정책
- 상태 확인과 기본 레코드 연결은 필수적이다.
- 비정상일경우 자동으로 2번째 보조 인스턴스로 장애 조치한다.
- 지연 시간 기반 정책
- 지연 시간이 가장 짧은 리소스로 리다이렉팅
즉, 가장 가까운 리소스로 리다이렉팅 - 지연 시간에 민감한 웹사이트나 애플리케이션에 유용
지연 시간은 유저가 레코드로 가장 가까운 AWS 리전에 연결하기까지 걸리는 시간을 측정
ex) 독일과 미국중 리소스 지연시간이 짧은 리전으로 리다이렉팅 - 상태 확인과 연결 가능
- 지연 시간이 가장 짧은 리소스로 리다이렉팅
- 지리적 정책
- 지리 위치 라우팅 정책
지연시간 기반 정책과 다르게 실제 사용자 위치 기반으로 한다.
가장 정확한 위치로 그 IP로 라우팅
일치하는 위치가 없는 경우를 대비해 기본 레코드를 생성해야한다.- 사용 사례
콘텐츠 분산을 제한하고 로드 밸런싱 등을 실행하는 웹사이트 현지화 - 상태 확인과 연결 가능
- 사용 사례
- 지리 근접 라우팅 정책
사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅
이 정책으로 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽을 이동하는 것.- 지리적 위치를 변경하려면 편향값을 지정해야 한다.
특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜 확장하면 된다.
리소스에 트래픽을 줄이려면 편향값을 음수로 축소시키면 된다. - 리소스
- AWS 리소스
특정 리전을 지정하면 목록에서 자동으로 올바른 라우팅을 계산 - AWS 리소스가 아닌경우(온프레미스 데이터 센터 등)
위도와 경도를 지정해 AWS가 위치를 파악하도록 해야한다. - 기능을 선택하는데 편향 활용을 위해 고급 Route 53트래픽 플로우를 사용한다.
- AWS 리소스
- 지리적 위치를 변경하려면 편향값을 지정해야 한다.
- 지리 위치 라우팅 정책
- IP 기반 정책
- 클라이언트 IP 주소를 기반으로 라우팅을 정의
Route 53에서 CIDR 목록을 정의한다.
그리고 CIDR에 따라 트래픽을 어느 로케이션으로 보내야 하는지 정한다.
-> IP를 미리 알고 있어 성능을 최적화
-> IP가 어디에서 오는지 알기 때문에 네트워크 비용 절감할 수 있다. - 사용 예
인터넷 제공업체가 특정 IP주소 셋을 사용하는걸 알면 특정 엔드포인트로 라우팅할 수 있다.
- 클라이언트 IP 주소를 기반으로 라우팅을 정의
- 다중 값 응답 정책
- 트래픽을 다중 리소스로 라우팅할 때 사용
- Route 53은 다중 값과 리소스를 반환한다.
- 상태 확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련있다.
- 각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환된다.
- ELB와 유사해보이지만 ELB를 대체할 수 없다.
클라이언트 측면의 로드 밸런싱인 것. - 예
단순 라우팅 정책은 상태확인을 허용하지 않기 때문에 비정상을 반환할 수도 있다.
다중 값 정책은 예를들어 3개의 다중값을 설정했을때 하나가 비정상 상태이면,
비정상인 레코드를 뺀 2개의 레코드 제공..?
- 단순 정책
- 지원하는 정책
- 상태 확인
공용 리소스에 대한 상태를 확인하는 방법이지만 개인 리소스의 상태를 확인하는 방법도 있다.- 상태 확인은 DNS 장애 조치를 자동화 하기 위한 작업
- 체크 목록
- 공용 엔드 포인트 모니터링
애플리케이션, 서버, 다른 AWS 리소스 - 다른 상태 확인을 모니터링
계산된 상태 확인 - CloudWatch 경보의 상태를 모니터링
- 공용 엔드 포인트 모니터링
- 상태 확인들은 각자의 메트릭을 사용하는데 CloudWatch의 지표에서도 확인이 가능하다.
- 엔드 포인트에서 상태 확인 작동 방식
전 세계 15개의 상태 확인이 온다.
루트를 설정한 공용 엔드포인트로 요청을 보낸다
200 ok를 받으면 정상으로 간주.
간격 설정 가능
HTTP, HTTPS, TCP등 많은 프로토콜 지원
18% 이상의 상태 확인이 엔드 포인트를 정상이라 판단하면 Route 53도 정상이라 간주
상태 확인에 사용될 위치 지정 가능- 상태 확인은 로드 밸런서로부터 2xx나 3xx 코드를 받아야만 통과 가능
- 텍스트 기반 응답일 경우
상태 확인은 응답의 처음 5120바이트를 확인
-> 응답 자체에 해당 텍스트가 있는지 보기 위함 - 네트워크에서 상태 확인의 작동이 가능하려면
상태 확인이 ALB나 엔드 포인트에 접근이 가능해야 한다.
-> Route 53의 상태 확인 IP 주소 범위에서 들어오는 모든 요청을 허용해야 한다.
- 계산된 상태 확인
여러 개의 상태 확인 결과를 하나로 합쳐주는 기능- 상태 확인들을 합치기 위한 조건
OR,AND,NOT - 하위 상태 확인을 256개까지 모니터링 가능
- 상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지 지정 가능
- 사용예
상태 확인이 실패하는 일 없이 상위 상태 확인이 웹사이트를 관리 유지하도록 하는 경우
- 상태 확인들을 합치기 위한 조건
- 개인 리소스 상태 확인
Route 53의 상태 확인이 VPC 외부에 있어 개인 엔드 포인트에 접근이 불가능
그래서 CloudWatch 지표를 만들어 CloudWatch 알람을 할당하는 방식으로 해결
-> CloudWatch 경보를 상태 확인에 할당해서 사용
-> CloudWatch 메트릭을 이용해 개인 서브넷 안에 있는 인스턴스를 모니터링
-> 메트릭이 침해되는 경우 CloudWatch 알람을 생성하게 된다.
-> 알람이 ALARM 상태가 되면 상태 확인은 자동으로 비정상이 된다.
+++
- Domain Registar VS DNS Service
도메인 이름 레지스트라를 통해 원하는 도메인을 구매 -> 매년 비용 지불
Route 53을 통한 아마존 레지스트라 말고 다른 DNS 레지스트라도 있다.(GoDaddy, Google Domain)- 레지스트라를 통해 도메인을 등록하면 DNS 레코드 관리를 위한 DNS 서비스를 제공한다.
- GoDaddy에서 도메인을 등록해도 된다.
example.com을 구매하고 DNS 레코드는 Route 53으로 관리 가능.- 과정
- GoDaddy에서 도메인을 등록하면 이름 서버 옵션이 생긴다.
- 사용자 정의 이름 서버를 지정할 수 있다.
-> Route 53에서 원하는 도메인의 공용 호스팅 영역 생성
-> 호스팅 영역 상세의 오른쪽 부분에서 이름 서버를 찾는다.
--> 호스팅 영역 상세의 이름 서버는 GoDaddy 웹사이트에서 변경해야한다.
-> GoDaddy에서 사용할 이름 서버에 관한 쿼리에 응답하면 이름 서버가 Route 53 이름 서버를 가리킨다.
-> Route 53을 사용해서 해당 콘솔에서 직접 전체 DNS 레코드를 관리 한다.
- 정리
- 도메인을 타사 등록 대행사에서 구매해도 DNS 서비스 제공자로 Route 53 사용 가능
- 사용하려면 Route 53에서 공용 호스팅 영역을 생성
- 도메인을 구매한 타사 웹사이트에서 NS 혹은 이름 서버를 업데이트하면 Route 53 이름 서버를 가리키게 된다.
- 모든 도메인 이름 레지스트라가 일부 DNS 기능을 제공하더라도 도메인 이름 레지스트라는 모두 비슷해 보이지만 DNS 서비스와는 다르다.
