nestJS 실시간 채팅 앱 - [Fin] 도메인

마루톡은 앞으로도 계속 리팩토링과 새로운 기능의 버젼이 업데이트됩니다!

하지만 마루톡 개발 관련 글은 이게 마지막이 될 것 같고, 올 한해의 마지막날을 내 서비스 개발기의 마지막 글로 장식할 수 있음에 기쁩니다.

 

아직 마루톡은 주변 지인들의 사용 후 피드백으로부터 버그와 개선을 진행 중입니다.

여태까지는 사용자가 아직 적기 때문에 s3 정적 웹호스팅 후 나온 주소로 사용 중이었는데, 폼나지도 않고 아직 https 프로토콜이 아니라 보안상 취약하기도 하기때문에 도메인을 구입해서 적용해주기로 결정했습니다.

그래서 마루톡개발기의 마지막은 AWS Route53을 이용한 내 서비스에 도메인 연결하기입니다.

 

크게 해야할 신경쓸 작업은 아래 세가지 같습니다.

1. 도메인 구하기

2. 도메인 연결하기

3. 보안 관련 설정하기

 

 

 

1.  도메인 구하기

도메인은 때마침 1년 2만원에 원하는 marutalk.com 을 사용할 수 있어서 냅다 구입했습니다. ^ㅡ^

출발부터 기분이 좋습니다.

 

2. SSL 인증서 작업

구매한 도메인이름으로 AWS Certificate Manager을 통해 인증서를 발급받자. (버지니아 북부)

발급을 받고 Route 53에 레코드를 생성해주도록 하자

그리고 인증서가 발급되면 Route 53에서 레코드 생성을 해주자 

 

3. S3, CloudFront 작업

설명

CloudFront는 AWS에서 제공하는 CDN (Content Delivery Network)서비스 이다.

전 세계에 분산된 엣지로케이션을 활용하여 정적 웹 컨텐츠를 빠르고 안전하게 제공하는데 사용한다.

• 배포
  CloudFront에서 생성하는 CDN 구성을 의미
  웹 배포: HTTP/HTTPS 프로토콜 기반 콘텐츠 전송
• 원본
  콘텐츠의 실제 저장소
• 캐시 동작
  특정 요청에 대한 CloudFront의 응답 방식을 정의

클라이언트가 브라우저에 URL을 입력해서 호출

cloudFront 도메인으로 DNS 요청이 발생하고 Route53 또는 다른 DNS 서비스가 가장 가까운 엣지 로케이션으로 요청 전달

캐시에 컨텐츠가 있다면 바로 반환, 없다면 원본 서버로 요청 전달

원본에서 가져온 콘텐츠를 엣지 로케이션에 저장(Cache)하고 클라이언트에 응답

cloudfront와 같이 사용하는 다른 aws 서비스

1. S3: 정적 파일 원본 서버로 활용.
2. Route 53: 사용자 도메인 이름을 CloudFront 배포와 연결.
3. ACM(AWS Certificate Manager): HTTPS를 위한 SSL/TLS 인증서 제공.

작업

S3버킷의 이름은 내가 사용할 도메인의 이름과 일치해야한다.

marutalk.com, www.marutalk.com  두개의 버킷을 생성했고,
특이점은 www.marutalk.com  버킷은 호스팅 유형을 객체에 대한 요청 리디렉션으로 하여 marutalk.com 으로, 프로토콜은 https로 해두었다.

그리고 구매한 도메인과 동일한 명의 버킷을 생성하여 build 파일들을 올려두자

그리고 정적 웹호스팅을 해서 누구나 내 사이트에 컨텐츠를 볼 수 있게 퍼블릭으로 해두자.

 

S3를 생성했고, 그 다음은 CloudFront 작업. 

 

발급받은 인증서로 cloudfront를 등록하고 원본에는 marutalk.com, www.marutalk.com  버킷을 둘다 등록했음.

그리고 route53에 레코드를 생성하는데,

cloudfront의 배포 도메인을 복사해서 
대체 도메인인 www.marutalk.com은 CNAME으로,  메인 도메인인 marutalk.com은 A로 별칭을 사용하여 각각 클라우드 프론트의 배포 도메인과 연결해주면 모두 https://marutalk.com 으로 리디렉팅된다.

 

4. Route53 작업

Amazon Route53은 AWS에서 제공하는 클라우드 기반 DNS 서비스다.

Route53을 통해 도메인 이름을 관리하고, 이를 통해 인터넷 사용자가 요청한 도메인을 올바른 리소스로 연결하도록 지원한다.

DNS 기능 외에도 도메인 등록과 헬스 체크 기능을 제공한다.

도메인 이름을 IP주소, AWS 리소스(CloudFront 배포, ALB, S3 버킷 등) 또는 외부 서버와 연결한다.

주로 사용되는 DNS 레코드 유형으로는

• A Record: 도메인 이름을 IPv4 주소로 변환
• CNAME Record: 도메인 이름을 다른 도메인 이름으로 매핑

일반적으로 위 두개가 가장 많이 사용되는 유형이다.

Route53의 웹 애플리케이션 호스팅 기능을 통해 S3, EC2, ALB, CloudFront 리소스를 도메인 이름에 연결하여 웹애플리케이션을 호스팅할 계획이다.

 

Route53을 통해 도메인을 구입하면 기본적으로 호스팅영역에 SOA 레코드와, NS 레코드가 등록되어 있다.

• SOA 레코드
  도메인 DNS 설정에 대한 기본정보 제공
  Serial Number를 사용해 DNS 데이터 변경을 다른 DNS 서버에 전파
  해당 도메인을 관리하는 권위있는 DNS 서버와 관련된 메타 데이터를 포함
  DNS 쿼리의 순서를 제어
• NS 레코드
  해당 도메인의 DNS 요청을 처리할 네임서버를 지정
  네임서버는 도메인에 대해 권위있는 응답을 제공, 도메인의 모든 하위 도메인까지 관리

s3로 정적웹호스팅을 하고 있는것을 https를 사용하기 위해 cloudfront를 사용중이라면

route53에 레코드를 등록할때 포인트는 s3로 등록하는 것이 아니라 cloudfront의 배포 도메인을 등록해주는 것이 포인트다.

 

5. 서버 작업

이제 정적 웹사이트가 도메인과, 대체 도메인으로 https 접속이 되었다면,

서버에도 SSL, https를 적용해주기 위해 서버내에 리버스 프록시 처리를 해주던지, 로드 밸런서를 생성해주던지 해야한다.

근데 서버에 따로 리버스프록시 설정을 해주기엔 또 SSL인증서를 받고 nginx따위의 세팅을 해줘야해서

굳이 아까 ACM 에서 발급받은 인증서가 있다면 ALB와 Route53을 활용해서 라우팅 시키는게 좋아보인다.

cloudfront의 경우 글로벌 서비스라 버지니아 북부 리전에서만 인증서를 발급받고 사용하지만,

다른 서비스(로드 밸런서 등)는 현재 리전에서 다시 인증서를 발급받아야한다.

재밌는점은 버지니아북부, 다른 리전에서 인증서를 발급받았을때 CNAME은 같은걸 볼 수 있는데, 이는 인증서 발급 시 사용하는 도메인 검증 과정에서 동일한 도메인 이름을 사용해서 그렇다.(정확히는 도메인 소유권을 인증하기 위한 방식이 리전 간에 동일하다) 하지만 리전마다 인증서가 관리되는 방식은 다르다!

• *로드밸런서 생성
  주석에 있는 로드밸런서 정리글을 읽고보면, 지금 필요한 로드밸런서는 L7 (애플리케이션 계층), (HTTP/HTTPS)에서 작동하는 애플리케이션 로드밸런서로 생성해야겠다는 생각이든다.
  • 애플리케이션 로드밸런스 3대요소 (리스너, 규칙, 대상그룹)
    • 리스너: 외부의 요청받아 검사하고 적절한 타겟으로 전달하는 기능
    • 규칙: 트래픽 분배를 위한 라우팅 규칙
    • 대상그룹: 리스너가 전달한 요청을 처리할 ec2 인스턴스 집합
  • 로드밸런서는 리스너는 40, 443 포트를 열어주고, 대상 그룹은 요청을 보낼 인스턴스의 포트로 해주면 된다.
  • 생성한 로드밸런서는 route53에 레코드를 등록해주면 되는데, 이때 통신만을 위한 대체도메인 (qwe.marutalk.com 따위) 로 해서 등록해주면 된다. 로드밸런서를 통해 요청을 내부적으로 리디렉션 시킬수있고, 포트 자체를 외부에서는 알수없게 된다.

 

6. 에러

웹소켓 연결이슈

nestjs gateway에서 서버자체의 cors origin 말고 웹소켓연결에서도 cors origin을 적어두는데, 도메인 변경하면서 gateway에 도메인을 추가해두지 않아 cors에러가 발생했었다.

 

 

 

 

 

 

** Load Balancer

• https://sihanni.tistory.com/87

 

** 브라우저에 url을 입력했을 때 발생하는 일들
https://sihanni.tistory.com/88