35일차 배포

osdsoonhyun·2023년 4월 3일

TIL 코드캠프

코드캠프

목록 보기

20/22

배포 환경에 대해 이야기해보자! -> Cloud
스토리지에 정적파일을 배포해보자! -> SSG / LB
구입한 주소를 입력하면 접속되게 연결해줘 -> DNS

전에는 배포시 어려움이 많았다. 장애(서버에 접속 안됨, 프로그램에 문제 발생, 등 모든 것 )가 발생시 대응이 어려웠다. 집에 남는 컴퓨터로 네트워크 세팅해서 서버를 만들어 놓는다. 용량이나 메모리가 많이 필요하다는 것은 접속자가 만명 정도 넘어가야 많다고 한다. 100명 정도는 작은 서버로도 충분하다.
서버 사용자가 많아지면 컴퓨터를 사서 네트워크 세팅을 해주고, 브라우저에서 엔드포인트를 하나만 입력하므로 컴퓨터 한대만 지칭하므로 여러 대의 컴퓨터에 나눠주는 쉽게 얘기해서 공유기인, 라우터라고 불리는 네트워크 장비인 LB를 구입한다.
IP주소를 LB로 접속을 하고 여러 대의 컴퓨터로 나눠준다. 나눠주는 방식은 순차적으로 접속시키는 round-robin 방식 접속자가 적은 곳으로 몰아주는 least-connection 방식이 있다.
스타트업의 경우 기하급수적으로 접속자가 늘어나면 컴퓨터를 늘릴 수 없으므로 따로 관리해주는 IDC라고 불리는 서버 센터에 맡긴다. 근데 여기도 24시간 관리해주지 못하기 때문에 즉각적인 피드백 적용이 안된다.
이때 컴퓨터를 빌려주는 회사인 클라우드 제공업체(Cloud-Provider), AWS(Amazon Web Service), GCP(Google Cloud Platform), Azure(Microsoft Azure)가 생겨났다.
여기서 실제로 컴퓨터를 빌려줄 수 없으니, 제공업체에서 웹사이트를 만들고 그 안에 터미널을 만들어서 사용할 수 있다. 물리적으로 컴퓨터 사용이 불가능했던 것이 가능해지고 스타트업들이 성장할 수 있게 되었다.
GCP - 4GB => 4만원 +- , AWS - 4GB => 5만원 +-
기능 상의 둘의 차이는 많이 없고 GCP로 가격이 싸서 시작하지만, AWS의 전문가들이 많아서 규모가 커지면 많이 사용한다.

배포환경 이해

Multi-cloud : 요즘 트렌드는 각 클라우드 GCP, AWS, Azure 의 장점들만 뽑아서 나눠서 여러개의 클라우드를 사용한다
네트워크 관리자라는 직업이 있었는데 클라우드가 제공되면서 개발(Development)을 어느정도 알면서 운영(Operations)까지 할 수 있는 DevOps 직업군이 생겨났다.

AWS 메뉴 구성

로컬 호스트 주소 대신 ip주소를 입력해야 접속이 되는데 ip주소를 외우고 다닐 수 없으므로 도메인 주소를 사야 한다. 그 도메인 주소를 등록(연결)해야 하고 이것은 DNS가 해준다. 컴퓨터는 아마존에서는 EC2(Elastic Compute Cloud), 구글에서는 GCE(Google Cloud Engine)라고 하고 여기에 ip주소 입력하고 접속해야하는데 ip 주소를 외우고 다닐 수 없으므로 ip주소를 읽기 쉬운 도메인 주소로 바꿔주는 DNS(Domain Name System)가 생겨났다. Amazon에서는 Route53, 구글에서는 CloudDNS 라고 한다.

배포 프로세스

브라우저에서 주소를 입력하면 DNS에 접속이 되고 DNS에서 도메인 주소를 ip 주소로 바뀌어 LB로 접속하고 LB에 저장된 ip주소로 round-robin, least-connection 방식으로 yarn dev가 실행된 EC2, GCE 컴퓨터로 각각 분산이 된다. 여기서 각각 html 코드를 다운 받아가지고 온다. 각각의 컴퓨터를 하나로 그룹핑하는데 LB의 target이라 해서 targetGroup이라 하고 Google에서는 하나의 객체로 봐서 instanceGroup이라고 한다.
여기까지가 1단계 배포이고 여기서 접속량이 많아지면 분산되어도 컴퓨터가 계속 필요하게 되고 접속량이 많아지면 컴퓨터가 장애가 나서 문제가 생기면 다운되는 문제가 발생하므로 걱정 없이 무한으로 트래픽을 받고 싶다.
방법으로 소스코드의 정적페이지들의 Html, css, js를 미리 뽑아놔서 storage service에 이미지 업로드 시켜놓듯이 올려놓는다. 그래서 브라우저를 시작할때 DNS로 가고 DNS에서 정적페이지면 storage로 동적페이지면 LoadBalance로 이동한다. 그러면 컴퓨터는 동적 페이지에 대한 요금만 내면 되고 동적 페이지 접속한 사용자의 트래픽만 받으면 된다. 동적페이지는 그때마다 바뀌는 페이지를 말한다. 예로 상품 상세보기, 게시글 상세보기가 있다.
실제 DNS에서 트래픽을 나눠주는 것이 아니고 CDN에서 나눠준다. CDN(AWS에서 CloudFront, GCP에서는 CloudCDN)에서 주소분기 입력창이 있어서 동적페이지 정적 페이지로 나뉘고 정적은 storage, 동적페이지는 LB로 이동시킨다.
1단계 배포를 하고 traffic이 많아지게 되면 정적페이지는 뽑아서 storage로 옮기는 것이 2단계 배포이다.

배포
1단계 배포 : LB에 연결을 하여 컴퓨터로 연결하는 과정.
-> 컴퓨터에서 yarn build => yarn start
2단계 배포 : storage로 정적 페이지, 동적 페이지 분리.
-> 컴퓨터에서 yarn build => 정적인 html, css, js를 뽑아내는 next export

정적 배포

프로젝트 build

정적페이지와 동적페이지를 만든 상태이다.
압축을 하거나 효율적으로, 남들이 보기 어렵게 판독을 불가능하게 하는 난독화 과정을 거쳐 배포를 위한 최적화 과정을 거친다.
build를 하여 최적화 과정을 거친 후 배포 시 yarn start를 한다.
정적인 파일 html, css, js를 뽑아내는 next export 과정을 거친다. static-site-generation 빌드 배포이다. 빌드 하위에 ssg인 build:ssg 명령어를 많이 사용한다.
scripts에 "build:ssg": "next build && next export" 하면 next build 명령어 하고 next export 명령어를 통해서 html, css, js만 뽑히고 이것을 storage에 저장하면 된다.
yarn build:ssg 명령을 실행하니 out 폴더가 생겼고 html 파일들이 나타났다. 이것은 index.js 파일들을 html로 바꾼 것이다.
out 폴더가 생성되며 해당 폴더 안에서 SSG 배포에 사용되는 폴더와 파일들을 확인할 수 있다.
404 페이지는 브라우저, 클라이언트에서 실패할 때 나오는 페이지이다.

Trailing Slash

트레일링 슬래시는 URL 주소 끝에 붙은 슬래시 / 를 말한다.
예를 들어 https://www.google.co.kr/ 를 보시면 끝에 슬래시가 붙어있다. 사실 https://www.google.co.kr 이렇게 적어도 잘 동작하지만, 브라우저는 두 가지 경우를 다른 주소로 인식한다. 주소 끝에 슬래시가 붙어있으면 이건 디렉토리, 즉 폴더라는 의미이고, 슬래시가 없다면 여기가 끝 엔드포인트, 즉 파일이라는 것을 의미한다.

module.exports = {
  trailingSlash: true,
}

// 또는
/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
  trailingSlash: true,
};

module.exports = nextConfig;

Next.js의 기본 ssg build 옵션은 /boards/index.js 페이지를 /boards.html 이라는 이름을 가진 html 파일로 바꿔준다. 하지만 이런 형태의 폴더구조는 보기 불편하기 때문에, /boards/index.html과 같은 형태로 build 하도록 설정을 변경한다.
next.config.js 파일을 열어 trailing slash 옵션을 추가한다.
그리고 나서 다시 yarn build:ssg 명령어를 실행하면 다음과 같이 build된 것을 확인할 수 있다.

S3(Simple Storage Service) 배포

DNS 연결

Domain Name System의 약자로 aws에서 제공하는 DNS인 Route53(Google - CloudDNS)를 활용해서 도메인을 등록하고 도메인에 연결해서 S3가 접속이 되게끔 연결해보자

	AWS	Google(GCP)
Storage	S3(Simple Storage Service)	CloudStorage
DNS	Route53	CloudDNS
CDN	CloudFront	CloudCDN

Route53 -> 호스팅 영역 -> 내가 구입한 도메인 -> 레코드 생성
에서 타입의 종류

A레코드

브라우저에서 DNS, DNS에서 LB로 접속하는데 DNS의 역할은 주소를 IP 또는 다른 주소로 바꿔주는 역할을 한다. 이러한 작업을 하는게 A레코드이다.
ex) naver.com => 10.0.2.3 / naver.com -> storage.com

value 값은 도메인 주소를 입력하면 value 값으로 이동시켜준다는 값이다.
shopismarket.shop을 입력하면 192.0.2.225:3000/ 이 값으로 바꿔서 화면을 나타낸다. 이 작업을 A레코드가 한다.

AAAA레코드

4개가 일반적으로 사용하고 있는 것이고 ip가 부족해서 ip6가 나온 것이기에 ip6를 사용하면 AAAA레코드를 사용하면 된다.

CNAME

다른 도메인의 이름과 일부 AWS 리소스로 트래픽 라우팅
네이버의 경우 이렇게 되는데, 주소창에 www.naver.com을 입력해도 네이버 접속하게 되면 naver.com으로 보인다
Record name에 www.naver.com을 적고 value에 naver.com을 적어주면 된다.

MX

Mail eXchange의 약자로 이메일 전송 서버를 만들때 사용한다.

TXT

이메일 발신자와 애플리케이션 값을 확인할 때 사용

도메인을 S3, EC2 등 AWS와 연결하는 데 반드시 Route 53을 사용할 필요는 없지만,
Route 53을 이용하면 통합 관리가 가능한 장점이 있습니다.
또한, CloudFront나 Load Balancer 등의 고급 DNS 설정이 필요한 경우에는 타사 서비스보다 Route 53을 이용하는 것이 저렴합니다
타입이 NS인 것을 찾고 가비아의 name서버에 있는 것을 route53의 name 서버로 바꿔 가비아 설정을 무력화시켜 aws의 설정을 모두 오픈한다.
aws의 name 서버를 가비아의 네임서버에 등록을 시키는 순간 가비아의 모든 설정들이 무력화되고 aws의 설정들이 오픈된다. 그럼 가비아를 안들어가도 aws에서 모두 처리할 수 있으므로 번거로움을 줄일 수 있다. 이 작업을 반드시 하지 않고 가비아를 사용해도 된다.

.을 삭제하고 저장해준다. 설정이 완료되었는지 확인하기 위해 터미널에서 dig (구입한 도메인) NS를 입력하여 ANSWER SECTION에 NS레코드로 입력한 4개의 URL이 표시되면 네임서버 연결이 완료된 것이다.
dig(domain information groper)의 약자로 도메인 정보를 잡아주는 기능을 한다.
이것이 확인되면 가비아는 무력화가 되고 aws의 네임서버가 연결된 것이다.