프론트엔드 배포와 렌더링 SSG,SSR

한군데에 접속량이 많아지면(트래픽 증가하면) 서버 부하→이용 불가능

→프론트 서버 컴퓨터 여러대를 두고 load balancing(=부하 분산)

로드밸런싱 알고리즘

1. round robin : 서버 컴퓨터 번갈아가며 접속
2. least connection : 서버 중 연결이 적은 곳에 서버 부하 집중

각각의 인스턴스마다 방화벽을 설치→직접적으로 접속 막음 yarn dev도 각각
cpu,memory 등 항상 모니터링 필요

렌더링 방식별 배포방법

1. SSR(server side rendering)
   서버에서 렌더 가능한 상태로 클라이언트에 전달됨

• 배포 : 로드밸런싱을 위해 인스턴스 그룹(ig)을 만들고 로드밸런서를 생성해서 배포

• 접속 시 localhost가 아닌 load balance ip주소로 접속→ip 주소를 기억하기 어려우므로 도메인을 만들어서 접속(DNS)
  ex) http://10.123.456.789:3000

• 동적 파일 배포 가능(ex: dynamic routing으로 만들어지는 파일)
• 서버 컴퓨터는 24시간 동작해야 함

2. SSG(Static Site Generation) 배포 : html,css,js 파일을 미리 만들어놓고 그 파일들을 스토리지에 업로드 (구글 클라우드 스토리지,아마존 S3)

• cloudfront-클라우드 스토리지 연결
• DNS → CloudFront → Cloud-storage → html,css,js (정적 파일) 다운로드해서 돌려줌
• 서버 트래픽 관리는 cloud provider에서 처리→무한 트래픽 가능
• 동적 파일은 배포 불가능

<CSR(client side rendering)>
리액트,뷰 같은 프레임워크에서의 렌더링 방식
서버가 요청을 받으면 클라이언트에 html,css,js를 보내주고 클라이언트가 이를 다운로드 받아 렌더링한다.

CSR,SSR 렌더링 방식은 각각 장단점이 있어서 어느 쪽이 더 좋다고 하기 어렵다.
다만 SSR은 metadata를 동적으로 받아올 수 있어 검색엔진최적화(SEO)에 대응이 잘되어있다.