35일차 / SSG / LB, DNS

SSG / LB

스토리지에 정적파일을 배포해보자

도메인으로 접속을 하면 DNS가 특정 IP주소로 바꿔준다.
그리고 DNS가 로드밸런서로 ip주소를 전달한다.
로드밸런서는 SSG와 서버사이드 렌더링(SSR)을 분기시킨다.

루트 페이지라 함은 시작페이지, 관리페이지

yarn start는 배포를 의미
따라서 refresh가 되지 않는다.

yarn start를 하기 위해서는 최적화과정을 거쳐야한다. => build
build를 해야만 start를 할 수 있다.

build를 바탕으로 html,css,js가 만들어진다.
서버사이드 렌더링, 정적 사이트가 분기된다.

next export에 SSR을 하는 함수가 들어가 있다면 정적파일을 만들수 없다는 에러가 난다.

next는 최적화 된 파일, out폴더는 html,css,js이 만들어져있다.

trailingSlash는 우리가 설정한 경로대로 폴더를 만들어준다.

구글 스토리지에 버킷을 만들고 out파일을 업로드 후 공개로 설정하기

드로그 앤 드롭으로 1개만 올라갈 경우에는 명령어 실행
-r: 파일을 돌면서 업로드

정적페이지와 오류페이지 구성

로드밸런서가 정적페이지는 스토리지로, SSR페이지는 yarn start 된 프론트엔드 서버로 보낸다. (부하 분산)
프론트엔드 서버도 인스턴스 그룹을 만들고 컴퓨터를 부하를 분산시킬 수 있음
어느정도의 부하가 생기면 자동으로 트래픽을 분산하는 것을 AutoScaling이라고 한다.

일반적으로 TCP를 많이 사용하며 안정성과 속도가 좋다.

VM가상 컴퓨터: 로드밸런서를 만드는데 인터넷 브라우저에서 뒷쪽에 있는 프론트엔드 컴퓨터(VM)으로 분산
서버리스 서비스: 하나의 컴퓨터에 api가 20개 있다하면 컴퓨터를 24시간 실행시켜야하는데, 20개의 api를 함수로 실행시킴

VM 사이에서만 분산: 백엔드가 있고 데이터베이스 컴퓨터가 여러대 있는데, VM 사이에서 로드밸런서로 분산

백엔드 버킷(스토리지)를 만드는 중

프론트엔드 개발자에게 배포가 더 중요해짐 => 서버사이드 렌더링 때문 (프론트엔드 영역이므로)

TTL: 임시저장한 데이터가 얼만큼 살아있게 할래? => 어디에 임시저장을?

전세계에 여러대의 컴퓨터를 놓고 html,css,js를 임시저장을 해놓는다(캐싱)
현재 있는 곳과 가장 가까운 컴퓨터에서 다운받아오는 것
이 캐싱을 얼마동안 저장해둘 것인가 => TTL
이 과정을 CDN이라고 함.
전같으면 CDN 회사를 많이 이용했지만 요즘에는 클라우드 서비스를 많이 이용하게 됨

AWS에서는 cloud front라는 이름으로 존재

https의 기본 포트번호는 443
http의 기본 포트번호는 80

DNS

구입한 주소를 입력하면 접속되게 연결

도메인을 바꿀 수 있는 권한이 가비아 or 고대디에 있음
권한을 구글 클라우드로 옮겨줄것이다.

가비아의 네임서버를 구글 플랫폼의 NS로 변경해준다.
터미널에서 dig abago.shop NS 해서 잘 적용이 되었는지 확인

A 레코드 추가해서 도메인을 적용
dig abago.shop A 적용이 되었는지 확인
=> 해당 도메인으로 접속