CSR(Client Side Rendering)이란?

어떤 유저가 리액트로 제작된 어떤 웹사이트에 접속한다고 가정해보자.
유저는 바로 Client가 되는 것이고 웹 서버에 접속하려는 사이트를 요청한다.

서버에서는 요청을 받고 빈 HTML 파일을 우선 전송한다.
클라이언트의 화면에는 빈 HTML을 그리기 때문에 빈 화면이 나타나고, 뒤늦게 React 소스 코드와 개발자가 웹 페이지를 구현하기 위해 작성한 JS파일을 다운로드 받아 읽어내고, 그리고 마침내 화면에 그려낸다.

요약하자면 클라이언트의 요청에 따라 HTML, React 라이브러리 자체, 개발자가 구현한 소스 코드 등의 파일을 모두 다운로드 한 후 DOM을 구성하고 그려내 화면에 나타내는 것.
바로 이것이 Client Side Rendering이라고 할 수 있다.

CSR의 장점

1. Client Side Rendering의 장점으로는 한번 로딩 되면, 빠른 UX를 제공한다.
2. Client에 화면을 구성하는 대부분의 요소가 존재하기 때문에 서버의 부하가 그만큼 적다.

CSR의 단점

1. 서버로부터 화면 구현에 필요한 요소를 받아와야 하기 때문에 페이지 로딩 시간 (Time To View)이 길다.
2. 자바스크립트 활성화가 필수이다.
   사용자가 브라우저 설정을 통해 자바스크립트 활성화를 꺼버린다면 어떠한 페이지도 볼 수 없다.
3. SEO 최적화가 힘들다.
   검색 엔진 로봇들이 웹사이트를 돌아다니며 메타 데이터 / Sementic Tag 등을 분석해 검색어와 연관 있는 요소들을 찾아 검색 엔진에 등록하는데, CSR의 경우 웹 페이지가 Client측에서 그려지고 나서야 이런 작업들이 가능하다.
4. 보안에 취약하다.
   페이지를 표기하기 위해서 어떤 서버에서 어떤 데이터를 받아오는지 이런 불안 요소들이 외부에 노출 될 수 있다.
5. CDN에 캐시가 안된다.
   Content Delivery Network의 약어로 각 국가나 지역에 있는 네트워크를 뜻한다.
   예를 들어 한국에서 미국으로 웹서버 요청을 전송 했을때, 도쿄 혹은 싱가포르 등 근처의 네트워크에 데이터를 캐싱할 수 있다.
   따라서 동일한 미국 서버에 여러번 접근 하더라도 근처에 이미 캐싱 된 데이터가 있기 때문에 응답이 빨라지는데,
   CSR에서는 HTML이 텅텅 비어있기 때문에 CDN에 캐싱하기 어렵다.

SSG (Static Site Generation)이란?

CSR이 처음에는 좋아보였지만, 앞선 포스팅에서 꽤나 비중 높은 단점들이 존재했고 이런 애로사항을 해소하고자 배포할때는 정적인 사이트로 전환해서 배포하는게 어떨까? 해서 나온게 SSG이다.

SSG의 특징

위에서 설명했듯이 렌더링 하는 주체자가 서버이다.
이후에 나타날 SSR과 동일하게 서버에서 렌더링을 하지만, 차이가 있다면 렌더링이 되는 시점이다.
SSG는 어플리케이션을 빌드할 때 렌더링한다.
빌드를 하는 과정에서 HTML에 React/JS 코드를 적용하고 필요하다면 클라우드나 DB에 있는 데이터를 fetch하여 정적인 웹페이지들을 미리 제작해둔다.

SSG의 장점

1. 페이지 로딩 시간이 빠르다.
2. 자바스크립트가 필요 없다.
3. SEO 최적화가 좋다.
4. 보안이 뛰어나다.
5. CDN 캐시가 된다.

SSG의 단점

1. build 시점에 렌더링이 되기 때문에 데이터가 정적이다.
   => 데이터가 가변적으로 변경되는 웹사이트의 경우 적절하지 않다. (예를 들면 실시간 날씨 정보 등등)
2. 사용자별 정보 제공이 어렵다.
   => 사용자가 1,000명 10,000명이라면 그만큼의 정적 파일들을 미리 렌더링해야 한다.
   => 이런 경우 서버 부하가 심하다.

ISR (Incremental Static Regeneration)이란?

SR도 SSG와 마찬가지로 빌드 단계에서 정적인 html을 전부 만들어 놓는 것은 동일하지만 주기적으로 변경사항에 대응할 수 있도록 한 방식이다.

ISR의 특징

SSG의 특징을 전부 가지고 있으며 주기적으로 빌드를 하기 때문에 데이터 업데이트가 가능하다.

SSG의 장점

1. 페이지 로딩 시간이 빠르다.
2. 자바스크립트가 필요 없다.
3. SEO 최적화가 좋다.
4. 보안이 뛰어나다.
5. CDN 캐시가 된다.
6. 데이터가 주기적으로 업데이트 됨

SSG의 단점

1. 데이터가 주기적으로 업데이트 되지만 이 또한 실시간 데이터가 아니다.
2. 사용자별 정보 제공이 여전히 어렵다.

SSR (Server Side Rendering)이란?

SSR은 렌더링을 하는 주체가 서버이며, 클라이언트가 요청을 할 때마다 렌더링을 진행하는 특징이 있다.

SSR의 장점

1. 페이지 로딩 시간이 빠르다.
2. 자바스크립트가 필요 없다.
3. SEO 최적화가 좋다.
4. 보안이 뛰어나다.
5. CDN 캐시가 된다.
6. 실시가 데이터를 사용한다.

SSR의 단점

1. SSG, ISR과 비교했을 때 상대적으로 느릴 수 있다.
2. 클라이언트의 요청마다 서버에서 렌더링을 진행하기 때문에 부하가 굉장히 커질 수 있다.

마무리

CSR, SSG, ISR, SSR에 대해 간략하게 알아보았다.
각각의 장단점이 뚜렷하기 때문에 Next.js에서는 위 네 가지 방식을 적재적소 사용할 수 있도록 지원한다.

어플리케이션을 어떻게 구성하고 각 기능마다 어떤 렌더링 기법을 사용할 것인지 많은 고민이 있어야 사용자 경험이 좋은 페이지를 제작할 수 있을 것 같다.

ECS Cluster 생성

Cluster란?
ECS 클러스터는 Docker Container를 실행할 수 있는 논리적인 공간이다.
ECR에 등록한 Docker Image를 가지고 컨테이너를 구성하려면 이 클러스터를 생성 및 사용해야 한다.

클러스터 이름을 sample-cluster로 짓고, 나머지 설정은 그대로 둔 후 생성한다.

인프라 탭에서 주로 Fargate와 EC2 인스턴스 둘을 사용한다.
간략하게 두 인프라의 차이점을 살펴보면 아래와 같다.

EC2인스턴스
EC2는 AWS에 대표적인 서비스 중 하나이다. 주로 서버로 사용하며, 비용을 지불하고 가상의 서버를 대여 받을 수 있다.

ECS 서비스를 구축할 때 EC2 인스턴스를 인프라로 선택하면 서비스에 속한 EC2 인스턴스 서버와 클러스터를 직접 관리해주어야 한다.

Fargate
EC2 인스턴스와 다르게 서버 인스턴스를 관리할 필요가 없는 컨테이너 서비스이며 사용량에 따라 요금이 부과되는 종량제 형식으로 제공된다.
(서버리스란 서버가 없다는 것이 아니다. 서버가 필요한 순간이 왔을 때 잠시 서버를 깨워 기능을 수행하고 다시 잠든다. 이렇게 종량제 서비스가 되는 것이다.)

EC2 인스턴스와 Fargate는 상황에 맞게 잘 고려해서 선택하면 될 것 같다.

Task 정의 생성

다시 본론으로 돌아와서 클러스터를 생성했다면, 이제 Task 정의를 생성한다.

클러스터를 생성할 때 인프라를 Fargate로 생성했으니 시작 유형을 AWS Fargate로 설정한다.
태스크 크기는 CPU : 0.25vCPU, 메모리 : 0.5GB 으로 설정한다. (캡처와 다르니 참고)

컨테이너 이름은 sample로 지었다.
이미지 URI는 지난번 ECR에 등록된 이미지 URI를 복사해서 사용한다.
여기서 주의할 점이 있는데, 레포지토리 URI가 아닌 이미지 URI를 복사해야한다.
(그래야 sample:${version}까지 복사된다.)

다음, 포트 매핑에서는 컨테이너 포트를 7000으로 설정한다.
Docker File에서 Port를 7000으로 설정했기 때문에 여기서도 맞춰준다.

이후에는 기본 값으로 두고 작업을 생성한다.

서비스 생성

앞서 클러스터와 Task를 정의 한 것은 바로 서비스를 생성하기 위함이다.
이제 대망의 서비스를 올려보자!

생성한 ECS 클러스터를 클릭하면 서비스 생성이 가능하다.

컴퓨팅 옵션 : 시작 유형
시작 유형 : Fargate
플랫폼 버전 : LATEST

태스크 : 2 (Fargate 인스턴스가 2개 생성된다.)

네트워킹은 별도로 건들지 않았다.
로드밸런서 및 대상 그룹은 서비스를 생성하며 함께 생성해준다.

서비스가 정상적으로 생성되고 활성화가 되었다.

이제서야 비로소 개인 프로젝트가 모든 서버 인스턴스에 Docker를 통한 동일한 서비스 환경을 구축한 것이다.

아래 로드밸런서 DNS 이름의 주소를 가지고 웹에서 나의 프로젝트를 확인할 수 있다.

결과 화면

마무리하며

포스팅을 하면서 서버와 네트워크에 대해 점점 친숙해지는 기분이다.
사실 여기까지의 과정에서 우여곡절이 많았지만 시간이 걸려도 해내면 그만이다.

다음 포스팅에서는 Git을 통한 ECS 서비스 자동 생성을 구현해볼 예정이다.

글을 읽으시는 모든 분들께 알량한 나의 지식이 도움이 되었으면 한다.

Next.js 프로젝트 생성

설치 및 실행

vscode를 열고 원하는 폴더에 접근한 후 다음 명령어를 실행한다.

$npx create-next-app

globals.css 파일에서 tailwind CSS 관련된 설정만 남겨두고 나머지는 전부 삭제한다.
page.tsx에서도 “Hello Next.js!” 라는 문구만 작성한다.

$npm run dev

위 명령어를 실행해서 정상적으로 웹 페이지가 열리는지 확인한다.

Github workflow 작성

생성한 Next.js 프로젝트 최상단에 다음과 같은 폴더 및 파일을 추가한다.

1. .github
2. .github/workflows
3. .github/workflows/workflow.yml

이후 workflow.yml 파일에 다음과 같은 내용을 추가한다.

name: Staging # 워크플로 Action의 이름
on:
  push:
    branches: [main] #github main 브런치에 푸시 발생 시 실행 ( main 외 다른브런치 이용시 이름변경)
jobs:
  staging: #staging이라는 작업
    name: deploy to staging # 작업의 이름
    runs-on: ubuntu-latest # 실행될 작업환경을 말함.
    steps:
      - name: Checkout
        uses: actions/checkout@v3 #체크아웃 받기
      - name: HelloWorld
        uses: actions/hello-world-javascript-action@v1 # 헬로월드 찍어보기

git에 push하여 Action이 잘 동작하는지 확인한다.

커밋 메세지가 이상하지만 Action은 정상적으로 동작한다!

다음 포스팅에서는 AWS 연동을 진행할 예정이다.
AWS에서 제공하는 다양한 서비스에 대해 가능하면 최대한 짚어볼 예정이다.

Next.js 샘플 프로젝트를 Git Workflow / Action을 통해 AWS ECS로 자동 배포하는 시스템을 구축해보려 한다.

자동 배포 sequence

아래와 같은 순서를 거쳐 최종적으로 AWS ECS에 프로젝트가 자동 배포되는 과정을 경험해보고자 한다.

1. Next.js 프로젝트 생성 및 배포
2. Git workflow 작성
3. AWS ECS 서비스에 연동

선행되어야 할 학습 내용

• Next.js 설치 및 프로젝트 생성
• Git / Github - workflow 설정과 Git Action
• AWS
  • Route53 - 도메인 호스팅
  • EC2 - 클라우드 인스턴스
  • Load Balancer - 인스턴스에 접근할 트래픽 분산 처리
  • ECR - Docker Image의 저장소
  • ECS - ECR에 저장된 Docker Image를 기반으로 인스턴스를 생성하는 서비스
• Docker - 배포한 시스템이 모든 환경에서 동일할 수 있도록 컨테이너라는 청사진 역할을 하는 시스템 구축 환경 제공