SSG 배포 (2) :: LoadBalancer 만들기

이주희·2022년 5월 3일

Deployment

목록 보기

4/10

LoadBalancer

접속을 하기 위해선 접속을 도와주는 도구와 연결을 해야 한다.
이 도구가 바로 로드밸런서(부하분산기)

LB의 역할 1

접속량이 늘어나면 메모리도 늘어나야 한다.
(왱? 동시 접속한 사람들의 요청을 하나씩 처리하니까 처리중인 애들, 대기중인 애들의 데이터를 저장해놔야 하는데 그러다보면 메모리가 많이 필요해진다.)
사용자가 너무 많아져서 메모리를 초과하게 되면 컴퓨터가 멈춘다!

이를 방지하기 위해서 컴퓨터를 여러 개 띄워놓아서 부하를 분산시킨다.(Scale Out)
(하나의 컴퓨터에서 메모리를 올리는 것은 Scale Up)

LB가 부하를 분산시켜준다.
부하를 분산시키는 방법에는 여러 알고리즘이 있는데, 내부 모듈에서 설정할 수 있다.

round-robin: 하나씩 돌아가면서 접속 고고
least-connection: 접속량이 가장 적은 컴퓨터로 고고

LB의 역할 2

LB가 역할을 확장해서 요청을 Storage와 Frontend-Server로 나눠서 보내는 역할도 해준다.(이것도 부하를 나눠주는 거죠!)

일반적인 페이지들은 Storage로 고고
SSR이 필요한 페이지들은 Front-end Server로 고고
(FE Server가 여러개인 경우, 거기서도 분산 가능)

각 컴퓨터를 인스턴스라고 부르고, 그룹을 인스턴스 그룹이라고 부른다.
인스턴스 그룹에는 특정 설정을 할 수 있다.
(ex CPU, 메모리가 몇 이상이면 똑같은 걸 복사해서 하나 더 만들어줘!)
Auto Scaling: 부하가 늘어나면 자동으로 컴퓨터를 새로 만들어줘서 부하가 자연스럽게 분산된다.

LB의 역할 3

https로 통신하려면 인증서를 설치해야 한다.
근데 이걸 연결하는 과정이 원래 디게 복잡함..
but! Google LB를 사용하면 Google이 관리해주는 무료 인증서를 받을 수 있어서 쉽게 인증서를 만들어서 연결해준다.

GCP로 가서 부하 분산기를 만들어보자~

부하 분산기 만들기

(1) GCP - 메뉴 > 네트워크 서비스 > 부하 분산

[부하 분산]

(2) 부하 분산기 만들기 > HTTP(S) 부하 분산 - 구성 시작

부하 분산기의 종류

HTTP(S) : request를 보내고 response를 받는 형태 👈🏻 지금 이거 쓸 거임

TCP : 채팅처럼 두 컴퓨터 간 연결해서 데이터를 주고받는 것, 잘 받았는지 확인을 한다.
안정성이 높고 UDP에 비해서는 속도가 조금 떨어진다.

UDP : TCP와 유사한데, 잘 받았는지 확인은 안하고 그냥 날린다. 안정성이 조금 떨어질 수 있지만 체크를 하지 않기 때문에 속도는 빠르다. 게임에 많이 쓰인다.

(4) 인터넷에서 VM / 전역 HTTP 기본 선택 > 계속

VM: Virtual Machine 가상 컴퓨터

VM: 지금 빌리려는 컴퓨터를 의미한다.

'인터넷에서 VM' : 로드밸런서를 만드는데, 브라우저에서 프론트엔드 컴퓨터(VM)으로 분산시키는 것

'VM 사이에서만 분산': 백엔드가 있고 DB가 여러개 있을 때 가운데에 LB가 있으면, VM들 사이에서 분산이 이루어진다.

서버리스 서비스 : Serverless Architecture

서버가 없다는 뜻이다!

서버를 24시간 띄워놓는 것이 아니라
CloudFunction이라는 함수 안에 API들을 함수로 만들어서 다 넣어놓는다.

브라우저에서 API를 요청하면 해당 함수를 가지고 있는 컴퓨터가 켜져서 그 컴퓨터 안에서 함수를 실행시키고 다시 꺼진다.

장점: 백엔드 컴퓨터를 24시간 안 켜놔도 된다.

단점: 처음에 요청할 때 컴퓨터가 켜지고 함수가 실행되어야 하기 때문에 처음에 좀 느리다.

서버리스로 하면 백엔드 개발자 없이 프론트 개발자가 cloudFunction에 API를 함수로 형태로 만들어서 프론트엔드에서 실행시키는 방식으로 이뤄지기도 한다.

전역 HTTP(S) 부하 분산기(전역 또는 리전의 두 번째 선택지)

round-robin, least-connection 등 LB가 부하를 분산시키는 알고리즘을 설정할 수 있다.

(5) 백엔드 구성

이름 : 도메인-lb(맘대룽)
백엔드 구성: 백엔드 버킷 만들기 클릭
Cloud Storage 버킷: 앞에서 만든 버킷 선택 > 만들기
지금은 백엔드 버킷만 만들면 된다.

백엔드 구성 & 프런트엔드 구성

여기서 백엔드와 프런트엔드는 LB의 앞과 뒤를 의미한다.
백엔드: LB의 뒤쪽에 Storage와 FE Server가 있다.
프런트엔드: 접속이 들어오는 부분이다. http로 접속할 지 https로 접속할지 등을 정한다.

백엔드 구성

SSR이 가는 곳이 백엔드 서비스

Storage가 백엔드 버킷

호스트 및 경로 규칙

경로에 따라서 스토리지로 보낼 지 프론트엔드 서버로 보낼지 설정한다.

Cloud CDN : Content Delivery Network 👉지금은 설정 안함

캐시: 임시 저장하는 것

TTL: Time to live 임시저장한 데이터를 유지할 기간

캐싱: 멀리 있는 컴퓨터로 접속하면 넘 오래 걸리니까!
다른 장소에도 임시로 저장을 해놓고(캐싱) 가까운 컴퓨터로 접속하게 한다.

이런 서비스를 CDN이라고 하다.

원래는 CDN 회사에서 주로 작업을 했는데 요즘엔 Cloud Service들이 해준다!

(6) 호스트 및 경로 규칙

자동으로 만들어진다.
따로 입력하지 않으면, 모든 경로가 방금 만든 bucket으로 가게 된다.

(7) 프런트엔드 구성

이름 : 도메인-frontendservice (맘대룽)
프로토콜: 여기서 HTTP, HTTPS 등을 설정하는데, 지금은 HTTP로 지정해놓고 뒤에서 바꾸자!

(8) IP 주소 만들기

IP 주소 > IP 주소 만들기 클릭
IP 주소: 임시로 발급받으면 바뀔 수가 있고, 고정적인 주소로 받으면 바뀔 리는 없지만 돈 내야됨 한달에 300원 정도?!

이름: 도메인-static-ip > 예약

IP 버전

IPv4 : 10.23.0.3처럼 4칸 있는 것! 👉 이거로 그대로 ㄱ

IPv6 : IPv4가 물리적으로 부족해서 나왔다.

포트

80번 포트는 http에서의 기본 포트를 의미한다.(기본 포트는 생략이 가능해서 80을 안 써줘도 된다.)

https에서의 기본 포트는 443이다.

로컬에서도 yarn dev -p 80 명령어로 80번 포트로 접속하면 http://localhost:3000/boards 하던걸http://localhost/boards 이런식으로 접속이 가능쓰