배포

사용자가 접속할 수 있도록 서버에 배포한다.

우리는 기존의 localhost 를 통해 만들었다. localhost 는 자신의 컴퓨터상에서만 사용가능한 주소이다.

즉, 다른 사람들은 localhost 에 접속하지 못한다.

우리는 다른사람이 사용가능할 수 있도록 server 를 통해 만든 결과물을 배포해야 한다.

Frontend Server

프론트엔드 전용 서버이다. Frontend server 역시 일반적이 서버이므로, 서버로써의 역할이 가능하지만 프론트엔드만을 위한 처리를 나누어주어야 할 필요가 있다.

이러한 Frontend server 는 html, css, js 를 보내주는 역할을 전담한다. nextjs 를 사용하므로, Frontend server 에서는 yarn dev 를 통해 만들어진다.

Backend Server

DB 관리및 Data 를 보내주는 역할을 한다. Frontend 에서 Backend 에 요청을 DB 상의 정보 및 가공을 위해 존재한다.

클라우드 서비스

서버를 임대해주는 서비스

서버를 직접 구성하는것은 비용이 많이든다. 이러한 부분을 도와주기 위해 만들어진것이 Cloude service 이다.

대표적으로 AWS, GCP, Azure 가 존재한다. 이러한 클라우드 서비스 제공자를 Cloude Provider 라 한다.

대략 배포를 위한 여러가지 개념에 대해서 알아보았다.

우리는 next.js를 사용하고 있다

배포를 위해서는 static page 와 dynamic page 에 대해서 알아보아야 한다.

정적페이지와 동적페이지 배포과정

홈페이지를 배포하기 위해서는 다음과 같은 과정이 있어야 한다.

1단계

위의 이미지를 보면 기존의 Frontend 서버와 cloude storage 를 통해 정적 파일을 가져오도록 이루어져 있다.

하지만 이러한 부분은 비효율적인 부분이 있다. Cloude Service 는 비용 이 발생하여 Traffic 에 대해 생각하며 만들어야 한다.

이러한 트래픽을 감소시키기 위해 처리할 수 있는 방법은 Frontend server 를 cloude storage 에서 실행하여 정적페이지 를 제공하도록 만드는 방법이다.

이러한 부분은 약간의 문제가 존재한다. 매번 cloudestorage 의 주소를 포함해서 요청해야 하는것이다.

cloude storage 는 일정금액만 제공하면, 트래픽 걱정없이 cloude provider 에서 알아서 관리해주므로 편리하게 사용가능하다.

하지만 이러한 방식은 추가적인 주소를 입력해야 하므로 불편하다. 이러한 불편한점을 해결하기 위해 DNS 를 통해 다음처럼 처리할 수 있다.

위의 이미지를 보면 DNS 는 주소를 받으면 cloude storage 로 주소를 변경한다. 이러한 방식은 단순한 구조로 여러 문제점이 발생할수 있다.

next.js 는 dynamic page 를 제공하므로, daymic page 를 제공할 방법이 존재하지 않는다.

이러한 문제점을 없애기 위해 다음의 2단계 과정을 통해 처리한다.

2단계

위의 장점은 트래픽 을 관리해주는 장점이 있지만, dynamic page 제공을 하지 못한다.

이러한 부분을 처리하기 위해서는 어쩔수 없이 기존의 방식대로 cloude server 를 통해 처리해야 한다.

3단계 (Load balencing: 부하분산)

하나의 서버를 사용하기에는 부하가 일어날 수 있으므로 이러한 경우 scale out 을 진행한다.

이렇게 진행한 scale out은 좋은 방법이지만, 인입되는 user 를 적절하게 나누어 server 를 이용할 수 있도록 해야 한다.

이러한 방법을 load balencing 을 사용한다.

load balencing 은 몇가지의 알고리즘이 존재하는대 대표적으로 round robin 과 least-connection 이 존재한다.

라운드 로빈방식은 매번 IG 를 하나씩 돌면서 1명 1명씩 넣는 방식의 알고리즘이다. 이러한 방식으로 각 VM 에 균등하게 User 를 넣어준다.

least-connect 은 매번 IG 내의 VM 중 가장 적은 user 를 가진 VM 에 해당 User 를 넣어준다

이러한 loadbalencing 을 통해 한 server 에 user 가 집중되는 부분을 효율적으로 분산시킬수 있게 되었다.

그런데, 여기서 한가지 더 생각해보아야 할 것이 있다. 우리가 cloude storage 를 사용하지 않고 server 를 사용하여 처리를 하는것은 순전히 dynamic routing 을 cloude storage 에서 처리하지 못함으로써 이루어지는 것이다.

그렇다면, 기존의 정적 페이지 같은 경우는 colude storage 에서 처리하고, 동적 페이지 는 server 상에서 처리하도록 만들면 훨씬 효율적이지 않을까?

4단계( static page 와 dynamic page 의 분기처리)

이러한 부분을 개선하기 위해 static page 일 경우 cloude storage 로, dynamic page 같은 경우는 server 상에서 처리할 수 있도록 분기처리가 이루어져야 한다.

이러한 분기처리를 위해서는 CDN(Contents Delivery Network) 을 사용하여 가능하다. 마치 if else문을 사용하듯 board/? 라면 static page 를 그렇지 않으면 board/*? 로 처리한다.

이러한 방식을 사용하면 매우 효율적으로 관리가 가능하게 된다. cloude storage 를 사용하여, 정적 페이지는 traffic 에 대한 고민없이 사용할 수 있다. 반면 동적 페이지는 server 에서 사용하여 3단계보다는 효율적인 관리가 가능하다.