HTTPS 배포 실습

SSL 인증서 발습

HTTPS는 SSL/TLS 인증서가 있어야 사용할 수 있습니다.

AWS에서는 웹서비스 제작을 위해 필요한 기본적인 퍼블릭 인증서를 무료로 제공하고 있습니다.

콘솔 상단의 서비스 또는 검색창에서 Certificate Manager를 찾아 접속한 뒤, 시작하기 버튼을 클릭합니다.

퍼블릭 인증서 요청을 선택한 뒤, 다음으로 넘어갑니다.

도메인 이름에 미리 구매했던 도메인을 입력( http:// 나 www 는 입력하지 않습니다)하고, DNS 검증을 선택한 다음 요청 버튼을 클릭합니다.

발급 요청이 완료되었지만, 아직 DNS 검증을 완료하지 않았기 때문에 8검증 대기 중으로 표시됩니다.

SSL 인증서 검증

AWS에서는 SSL 인증서가 무분별하게 사용되는 것을 방지하기 위하여 도메인에 맞는 인증서를 발급한 다음, 실제로 해당 도메인을 소유하고 있는 지 검증하여야 활성 상태로 변경합니다.

Route53에 검증용 CNAME 레코드를 추가하여 도메인 소유 여부를 검증할 수 있습니다.

DNS 검증을 위해 인증서 ID를 클릭합니다.

Route 53에서 레코드 생성 버튼을 클릭합니다.

레코드 생성 버튼을 클릭합니다.

Route 53으로 이동하여 여러분이 생성한 호스팅 영역의 레코드 목록을 보면, CNAME 레코드가 생성된 것을 확인할 수 있습니다

연결 확인을 위해 ACM에서 인증서 정보를 조회한 다음, CNAME 이름을 복사합니다.

터미널에서 dig (CNAME 이름) CNAME 을 입력합니다.

ANSWER SECTION에 CNAME 이름과 CNAME 값이 모두 표시되면 연결이 완료된 것입니다.
(확인이 완료될 때까지 시간이 다소 소요됩니다)

CNAME 확인이 완료되면, 인증서 상태가 발급됨으로 변경됩니다.

💡 DNS는 도메인에 맞는 IP를 안내하는 일종의 네트워크의 114와 같은 서비스입니다.
앞서 지정한 A레코드, CNAME 등은 모두 DNS 레코드의 일종이며, 처리할 방법에 따라 분류가 달라집니다.

1) A
IP와 도메인 매핑 시 사용합니다. 1개의 도메인에 다수의 대상 서버 IP를 등록할 수 있습니다.

2) AAAA
A레코드의 확장입니다. IPv6으로 매핑 시 사용하지만, IPv6이 아직 대중적으로 사용되지 못하고 있기 때문에 실제 사용은 저조합니다.

3) CNAME
서브도메인을 운영할 때 사용합니다. 서브도메인 ⇒ 주 도메인 ⇒ 대상 서버 IP 의 흐름으로 대상지를 찾습니다.

4) MX
도메인과 연동된 메일 서버를 확인할 때 사용되는 메일 서버 레코드입니다.

5) NS
도메인에 대한 네임서버를 확인할 수 있도록 하는 레코드입니다.

6) SOA
도메인에 대한 상세 정보가 기록되어 있는 레코드입니다.

CloudFront 배포 생성 및 인증서 적용

유저의 접속 트래픽은 가장 먼저 CloudFront에 도달하여 S3과 로드밸런서 중 어느 곳으로 데이터를 요청할 지 분류를 받게 됩니다.

또한, CloudFront는 전세계에 위치한 AWS 서버들을 이용하여 CDN 서비스를 제공합니다.

CDN 서비스를 이용하여 유저는 전세계 어디서든 빠른 속도로 컨텐츠를 전송받을 수 있고, 일부 리전의 접속이 원활하지 않거나 서버가 다운되었을 때 캐싱된 페이지를 조회할 수 있도록 하여, 서버가 중단된 상황에서도 일부 서비스에만 장애가 발생한 것과 같이 보이도록 합니다

aws 콘솔 상단의 서비스 또는 검색창에서 CloudFront를 찾아 접속한 뒤, 시작하기 버튼을 클릭합니다.

원본 도메인에 S3 엔드포인트 주소를 반드시 직접 복사하여 입력합니다.

Origin Shield 활성화 는 아니요를 선택합니다.

뷰어 프로토콜 정책 및 허용된 HTTP 방법을 아래와 같이 선택합니다.

대체 도메인 이름 영역에서 항목 추가 버튼을 클릭합니다.

대체 도메인 이름에 구입한 도메인을 입력한 다음, 사용자 정의 SSL 인증서 선택창을 클릭합니다.

인증서를 선택한 다음 배포 생성 버튼을 클릭합니다.

배포 도메인 이름을 복사합니다.

주소창에 입력하고, 제대로 페이지가 표시되는 지 확인합니다.
(시간이 다소 소요됩니다)

Route 53과 CloudFront

이제 Route 53과 CloudFront를 연결하여, 유저가 도메인을 입력하면 https를 이용하여 S3에 접속할 수 있도록 설정해 보도록 하겠습니다.

aws 콘솔 상단의 서비스 또는 검색창에서 Route 53을 찾아 접속한 뒤, 호스팅 영역 버튼을 클릭합니다.

기존에 생성했던 호스팅 영역을 클릭합니다.

도메인-S3엔드포인트를 연결하였던 A 레코드를 선택하고, 레코드 편집 버튼을 클릭합니다.

트래픽 라우팅 대상을 변경하기 위해 S3 웹사이트 엔드포인트에 대한 별칭을 클릭합니다.

CloudFront 배포에 대한 별칭을 선택하여 트래픽 라우팅 대상을 변경합니다.

대상 CloudFront 배포를 지정하기 위해 배포 선택창을 클릭합니다.

이전에 생성한 CloudFront 배포 도메인을 선택합니다.

저장 버튼을 클릭합니다.

구입한 도메인을 주소창에 입력하여 HTTPS 연결을 확인합니다.

SSR 배포 실습

인스턴스 배포 파일 생성

스태틱 라우팅으로 제작한 페이지는 직접 주소를 입력하여 접근할 수 있어서 S3에 업로드하여 조회할 수 있으나, 다이나믹 라우팅으로 제작한 페이지는 실제 주소가 존재하지 않아 직접 접근이 불가능합니다.

그렇기 때문에 다이나믹 라우팅은 SSR 배포를 통해서 접근이 가능하도록 코드를 작성하여야 합니다.

실제로 유저에게 렌더되는 화면은 위와 같지만, 실제 데이터는 비어있는 상태이기 때문에 getServerSideProps를 이용하여 데이터를 받아온 후 props를 통하여 렌더될 데이터를 전달해 주어야 합니다.

getServerSideProps가 존재한다면 getServerSideProps를 먼저 실행합니다.

이후 Props를 통하여 데이터를 받은 다음 유저의 브라우저로 전송되게 됩니다.

인스턴스 배포

이제 SSR 배포를 하기 위해 EC2 인스턴스를 생성하고 환경을 세팅한 다음, 프론트엔드 서버를 가동해 보도록 하겠습니다.

aws 콘솔 상단의 서비스 또는 검색창에서 EC2를 찾아 접속한 뒤, 인스턴스 시작 버튼을 클릭합니다.

인스턴스 구분이 용이하도록 이름에 구입한 도메인을 입력합니다.

OS 선택 블록에서 프리 티어 사용 가능한 64비트 Amazon Linux인지 확인합니다.

💡 Amazon Linux 대신 Ubuntu를 사용하면 안되나요?
사용하셔도 무방합니다.
단, Amazon Linux 외에는 가상 쉘을 이용할 수 없기 때문에 토큰 발급 후 터미널로 로그인하여 인스턴스에 접속하는 번거로움이 있어, 최근에는 Amazon Linux를 이용하는 추세입니다.

인스턴스 유형 블록에서 프리 티어 사용 가능한 t2.micro인지 확인합니다.

이후 키 페어 선택창을 클릭합니다.

💡 인스턴스에는 다양한 종류가 있고, 아래의 네이밍 규칙을 따릅니다.
[종류][세대](a).[등급]
ex) c5d.9xlarge

1) 종류
t : 가장 저렴하며 가장 많이 사용되는 인스턴스입니다.
c : CPU에 특화된 인스턴스입니다.
m : RAM(메모리)에 특화된 인스턴스입니다.
r : RAM(메모리)에 극히 특화된 인스턴스입니다.

2) 세대
숫자가 클수록 최신 사양입니다.
t 4세대와 c, m, r 6세대부터는 CPU가 달라 네이밍에 g가 붙습니다 (ex : r6g.xlarge)

3) 등급
nano, micro, small, medium, large, xlarge, 등 서버 내 임대 규모에 따라 이름이 붙습니다.
metal 등급은 서버의 모든 자원을 끌어와 사용할 수 있는 특별 등급입니다.

키 페어 없이 계속 진행을 클릭합니다.

가상 쉘 접속 시에는 이 옵션이 가장 편리합니다.

SSH 트래픽 허용에 체크하고, 위치 무관(0.0.0.0/0)을 선택합니다.

인스턴스 시작 버튼을 클릭합니다.

인스턴스 시작 성공 메세지가 표시되면, 모든 인스턴스 보기 버튼을 클릭해 목록으로 되돌아갑니다.

인스턴스 id를 클립합니다.

우측 상단의 연결 버튼을 클릭합니다.

연결 버튼을 클릭합니다.

아래와 같은 화면이 표시되면 정상 접속 상태입니다.

이 가상 컴퓨터는 방금 OS 설치가 완료되어, 아직 아무런 세팅이나 모듈이 설치되지 않은 초기 상태입니다.

아래의 명령어를 입력하여 먼저 nodejs 패키지부터 다운로드하도록 합니다.

curl -sL https://rpm.nodesource.com/setup_14.x | sudo bash

아래와 같은 화면이 표시되면 패키지 다운로드가 완료된 상태입니다.

아래의 명령어를 입력하여 nodejs를 설치합니다.

sudo yum install -y nodejs

yum이 nodejs를 설치하면 node --version 및 npm --version 입력 시 버전이 표시됩니다.

sudo npm install -g yarn 을 입력하여 yarn을 설치해 주도록 합니다.

yarn을 설치하면 yarn --version 입력 시 버전이 표시됩니다.

이제 git을 설치할 차례입니다.

sudo yum install git 을 입력하여 설치해 주도록 합니다.

패키지 다운로드 승인 요청이 표시되면 y를 입력한 다음 엔터를 눌러 승인합니다.

git을 설치하면 git --version 입력 시 버전이 표시됩니다.

로컬에서 미리 github에 클라이언트를 업로드 한 다음, EC2에서 해당 Repo를 clone합니다.

clone 시 깃허브 로그인을 요구합니다.

내 username (ID,email 아님에 유의!)을 입력하고 엔터를 누르면 아래와 같이 password를 요구하는데, 이 때 비밀번호가 아닌 github 토큰이 필요합니다.

github 우측 상단의 내 프로필을 클릭해서 settings를 클릭합니다.

설정 메뉴 하단의 Developer settings를 클릭합니다.

좌측 메뉴에서 Personal access tokens를 클릭합니다.

Generate new token을 클릭합니다.

Note에는 관리 시 식별 가능한 별칭이나 메모를 입력합니다.

토큰의 유효기간을 설정합니다.

원한다면 No expiration을 선택하여 만료되지 않도록 할 수 있습니다.

토큰 권한을 설정합니다.

원한다면 서버에서 모두 허용할 수 있습니다. Generate token 버튼을 클릭합니다.

토큰이 발급되면 복사 버튼을 누릅니다.

💡 주의!
토큰 코드는 해당 페이지 접속 시에만 조회할 수 있으며 다시 열람할 수 없습니다.
토큰은 보안상 매우 중요하기 때문에 외부로 유출되지 않도록 각별히 유의해 주세요!

복사한 토큰을 password에 붙여넣습니다.

아래와 같이 표시되면 clone에 성공한 것입니다.

CLI 명령어를 이용하여 원하는 디렉토리로 이동합니다.

package.json 이 위치한 디렉토리에서 미리 지정해 둔 SSR 빌드 스크립트 명령어를 입력합니다

인스턴스에 설치된 yarn이 SSR 빌드를 시작합니다. 이 과정에는 시간이 다소 소요됩니다.

아래와 같은 화면이 표시되면 빌드에 성공한 것입니다.

yarn start 를 입력하여 프론트엔드 서버를 가동합니다.

인스턴스 연결 허용

인스턴스에서 프론트엔드 서버 가동을 완료하였지만, 아직 외부 접근이 가능하도록 설정하지 않았습니다.

보안 그룹 설정을 통해 외부 연결을 허용해 보도록 하겠습니다.

EC2 인스턴스 목록에서 설정할 인스턴스 ID를 클릭합니다.

보안 탭을 클릭합니다.

보안 그룹 링크를 클릭합니다.

인바운드 규칙 편집 버튼을 클릭합니다.

규칙 추가 버튼을 클릭합니다.

유형을 사용자 지정 TCP로 선택하고, 포트 범위에 3000을 입력합니다.

소스에서 0.0.0.0/0 을 선택합니다. 선택박스가 자동으로 Anywhere로 변경됩니다.

규칙 저장 버튼을 클릭합니다.

EC2 인스턴스 목록에서 인스턴스 ID를 클릭합니다.

퍼블릭 IPv4 주소 및 퍼블릭 IPv4 DNS를 통해 모두 접속할 수 있습니다.

로드 밸런서 연결

SSR 배포 시 트래픽이 몰려 프론트엔드 서버에 과부하가 발생하는 상황을 방지하기 위해 자동으로 부하 분산 처리를 도와주는 로드밸런서를 연결하여 안정적인 클라이언트 배포를 하여야 합니다.

로드 밸런서 연결 방법에 대해 알아보도록 하겠습니다.

EC2 메뉴 좌측 하단의 로드밸런서를 클릭합니다.

로드 밸런서 생성 버튼을 클릭합니다.

Application Load Balancer의 Create 버튼을 클릭합니다.

이름 칸에는 구분이 용이하도록 구입한 도메인-lb 를 입력합니다.

로드밸런서 설정 시에는 EC2 인스턴스의 가용 영역을 확인해야 합니다.

새 창으로 인스턴스 목록을 띄워 가용 영역을 확인합니다.

로드밸런서 설정 창으로 돌아와서, Network mapping 블럭을 찾습니다.

이 때 미리 확인한 인스턴스의 가용 영역을 선택합니다.

이후 아무 영역이나 추가로 선택합니다.
(최소 2개의 영역이 선택되어 있어야 합니다)

Listeners and routing 블럭에서 Create target group 링크를 클릭합니다.

인스턴스를 선택하고, 타겟 그룹 이름에 구분이 용이하도록 구입한 도메인-lb-target-group을 입력합니다.

포트를 3000으로 변경합니다.

Next 버튼을 클릭합니다.

타겟을 등록할 인스턴스를 선택합니다.

Include as pending below 버튼을 클릭합니다.

Create target group 버튼을 클릭합니다.

아래와 같이 타겟 그룹 리스트에 새로운 그룹이 추가된 것을 확인할 수 있습니다

원래 창으로 돌아와서 새로고침 버튼을 클릭합니다.

선택창을 클릭하여 생성한 타겟 그룹을 선택합니다.

Create load balancer 버튼을 클릭합니다.

이제 로드밸런서가 생성되었습니다.

View load balancer 를 클릭하여 로드밸런서 목록을 확인합니다.

생성 후 초기 세팅을 위한 시간이 필요합니다.

상태가 프로비저닝 중 일 때에는 작동하지 않습니다.

상태가 활성으로 변경되면 로드밸런서 작동이 시작됩니다.

외부 접근을 허용하기 위해 보안 그룹 링크를 클릭합니다.

보안 그룹 목록에서 로드밸런서에 연결되어 있는 보안 그룹 ID를 찾아 클릭합니다

인바운드 규칙 편집 버튼을 클릭합니다

규칙 추가 버튼을 클릭합니다

유형을 HTTP로 설정합니다

소스를 0.0.0.0/0 으로 설정합니다

규칙 저장 버튼을 클릭합니다

보안 그룹 설정이 완료되면, 로드밸런서의 DNS 주소를 복사하여 접속할 수 있습니다

로드밸런서 연결을 해줌으로서 SSR 배포시 안정적인 클라이언트 배포를 위한 부하분산처리가 완료되었습니다.

여기까지 S3에 파일을 올려 정적 파일 SSG 배포와, EC2를 활용하여 서버에 접근해 동적 파일 SSR 배포까지 각각 완료했습니다. 이제는 요청이 들어올때마다 SSR과 SSG방식을 분기처리 해주어 각각 다른쪽으로 요청을 보내주어야 합니다.(SSR + SSG Hybrid)

다음 시간에는 이를 위해 분기처리를 위한 CloudFront 라우팅을 연결해주도록 하겠습니다.