배포 Deployment

e_juhee·2022년 5월 2일
0

Deployment

목록 보기
1/9

배포 Deployment

  • 만든 서비스를 세상에 공개하는 작업을 의미한다.
  • 배포 환경 = production 환경 = prod 환경 = 운영 환경

1. 예전의 배포 방식

  • 배포를 하려면 DB, 프론트엔드, 백엔드가 배포되어야 한다.

프론트엔드에서 yarn dev로 실행하면 브라우저에서 localhost 주소로 접속해서 html, css, js를 다운받아서 브라우저에서 볼 수 있다. 👈🏻 지금까지 써온 방식

이렇게 하면 localhost에서 접속해야만 들어올 수 있다.(다른 사람은 접속 불가!)

예전의 배포 방식

다른 사람도 접속할 수 있게 하기 위해서 새 컴퓨터를 하나 구매하고, (내 컴퓨터로도 가능하지만, 하루종일 켜놔야 되니까 비용 절감을 위해서~) 구매한 컴퓨터에 `git clone > yarn dev`를 해놓으면 여러 사람이 접속해서 html, css, js를 다운받아갈 수 있게 된다.

위 방식의 문제점

사람들이 접속을 하면 요청에 대한 응답을 하고 접속자 체크 등을 위해 메모리가 사용되는데
사용량이 많아지면 평범한 사양의 컴퓨터라면 메모리가 부족해진다.
(참고: 빨리 처리하려면 CPU가 많아야 하고, 저장을 많이 하려면 메모리가 많아야 한다.)

메모리 부족을 해결하기 위해서 컴퓨터를 새로 더 구매해서 같은 방식으로 git clone > yarn dev하면,
한쪽으로 몰리던 트래픽을 분산할 수는 있다.
하지만 이런 대응 방식으로는 사용자가 '갑작스럽게' 증가했을 때 바로 대응하기 어려울 것이다.

해결 방법

그래서!
컴퓨터를 굉-장히 많이 가지고 있는 회사가 등장했다!
(Cloud Provider : Amazone Web Service, Google Cloud Platform, Microsoft Azure)

이 회사들은 사용 요금을 받고 컴퓨터를 빌려준다.
이젠 실물 컴퓨터를 구매하는 것이 아니라,
빌릴 컴퓨터의 메모리를 설정하고, 운영체제를 선택(윈도우, 리눅스 등)하면 빌린 컴퓨터에 접속할 수 있게 터미널을 열어준다.
빌린 컴퓨터에 24시간동안 서버를 실행시켜 놓아 사람들이 접속할 수 있게 대기시킨다.

2. Cloud Provider

  • AWS가 사용량이 가장 많고 다음이 GCP이다.

어떻게 선택하지?

  • 보통 처음에 GCP를 사용하다가 서비스가 커지면 AWS로 옮겨간다.

  • 기능은 거의 동일하나, GCP가 가격이 더 저렴하기 때문이다.(AWS와 비교했을 때 70%정도의 요금이다.)

  • 서비스가 커지면 AWS로 옮겨가는 이유는,
    AWS가 아무래도 1등 업체이다 보니까, 커뮤니티도 크고 컨퍼런스도 많이 열리는 등의 이점이 있다.
    큰 서비스를 위해서는 1등 업체가 더 유리하기 때문에 서비스가 커지면 AWS로 옮겨가는 것이다.

  • Multi Cloud: 최근에는 두개를 같이 쓰는 회사도 많아지고 있다.


3. Google Cloud Service 둘러보기

[GCP]

(1) VM 인스턴스

여기서 켜져있는(체크되어 있는) 컴퓨터에 대해서 요금을 지불하게 된다.
가격: (GCP 기준) 한달에 메모리 1GB 당 10,000원 정도 발생한다.
켜둔 시간만큼 비용이 발생한다.
테스트용을 만들 때는 2GB정도면 충분하다!

(2) SSH: Secure Shell

위의 VM 인스턴스 화면에서 우측의 SSH를 누르면 나온다.
SSH를 통해 빌린 컴퓨터에 접속한다.

터미널을 Shell이라고 한다. SSH는 보안이 들어간 Shell이란 의미이다.

✨ 터미널을 끈다고 이 컴퓨터가 꺼지는 것은 아니다. 컴퓨터를 끄려면 중지를 시켜야 한다


(3) 인스턴스 만들기 : 컴퓨터 빌리기

  • 리전
    빌릴 컴퓨터의 위치 --> 서울을 선택하자!
    👉🏻 why ? 실제 서비스를 할 때 물리적인 컴퓨터가 얼마나 가까운지에 따라서 네트워크 속도에 영향을 미치기 때문에 가까운 서울을 선택한다.

Ping

[GCPing]
물리적인 컴퓨터로 요청을 보내서 얼마나 걸리는지 측정할 수 있다.

  • 부팅 디스크
    사용할 운영체제 선택

(4) 방화벽

  • 컴퓨터에 접속할 수 있게 네트워크를 열어줄 때 컴퓨터에는 port별로 일반적으로 방화벽이라는 것이 있다.

  • 기본적으로 port가 다 막혀있고, 접속을 허용하려면 해당 port의 방화벽을 해제해줘야 한다.
    (이 메뉴에서 해제할 수 있다.)

  • 부분 허용: 특정 아이피를 막거나, 한국에서만 접속 가능하게 등 부분적으로 설정도 가능하다.

  • Frontend-Server에 아무나 접근하면 안됨! 지정한 특정 접근으로만 방화벽이 열리게 설정해줘야 한다.


(5) Cloud DNS (Domain Name System)

  • 서버를 실행시킨 빌린 컴퓨터 앞에 DNS가 있다.
  • 보통 도메인을 구매해서 도메인으로 접속을 하면 34.64.118.51:3000와 같은 주소로 접속하게 된다.
  • DNS가 도메인을 입력했을 때 해당 IP로 접속할 수 있도록 연결해준다.

도메인 구매 방식은 회사마다 비슷하지만, 네이버 로그인이 있어서 편리하므로 가비아를 사용할 것이다.
[가비아]


(6) SSG : Static Site Generation

Next는 서버에서 미리 HTML 화면을 그린 다음에 브라우저에 보여주는데, 여기에는 2가지 방식이 있다.

1. SSG
빌드할 때 페이지별로 HTML을 생성하고 요청을 받을 때마다 미리 만들어둔 것으로 응답하는 방식

2. SSR: Server-side Rendering
매번 요청을 받을 때마다 서버에서 HTML을 그려서 주는 방식

SSG

Static File을 서빙한다.

배포를 하면, 빌린 컴퓨터가 꺼지지 않도록 메모리/CPU 상황 등을 잘 관리해줘야 한다.

트래픽이 늘어나게 되면

  • html, css, js 파일(정적 파일 = static file)로 추출해내서 이 정적 파일들을 Storage(대용량 파일 저장소)에 올려 놓는다.
  • Storage는 구글에서 관리해주기 때문에 무한으로 트래픽을 받을 수 있게 된다.
  • 브라우저에서 Storage에 접근해서 static file을 다운로드 받게 되고, 이를 Static-File Serving이라고 부른다.
    (Storage말고도 Nginx, Apache 등에서 이런 역할을 해주기도 한다.)

그런데, Static-File Serving이 안되는 파일이 있다.
WHY? SSR 때문!!

  • 서버 사이드 렌더링을 하려면 브라우저에서 요청을 하면, 프론트에서 백엔드에 요청을 하고 DB를 다녀와서 html,css,js새로 만들어서 제공해줘야 하기 때문에 Storage에 정적 파일 형태로 미리 적재해둘 수 없다.
  • 접속 요청을 받았을 때 데이터를 받아서 그때 즉시 만들어내주기 때문이다.
  • SSR을 위해서는 yarn dev가 반드시 필요해지게 된 것이다.

하지만, 모든 페이지가 SSR은 아니다.

  • 가급적이면 Storage에 올리는 것이 유리하므로
    요청을 분산해주는 역할을 하는 Load Balancer를 둔다.
  • DNS가 도메인을 IP주소로 바꿔서 LB에 전달하는데,
    LB가 주소를 보고 정적페이지라면 Storage로, SSR 페이지라면 Frontend-server로 보내준다.
  • 이렇게 정적페이지는 무한 트래픽이 가능한 Storage로 관리가 되고, SSR 페이지는 무한 트래픽이 불가능하므로 우리는 SSR 페이지에 대해서만 메모리, CPU 등을 관리해주면 된다.
profile
쥐로그

0개의 댓글