DNS(Domain Name System)
사람에게 친숙한 호스트 이름을 대상 서버 IP 주소로 번역
예시로 www.google.com => 172.217.18.36
계층적 구조 이름
.com: TLD
google.com: SLD
www.google.com: Sub Domain
api.www.google.com: Domain name
http: protocol
http://api.www.google.com.: FQDN(Fully Qualified Domain Name)
DNS Terminologies
- Domain Registrar
- 도메인 이름을 등록하는 곳(Route 53, GoDaddy, ...)
- DNS Records
- A, AAAA, CNAME, NS, ... (스크롤 내리면 확인 가능)
- Zone File
- 모든 DNS 레코드를 포함하는 파일
- 호스트 이름과 IP or 주소를 일치시키는 방법
- Name Server
- DNS 쿼리를 실제로 해결하는 서버
- Top Level Domain
- .com, .us, .in, .gov, .org, ...
- Second Level Domain
- amazon.com, google.com, ...
How DNS Works
Web Browser -> www.google.com 검색 -> Local DNS Server ->
Root, TLD, SLD DNS Server 에게 www.google.com 주소를 아는지 확인
-> 알고 있는 서버는 IP 주소를 리턴 -> IP 주소로 구글 Web Server 에
요청 -> 리턴 값을 Web Browser 에게 다시 전달
Route 53
고가용성, 확장성, 권한이 있는 DNS
고객이 DNS 레코드를 업데이트 할 수 있음, DNS에 대한 완전한 제어
1.클라이언트에서 EC2 인스턴스에 접근 시도(example.com)
2.EC2 인스턴스 에는 퍼블릭 IP만 있는 경우
3.DNS 레코드를 아마존 Route 53 호스팅 존에 사용하려고 함
(Amazon Route 53에 example.com 요청을 의미)
4.Route 53에서 IP xx.xx.xx.xx 을 찾고 있다고 응답
5.클라이언트는 응답을 확인하고 EC2 인스턴스에 접근
Route 53의 리소스 관련 상태 확인 가능
Recodrds
여러 DNS 레코드를 정의하고 레코드를 통해 특정 도메인으로 라우팅 하는
방법을 정의
레코드에서 반드시 알아야할 것
A, AAAA, CNAME, DS(실습에서 확인 가능)
Record Types
- A - 호스트 이름을 IPv4 IP를 매핑
- 예시) example.com -> 1.2.3.4 로 매핑
- AAAA - 호스트 이름을 IPv6 에 매핑
- CNAME - 호스트 이름을 다른 호스트 이름과 매핑
- 대상 호스트 이름은 A, AAAA 레코드가 될 수 있음
- Route 53에서 DNS namespace(Zone Apex)의 상위 노드에 대한 CNAMES 생성할 수 없음(이번 섹션에서 확인 가능)
- example.com -> CNAME: X, www.example.com -> CNAME: O
- NS - 호스팅 존의 이름 서버
- 서버의 DNS 이름, IP 주소로 호스팅 존에 대한 DNS 쿼리 응답
- 트래픽이 도메인으로 라우팅 되는 방식 제어
Hosted Zones
레코드 컨테이너, 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식 정의
- Public Hosted Zone
- 퍼블릭 도메인 이름을 살 때마다 mypublicdomain.com이 퍼블릭
도메인 이름이라면 퍼블릭 호스팅 존을 만들 수 있음 - 퍼블릭 존은 쿼리에 application.mypublicdomain.com 의
IP 가 무엇인지 알 수 있음
- 퍼블릭 도메인 이름을 살 때마다 mypublicdomain.com이 퍼블릭
- Private Hosted Zone
- 공개되지 않은 도메인 이름 지원
- 가상 프라이빗 클라우드(VPC) 에서만 URL을 해결할 수 있음
- application.company.internal 같은 경우(사내망)
AWS 만드는 어떤 호스팅 존이든 달에 50 센트를 지불 해야함(1년 12달러)
Hosted Zones 을 쉽게 이해하자면
public zone은 공개된 클라이언트 즉 브라우저에서 온 쿼리(example.com)
에 응답할 수 있음
private zone은 해당 VPC 안에서만 동작
도메인 생성
1.Route 53 Dashboard -> Domains -> Registered Domains
2.Register Domain -> 사용할 도메인명 입력 -> Check 클릭
3.확인 및 add to cart -> Continue
4.개인 정보 입력, 개인 정보 보호 옵션 선택 -> Continue
5.자동 도메인 관리, 약관 동의 -> Complete Order
6.생성된 도메인 확인, Records 생성된 Type 확인
레코드 생성
1.생성한 도메인 클릭 -> Records(Tab) -> Create record
2.레코드 네임, Rocord type, value, TTL, Routing policy 설정
value: 11.22.33.44, Rocrd type: A, 외에 default
3.Create recoreds
4.생성한 후 브라우저에 record name 입력 시 value 에 해당하는 IP 웹서버가 없어 보여지는 화면이 없음
5.명령줄에서 입력 시도
6.CloudShell 접속에 가능한 리전으로 이동(서울 안됨)
7.터미널 $ sudo yum install -y bind-utils (nslookup, dig 설치)
8.터미널 $ nslookup (record name)
9.name(record name), address(11.22.33.44) 확인 가능
10.터미널 $ dig (record name)
11.name, record type, addresss 확인 가능(record type 추가)
EC2 설정
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/latest/meta-data/placement/avaliability-zone)
echo "<h1>Hello World from $(hostname -f) in AZ$EC2_AVAIL_ZONE </h1>"> /var/www/html/index.html1.각 각의 다른 리전에 EC2 인스턴스를 1개씩 총 3개 생성
공공 IP 허용, user data 입력, key pair 없음, 이 외 default 구성
2.3개의 리전 중 하나 선택해서 Application Load Balancer 생성
Mapping 서브넷 3개 적용, 보안 그룹(HTTP 허용 보장)
대상 그룹 생성(위 에서 만든 인스턴스 등록) 및 등록
3.3개의 EC2 인스턴스의 공공 IP 접속하여 출력 정보 확인
4.ALB DNS name 도 마찬가지로 브라우저에 입력하여 출력 정보 확인
TTL(Time To Live)
1.클라이언트 -> Amazon Route 53에 example.com 요청
2.클라이언트에게 record type, ip address를 캐시하도록 요청
3.클라이언트는 TTL 300초 동안 응답 내용을 캐시함
4.응답받은 내용으로 Web Server 와 통신이 가능하게 됨
TTL의 극단적인 예시
TTL 24시간으로 설정한 경우 Route 53 에 그만큼 요청이 줄어듬
즉 트래픽량이 줄어들며 지불해야할 비용도 줄어듬
그러나 변경된 내용이 있어도 24시간 동안은 재요청을 하지 않기 때문에
오래된 응답을 가지고 있게 됨
TTL 60초로 적용한 경우 자주 요청하게 되어 최신 정보를 유지할 수
있지만 트래픽량이 늘어나게 되며 비용이 커짐
Route 53은 들어오는 요청의 양에 따라 요금이 책정 됨
TTL 확인
1.레코드 생성시 TTL 120초, value는 위 EC2 설정에서 확인한
IP Address 를 적용 -> Create records
2.브라우저에 Record name 을 이용하여 접속 테스트
3.CloudShell & dig Record name 입력
4.출력된 내용을 보면 record name 오른쪽에 숫자 출력(TTL 시간)
5.TTL 시간 120초가 지나기 전에 레코드 내용 수정
6.다른 EC2 인스턴스 IP Address 를 적용
7.CloudShell & dig Record name 입력
8.출력 된 내용을 확인해보면 TTL 시간을 제외한 다른 내용이 변경되지 않음
9.TTL 시간 120초가 지난 후 CloudShell 에 재입력해서 확인
10.다른 EC2 인스턴스 IP Address 가 적용되어 있는 것을 확인
CNAME vs Alias(별칭)
LB, CloudFront, ... AWS 리소스의 호스트 이름에 매핑하고자 할 때
예시) www.example.com 에 Application LB의 DNS name 매핑
- CNAME
- 호스트 이름이 다르 호스트 이름으로 향하도록
- 루트 도메인 이름이 아닌 경우
- amazon.com (X)
- aws.amazon.com (O)
- Alias
- Route53에 한정되지만 기능은 CNAME과 동일
- 루트, 비루트 도메인에 모두 작동
- 무료, 자체적으로 상태 확인 가능
- TTL 설정 불가하며 Route53에 의한 자동 설정
- AWS 리소스를 위한 별칭 레코드는 항상 A, AAAA type
- EC2 DNS 이름은 별칭 레코드의 대상이 될 수 없음
CNAME 실습
1.Route53 Dashboard -> 생성한 Domain 클릭 -> Create Record
2.Record Name, Record Type: CNAME, Value: 다른 호스트 네임 설정
3.create
Alias 실습
1.Route53 Dashboard -> 생성한 Domain 클릭 -> Create Record
2.Record Name, Record Type: CNAME, Value: IPv4 에 해당하는 설정 값
3.alias 활성화, ALB, 가용 영역, 생성해놓은 ALB 설정
4.create
라우팅 정책
라우팅이란 특정 서버로 트래픽을 전달하는것을 의미하는데 Route53에서 라우팅이란
DNS 라우팅으로 트래픽과 관계가 없으며 호스트 이름들을 실제 엔드포인트로 변환하여
클라이언트가 특정 서버에 갈 수 있도록 전달하는 것을 의미함
Route53이 DNS 쿼리에 응답하는 것을 도움
정책 - Simple
트래픽을 단일 리소스로 보내는 방식
동일한 레코드에 여러 개의 값을 지정하는 것도 가능
IP 를 입력하고 엔터로 구분하여 여러개를 지정할 수 있음
호스트이름을 전달받은 Route53은 설정되어 있는 정책 값 개수만큼 IP를 전달
클라이언트는 여러개의 IP 중 하나의 IP를 선택하여 라우팅에 적용함
별칭을 사용하여 하나의 AWS 리소스만 지정하는 것도 가능함
정책 - Weighted(가중치)
요청의 일부 비율만큼 특정 리소스로 보내는 식의 제어가 가능
가중치를 0으로 설정하여 해당 인스턴스에 트래픽을 보내지 않도록 설정 가능
가중치 실습
1.레코드를 생성하는 방법은 동일
2.Routing Policy: Weighted 선택
3.Weight 설정, Record ID(사용 레코드 구분하기 위한 값)
4.Add another record 클릭하여 3개의 레코드 생성, 3개의 인스턴스,가중치 10,20,70
5.테스트를 위해 TTL을 짧게 설정 후 Create
위 레코드를 생성하여 해당 레코드 네임으로 브라우저에 접속하여 새로고침 반복
70으로 설정되어 있는 인스턴스 정보가 주로 보이며 20은 가끔, 10은 어쩌다 출력되는 것을
확인할 수 있음
Use Case
서로 다른 지역에 대해 로드밸런싱이 필요한 경우
적은 양의 트래픽을 새로운 애플리케이션에 보내 테스트를 해야되는 경우
정책 - Latency(지연시간)
지연 시간이 가장 짧은 가까운 리소스로 리다이렉팅
유저가 레코드로 가장 가까운 식별된 AWS리전에 연결하기까지 걸리는 시간을 기반으로 측정
지연시간 실습
1.레코드 생성하는 방법은 동일
2.Value IPv4 입력, Record Policy: Latency, region 설정
IPv4의 입력만으 어떤 region인지 알 수 없으므로 직접 명시해주어야 함
3.Add another record 클릭, 다른 리전의 IPv4, 리전 설정
4.총 3개의 인스턴스를 등록 후 Create
생성한 레코드 네임을 브라우저에 입력하여 출력되는 내용을 확인해보면
user data 에 설정한 리전 값이 출력되는데 가장 가까운 리전의 정보가 출력됨을 확인
VPN 을 사용하여 다른 리전에 가까운 국가를 설정하여 지연시간이 적용되고 있음을 확인
Use Case
지연시간이 예민한 웹사이트에 사용
Health Checks(상태 확인)
주로 공용 리소스에 대한 상태 확인하며 개인 리소스도 확인 가능
하나의 레코드가 설정된 Route53 서비스, 두 개의 ALB(여러 개의 EC2 인스턴스)
구성되어 있다는 가정하에 클라이언트에서 레코드 네임으로 접근을 시도하는 경우
그리고 특정 ALB에 사용이 불가능한 경우 Route53 서비스에서는 해당 ALB에 요청을
보내지 않기 위해 상태 확인이 가능해야 함
이 때 각 각의 ALB에 상태 확인을 생성하여 Route53 서비스에 연결 가능
DNS의 장애 조치를 자동화 하기 위한 작업
3가지 상태 확인 방법
1.공용 엔드포인트(애플리케이션, 서버, AWS리소스) 모니터링
2.계산된 상태 확인(다른 상태 확인을 모니터링하는 상태 확인)
3.CloudWatch 경보의 상태 확인을 모니터링하는 상태 확인
위 상태 확인은 각자의 매트릭을 사용하는데 CloudWatch의 지표에서도 확인 가능
상태 확인의 모니터링과 엔드포인트
전세계에서 특정 리전의 ALB에 상태 확인 요청이 올 수 있음
공용 엔드포인트에 요청을 보내옴
200 OK 코드, 정의한 코드를 받은 경우 정상으로 간주함
간격 설정이 가능한데 Standard(30초) 또는 Fast(10초: 빠른 상태 확인) 설정 가능
Fast를 사용하게 되면 비용이 추가됨
다양한 프로토콜 지원
상태 확인에 대한 위치 설정
상태 확인은 로드밸런서의 상태값 2xx, 3xx 코드를 받아야 통과가 됨
상태 확인이 텍스트 기반인 경우 5,120 바이트를 확인(응답 자체에 해당 텍스트가 있는지)
계산된 상태 확인
여러 개의 상태 확인 결과를 하나로 합쳐주는 기능
최대 256개의 하위 상태 확인 모니터링 가능
인스턴스가 3개, Route53의 하위 상태 확인이 3개인 경우 각 각의 상태 확인이 됨
3개의 상태 확인이 상태 값을 합쳐 상위 상태 확인에 결과를 전달
상태 확인의 기준(3개의 상태 확인 중 2개가 OK인 경우)을 설정할 수 있음
개인 리소스 상태 확인
모든 상태 확인은 VPC 외부에 있어 개인 리소스에 대한 상태 확인이 어려움
개인 엔드포인트에 접근할 수 없기 때문
외부의 상태 확인이 개인 리소스의 CloudWatch를 참조하는 해결 방법
CloudWatch 지표를 생성하여 개인 리소스를 모니터링하고 지표가 침해되는 경우 알람 생성
외부의 상태 확인은 자동으로 비정상이 되며 외부의 상태 확인은 상태 확인 됬다고 볼 수 있음
Health Checks 실습
1.Route 53 Dashboard -> Health checks -> Create health check
Endpoint
2.Endpoint, IP address or Domain name 설정
3.Endpoint의 경우 Advanced configuration의 추가 설정 가능
request interval(요청 간격): Standart(30초), Fast(10초)
Failure threshold(실패로 간주하기 까지 몇번을 요청 할지)
String matching(요청 앞부분의 5120 bytes 먼저 체킹 여부) 등...
4.Next -> Create
Calculated
2.Status other health checks
3.몇 개의 인스턴스 상태를 기준으로 정상인지 비정상인지 판정하는 설정
4.특정 수량 설정, 전체, 1 or more 선택
5.Next -> Create
CloudWatch alarm
2.State of CloudWatch alarm
3.리전, 특정 리전에 생성한 알람 설정
4.Next -> Create
Failover(장애 조치)
특정 인스턴스의 에러를 Route 53에서 상태 확인으로 체크하여
클라이언트의 요청을 받을 때 특정 인스턴스가 에러가 발생하는 경우
에러가 발생하지 않은 인스턴스로 요청을 전달하여 장애를 조치할 수 있음
Failover 실습
1.Route 53 -> Hosted zones -> 생성되어 있는 도메인 네임 클릭
2.Create record -> 아래 설정을 제외한 나머지 설정은 동일
3.Routing policy -> Failover -> primary(첫 번째 인스턴스)
4.Health check, Record ID 설정
5.Add another record 클릭 -> Failover -> secondary
6.나머지 설정은 동일 -> Create records
7.레코드를 생성한 인스턴스 중 하나의 EC2 Instance 페이지 이동
8.보안그룹에 80포트에 대한 모든 접근 허용을 제거
9.다시 Route53 -> Health checks 확인하면 인스턴스의 상태 확인
10.Healthy -> Unhealthy 로 변경되어 있음을 확인 가능
11.브라우저에 URL을 입력해보면 다른 인스턴스에 대한 접속정보 확인 가능
Geolocation(지리적 위치)
사용자의 실제 위치를 기반 정책
대륙, 국가 또는 미국의 특정 주 처럼 더 정확한 위치를 기반하여
해당 IP로 라우팅
해당하는 위치가 없는 경우 기본 레코드 생성
Use cases
특정 국가에 해당하는 언어와 버전의 앱을 클라이언트에게 제공하려 할 때
IP를 기준으로 특정 국가에 맞춰 애플리케이션을 적용할 수 있음
Geolocation 실습
1.Route 53 Dashboard -> Hosted zones -> 도메인 선택 -> Create record
2.Value: 인스턴스 IP, Routing policy: Geolocation, Location: 해당 인스턴스로
요청을 접달하게 될 지역 지정
3.Add another record -> 다른 인스턴스에 대해 설정하고 Location 변경
4.네트워크 위치 변경 소프트웨어를 사용하면서 인스턴스에 접근 시도
5.브라우저에 출력되는 인스턴스의 리전명을 확인하여 사용자 위치 기반으로 요청을 받는
인스턴스가 변경 되는지 확인
지리적 근접성
편향값을 수정하여 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용
트래픽을 더 많이 받게하려면 양수, 줄이려면 음수로 설정하면 됨
Multi Value(다중 값)
트래픽을 다중 리소스로 라우팅하려고 할 때
Route 53은 다중 값, 리소스 반환
각 각의 다중 값 쿼리에 최대 8개 정상 레코드 반환
Multi Value 실습
1.Route 53 Dashboard -> Hosted zones -> 도메인 선택 -> Create record
2.Add another record: 3개 설정
3.Record name: 공통으로 multi 입력, Routing policy: Multivalue answer, 각 각의 인스턴스에 대한 상태 확인 설정
4.cloudshell 을 이용하여 dig 에 multi.도메인 입력하여 테스트하면
등록되어 있는 3개의 인스턴스에 대한 정보가 출력됨
5.3개의 인스턴스 중 특정 인스턴스의 상태에 대해 비정상으로 변경
6.cloudshell 에서 동일한 명령어를 입력하고 비정상 상태처리된 인스턴스
를 제외한 정상 인스턴스에 대해서만 출력이 됨을 확인할 수 있음
타사 도메인 및 Route 53
Godaddy 와 같은 도메인회사에서 도메인을 구매하여도
AWS Route 53에 연결하여 관리할 수 있음
1.Route 53 에서 공용 호스팅 영역을 생성
2.도메인 회사에서 NS, 이름 서버 업데이트로 Route 53 이름 서버 지정
