배포 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
2. Cloud Provider
- AWS(Amazone Web Service)
- GCP(Google Cloud Platform)
- Azure(Microsoft Azure)
AWS가 사용량이 가장 많고 다음이 GCP이다.
이 회사들은 사용 요금을 받고 컴퓨터를 빌려준다.
이젠 실물 컴퓨터를 구매하는 것이 아니라,
빌릴 컴퓨터의 메모리를 설정하고, 운영체제를 선택(윈도우, 리눅스 등)하면 빌린 컴퓨터에 접속할 수 있게 터미널을 열어준다.
빌린 컴퓨터에 24시간동안 서버를 실행시켜 놓아 사람들이 접속할 수 있게 대기시킨다.
어떻게 선택하지?
-
보통 처음에 GCP를 사용하다가 서비스가 커지면 AWS로 옮겨간다.
-
기능은 거의 동일하나, GCP가 가격이 더 저렴하기 때문이다.
(AWS와 비교했을 때 70%정도의 요금이다.) -
서비스가 커지면 AWS로 옮겨가는 이유는,
AWS가 더 오래되었기 때문에 AWS 전문가가 더 많아 채용 시 유리하다.
또한 AWS가 커뮤니티도 크고 컨퍼런스도 많이 열리는 등의 이점이 있다.
큰 서비스를 위해 더 유리하기 때문에 서비스가 커지면 AWS로 옮겨가는 것이다. -
Multi Cloud: 최근에는 여러 개의 업체를 같이 쓰는 회사도 많아지고 있다.
3. Google Cloud Service 둘러보기
(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 등을 관리해주면 된다.
