AWS) Web Hosting

Web Hosting?

💡웹 사이트를 구성하는 여러 파일을 다양한 디바이스에서 엑세스할 수 있도록 하는 서비스

웹사이트에 엑세스하는 과정과 원리

💡웹사이트를 본다 === IP 주소를 통해 서버에 페이지를 요청한다

 

하지만 우리는 보통 IP 주소를 입력하여 웹사이트에 접근하지 않는다.

1. 유저가 브라우저 URL 주소를 입력한다.

💡URL의 2가지 형태

• 도메인 (ex. naver.com)
• IP 주소 (ex. 172.0.0.1) </aside>

거의 대부분의 서비스들은 URL 주소로 IP를 직접 노출시키지 않는다.

사용자의 편의성을 위하여, 인식하기 쉬운 naver.com과 같은 도메인을 사용한다.

 

도메인으로 웹사이트에 접근하는 원리

• 도메인은 IP 주소와 매칭되어있다.
• DNS 서버를 통해 해당 도메인과 매칭되는 IP 주소를 찾을 수 있다.

 

DNS(도메인 네임 시스템)

DNS 쿼리가 캐시되어 있지 않다면, IP 탐색은 Root 영역으로부터 시작된다.

Root 영역에서부터 차례로 내려가며, 최종적으로 해당 도메인과 매칭되는 IP 주소를 찾는다.

찾은 IP 주소는 최종적으로 클라이언트에게 반환되며, 반환된 IP 주소로 웹 사이트를 요청한다.

 

가비아, 고대디와 같이 도메인 거래 서비스 업체에서 특정 도메인 이름을 구매할 수 있다.

 

DNS 설정

DNS는 등록된 레코드 정보를 바탕으로 IP를 탐색한다.

 

💡참고 - 레코드 종류별 정보

• A 레코드 - 도메인의 IP 주소를 갖고 있는 레코드. A 레코드에 대해 자세히 알아보세요.
• AAAA 레코드 - 도메인의 IPv6 주소를 포함하는 레코드(IPv4 주소를 나열하는 A 레코드와 반대).AAAA 레코드에 대해 자세히 알아보세요.
• CNAME 레코드 - 하나의 도메인이나 하위 도메인을 다른 도메인으로 전달하며, IP 주소를 제공하지는 않습니다. CNAME 레코드에 대해 자세히 알아보세요.
• MX 레코드 - 이메일을 이메일 서버로 전송합니다. MX 레코드에 대해 자세히 알아보세요.
• TXT 레코드 - 관리자가 레코드에 텍스트 메모를 저장할 수 있습니다.이 레코드는 종종 이메일 보안에 사용됩니다.TXT 레코드에 대해 자세히 알아보세요.
• NS 레코드 - DNS 항목의 이름 서버를 저장합니다. NS 레코드에 대해 자세히 알아보세요.
• SOA 레코드 - 도메인에 대한 관리자 정보를 저장합니다. SOA 레코드에 대해 자세히 알아보세요.
• SRV 레코드 - 특정 서비스에 대한 포트를 지정합니다. SRV 레코드에 대해 자세히 알아보세요.
• PTR 레코드 - 리버스 조회에서 도메인 이름을 제공합니다. PTR 레코드에 대해 자세히 알아보세요.

NS / A 레코드를 통한 IP 탐색 흐름

1 NS 레코드 → 네임서버 정보 요청

2	도메인에 대한 DNS 요청권한을 가진 네임서버 정보 획득
3	네임서버 정보 → A 레코드 정보 요청
4	A 레코드에 대한 IP 주소 획득

CNAME의 역할

하위 도메인의 이름과 매칭되는 정보

CNAME을 통해 페이지를 요청한다면, 연결된 도메인을 먼저 탐색한 후에 NS / A 레코드를 통한 IP 탐색을 시작한다.

2. URL 주소와 연결되어 있는 서버에 페이지를 요청한다.

💡서버의 종류

• 자체적으로 관리하는 내부서버
• 클라우드를 통해 임대하는 외부서버

클라우드 서버의 장점

• 서버의 물리적인 유지보수를 할 필요가 없음
• 대규모 트래픽에 대하여 안정적이고 일관성 있는 대응이 가능함

클라우드 서버를 사용하면 적은 리소스로 안정적이고 신뢰성있는 서비스 제공이 가능하다.

• 참고) 위펄슨에서 사용하는 클라우드GCP: Cloud Functions, Authentication
• AWS: 웹 호스팅, S3 버킷

AWS로 웹 호스팅하기

S3 Bucket 생성

클라이언트에게 웹 사이트를 보여주려면,

서버가 클라이언트에게 보낼 웹 사이트 구성 파일을 가지고 있어야 한다.

S3 > 버킷 만들기

💡버킷 정보 입력

• 버킷 이름 : CloudFront, Route53에서 생성할 이름과 동일하게 지정
• ACL 활성화 버킷 소유자 : 버킷을 소유한 계정에게 버킷에 있는 모든 객체(파일들)에 대한 모든 권한이 있음 : 버킷 소유자가 아닌 사람이 해당 버킷에 객체 업로드를 하는 경우, 버킷 소유자에게 모든 권한을 이전하는 추가 설정이 필요함 (--acl bucket-owner-full-control) 객체 라이터 : 버킷에 업로드한 객체의 권한은, 해당 객체를 업로드한 사람에게 있음
• 퍼블릭 엑세스 차단 설정 : 버킷의 객체에 접근할 수 있는 엑세스 권한 설정 : CloudFront를 통해서만 S3 버킷에 접근하는 경우, 엑세스 차단을 풀어줌

정적 웹 사이트 호스팅

버킷 > 버킷 이름 > 속성 > 정적 웹 사이트 호스팅 > 편집

정적 웹 사이트 호스팅을 활성화

→ 지정한 인덱스 문서에 대한 원본 주소를 얻을 수 있음

CloudFront 배포하기 ( + 기존 캐시된 파일 무효화 )

💡CloudFront > 배포 생성

• 원본 Origin Domain : S3 Bucket의 주소
• 원본 엑세스 Legacy access Identities : 원본 엑세스 ID를 사용하여 Bucket에 접근 : 새 OAI 생성으로 ID 등록
• 기본 캐시 동작 뷰어 > 프로토콜 정책 > Redirect HTTP to HTTPS : weperson에서는 사용자 편의성을 위해 리다이렉트 옵션 사용중 뷰어 > 허용된 HTTP 방법 > GET, HEAD : weperson은 SPA 서비스이기 때문에, 최소 허용 옵션 사용중
• 설정 Custom SSL certificate - optional : HTTPS 보안 세팅을 위한 SSL 파일 등록

생성 후

aws cli를 통해 빌드한 파일을 업로드 / 캐시 무효화 할 수 있다.

// 빌드
yarn build

// 기존 dist/spa 제거 후 새롭게 빌드된 dist/spa 파일 업로드
aws s3 sync --acl public-read --delete dist/spa s3://서브도메인.com

// 존재하는 CDN 캐시파일 무효화
aws cloudfront create-invalidation --distribution-id ${{ secrets.AWS_PROD_CLOUDFRONT_ID }} --paths "/*"

 

캐시 무효화 직접 해보기

CloudFront > 배포 > 배포ID > 무효화 생성

경로 패턴을 통해 하위 파일들을 타겟팅하여 무효화 생성 → 캐시 무효화

Route53 연결

💡Route53 > 호스팅 영역 > 레코드 생성

• 레코드 이름 : 유저가 입력할 도메인 이름 레코드 유형

1. CloudFront 연결을 할 때 → CloudFront의 도메인 이름 또는 IP 주소
2. 정적 웹 호스팅을 할 때 → S3 Bucket의 인덱스 문서의 주소