Environment(개발환경)/Infra(인프라)

[AWS] 강의실습 - (11) Amazon Route 53 구성

ttaeng_99 2023. 7. 31. 17:48
반응형

AWS 강의 커리큘럼을 통해, 기본적인 사용법 학습과 경험을 취득하고자 수강을 시작했다!

애초에 코딩하면서 수기노트를 한 적도 까마득하며, 글씨 쓰는것도 귀찮아하는 나이기에 포스팅으로나마 주요내용을 정리하며 강의를 들으려한다!

- 강의 : CloudNet@와 함께하는 AWS 네트워킹 입문 (인프런 링크)

 

CloudNet@와 함께하는 AWS 네트워킹 입문 - 인프런 | 강의

AWS 클라우드 입문자를 대상으로, AWS 클라우드 네트워크 기초 지식을 따라하며 배우는 실습 기반의 입문 강의입니다., - 강의 소개 | 인프런

www.inflearn.com

* CloudNet@ 측에서 강의영상 및 자료 저작권이 있어, 최대한 내용이해를 도울 수 있는 사진으로 대체해보려고 합니다 😁😁


☁️  실습 사전준비

- DNS 통신 정보 확인

# DNS 서버 정보 확인
dig

# 도메인 네임의 IP 주소 확인
dig blog.cloudneta.net
dig +short blog.cloudneta.net

# 도메인 네임의 IP 주소 확인 과정
dig +trace blog.cloudneta.net

 dig DNS 서버 정보를 확인할 수 있는 명령어이다. dig만 사용하면 개인PC의 정보에 대해 알 수 있다.

 

 dig  명령어와 도메인 네임을 같이 입력하면 해당 도메인에 대한 정보를 확인할 수 있다.  +short  옵션을 붙이면 IP주소만 반환해준다.

또한,  +trace  옵션을 통해 도메인 네임에서 IP주소를 해석하는 일련의 과정도 확인해볼 수 있다.

 

 

- Route 53으로 도메인 네임 신규생성(유료)

먼저, 실습을 위한 도메인 내임을 신규로 생성해줘야 한다. Amazon Route 53 서비스로 도메인 네임을 생성할 수 있다.

(유료이며, TLD 에 따라 가격이 조금씩 상이해짐)

 

우선 AWS 콘솔에서 Route 53 페이지로 진입한다. 여기서 등록된 도메인 메뉴로 들어오면, 도메인을 신규로 등록할 수 있다.

 

위처럼 사용하고자 하는 도메인 네임을 검색하면, 사용 가능한 도메인 주소와 요금을 보여준다.

사용할 도메인 주소를 선택하고, 결제 프로세스를 진행하면 Route 53에서 도메인을 등록해준다.

 

이처럼, 최초에는 요청 메뉴에서 상태를 확인할 수 있다.(약 10분 소요)

개인 이메일 인증까지 진행하여 등록이 완료되면, 호스팅 영역 메뉴에서 정보를 확인할 수 있다.

* 우측 메뉴의 이름 서버가 도메인에 대한 정보를 가지고 있는 권한 있는 네임 서버에 해당


☁️  Amazon Route 53 구성 및 라우팅 정책

이제 위에서 생성한 도메인 네임을 통해, Amazon Route 53으로 다양한 라우팅 정책을 구성하고 검증하는 실습을 진행할 것이다.

 

 

* 기본 인프라 구성(CloudFormation)

 

이전과 같이 CloudFormation 스택을 생성했다. 방법과 스펙은 아래를 참고해주면 된다! (CloudFormation 생성참고)

 

[AWS] 강의실습 - (7) 보안 그룹, 네트워크 ACL + Flow Logs

AWS 강의 커리큘럼을 통해, 기본적인 사용법 학습과 경험을 취득하고자 수강을 시작했다! 애초에 코딩하면서 수기노트를 한 적도 까마득하며, 글씨 쓰는것도 귀찮아하는 나이기에 포스팅으로나

abangpa1ace.tistory.com

위 자원의, ALB로 트래픽을 20회 전송했을 때, 인스턴스 서버 1과 2로 각각 10개씩 부하 분산시키고 있음을 볼 수 있다.

 

 

1. 단순 라우팅 정책

먼저, 인스턴스 서버1, 2에 대해 A 호스팅으로 단순 라우팅 정책을 추가해 볼 것이다.

먼저, Route 53의 호스팅 영역 메뉴로 진입했다. 여기서 호스팅들을 확인할 수 있으며, 앞에서 만든 abang.click 호스팅에서 레코드를 추가한다.

 

먼저, 레코드의 Subdomain, 레코드 유형 등을 선택한다. 값은, 인스턴스들의 탄력적 IP(Public) 값들을 넣어주었다.

TTLDNS 서버가 해당 도메인에 대한 IP주소를 캐싱하는 시간으로, 최소값인 60(초)를 주었다.

라우팅 정책 역시 다양한 유형이 있지만, 가장 기본적인 단순 라우팅 조건을 설정하였다.

 

# HTTP 1회 접근
curl test.abang.click

# dig 명령어 활용
dig test.abang.click
dig +short test.abang.click  # IP주소만
dig +trace test.abang.click  # DNS -> IP해석 절차

# HTTP 30초 간격으로 무한 접근
while true; do curl test.abang.click && date && echo; sleep 30; done

 curl  명령어로 확인해보면 서버1만 응답이 오는 것을 볼 수 있다. 이는, DNS의 캐싱때문에 일정시간(TTL) 동안 같은 응답이 오는 것이다.

while 반복 명령어를 통해 확인해보면, 30초 간격으로 실행했을 때 TTL(60초) 묶음에 대해 캐싱된 같은 서버가 응답하는 것을 볼 수 있다.

 

 

* Alias 를 통한 도메인 네임 간소화

 

AWS Route 53에서는 Alias 라는 네임 간소화 기능을 제공한다. 이를 통해, 길고 복잡한 ALB의 도메인을 간소화 해 볼 것이다!

다시, Route 53 페이지의 호스팅 영역 메뉴로 진입해서, 레코드를 새로 생성해준다.

 

레코드 이름을 설정하고 유형을 A로 유지한다. 여기서, 별칭(Alias) 스위치를 ON하면 설정창이 위 사진처럼 변하게 된다.

Application/Classic Load Balancer에 대한 별칭을 설정하고, 리전(가용영역)과 ALB를 선택해주면 Alias 레코드가 적용된다!

 

 curl  명령어를 통해 ALB를 통한 트래픽 전달과 부하 분산을 검증할 수 있다.

 

 

2. 가중치 기반 라우팅 정책

가중치 기반 라우팅 정책도 어렵지 않게 설정할 수 있다. 마찬가지로, 호스팅 영역 메뉴로 들어와서 레코드를 추가해준다.

서브도메인, 레코드 유형(A), TTL 등을 설정해주고, 라우팅 정책가중치 기반으로 바꿔준다.

그러면 하단에 설정 창이 추가되는데, 여기서 가중치와 레코드 ID(식별 위함으로 중요한 값은 아님) 등을 입력하고 생성해주면 된다.

 

 curl  명령어를 통해 확인하면 서버1 응답이 현저히 많은 것을 알 수 있다. (TTL 캐싱도 반영되겠지만, 일정 간격으로 호출해도 비슷하다)

 

 

3. 장애 조치 라우팅 정책

마지막으로 장애 조치 라우팅 정책을 추가하는 실습이다. 여기선, 장애에 대한 상태 검사를 포함시키기에 앞서 상태 검사를 생성해준다.

Route 53의 상태 검사 메뉴로 진입해서 상태 검사를 새로 구성할 수 있다.

 

이름을 추가하고 모니터링 대상은 엔드포인트를 유지한다.
프로토콜, 포트 역시 유지하며, IP주소에 웹 서버의 퍼블릭 IP주소를 넣고 경로는 index.html 로 설정한다.

고급 구성을 통해 추가 설정이 가능한데, 요청 간격을 빠름으로 변경하거나 실패 임계값을 줄여 검사성능을 높일 수 있다.

* 2단계(상태 검사 실패 시 알림 메세지 받음) 으로 경보를 설정할 수 있다. 실제 서비스에서는 SNS 등으로 알람할 수 있는 필수적인 설정

 

이제 각 웹서버에 대한 상태 검사들이 추가되었다. 모니터링 탭 메뉴에서 에러상태를 그래프로 확인할 수 있다. (정상은 1, 에러가 0)

 

다음으로, 호스팅 영역 메뉴로 돌아와서 신규 레코드를 생성해준다.

마찬가지로, 서브도메인, 레코드 유형(A), IP주소, TTL을 입력하고, 라우팅 정책을 장애 조치로 변경해준다.

아래 추가설정에서, 장애조치 유형, 상태확인 ID(상태 검사), 레코드 ID 등을 추가로 입력해주면 된다.

 

# HTTP 1회 접근
curl failover.abang.click

# HTTP 5초 간격으로 무한 접근
while true; do curl failover.abang.click --connect-timeout 5 && date && echo; sleep 5; done

 curl  명령어를 통해, 장애 조치 대응을 위해 기본적으로 서버1이 응답하고 있는 것을 볼 수 있다.

 

이제 장애구현을 위해 서버1 인스턴스를 중지시켜 보았다.

서버1은 에러발생 혹은 연결이 해제될 것이고, 다시 연결을 시도하면 서버2로 변경된 것을 확인할 수 있다.

 

상태 검사에서, 서버1의 상태 검사의 모니터링 탭으로 이동하면 에러 이력을 확인할 수 있다.


📎 출처

- [도메인, DNS 및 네임서버] opentutorials 포스팅 : https://www.opentutorials.org/module/288/2802

반응형