1. DNS란
1) DNS 서비스
- Domain Name System의 약어로, 네트워크 통신을 위한 주소 체계를 문자 형태인 도메인으로 매핑하여 연결하는 서비스
- IP 주소를 문자 형태의 도메인 주소로 매핑해서 사용하는 서비스
도메인 주소를 이용한 통신과정
- 웹 서버의 IP 주소를 도메인 주소로 사용하고자 ongja.com 도메인을 구매하고 등록한다. 그러면 DNS 서버는 ongja.com의 IP 주소가 무엇인지 알고 정보를 기록해둔다.
- 사용자는 ongja.com이라는 도메인 주소가 어떤 IP 주소인지 모르고 있으므로 해당 정보를 확인하는 작업이 필요하다.
- 사용자는 도메인 주소의 IP 주소를 확인하기 이해 DNS 서버에 ongja.com의 도메인 주소를 요청하고 응답받는다. 이때 UDP 53번 포트를 사용하는 DNS 프로토콜을 이용하여 통신한다. 그러면 사용자는 ongja.com에 대한 IP 주소가 무엇인지 알 수 있다.
- 사용자는 ongja.com의 IP 주소를 알아냈기 때문에 해당 IP 주소로 통신한다.
2) 도메인 구조
루트 도메인
- 모든 도메인 주소의 가장 마지막에 있는 온점
탑 레벨 도메인 (Top Level Domain)
- 도메인 주소에서 가장 상위에 위치한 도메인
- .com, co.krt, .org
세컨드 레벨 도메인(Second Level Domain)
- TLD 다음에 위치한 두 번째 도메인 영역
- 상위 TLD에서 유일하게 존재하고 식별하는 도메인 영역
- 일반적으로 도메인 이름은 SLD와 TLD를 합친 형태로 표현
서브 도메인
- 도메인을 용도에 따라 앞에 명칭을 부여해서 분류할 수 있는데, 이를 서브 도메인이라고 한다.
- 예를들어 blog.cloudneta.net이나 test.cloudneta.net처럼 앞의 blog와 test가 서브 도메인이다.
3) DNS 서버 종류
- 도메인 구조를 루트 도메인, 탑 레벨 도메인, 세컨드 레벨 도메인, 서브 도메인으로 구분하는 가장 큰 이유는 영역별 도메인을 관리하는 주체를 분리하기 위해서이다. 도메인은 DNS 네임 서버로 관리하는데, 이때 도메인 영역별로 DNS 네임 서버를 분류해서 관리한다.
루트 네임 서버
- 루트 도메인을 관리하는 DNS 서버
- DNS 요청에 대해 TLD에 해당하는 네임 서버 정보를 응답한다.
- 루트 네임 서버는 전 세계에 13개만 존재한다.
TLD 네임 서버
- 도메인 이름의 최상위 영역인 TLD를 관리하는 DNS 서버
- TLD 영역에서 식별되는 모든 SLD를 관리하여 DNS 요청에 대해 SLD 네임 서버 정보를 응답한다.
ex)
.com이라는 TLD 네임 서버는 .com 내에 있는 google.com 도메인을 관리하는 SLD 네임 서버 정보를 알고 있다.
SLD 네임 서버
- 실질적인 도메인 이름을 관리하는 DNS 서버로, SLD 네임 서버(권한 있는 네임 서버)라고 한다.
- 실제 도메인의 최종 관리 서버로 권한이 있는 네임서버라고 한다.
- 도메인 주소에 대한 IP 주소를 확인하는 가장 마지막 단계이다.
DNS 해석기
- 사용자와 네임 서버 사이에서 중계자 역할을 수행
- 사용자가 DNS 해석기로 DNS 요청을 하면 DNS 해석기가 DNS 네임 서버와 정보를 주고받아 도메인 주소를 해석하여 최종적으로 IP 주소를 사용자에게 알려준다.
4) DNS 통신 흐름
- 사용자 PC에서 blog.cloudneta.net이라는 도메인 주소의 IP 주소를 알기 위해 DNS 서버에 질의한다. 여기에서 DNS 서버는 DNS 해석기를 이용하여 다양한 네임 서버와 통신하는 중계자 역할을 수행한다.
- 기본적으로 DNS 해석기는 전 세계에 있는 루트 네임 서버의 주소를 알고 있다. 해당 루트 네임 서버에 blog.cloudneta.net 도메인 주소를 알지 못하지만, .net의 TLD 네임 서버는 알고 있기 때문에 해당 정보를 DNS 해석기에 전달한다.
- 그러면 DNS 해석기는 .net에 해당하는 TLD 네임 서버에 blog.cloudneta.net 도메인 주소의 IP 주소를 물어본다. 여기에서 TLD 네임 서버는 blog.cloudneta.net이라는 도메인 주소를 알지 못하지만 cloudneta.net의 SLD 네임 서버는 알고 있어 해당 정보를 DNS 해석기에 전달한다.
- 다시 DNS 해석기는 cloudneta.net에 해당하는 SLD 네임 서버에 blog.cloudneta.net 도메인 주소의 IP 주소를 물어본다. 이 SLD 네임 서버는 도메인의 최종 정보가 있는 '권한이 있는 네임 서버'로. blog.cloudneta.net에 대한 IP 주소를 DNS 해석기에 전달한다.
- DNS 해석기는 blog.cloudneta.net에 대해 최종적으로 해석한 IP 주소를 사용자 PC에 전달한다. 이것으로 사용자 PC는 blog.cloudneta.net 도메인 주소의 IP 주소를 알게 되어 해당 IP 주소로 통신한다.
5) DNS 레코드 유형
- DNS 레코드는 도메인에 대한 요청 처리 방법을 정의한 것으로, 용도에 따라 DNS 레코드 유형을 분류한다.
A 레코드 유형
- 도메인 이름을 IPv4 주소로 매핑하는 가장 기본적인 DNS 레코드 유형
blog.cloudneta.net A 52.219.60.13
- blog.cloudneta.net이라는 도메인 주소로 질의하면 IPv4 주소인 52.219.60.13로 응답한다.
AAAA 레코드 유형
- 도메인 이름을 IPv6 주소로 매핑하는 DNS 레코드 유형
blog.cloudneta.net AAAA 2001:A10:2001
- blog.cloudneta.net이라는 도메인 주소로 질의하면 IPv6 주소인 2001:A10::2001로 응답한다.
NS 레코드 유형
- 도메인 이름의 네임 서버 주소로 매핑하는 DNS 레코드 유형
net NS a.gtld-servers.net.
- blog.cloudneta.net이라는 도메인 주소로 질의하면, .net의 TLD 네임 서버 주소인 a.gtld-servers.net.이라는 도메인 주소로 응답한다.
CNAME 레코드 유형
- 도메인 이름의 별칭을 지정하는 DNS 레코드 유형으로, 다른 도메인 이름을 정의한다.
www.cloudneta.net CNAME cloudneta.net
- www.cloudneta.net 이라는 도메인 주소로 질의하면 cloudneta.net의 도메인 주소로 응답한다.
2. Amazon Route 53 서비스
- AWS에서 제공하는 관리형 DNS 서비스
1) Amazon Route 53의 주요 기능
- 주로 도메인 이름 등록과 호스팅 영역 생성, 레코드 작성같은 기능을 제공
도메인 이름 등록
- 도메인 이름을 사용하려면 도메인 이름을 등록하는 절차가 필요하다.
- 사용자가 도메인 등록대행소에 도메인 이름 등록을 요청하면 도메인 등록 작업을 등록대행소에서 대행한다. 도메인 등록대행소로 국내외에 다양한 웹 사이트가 존재하는데 Amazon Route 53도 도메인 등록대행소 역할을 수행한다.
호스팅 영역 생성
- Amazon Route 53으로 호스팅 영역을 생성하여 네임 서버를 관리할 수 있다.
- 호스팅 영역을 생성해야 Amazon Route 53이 등록된 도메인 이름에 대한 권한 있는 네임 서버이자 SLD 네임 서버의 역할을 수행할 수 있다.
- 호스팅 영역의 네임 서버들은 고가용성을 위해 다수의 서버로 구성하는데, 마치 네임 서버들의 Zone을 구성하는 개념이다.
레코드 작성
- Amazon Route 53은 DNS 레코드를 정의하여 도메인에 대한 요청 처리 방법을 정의할 수 있는데, 이런 DNS 레코드는 다양한 형태의 라우팅 정책을 연결하여 도메인 요청에 대한 응답 방식을 정의할 수 있다.
2) Amazon Route 53의 라우팅 정책
단순 라우팅 정책
- 도메인에 대해 특정 대상을 지정하는 방식으로 여러 대상이 있으면 랜덤한 대상을 선택하고 응답한다.
가중치 기반 라우팅 정책
- 대상의 가중치를 지정하여 비중에 따라 대상을 선택하고 응답한다.
- 가중치는 0~255 범위에서 설정하는데, 대상별 가중치 값을 합산한 전체 가중치를 대상별 가중치로 나누어 비중을 부여한다.
지연 시간 기반 라우팅 정책
- 다수의 리전에 대상 자원이 있으면 사용자와 인접한 리전을 기준으로 대상 자원의 리전까지 지연 시간을 파악해서 지연 시간의 대상을 선택하고 응답한다.
장애 조치 라우팅 정책
- 다수의 대상 자원에 대해 액티브와 패시브로 분류하고 대상 상태를 주기적으로 검사하여 액티브 대상을 선택하고 응답한다.
- 액티브 대상이 통신 불가능할 때는 패시브 대상을 액티브로 승격하여 대상 경로로 라우팅한다.
3) 도메인 이름 생성하기
Amazon Route 53을 이용한 유료 도메인 네임 생성 단계
- AWS 관리 콘솔에서 Route 53 서비스에 진입하고 왼쪽 등록된 도메인 메뉴를 선택한 후 도메인 등록을 누른다.
- Route 53 서비스에서 호스팅 영역 메뉴를 선택한 후 생성한 도메인을 클릭하여 호스팅 영역에 진입한다.
- 생성한 도메인의 호스팅 영역에서 가지고 있는 레코드를 확인하고, 테스트용 레코드를 생성하기 위해 레코드 생성을 누른다.
- 간단한 테스트용 레코드를 생성하기 위해 다음과 같이 설정
- 레코드 이름에 내 도메인의 서브 도메인으로 'test' 입력
- 레코드 유형은 A 레코드 유형 선택
- 값에 A 레코드의 IPv4 값으로 '8.8.8.8' 입력
- 라우팅 정책은 단순 라우팅 선택
- 레코드 생성 누르기
- ㅊ이라는 도메인 이름은 A 레코드 유형으로 IPv4 주소를 8.8.8.8로 매핑한 단순 라우팅 정책이다. 즉, test.cloudnetajuju.com 도메인 이름을 요청하면 8.8.8.8의 IP 주소를 반환한다.
- test.cloudnetajuju.com에 대해 nslookup 명령어로 확인해 보면 DNS 서버에서 8.8.8.8 IP 주소를 응답한다. 그리고 ping 명령어로 통신 테스트를 하면 8.8.8.8 IP 주소로 통신하는 것을 확인할 수 있다.
3. CDN이란
- CDN은 Contents Delivery Network의 약어로, 콘텐츠 제공자와 사용자가 지리적으로 멀리 떨어져 있는 환경에서 콘텐츠를 빠르게 전달하는 네트워크 기술이다.
1) CDN 환경
- CDN 기술이 없는 일반적인 네트워크 통신 환경에서는 원본 콘텐츠를 가지고 있는 오리진(origin) 서버에서 사용자에게 콘텐츠를 전달한다. 이런 환경에서는 오리진 서버에 높은 부하가 발생하고 지리적으로 멀리 떨어져 있는 사용자에게 콘텐츠를 전달할 때 지연 시간이 길어지는 것은 불가피하다.
- CDN 기술의 핵심은 캐시 서버를 지역적으로 분산하고 콘텐츠를 동기화하여 분산 처리하는 것이다. 오리진 서버에서 지역적으로 분산된 캐시 서버에 콘텐츠를 동기화해서 콘텐츠가 분산된 환경을 구성한다. 그러면 사용자는 인접한 캐시 서버로 콘텐츠를 전달받아 빠르고 효율적인 서비스를 제공받을 수 있다.
2) CDN 캐싱 방식
캐싱
- 오리진 서버의 원본 콘텐츠를 지역적으로 분산된 캐시 서버로 전달하고 콘텐츠를 저장하는 것
캐시 미스(Cache Miss)
- 캐시 서버에 콘텐츠를 가지고 있지 않은 상태
- 사용자가 캐시 서버에 콘텐츠를 요청한다.
- 캐시 서버에 해당 콘텐츠가 없어 Chche Miss 판정을 한다
- 캐시 서버는 오리진 서버에 콘텐츠를 요청한다.
- 오리진 서버는 원본 콘텐츠를 복제하여 캐시 서버에 전달한다.
- 캐시 서버는 해당 콘텐츠를 저장하는 캐싱을 수행한다.
- 캐시 서버는 사용자에게 콘텐츠를 전달한다.
캐시 히트(Cache Hit)
- 콘텐츠를 가지고 있는 상태
- 사용자가 캐시 서버에 콘텐츠를 요청한다.
- 캐시 서버에서 해당 콘텐츠를 가지고 있어 Cache Hit 판정을 한다.
- 캐시 서버는 사용자에게 콘텐츠를 전달한다.
정적 캐싱
- 정적 콘텐츠는 변경되거나 수정되지 않는 콘텐츠를 의미한다. (이미지 파일, 자바스크립트, CSS 등)
- 정적 캐싱은 정적 콘텐츠를 캐싱하는 방식을 의미한다.
- 정적 캐싱은 정적 콘텐츠가 변경되지 않는 특징에 따라 별도의 사용자 요청이 없어도 오리진 서버에서 캐시 서버로 미리 콘텐츠를 복사한다. 그래서 사용자가 캐시 서버로 콘텐츠를 요청하면 TTL 동안 바로 응답할 수 있는 Cache Hit 상태로 동작한다.
동적 캐싱
- 동적 콘텐츠는 사용자 요청이나 정보에 따라 즉석에서 생성되는 콘텐츠를 의미한다.
- 사용자의 정보를 활용하여 매번 변경되는 형태의 콘텐츠가 동적 콘텐츠이다.
- 동적 캐싱은 동적 콘텐츠를 캐싱하는 방식을 의미한다.
- 동적 캐싱은 캐시 서버에서 콘텐츠를 보관하지 않고 Cache Miss 상태로 동작한다. 이때 캐시 서버는 콘텐츠를 저장하지 않고 통과시키기 때문에 결국 사용자는 오리진 서버에서 캐시 서버를 거쳐 콘텐츠를 전달받는다.
- 동적 캐싱은 캐시 서버에서 동적 컨텐츠를 저장하지 않기 때문에 TTL을 0으로 설정한다.
4. Amazon CloudFront란
- AWS에서 제공하는 CDN 서비스로 정적 콘텐츠나 동적 콘텐츠를 사용자에게 빠르게 배포하도록 지원하는 서비스
- 전 세계에 분포된 엣지 로케이션(edge location)이라는 곳에 콘텐츠를 캐싱하고 사용자 요청에 따라 가장 지연 시간이 낮은 엣지 로케이션이 응답하여 최적의 성능을 보장한다.
1) Amazon CloudFront 구성
- AWS의 글로벌 엣지 네트워크를 이용하여 오리진 대상의 콘텐츠를 전 세계에 위치한 엣지 로케이션과 엣지 캐시에 캐싱하여 CDN 서비스를 제공한다.
오리진 | - 원본 콘텐츠를 가지고 있는 대상 - 온프레미스의 일반 서버나 AWS 서비스의 EC2, ELB, S3이 될 수 있다. |
Distribution | - 오리진과 엣지 중간에서 콘텐츠를 배포하는 역할을 수행하는 CloudFront의 독립적인 단위 - 웹 서비스 전용의 Web Distribution과 스트리밍 전용의 RTMP Distribution으로 분류 |
리전 엣지 캐시 | - 빈번하게 사용되는 콘텐츠에 대해 캐싱하는 큰 단위의 엣지 영역으로, 오리진과 엣지 로케이션 사이에 위치 |
엣지 로케이션 | - Distribution으로 배포되는 콘텐츠를 캐싱하는 작은 단위의 엣지 영역 - 사용자 입장에서 가장 인접한 엣지 로케이션이 콘텐츠를 전달 |
2) Amazon CloudFront 기능
정적 및 동적 콘텐츠 처리 | Amazon CloudFront는 정적 콘텐츠와 동적 콘텐츠에 최적화된 캐싱 동작을 제공 |
HTTPS 기능 | 오리진 대상이 HTTPS를 지원하지 않아도 Amazon CloudFront가 알아서 HTTPS 통신을 중계한다. 즉 사용자와 CloudFront는 HTTPS로 통신하고 CloudFront와 오리진은 HTTP로 통신할 수 있다. |
다수의 오리진 선택 기능 | Amazon CloudFront의 단일 Distribution 환경에서 다수의 오리진을 지정하고 선택하여 콘텐츠를 분산 처리할 수 있다. |
접근 제어 | 서명된 URL과 쿠키(cookie)로 사용자 인증을 지원하여 인증된 사용자만 접근할 수 있도록 지원 |
5. Amazon CloudFront로 CDN 서비스 구성하기
실습 단계
- 실습을 위한 기본 인프라를 CloudFormation으로 배포
- Amazon Route 53을 설정하고 기본 인프라 환경의 검증을 수행
- Amazon CloudFront Distribution을 생성
- Amazon Route 53을 설정하고 Amazon CloudFront 환경의 검증을 수행
1) CloudFormation으로 기본 인프라 배포하기
- 남아메리카(상파울루) sa-east-1 리전을 선택한 후 CloudFormation 메뉴에서 스택 생성을 누른다.
- 스택 세부 정보 지정 페이지에서 스택 이름에 'CF-LAB'을 입력하고 다음을 누른다.
- 스택 옵션 구성과 CF-LAB 검토에서는 별도의 설정을 하지 않고 각각 다음과 전송을 누른다.
2) Amazon Route 53 설정과 기본 인프라 검증하기
- 앞서 CloudFormation을 이용하여 상파울루 리전에서 생성한 EC2 인스턴스에서 웹 서비스가 동작하고 있는데, Amazon Route 53으로 레코드를 설정한 후 웹에 접속하기
- Amazon Route 53 > 호스팅 영역으로 들어가 사전 작업에서 생성한 도메인 이름을 클릭한다.
- 도메인의 호스팅 영역 페이지에서 오른쪽에 있는 레코드 생성을 누른다.
- 신규 레코드를 생성하기 위해 다음과 같이 설정
- 레코드 이름은 빈칸으로 유지
- 레코드 유형은 A 레코드 유형 선택
- 값에는 앞서 복사한 인스턴스의 퍼블릭 IP 주소 붙여넣기
- 라우팅 정책은 단순 라우팅 선택
- 레코드 생성 누르기
- 해당 인스턴스에서 제공하는 웹 페이지는 대용량의 이미지 파일이 구성되며, 구글 크롬 브라우저에서 지연 시간을 체크할 것
- 구글 크롬 브라우저에서 단축키를 눌러 개발자 도구를 실행하고 Network 탭을 클릭
- Amazon Route 53 레코드에서 정의한 각자 생성한 도메인 주소로 접근
- 지연시간 60밀리초
- 재접속하여 평균 측정값을 확인한다.
- 구글 크롬 브라우저의 새로고침 위에서 마우스 오른쪽 버튼을 눌러 캐시 비우기 및 강력 새로고침을 선택하여 지연시간을 측정한다.
3) Amazon CloudFront Distribution 생성하기
AWS Certificate Manager에서 도메인 인증서 등록
- AWS Certificate Manager는 AWS 서비스 및 연결된 리소스에 대해 SSL/TLS 인증서를 관리하는 서비스이다.
- 미국 동부(버지니아 북부) us-east-1 리전을 선택하고 AWS Certificate Manager 서비스에 들어가 인증서 요청을 누른다.
- 인증서 유형에서 퍼블릭 인증서 요청을 선택하고 다음을 누른다.
- 퍼블릭 인증서 요청 페이지에서 다음과 같이 설정한다.
- 완전히 정규화된 도메인 이름에는 ".(도메인 이름) 입력
- 검증 방법은 DNS 검증 선택
- 가장 아래쪽에 있는 요청 누르기
- 오른쪽 위에 있는 Route 53에서 레코드 생성을 누른다.
- DNS 검증을 위해 레코드 생성을 누른다.
Amazon CloudFront Distribution 생성하기
- EC2 인스턴스의 퍼블릭 DNS 주소 복사
- Amazon CloudFront 서비스에 들어가 오른쪽에 있는 CloudFront 배포 생성을 누른다.
- Amazon CloudFront의 Distribution을 생성하기 위해 다음과 같이 설정한다.
- 원본 도메인에는 앞서 복사한 EC2 인스턴스의 퍼블릭 DNS 주소 붙여넣기
- 프로토콜은 HTTP만 해당 선택
- 자동으로 객체 압축은 No 선택
- 뷰어 프로토콜 정책은 HTTP and HTTPS 선택
- [캐시 키 및 원본 요청] Legacy cache settings 선택하고 하위 설정은 기본값 유지
- 웹 애플리케이션 방화벽(WAF)은 보안 보호 비활성화 선택
- 가격 분류는 모든 엣지 로케이션에서 사용 선택
- 대체 도메인 이름에서 항목 추가를 눌러 cdn.도메인 이름 입력
- 사용자 정의 SSL 인증서는 앞서 생성한 ACM 인증서 선택
- 기본값 루트 객체는 '/index.php'입력
- IPv6는 끄기 선택
- 마지막으로 배포 생성 누르기
4) Amazon Route 53 설정과 CloudFront 환경 검증하기
- 생성한 Distribution에서 Amazon Route 53으로 레코드를 설정한 후 웹에 접속
- Amazon CloudFront에서 Distribution의 도메인 이름을 복사
- Amazon Route 53 > 호스팅 영역으로 들어가 사전 작업에서 생성한 도메인 이름을 클릭
- 도메인의 호스팅 영역 페이지에서 오른쪽에 있는 레코드 생성을 누른다.
- 신규 레코드를 생성하기 위해 다음과 같이 설정
- 레코드 이름에 'cdn' 입력
- 레코드 유형은 A 레코드 유형 선택
- 별칭 선택
- 트래픽 라우팅 대상은 CloudFront 배포에 대한 별칭 선택
- 앞서 생성한 CloudFront Distribution의 도메인 이름 선택
- 라우팅 정책은 단순 라우팅 선택
- 레코드 생성 누르기
- 사용자 PC에서 Amazon CloudFront의 Distribution으로 웹에 접근
최초 접속
- Amazon Route 53 레코드에서 정의한 각자 생성한 도메인 주소로 접근
- 사용자 PC에서 최초로 Amazon CloudFront Distribution의 도메인 주소로 접근하면 엣지 로케이션에 콘텐츠가 없어 오리진으로 콘텐츠를 받아 전달한다.
- 왼쪽 콘텐츠에서 test.jpg 파일을 클릭하고 오른쪽에서 헤더 정보를 확인한다.
- x-cache 필드 값은 'Miss from cloudfront'인데, 이것은 콘텐츠 응답을 엣지 로케이션이 아닌 오리진을 통해 응답했다는 의미이다.
재접속
- 구글 크롬 브라우저의 새로고침 위에서 마우스 오른쪽 버튼을 눌러 캐시 비우기 및 강력 새로고침을 선택한다.
- 왼쪽 콘텐츠에서 test.jpg 파일을 클릭하고 오른쪽에서 헤더 정보를 확인
- 콘텐츠 헤더 정보 중 x-cache 필드 값이 'Hit from cloudfront' 인데, 이것은 콘텐츠 응답을 엣지 로케이션을 통해 응답했다는 의미이다. 사용자 PC에서 인접한 엣지 로케이션이 콘텐츠를 제공해 준 것이다.
'AWS' 카테고리의 다른 글
[AWS 교과서] 8장 AWS IAM 서비스 (0) | 2024.08.13 |
---|---|
[AWS 교과서] 6장 AWS 데이터베이스 서비스 (0) | 2024.08.08 |
[AWS 교과서] 5장 AWS 스토리지 서비스 (0) | 2024.08.02 |
[AWS 교과서] 4장 AWS 부하 분산 서비스 (0) | 2024.08.01 |
[AWS 교과서] 3장 AWS 네트워킹 서비스 (0) | 2024.07.31 |