2023. 5. 2~4

Index

클라이언트 배포 기초(AWS 배포 흐름 & 역할, 배포 방식&데이터 흐름)

배포(Next.js 프로젝트 빌드, Trailing Slash, S3, 도메인 연결)

와이어샤크(SSL, HTTPS - 3wayhandshake, 4wayhandshake)

HTTPS배포 실습(SSL인증서 발급, 검증, CloudFront 배포 생성, 인증서 적용, Route53과 CloudFront 연결)

SSR배포 실습(인스턴스 배포)

방화벽

로드 밸런서

CloudFront 라우팅 연결

Docker(설치, 사용하는 이유, Docker-compose의 이해, Dockerfile, 환경변수)

intro

인기가 많은 AWS(Amazon Web Service) - 선두주자, 사용자 많음
극초기의 스타트업 GCP // 구글
AZURE // MS
백엔드 컴퓨터를 대여하는 개념
정적페이지(스토리지주소/boards/~) index파일 - 항상 동일한 파일명 // 와 동적페이지(파일명 계속 바뀜-다이나믹 라우팅; 상세 페이지) 배포

1단계 배포 : 스토리지배포 - 아마존이 관리 해줌(AWS)
2단계 : 동적페이지 - 메모리,CPU등 알아서 트래픽 관리해야함 // 접속량 많아지면 컴퓨터 여러 대 필요하게 됨
3단계 : 트래픽 관리 // ELB(엘라스틱 로드밸런서) 프론트 서버들 그룹핑(타겟그룹, 인스턴스 그룹) // 트래픽 분산 로직 : round-robin, least-connection
4단계 : 동적 페이지와 정적 페이지 분기
회사 규모와 상세 페이지(다이나믹 라우팅) 여부에 따라 단계 설정

3, 4단계에서 로드밸런서에 SSL 인증서 부착( 이제부터 https로 보내라는 의미) // SSL 인증서는 CDN(CloudFront: 1단계, 4단계)에도 부착할 수 있다

SSL 인증서 발급시 반드시 버지니아 북부로 설정해야함

DNS(DomainNameSystem) Route53

클라이언트 배포 기초

AWS 배포 흐름 & 역할

1) S3 : Simple Storage Service (단위 : 1 Bucket)
무제한 용량을 제공하는 온라인 스토리지 서비스로 데이터를 객체 형태로 저장하여 관리하며, 비용이 매우 저렴함. 무료 사용량 없이 실제 사용량(저장한 데이터 크기 및 트래픽)에 따라 비용이 부과되도록 과금 테이블이 설정되어 있지만, 테라바이트 이상의 데이터가 저장되어야 달러 단위의 비용이 발생한다. (50TB까지 매월 1GB당 USD 0.025(약 KRW 32.25) 과금)

S3 Glacier (단위: 1 Vault)
백업을 위한 스토리지 서비스로 HDD가 아닌, 자기 테이프 기반 스토리지 서비스이며, 일정 기간마다 Vault로 전송된 데이터를 한번에 기록한 다음 전원을 차단하여 초장기 보관을 하는 방식으로 서비스된다. 자기 테이프를 읽어야 하기 때문에 데이터 열람 및 반출에 비용과 시간이 소요되며, 일반 사용자보다는 기업에서 대규모 데이터를 백업할 때 주로 사용한다.

2) EC2 : Elastic Compute Cloud(단위 : 1 인스턴스)
아마존 서버 내 일부 영역을 가상 컴퓨터 형태로 임대하는 서비스로 클라이언트 동적 배포 시에도 사용할 수 있으며, 주로 RDS와 같은 DB서비스에 연결하여 백엔드 서버로 이용된다.
대시보드에서 클릭 몇번으로 생성할 수 있고, 대규모 서비스를 구축하는 경우 오토스케일링을 이용하여 트래픽에 따라 인스턴스를 자동으로 늘리거나 줄여 손쉽게 대응할 수 있다. 단, 사용량(컴퓨터 가동 시간, 트래픽)에 따라 과금되며 분당 요금을 부과하기 때문에 프리티어가 아닐 경우 과도한 요금이 청구될 수 있어 유의해야 한다.

Load Balancer (단위: 1 로드밸런서)
트래픽을 여러 서브넷(하나의 네트워크를 필요한 크기만큼 분리)으로 분산 처리하여 EC2가 트래픽을 안정적으로 처리할 수 있도록 하는 부하 분산 서비스로 로드밸런서와 오토스케일링이 설정되지 않은 상태에서 인스턴스의 처리 한계를 넘을 경우 서비스 제공이 지연되거나 중단될 수 있기 때문에 대규모 서비스 구축 시 1차 대비책으로 로드밸런서를, 2차 대비책으로 오토스케일링을 설정하게 된다.

3) CloudFront (단위 : 1 배포)
아마존에서 제공하는 CDN 서비스로 대한민국에서 동일한 CDN 서비스를 제공하는 클라우드플레어보다 AWS CloudFront가 속도 및 사용 편의성 면에서 다소 유리하다.
전세계 어디서나 빠른 속도로 파일을 제공받을 수 있도록 해주며, S3과 연결하여 클라이언트 복합 배포를 할 수 있고, 라우팅 경로 최적화용으로도 사용할 수 있다.
또한 전세계의 AWS 캐시 서버에 동일한 내용이 복제되어 있기 때문에, 복합 배포 시 클라이언트 인스턴스나 서버 인스턴스가 작동을 중단한 상태에서 일정 기간 S3에 저장되어 있는 파일을 제공받을 수 있으며, 서비스 전체의 중단이 아닌 일시적인 장애 상태로 보이도록 할 수 있다.

4) Route 53 (단위: 1 호스팅 영역)
아마존에서 제공하는 DNS 서비스로
구입한 도메인을 AWS의 각 서비스들에 연결할 수 있도록 해 주며, 도메인 구입 및 관리도 지원한다.
단, 도메인 구입은 국내 호스팅 업체보다는 가격이 높으며 일부 도메인(.kr, .shop 등)은 지원하지 않는다.
도메인을 개별적으로 EC2나 S3에 연결할 때 반드시 Route 53을 이용할 필요가 없고, 단순히 DNS 기능만 이용할 때에는 타사 무료 호스팅 서비스를 이용할 수 있지만, AWS의 각종 서비스와 연결할 때에는 통합 관리를 제공하기 때문에 Route 53을 이용하는 것이 가격 및 편의성에서 유리하다.
무료 제공량 없이 호스팅 영역 당 월 USD 0.50 (KRW 600~700)이 부과된다.

5) ACM : Amazon Certificate Manager (단위: 1 인증서)
HTTPS 연결을 위한 SSL 인증서를 발급하고 관리하도록 해 주는 서비스로 퍼블릭 인증서는 무료로 발급이 가능하며, 무분별한 인증서 발급을 방지하기 위해 인증서 발급 후 도메인 소유권을 검증해야 인증서가 활성화된다.

배포 방식에 따른 데이터 흐름

클라이언트를 배포하는 방식에는 여러가지 방법이 존재한다.
크게 SSG Only, SSG+SSR, SSR Only로 분류할 수 있고, 서비스 특성과 규모에 따라 배포 방식이 결정된다.

1) SSG Only(Use CloudFront)

CloudFront를 이용하여 S3 엔드포인트에 접근하도록 하는 방법으로
유저가 Route 53으로 DNS 레코드를 요청하면 Route 53은 CloudFront의 도메인을 안내한다.
이후 유저는 CloudFront로 연결하고, CloudFront는 S3으로 요청과 응답을 중계한다.

CDN을 이용하여 캐싱된 파일들이 빠르게 제공되기 때문에, 퍼포먼스에 집중해야 하거나 마케팅 페이지 / 제품 목록 등과 같이 정적으로 생성하여 각 요청에 동일한 문서를 반환하는 서비스에 주로 사용되는 배포 방법이다.

단, CloudFront에 캐싱된 데이터가 렌더되기 때문에 변경사항을 자주 확인해야 하는 경우(개발단계 등)에는 적합하지 않은 방식이다.

2) SSG Only (no CloudFront)

CloudFront를 이용하지 않고 S3 엔드포인트에 접근하도록 하는 방법이다.
유저가 Route 53으로 DNS 레코드를 요청하면 Route 53은 S3 엔드포인트 주소를 안내한다.
이후 유저는 즉시 S3로 연결하여 요청과 응답을 주고받는다.

S3에 변경된 사항이 있을 경우 즉시 확인이 가능하기 때문에 개발 단계와 같은 상황에서는 적합하지만, CloudFront(CDN)를 이용하지 않기 때문에 1-1의 방법보다 퍼포먼스가 다소 좋지 못하며, CloudFront를 이용하지 않아서 SSL 인증서 적용이 어렵기 때문에 보안상으로도 취약한 부분이 발생할 수 있다.

3) SSR Only

정적 스토리지를 사용하지 않고 EC2만 이용하여 SSR로만 클라이언트를 배포하는 방법이다.
유저가 Route 53으로 DNS 레코드를 요청하면 Route 53은 CloudFront의 도메인을 안내한다.
이후 유저는 CloudFront로 연결하고, CloudFront는 로드밸런서를 거쳐 EC2로 요청과 응답을 중계한다.

항상 최신 상태를 유지해야 하거나, 제품 상세 정보 / 분석 자료 등과 같이 요청마다 다른 내용이나 형식의 문서를 반환하는 서비스에 주로 사용되는 방법이다.

4) SSG + SSR Hybrid

SSG와 SSR을 혼합하여 클라이언트를 배포하는 방법이다.
S3에 업로드된 빌드 파일을 CloudFront를 이용하여 캐싱하여 빠른 속도로 최초 화면을 표시한 다음, 나머지 페이지와 데이터들은 SSR 방식으로 전달한다. 그렇기 때문에 사용자는 빠르고 역동적인 경험이 가능하다.

또한, 잦은 변경이 필요하지 않은 파일(기본 레이아웃 및 디자인 등)들을 S3로 분리하여 EC2 인스턴스에 대한 부하를 줄일 수 있으며, 이를 통해 안정적인 서비스 제공 및 비용 절감 효과를 도모할 수 있다.

클라이언트 배포 실습

Next.js 프로젝트 빌드
SSG, SSR 각각 빌드를 하기 위해 명령어를 나누어주기

"scripts": {
  "dev": "next dev",
  "build": "next build",
	"build:ssg": "next build && next export"
  "start": "next start"
},

터미널에서 build 을 입력하면 SSR 빌드를, build:ssg 를 입력하면 SSG 빌드가 진행된다.

SSG 빌드 명령어를 입력하면 out 폴더가 생성되며 해당 폴더 안에서 SSG 배포에 사용되는 폴더와 파일들을 확인할 수 있다.

Trailing Slash
트레일링 슬래시는 URL 주소 끝에 붙은 슬래시 / 를 말한다.
예를 들어 https://www.google.co.kr/ 를 보시면 끝에 슬래시가 붙어있다.

사실 https://www.google.co.kr 이렇게 적어도 잘 동작하지만, 브라우저는 두 가지 경우를 다른 주소로 인식한다. 주소 끝에 슬래시가 붙어있으면 이건 디렉토리, 즉 폴더라는 의미이고, 슬래시가 없다면 여기가 끝, 즉 파일이라는 것을 의미한다.

Next.js의 기본 ssg build 옵션은 /boards/index.js 페이지를 /boards.html 이라는 이름을 가진 html 파일로 바꿔준다. 하지만 이런 형태의 폴더구조는 보기 불편하기 때문에, /boards/index.html과 같은 형태로 build 하도록 설정을 변경해보자.

next.config.js 파일을 열어 trailing slash 옵션을 추가하고 다시 yarn build:ssg 명령어를 실행하면 다음과 같이 build된 것을 확인할 수 있다.

S3(Simple Storage Service) 배포

먼저, S3에 SSG 배포 파일을 업로드 해보자.

1) AWS 콘솔에 로그인

1-2) 상단의 검색창에 S3을 검색하거나, 서비스 메뉴에서 직접 찾아 접속

1-3) 우측의 버킷 만들기 버튼을 클릭

2-1) 1번 부분에는 구매한 도메인을 입력하고, 2번 부분은 아시아 태평양(서울) 리전을 선택

주의) 버킷 이름에 http://, www 등은 입력하지 않는다.

2-2) 객체 소유권 블럭에서, ACL 활성화됨 을 선택하고, 객체 소유권은 버킷 소유자 선호 를 선택

2-3) 이 버킷의 퍼블릭 액세스 차단 설정 블럭에서 모든 퍼블릭 액세스 차단의 체크를 해제, 하위 체크박스도 모두 체크를 해제한 뒤, 경고창 내의 체크박스만 체크

2-4) 버킷 버전 관리와 서버 측 암호화는 비활성화 상태로 유지

버킷 버전 관리 사용이 좋은 것 아닌가?
스냅샷을 이용하여 git과 비슷하게 변경된 내용을 저장하기 때문에, 수정 전 내용으로 손쉽게 돌아갈 수 있는 장점이 있지만 자동으로 백업된 스냅샷 용량으로 인해 프리 티어 제한 사용량을 초과하여 과금될 수 있기 때문에 반드시 필요한 경우에만 사용해야 한다.

2-5) 버킷 만들기 버튼을 클릭

3-1) 버킷 목록에서 여러분이 입력한 도메인을 클릭

3-2) 업로드 버튼을 클릭

3-3) SSG 빌드를 통해 생성된 out 디렉토리 내의 모든 파일과 폴더를 Drag&Drop!

3-4) 모든 폴더와 파일이 업로드되었는지 확인

3-5) 업로드 버튼을 클릭

3-6) 업로드 성공이라는 메세지가 표시되면, 버킷 목록으로 돌아가서 구매한 도메인을 다시 클릭

3-7) 상세 화면의 객체 탭에서 모든 파일을 선택한 다음 작업을 클릭하고, 하위 메뉴에서 ACL을 사용하여 퍼블릭으로 설정 메뉴를 클릭

3-8) 퍼블릭으로 설정 버튼을 클릭

3-9) 퍼블릭 액세스 설정이 완료되었는지 확인한 뒤, 닫기 버튼을 누르기

3-10) 버킷 목록에서 도메인을 클릭하여 상세 보기 화면으로 진입한 뒤, 속성 탭 클릭

3-11) 아래로 스크롤하여 정적 웹 사이트 호스팅 블럭을 찾은 다음, 편집 버튼 클릭

3-12) 정적 웹 사이트 호스팅을 활성화한 다음, 호스팅 유형에서도 정적 웹 사이트 호스팅 선택(기본값).

3-13) 인덱스 문서에 index.html을 입력하고, 오류 문서에 404/index.html 입력

3-14) 아래로 스크롤하여 변경 사항 저장 버튼 클릭

3-15) 버킷 속성에서 아래로 스크롤하여 정적 웹 사이트 호스팅 블럭을 찾은 다음 엔드포인트 주소 클릭.

3-16) 정상적으로 엔드포인트에 접속되고 화면에 표시되는지 확인
여기까지 S3에 SSG 배포 파일을 업로드함으로써, 정적 웹 사이트 배포가 엔드포인트로 접속이 가능한 상태가 되었다. 하지만, 일반적인 url 접근방식을 위하여 엔드포인트가 아니라 도메인을 이용해 접근할 수 있도록 하려면, 엔드포인트와 도메인을 연결해 주어야 한다.

도메인 연결

도메인을 S3, EC2 등 AWS와 연결하는 데 반드시 Route 53을 사용할 필요는 없지만,
Route 53을 이용하면 통합 관리가 가능한 장점이 있다.
또한, CloudFront나 Load Balancer 등의 고급 DNS 설정이 필요한 경우에는 타사 서비스보다 Route 53을 이용하는 것이 저렴하다.

Route53은 프리 티어가 제공되지 않는다. 호스팅 영역 1개당 약 7~800원의 비용이 과금된다.

1-1) aws 콘솔 상단의 ‘서비스' 또는 검색창에서 Route 53을 찾아 접속한 뒤, 시작하기 버튼 클릭

1-2) 호스팅 영역 생성을 선택한 뒤, 시작하기 버튼을 클릭

1-3) 도메인 이름에 미리 구입한 도메인을 입력하고, 퍼블릭 호스팅 영역을 선택

1-4) 호스팅 영역 생성을 클릭
1-5) 레코드 블록에서 유형이 NS인 항목을 확인

1-6) 도메인을 구입한 호스팅사에 접속한 다음, 도메인 관리 메뉴에서 네임서버 설정 부분을 찾기 -> 호스팅 사에 접속해서 네임서버 설정권한을 route53으로 넘겨주는 과정으로 Route53을 사용하여 도메인 통합 관리를 편하게 하기 위함이다.

1-7) NS레코드의 값/트래픽 라우팅 대상 부분을 순서대로 네임서버 설정에 입력

1-8) 설정 완료 페이지에서 제대로 설정이 완료되었는지 확인. 네임서버 설정은 시간이 다소 소요
1-9) 터미널에서 dig (구입한 도메인) NS를 입력

1-10) ANSWER SECTION에 NS레코드로 입력한 4개의 URL이 표시되면 네임서버 연결이 완료된 것

2-1) 네임서버 연결이 완료되었다면, Route53에서 레코드 생성 버튼을 클릭

2-2) 단순 라우팅을 선택하고 다음으로 넘어감

2-3) 단순 레코드 정의 버튼을 클릭

2-4) 값/트래픽 라우팅 대상 > 엔드포인트 선택을 클릭

2-5) 옵션 중 S3 웹 사이트 엔드포인트에 대한 별칭을 찾아 선택

2-6) 이어서 리전 선택을 클릭한 다음, 아시아 태평양(서울) 리전을 클릭

2-7) 이어서 표시되는 S3 엔드포인트 입력을 클릭하면 앞서 생성한 엔드포인트가 표시된다. 해당 엔드포인트를 클릭.

2-8) 모든 정보가 잘 입력되었는지 확인한 다음, 단순 레코드 정의 버튼을 클릭

2-9) 레코드 구성 목록에 방금 정의한 레코드가 추가되었다. 레코드 생성 버튼을 클릭

2-10) 레코드 목록에 도메인이 A레코드로 등록되었는지 확인

2-11) 구매했던 도메인을 주소창에 입력하고, 제대로 로드되는 지 확인

와이어샤크(SSL & HTTPS)

실시간 네트워크 분석을 위해 패킷 교환 과정을 포착하는 도구 중 하나

패킷? 네트워크 상에서 주고 받는 메시지 데이터 블록의 기본 단위

80번 포트와 443번 포트
💡 표시되어 있는 80은 http를 의미하며, 443포트는 https를 의미한다.
이 포트 번호들은 생략이 가능

그렇다면 왜 https를 사용해야 하는가?

‘ loginUserExample ‘ 이라는 요청을 보낼때 입력한 이메일과 패스워드가 쉽게 노출되는 것을 볼 수 있다.

왼쪽이 프론트엔드, 오른쪽이 백엔드 컴퓨터라 가정해 보자.
프론트 엔드 컴퓨터에서 백엔드 컴퓨터로 요청을 보내는 것을 ‘SYN’
백엔드 컴퓨터에서 프론트엔드 컴퓨터로 요청에대한 응답을 ‘SYN + ACK’
다시 프론트엔드 컴퓨터에서 백엔드 컴퓨터로 ACK를 돌려주게 된다.

연결을 종료할 때에는 ‘FIN’을 돌려주면서 4-way-handshake 형식이 된다.

HTTPS 배포 실습

SSL 인증서 발급
HTTPS는 SSL/TLS 인증서가 있어야 사용할 수 있다. AWS에서는 웹서비스 제작을 위해 필요한 기본적인 퍼블릭 인증서를 무료로 제공하고 있다.

1) 콘솔 상단의 ‘서비스' 또는 검색창에서 Certificate Manager를 찾아 접속한 뒤, 시작하기 버튼을 클릭(인증서 요청 버튼)

2) 퍼블릭 인증서 요청을 선택한 뒤, 다음으로 넘어감

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

4) 발급 요청이 완료되었지만, 아직 DNS 검증을 완료하지 않았기 때문에 검증 대기 중으로 표시됨

SSL 인증서 검증

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

1) DNS 검증을 위해 인증서 ID를 클릭

2) Route 53에서 레코드 생성 버튼을 클릭

3) 레코드 생성 버튼을 클릭

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

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

6) 터미널에서 dig (CNAME 이름) CNAME 을 입력

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

8) CNAME 확인이 완료되면, 인증서 상태가 발급됨으로 변경

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

CloudFront 배포 생성 및 인증서 적용

유저의 접속 트래픽은 가장 먼저 CloudFront에 도달하여 S3과 로드밸런서 중 어느 곳으로 데이터를 요청할 지 분류를 받게 된다. 또한, CloudFront는 전세계에 위치한 AWS 서버들을 이용하여 CDN 서비스를 제공한다.

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

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

2) 원본 도메인에 S3 엔드포인트 주소를 반드시 직접 복사하여 입력한다. Origin Shield 활성화는 아니요를 선택!

입력창 클릭 시 자동으로 검색되는 원본 도메인을 선택할 경우 S3과 제대로 연결되지 않는다

3) 뷰어 프로토콜 정책 및 허용된 HTTP 방법을 아래와 같이 선택

4) 대체 도메인 이름 영역에서 항목 추가 버튼을 클릭

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

6) 인증서를 선택한 다음 배포 생성 버튼을 클릭

7) 배포 도메인 이름 복사

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

Route 53과 CloudFront 연결

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

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

2) 기존에 생성했던 호스팅 영역을 클릭

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

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

5) CloudFront 배포에 대한 별칭을 선택하여 트래픽 라우팅 대상을 변경

6) 대상 CloudFront 배포를 지정하기 위해 배포 선택창을 클릭

7) 이전에 생성한 CloudFront 배포 도메인을 선택

8) 저장 버튼 클릭

9) 구입한 도메인을 주소창에 입력하여 HTTPS 연결 확인

SSR 배포 실습

인스턴스 배포 파일 생성
스태틱 라우팅으로 제작한 페이지는 직접 주소를 입력하여 접근할 수 있어서 S3에 업로드하여 조회할 수 있으나, 다이나믹 라우팅으로 제작한 페이지는 실제 주소가 존재하지 않아 직접 접근이 불가능하다.
그렇기 때문에 다이나믹 라우팅은 SSR 배포를 통해서 접근이 가능하도록 코드를 작성하여야 한다.

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

getServerSideProps가 존재한다면 getServerSideProps를 먼저 실행한다.
이후 Props를 통하여 데이터를 받은 다음 유저의 브라우저로 전송되게 된다.

인스턴스 배포

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

2) 인스턴스 구분이 용이하도록 이름에 구입한 도메인을 입력

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

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

4) 인스턴스 유형 블록에서 프리 티어 사용 가능한 t2.micro인지 확인하고 이후 키 페어 선택창을 클릭

5) 키 페어 없이 계속 진행을 클릭한다. 가상 쉘 접속 시에는 이 옵션이 가장 편리하다.

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

7) 인스턴스 시작 버튼을 클릭

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

9) 인스턴스 id를 클릭

10) 우측 상단의 연결 버튼을 클릭

11) 연결 버튼을 클릭

12) 아래와 같은 화면이 표시되면 정상 접속 상태

13) 이 가상 컴퓨터는 방금 OS 설치가 완료되어, 아직 아무런 세팅이나 모듈이 설치되지 않은 초기 상태로 아래의 명령어를 입력하여 먼저 nodejs 패키지부터 다운로드하도록 한다.

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

14) 아래와 같은 화면이 표시되면 패키지 다운로드가 완료된 상태로 아래의 명령어를 입력하여 nodejs를 설치

sudo yum install -y nodejs

15) yum이 nodejs를 설치하면 node --version 및 npm --version 입력 시 버전이 표시된다

16) sudo npm install -g yarn 을 입력하여 yarn을 설치해 주도록 한다.

17) yarn을 설치하면 yarn --version 입력 시 버전이 표시된다.

18) 이제 git을 설치할 차례이니 sudo yum install git 을 입력하여 설치해 주도록 한다.

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

20) git을 설치하면 git --version 입력 시 버전이 표시된다.

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

22) clone 시 깃허브 로그인을 요구한다. 내 username (ID,email 아님에 유의!)을 입력하고 엔터를 누르면 아래와 같이 password를 요구하는데, 이 때 비밀번호가 아닌 github 토큰이 필요하다.

23) github 우측 상단의 내 프로필을 클릭

24) settings를 클릭

25) 설정 메뉴 하단의 Developer settings를 클릭

26) 좌측 메뉴에서 Personal access tokens를 클릭

27) Generate new token을 클릭.

28) Note에는 관리 시 식별 가능한 별칭이나 메모를 입력

29) 토큰의 유효기간을 설정한다. 원한다면 No expiration을 선택하여 만료되지 않도록 할 수 있다.

30) 토큰 권한을 설정. 원한다면 서버에서 모두 허용할 수 있다. Generate token 버튼을 클릭.

31) 토큰이 발급되면 복사 버튼을 누른다.

토큰 코드는 해당 페이지 접속 시에만 조회할 수 있으며 다시 열람할 수 없다.
토큰은 보안상 매우 중요하다.

32) 복사한 토큰을 password에 붙여넣는다.

33) 아래와 같이 표시되면 clone에 성공한 것

34) CLI 명령어를 이용하여 원하는 디렉토리로 이동

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

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

37) 아래와 같은 화면이 표시되면 빌드에 성공한 것

38) yarn start를 입력하여 프론트엔드 서버를 가동

인스턴스 연결 허용
인스턴스에서 프론트엔드 서버 가동을 완료하였지만, 아직 외부 접근이 가능하도록 설정하지 않았다.
보안 그룹 설정을 통해 외부 연결을 허용해 보도록 하자.

1) EC2 인스턴스 목록에서 설정할 인스턴스 ID를 클릭

2) 보안 탭을 클릭

3) 보안 그룹 링크를 클릭

4) 인바운드 규칙 편집 버튼을 클릭

5) 규칙 추가 버튼을 클릭

6) 유형을 사용자 지정 TCP로 선택하고, 포트 범위에 3000을 입력

7) 소스에서 0.0.0.0/0을 선택. 선택박스가 자동으로 Anywhere로 변경

8) 규칙 저장 버튼을 클릭

9) EC2 인스턴스 목록에서 인스턴스 ID를 클릭

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

방화벽의 이해

서버는 띄웠지만, 아직 접속할 수는 없다. 방화벽이 있기 때문이다.
방화벽을 여는 작업을 해주어야 한다.

GCP 콘솔에서 VPC 네트워크 > 방화벽에 들어간다

방화벽 규칙 만들기를 클릭하고 이름을 짓는다.
이름과 똑같이 대상 태그를 만들어준다.

태그는 스티커와 비슷하다. 만들어둔 VM 인스턴스에 이 스티커(태그)를 붙여주면 방화벽 규칙이 적용된다.

소스 IP 범위를 입력한다. 아래와 같이 하면, 누구든지 접속 가능하다는 뜻이다.

포트를 지정해주면 3000번 포트에 누구든지 접속할 수 있다.

로드 밸런서 연결

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

1) EC2 메뉴 좌측 하단의 로드밸런서를 클릭
2) 로드 밸런서 생성 버튼을 클릭
3) Application Load Balancer의 Create 버튼을 클릭
4) 이름 칸에는 구분이 용이하도록 구입한 도메인-lb 를 입력
5) 로드밸런서 설정 시에는 EC2 인스턴스의 가용 영역을 확인해야 한다. 새 창으로 인스턴스 목록을 띄워 가용 영역을 확인

6) 로드밸런서 설정 창으로 돌아와서, Network mapping 블럭을 찾고 이 때 미리 확인한 인스턴스의 가용 영역을 선택

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

8) Listeners and routing 블럭에서 Create target group 링크를 클릭

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

10) 포트를 3000으로 변경

11) Next 버튼을 클릭
12) 타겟을 등록할 인스턴스를 선택

13) Include as pending below 버튼을 클릭

14) Create target group 버튼을 클릭
15) 타겟 그룹 리스트에 새로운 그룹이 추가된 것을 확인할 수 있다
16) 원래 창으로 돌아와서 새로고침 버튼을 클릭
17) 선택창을 클릭하여 생성한 타겟 그룹을 선택

18) Create load balancer 버튼을 클릭
19) 이제 로드밸런서가 생성되었다. View load balancer를 클릭하여 로드밸런서 목록을 확인
20) 생성 후 초기 세팅을 위한 시간이 필요하다. 상태가 프로비저닝 중 일 때에는 작동하지 않는다.
21) 상태가 활성으로 변경되면 로드밸런서 작동이 시작된다. 외부 접근을 허용하기 위해 보안 그룹 링크를 클릭한다.
22) 보안 그룹 목록에서 로드밸런서에 연결되어 있는 보안 그룹 ID를 찾아 클릭

23) 인바운드 규칙 편집 버튼을 클릭
24) 규칙 추가 버튼을 클릭
25) 유형을 HTTP로 설정
26) 소스를 0.0.0.0/0 으로 설정

27) 규칙 저장 버튼을 클릭
28) 보안 그룹 설정이 완료되면, 로드밸런서의 DNS 주소를 복사하여 접속할 수 있다.

CloudFront 라우팅 연결

CloudFront와 로드밸런서를 연결하여, SSG + SSR 하이브리드 배포를 완성!

1) 기존에 S3과 연결했던 CloudFront에 로드밸런서 연결을 추가해야 한다.
CloudFront ID를 클릭

2) ‘원본'탭에서 원본 생성 버튼을 클릭

3) 원본 도메인 선택창을 클릭
4) 원본 도메인에 로드밸런서를 선택하여 지정

5) 프로토콜 > HTTP만 해당을 선택
6) 원본 생성 버튼을 클릭하면, 로드밸런서와 기본 연결이 완료!

7) 이제 특정 도메인 접근 시 로드밸런서로 라우팅되도록 설정. ‘동작'탭에서 동작 생성 버튼을 클릭

8) 경로 패턴에 /boards/* 를 입력하고, 원본 및 원본 그룹은 로드밸런서를 선택

9) 뷰어 프로토콜 정책과 허용된 HTTP 방법을 아래와 같이 선택

10) 동작 생성 버튼을 클릭
11) 동작 목록에서 S3과 로드밸런서로 모두 동작이 연결되는 지 확인

SSG + SSR 하이브리드 배포가 완료되었다.
S3에 업로드된 빌드 파일을 CloudFront를 이용하여 캐싱하여 빠른 속도로 최초 화면을 표시한 다음, 나머지 페이지와 데이터들은 SSR 방식으로 전달하기 때문에 사용자는 빠르고 역동적인 경험이 가능!

또한, 잦은 변경이 필요하지 않은 파일(기본 레이아웃 및 디자인 등)들을 S3로 분리하여 EC2 인스턴스에 대한 부하를 줄일 수 있으며, 이를 통해 안정적인 서비스 제공 및 비용 절감 효과를 도모할 수 있다.

Docker

도커 설치
https://www.docker.com/ 도커 홈페이지에 접속한 뒤, Get Started!

Docker를 사용해서 배포하는 이유
서버를 돌리기 위해서는 먼저 환경이 갖춰져야 한다.
새로 컴퓨터를 샀다거나 또는 새로 직원이 들어왔다고 생각해보면 컴퓨터에 개발한 환경과 똑같이 만들어야 한다.

이를 위해 Node.js와 같은 언어 그리고 언어의 버전, 데이터베이스, 수 많은 node_modules를 버전을 맞춰서 설치해줘야 한다. 한두가지가 아니다.

그래서 예전 회사에서는 환경을 구축하는 과정을 하나씩 캡쳐하고, 기록해서 방법을 정리해두기도 한다. 가이드 문서가 있다고 한들 매번 이렇게 구축하는 것은 매우 번거로운 일이다. 이를 간편하게 해주는 것이 바로 도커이다.

Docker 란?
도커는 개발 환경 요소들이 설치된 모습을 이미지로 저장한다. 저장한 이미지를 클라우드에 올린다. 이미지들이 서로 연결되서 동작하는 설정을 문서(Dockerfile)로 저장한다. 새 컴퓨터에 가서 복사한 문서의 내용대로 이미지를 다운받아 설치한다.

가상 머신과 비슷하다고 볼 수 있다. 하지만 가상머신보다 훨씬 빠르고, 자원을 효율적으로 사용한다. 왼쪽이 가상머신, 오른쪽이 도커. 도커에는 불필요한 추가적인 운영체제 설치가 필요 없다.

도커 허브에서는 npm 다운 받는 것처럼 다른 사람들이 올려놓은 이미지를 다운로드 할 수도 있다. 또한, 한 컴퓨터에서 다른 환경의 여러 서비스를 실행해야 하는 경우, 컨테이너로 분리되어 있기 때문에 서로 독립되어 실행 될 수 있다.

이것들을 모두 간단한 명령어로 실행 할 수 있다.

Docker-compose의 이해
여러가지 컨테이너를 다룰 때 좀더 복잡한 설정이 필요하게 된다. 이럴 때 Docker-compose를 사용한다. docker-compose.yml 파일을 미리 만들어서 설정을 어떻게 할지 적어둔다. 그리고 docker-compose up 명령어를 입력해서 컨테이너를 실행한다.

docker-compose.yml 파일 예시 ( yml 파일은 들여쓰기를 꼭 지켜야 함)

version: "3.3"

services:
  class_build:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - 3000:3000

Dockerfile
컨테이너를 실행하기 전에 먼저 해줘야할 것은 이미지를 만드는 것이다. Dockerfile 이라는 이름의 파일을 만들고 이미지를 만들기 위한 명령어를 입력한다. 그리고 docker-compose build 명령어를 통해 이미지를 만들게 된다.

FROM node:16

WORKDIR /class_build/
COPY . /class_build/

RUN yarn install
RUN yarn build
CMD yarn start

도커파일 예시
https://nodejs.org/ko/docs/guides/nodejs-docker-webapp/

환경 변수 설정
Dockerfile 안에서 환경 변수를 설정하고 싶은 때는 ENV 명령어로 설정

ENV [key] [value]
ENV [key]=[value]