#AWS Certified Developer Associate
84. DNS란?
Domain Name System(or Server)
Domain Registrar : Amazon Route 53 , GoDaddy ...
DNS Records : A, AAAA, CNAME, NS ...
Zone File : 모든 dns 레코드를 포함하는 파일
Top Level Domain(TLD) 최상위 도메인 : .com , .us , .in , .gov , .org ...
85. Route 53 개요
고가용성, 확장성을 갖춘 완전히 관리되며 권한있는 DNS - Domain Registrar
DNS 를 완전히 제어할 수 있음
100% SLA(Second Level Address) 가용성을 제공하는 유일한 AWS 서비스
why route '53' ? - 53은 dns 포트이다
Record Types
- A
호스트 이름과 IPv4 IP를 매핑
- AAAA
호스트 이름과 IPv6 IP를 매핑
- CNAME
호스트 이름을 다른 호스트 이름(A or AAAA record)과 매핑
dns 이름 공간 또는 Zone Apex의 상위 노드에 대한 CNAMES 를 생성할 수는 없음
(ex- you can't create CNAME Record for example.com, but you can create for www.example.com)
- NS
호스팅 존의 이름 서버
트래픽이 도메인으로 라우팅되는 방식을 제어
Hosted Zones
호스팅 존 - 레코드의 컨테이너
도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의함
퍼블릭 호스팅 존 <-> 프라이빗 호스팅 존
- 퍼블릭 호스팅 존
공개된 클라이언트로부터 온 쿼리에 응답할 수 있음
- 프라이빗 호스팅 존
VPC 에서만 쿼리할 수 있음 (인트라넷 dns)
85. Route 53 - 도메인 등록
이게없네 ㅋㅋ
1년에 12달러면 도메인을 이용할 수 있는데
일단 지금 막상 필요한 도메인은 없기때문에 구매하지 않고 그냥 강의만 보기로 했다
87. Route 53 - 첫 번재 기록 생성 (create first record)
구입한 도메인의 hosted zone 으로 들어가서
레코드 만들기로 들어가서
레코드 이름을 정하고(도메인 이름 ex - test.yeonwoo.com)
레코드 유형을 선택하고
IP주소를 적어준다(A, AAAA)(ex.11.22.33.44)
등록하고 나면
주소창에 test.yeonwoo.com 으로 들어가면 11.22.33.44 ip 로 접속하게 됨
새로 만든 레코드를 매핑하고 dig 명령어로 확인하는데
나는 도메인을 구입하지 않았기때문에 구글로 확인해봣다
레코드 타입은 A 로 나오고 매핑된 아이피는 172.217.161.228 로 나온다
88. Route 53 - EC2 설정
(이거 영상 보는데 실습이 도움이 될것 같아서 일단 오늘은 여기까지만 하고 내일 도메인 사서 다시 실습해봐야겠다 7.25 끝)
(7.27 시작)
내 이름으로 된 도메인을 구매했다
88. Route 53 - EC2 설정
도쿄, 프랑크푸르트, 버지니아 리전에 기본적인 인스턴스를 각각 하나씩 만들어줬다
amazon linux2 - t2.micro - ssh, http 0.0.0.0/0
사용자 데이터 추가
#!/bin/bash
sudo yum update -y
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd
EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/latest/meta-data/placement/availabilty-zone)
sudo chmod 777 /var/www/html
sudo echo "<h1>Hello World from $(hostname -f) in AZ $EC2_AVAIL_ZONE </h1>" > /var/www/html/index.html
버지니아북부(us-east-1) 44.206.241.17
프랑크푸르트(eu-central-1) 3.68.191.246
도쿄(ap-northeast-1) 52.194.241.156
그리고 ALB 도 만들어줌
demo-alb-route-53-946425846.ap-northeast-1.elb.amazonaws.com
public ip 로 접속하니 이렇게 404not found 가 뜨는데
유저데이터에 입력해줬던 링크가 작동이 잘 안되나보다
고쳐보려고 했는데 일단 뒤에 어느리전인지는 대충 나오니까 넘어가자
89. Route 53 - TTL
Time To Live
A 레코드 유형으로 버지니아 북부에 생성한 인스턴스를 연결해주고
TTL 을 120초 줬다
answer section 에 보면 ttl 값이 61 , 24 로 보이는데
이 시간이 다 되기 전에 레코드 값을 바꾸어도
여전히 기존 페이지로 접속된다.
ttl 로 설정한 시간이 끝나야(캐시가 만료되야) route 53이 레코드 값을 새로 리다이렉팅 된다
90. Route 53 CNAME 대 Alias
CNAME : 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있음 (ex. app.mydomian.com -> blabla.anything.com)
- 루트 도메인 이름이 아닌 경우에만 가능
Alias : 호스트이름이 특정 AWS 리소스로 향하도록 할 수 있음 (ex. app.mydomain.com -> blabla.amazon.com)
- 루트 및 비루트 도메인 모두에서 작동
- 자체적인 상태 확인 가능
- 레코드 타입은 A/AAAA 이다 (IPv4, IPv6)
- TTL 을 설정할 수 없음 (자동할당됨)
- ELB, Amazon CloudFront, Amazon API Gateway, Elastic Beanstalk, S3 Websites, VPC Interface Endpoints, Global Accelerator, Route 53 Record(same Hosted zone) 에 연결 가능
- EC2 DNS 은 Alias 레코드에 연결할 수 없음
- alias 레코드 설정은 무료임
cname 은 url 을 매핑한다
CNAME 레코드로 매핑한 ALB 주소가 연결된 모습
alias 주소로 route53 alb dns 접속
루트 도메인만을 이용하고자 할때 CNAME 레코드 타입으로 하면 오류가 발생한다
하지만 alias 를 사용하면 루트 도메인을 다른 aws 서비스와 매핑할 수 있다
(7.27 끝)
(7.30 시작 - 술먹고 술병났다가 부활ㅋㅋ)
91. 라우팅 정책 - 단순
Routing Policies - Route 53가 DNS 쿼리에 응답하는 것을 돕는다
여기서 라우팅은 트래픽을 라우트 한다는 개념이 아닌 DNS 쿼리에 응답한다는 개념
Route 53 이 지원하는 라우팅 정책
- 단순
- 가중치 기반
- 장애 조치
- 지연 시간 기반
- 지리적
- 다중 값 응답
- 지리 근접
-단순 (Simple)
기존에 사용해왔던 방식
일반적으로 트래픽을 단일 리소스로 보내는 방식
동일한 레코드에 여러 개의 값을 지정하는 것도 가능
여러 값을 리턴할 경우 클라이언트쪽에서 그중 하나를 무작위로 고르게 됨
TTL 시간이 끝난후 IP를 하나 더 추가해주면
ANSWER SECTION 에 등록한 IP 주소 2개 모두 나오고
이제 클라이언트가 이 둘중 하나를 무작위로 선택하게 됨
92. 라우팅 정책 - 가중치
가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능함각 레코드에 상대적으로 가중치(트래픽 비율)를 할당하게 되는 것가중치 정책을 사용하려면 DNS 레코드들은 동일한 이름과 유형을 가져야 함 - Health Checks(상태확인) 과 관련use cases : 서로 다른 지역들에 걸쳐 로드밸런싱 할 때 , 적은 양의 트래픽을 보내 새로운 앱을 테스트하는 경우에도 사용가중치를 0으로 설정하면 트래픽 보내기를 중단해 가중치를 바꿀 수 있다모든 레코드의 가중치가 0일 경우 모든 레코드가 다시 동일한 가중치를 갖게 됨
이렇게 가중치 기반으로 라우팅 정책을 선택하게 되면가중치와 상태확인 id , 레코드 id 를 새로 추가할 수 있다상태확인 id 는 일단 놔두고동일한 방식으로 3개의 다른 ip 를 넣어서 추가해줬다
ttl 시간이 끝나고 매핑된 ip 가 바뀌어서 리턴된걸 확인할 수 있다
93. 라우팅 정책 - 지연 시간(Latency-based)
가장 가까운 리소스로 리다이렉팅을 하는 정책
지연시간에 민감한 웹사이트나 애플리케이션이 있는 경우 아주 유용한 정책
유저가 가장 가까이 식별된 AWS 리전에 연결하기 까지 걸리는 시간을 기반으로 측정됨
지연시간 정책으로 3개 다른 리전 ip 레코드를 추가해줌
이렇게 잘 추가해 준 것 같은데
왜 안가지냐
ㅅㅂ
(7.30 끝)
(8.3 시작)
94. Route 53 상태점검
상태점검(Health Checks)
- 공용 리소스에 대한 상태를 확인하는 방법
- DNS의 장애 조치를 자동화 하기 위한 작업
- 공용 엔드 포인트 모니터링 (application, server, other AWS resoure)
전세계에서 15개의 상태확인 요청이 하나의 엔드포인트로 오고 임계값을 정상 혹은 비정상으로 설정함 (일반-30초마다 / 빠른상태확인-10초(비쌈))
상태 확인을 하려면 엔드포인트에서 '상태 확인' 이 접근 가능해야 한다 - 상태확인 ip 주소 범위에서 들어오는 모든 요청을 허용해야함
- 계산된 상태 확인 (Calculated Health Checks)
여러 개의 상태 확인 결과를 하나로 합쳐주는 기능
부모상태확인-자식상태확인 (child-healthchecker 하나당 인스턴스 하나씩을 모니터링 가능)
OR, AND, NOT
자식(하위) 상태 확인을 256개 까지 모니터링 할 수 있다
- CloudWatch 경보의 상태를 모니터링 하는 상태 확인 (Private Hosted Zones Health Checks)
상태 확인은 개인 엔드포인트에 접근할 수 없음
그래서 CloudWatch 지표 - 알람을 만들어 할당하는 식으로 해결 가능
95. Route 53 - 상태 점검 실습
앤드포인트 상태 검사
이후 상태 검사 실패 시 알람 메세지를 받을 수 있는 설정 탭이 나오는데
아니요로 넘어갔다
같은 방식으로 2개 다른 리전의 상태 검사를 추가해줬다
계산된 상태 검사
조건을 선택할 수 있음
CloudWatch 경보 상태 검사
따로 만든 알람은 없으므로 이건 만들진 않고 옵션만 확인하고 넘어갔다
96. 라우팅 정책 - 장애 조치(Failover)
최소2개 인스턴스로 구성된다고 한다
기본 인스턴스로 응답하다가 기본 인스턴스의 상태 검사가 비정상이라면
두번째 인스턴스로 연결되는 방식
장애 조치 정책을 적용하려면 상태 검사 적용이 필수이다
레코드 유형에는 기본(primary) 와 보조(secondary or disaster recovery) 가 있다
보조 유형에서는 상태 확인 id 를 굳이 지정하지 않아도 된다
기본으로 설정해놓은 인스턴스의 상태 검사가 unhealthy(비정상) 이 나오면 보조로 설정한 인스턴스로 연결된다
97. 라우팅 정책 - 지리적 위치(Geolocation)
지연시간(latency) 와 다르게 사용자에 실제 위치를 기반으로 라우팅 한다
할당한 지역과 일치하는 지역이 없을 경우 request 할 기본 레코드를 생성해야 함
위의 예를 들면 아시아 혹은 미국에 속한 국가가 아니라면 기본 레코드에 할당한 인스턴스로 연결 될 것이다
98. 라우팅 정책 - 지리적 근접성(Geoproximity Routing Policy)
사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅 하도록 함
편향값을 사용해 특정 위치를 기반으로 리소스에 더 많은 트래픽을 이동하는 것
지리적 위치를 변경하려면 편향값을 지정해야 함
특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장해야함
리소스에 트래픽을 줄이려면 편향값을 음수로 축소시키면 됨
리소스는 aws source임 - aws source 가 아닌 온프레미스 앤드포인트라면 위도와 경도 값을 조정해야함
이런식으로 bias(편향값)을 증가시켜서
해당 리전에서 다른 리전으로 트래픽을 분할할 수 있음
99. 라우팅 정책 - 트래픽 플로우 및 지리적 근접성 실습
트래픽 플로우(Traffic flow)
- UI로 복잡한 라우팅 의사 결정 트리를 관리하는 것
- 버전을 지정하고 호스팅 영역을 적용할 수 있음
- 호스팅 영역에서 쉽게 변경하고 적용할 수 있음
이런식의 시각적으로 Route 53 정책을 지정할 수 있다
대충 음수로 값을 줄여보면 바이어스 값으로 트래픽을 조절할 수 있고
간략하게 맵으로도 보여준다
한 국가 안에서도 트래픽이 향하는 리소스가 다를 수 있음
바이어스 갑 조정 이후 다음을 누르면
정책 레코드의 dns 이름을 입력하고 TTL 값을 설정할 수 있는 화면이 나오고
이후 정책이 생성된다.
정책 버전 생성(무료) - 정책 레코드 생성(유료-매달50달러)
100. 라우팅 정책 - 다중 값(Multi-Value)
트래픽을 다중 리소스로 라우팅할 때 사용
상태 검사 시 값을 반환할때 리소스들의 정상 상태만을 반환한다.
각각 다중 값 쿼리에 최대 8개의 정상 레코드가 반환됨
ELB와 유사해 보이지만 ELB를 대체할 수는 없음
레코드 생성에 들어가 3개 래코드를 추가해주고
각각 해당하는 ip 주소와 상태검사를 할당해 줬다
3개 ip 모두 정상인 모습
여기서 상태 검사에 들어가서
eu 리전의 상태검사를 비정상으로 만든 후 다시 테스트 해봤다 (상태 검사 반전)
이렇게 상태 검사에서 비정상이 된 레코드는 제외한 2개 레코드만 동작하게 된다
101. 타사 도메인 및 Route 53
대게 도메인 레지스트라를 통해 도메인을 구매하면 DNS 레코드 관리를 위한 DNS 서비스를 제공함
다른 도메인 레지스트라를 통해 도메인을 구매햇어도 AWS DNS 관리 서비스인 Route 53를 이용할 수 있다
102. 섹션 정리
호스팅 영역 삭제 - 기본 레코드 빼고 나머지 전부 삭제한 후 삭제 가능
3개 리전의 인스턴스 삭제
로드밸런서와 타겟그룹 삭제
이후 퀴즈 풀고 끝!
'AWS > AWS Certified Developer Associate' 카테고리의 다른 글
| [Udemy][day-19~22] AWS 강의 section 11 : Amazon S3 소개 (0) | 2022.08.18 |
|---|---|
| [Udemy][day-18] AWS 강의 section 10 : VPC 기초 (0) | 2022.08.05 |
| [Udemy][day-13] AWS 강의 section 8 : AWS기초: RDS + Aurora + ElasticCashe (0) | 2022.07.23 |
| [Udemy][day-6~12] AWS 강의 section 7 : AWS기초: ELB + ASG (0) | 2022.07.12 |
| [Udemy][day-4,5] AWS 강의 section 6 : EC2 인스턴스 스토리지 (0) | 2022.07.11 |