코드 캠프 35일차) 배포 시작

민겸·2022년 10월 24일

코드캠프_FE09

목록 보기

22/28

Cloud
SSG / LB
DNS

클라우드의 탄생 배경

옛날에는 사용자가 어느 순간에 갑자기 폭발적으로 증가하는 스타트업이란 개념이 없었다. 사용자가 폭발적으로 증가하는 이 순간을 감당해내느냐 못해내느냐로 성공과 실패가 나뉘어진다. 이 고비에서 가장 많이 다뤄볼 수 있는 것이 바로 배포 이다.

서버용 컴퓨터를 3 대를 뒀을 때, 사용자를 각각의 컴퓨터에 분배해야 하는데, 브라우저에서는 하나의 엔드 포인트로 들어오는 사용자를 어떻게 나누지?
-> 로드밸런서 사용.

로드 밸런서에는 컴퓨터 각각의 IP를 적는 공간이 있고 거기에 내가 가지고 있는 3 대의 컴퓨터 IP를 각각 적어주면 된다.

여기서, 사용자가 기하급수적으로 많아졌다고 가정하자.

100 대 분의 컴퓨터가 필요한대, 공간은 없다. 그럴 때 이런 생각을 한다.
아 이럴 게 아니라 외부 서버실을 이용하자.
-> IDC 이용.

이게 되는 케이스도 있고 안되는 케이스도 있다.

예를 들어, 문제가 생겼고 바로 픽스를 해야하는 상황인데 IDC 사람들은 주말에 출근을 안한다. 이외에도 여러가지 이유들로 관리해줄 사람이 없는 경우가 생긴다.

이 찰나에, 어떤 회사들이 등장하게 된다. 이 회사들은 컴퓨터가 많아서 컴퓨터들을 빌려주는 회사이다. 이 회사들을 Cloud Provider라고 한다.

대표적으로 AWS(아마존), GCP(구글), Azure(마이크로소프트)가 있다.

그런데, 다른 지역의 컴퓨터들을 어떻게 빌려줄 것인가?

바로 컴퓨터를 빌려주는 사이트를 구축하는 것이었다. 이 컴퓨터를 웹 사이트를 통해 빌리면 온라인으로 ON / OFF, OS, IP, Memory 용량 등을 조작할 수 있게 된다. 물론, 기능을 많이 사용하거나 고성능으로 사용하고싶을 경우 더 많은 비용을 지불해야한다. 이렇게 빌려서 접속하게 되면 빌려주는 곳의 컴퓨터와 내 컴퓨터가 터미널로 연결이 된다.

이렇게 여러가지 환경들을 조작한 후, 이 환경들을 원하는 컴퓨터 수만큼 복사/붙여넣기해서 사용하면 된다.

덕분에, 스타트업이 등장할 수 있게 되었다.

GCP는 메모리 4GB 당 4만원+a
AWS는 메모리 4GB 당 5만원+a 정도이다.

자금이 넉넉하지 않은 스타트업은 보통 GCP를 처음 이용하다가, 서비스 규모가 커지면 AWS로 넘어가는게 추세이다.

AWS가 더 비용이 큼에도 불구하고, 넘어가는 이유는 전문가들이 좀 더 많기 때문이다.

각 클라우드 플랫폼들이 가지고 있는 기능들이 조금씩 달라서, 필요한 기능들만 뽑아서 여러 클라우드들을 사용하는 것을 Multi-Cloud라고 한다.

원래, 이런 네트워크 관련 작업을 회사에서 했었고 그런 작업을 하는 사람들을 네트워크 관리자라고 불렀다. 요즘은, 클라우드에 있는 인프라를 사용하고 있기 때문에 네트워크 관리자들이 클라우드 회사로 옮겨가게 되었다.

그래도 네트워크 관련 지식을 가지고 있는 것이 클라우드를 사용할 때 필요하기 때문에 개발 관련 지식과 네트워크 관련 지식을 같이 가지고 있으면서 클라우드와 개발 사이에서 일하는 사람들을 DevOps(Development + Operations)라고 부른다.

배포를 해봐야 하는 이유

배포를 통해 전체적인 프로세스를 이해할 수 있다.

언젠가 반드시 개발 서버(나의 경우 FE 서버)를 배포할 일이 생긴다.

네트워크 개념을 알 수 있다.

컴퓨터를 통해 서버를 켰다면, 다른 브라우저에서 해당 컴퓨터의 ip로 접속할 수 있게 된다. 그런데 ip를 외워서 들어갈 때 마다 ip를 치고 들어갈 것은 아니지 않은가?

DNS

그 때 사용하는 것이 DNS(Domain Name System)이다.

이 DNS는 도메인 주소를 IP주소로 바꿔주는 역할을 한다.
이 DNS는 Route53(AWS) 또는 CloundDns(구글) 라고도 불린다.

여기서 53은 Port Number(포트 번호)이다.

도메인 주소(예) naver.com)를 입력하면 DNS로 넘어가게 되고 DNS에서 해당 주소를 IP주소로 변환하여 IP주소에 맞는 서버에 접속하게 된다.

서버에 접속하기 전에 서버 과부하를 방지해주는 로드 밸런서를 거치게 되는데, DNS에는 로드 밸런서의 IP를 등록해놓기 때문에 가능하다. 그리고 로드 밸런서에는 내가 열어놓은 서버의 IP주소들이 적혀있고, 서버 사용량에 따라 적절하게 round-robin과 같은 알고리즘을 통해 사용자가 분배되어 접속된다.

과정 상 로드 밸런서 다음 부분에 서버들이 위치하게 되는데, 이 서버 하나 하나를 EC2와 GCE라고 부르고 서버들을 묶어서 targetGroup 또는 instance Group이라고 부른다.

이렇게 Browser - DNS - LB(로드 밸런서) - targetGroup 까지가 1 단계 배포이다.

무한으로 트래픽을 받을 수 없나? 가능하다

서버에서 html, css, js를 정적 페이지로 따로 빼놓으면 된다!

동적 페이지는 무엇인가? 게시글 상세보기, 상품 상세보기와 같은 것들이 동적 페이지이다. 동적 페이지는 사용자가 접속했을 때에 동적으로 바뀌는 페이지이기 때문에 미리 뽑아놓을 수 없다. 하지만 정적 페이지는 누구에게나 똑같은 고정된 페이지이기 때문에 빼놓을 수 있다. 어디로? 스토리지로!

스토리지는 이전에 이미지를 저장하는 공간으로 사용했던 적이 있다. 여기에 정적 페이지(HTML,CSS,JS)를 저장해놓고, DNS와 연결을 해놓으면..!

브라우저에서 사용자가 접속을 하면 DNS로 들어오게 되고 여기서 동적 페이지로의 접속인지 정적 페이지로의 접속인지 구별한 후 정적 페이지일 경우, 바로 스토리지에서 페이지를 다운로드 받아서 DNS로 보낸 다음 브라우저로 보내어 사용자에게 화면을 보여준다!!

주의할 점은 DNS에서 실제로 트래픽을 나눠주는 것은 아니다. CDN(Contents Deilivery NetWork) 이라는 도구가 있는데, AWS에서는 CloudFront라는 이름을 가지고 있고, GCP에서는 CloudCDN라고 부른다. 이 CDN에는 동적 페이지와 정적 페이지에 따른 분기 처리를 해주는 기능이 있다.

여기까지가 2 단계 배포이다.

프론트 엔드 서버에 접속했을 때는 HTML만 주자, 백엔듯 서버에 접속했을 때는 JSON 데이터를 주자 라는 관례가 있다. CNA를 사용할 때, api 폴더가 있는 건, 관례에 상관없이 프론트 서버에서 모든 것을 다 하고 싶을 경우를 위한 것이다. 마찬가지로, 백엔드에서도 HTML을 보내도 된다. 하지만 역할 분담을 위해 그렇게 하지 않는 것이 관례이다.

SSG Static Site Generation

이번에는, 클라우드 스토리지에 정적 페이지를 저장한 다음, 브라우저에서 접근하는 것을 알아보기로 하자.

CNA를 하게 되면, index.js파일에 Image태그가 있는데 이 태그는 next에서 제공해주는 태그이다. 이 태그는 proload, lazyload등이 자동으로 적용되어 있다. 하지만 이 태그는 정적 페이지로 사용하기 위해서는 사용하면 안되기 때문에 정적 페이지를 만들 경우 이 태그를 사용하지 말도록 하자.

배포를 할 때 가장 처음 npm build 또는 yarn build 이후 npm start 또는 yarn start를 하게된다.

storage로 분리하기 위해서는 build 과정을 거쳐야 하고 정적 페이지들을 뽑아내기 위해서는 next export를 해주어야 한다.

개발 환경을 Development 배포 환경을 Production이라고 부른다.
줄여서 dev와 prod라고 부르기도 한다.

이렇게 빌드를 하게 되면, js파일들이 전부 html파일로 변환되어 있는 것을 볼 수 있다. 그런데 분명 폴더안에 내가 만든 페이지를 넣어놨는데 폴더밖으로 나온 것을 볼 수 있다. 폴더 구조는 배포 환경에서도 잡혀있는 것이 좋으므로 config.js 파일을 다음과 같이 수정해줘야 한다. trailingSlash: true

그 다음으론 out 폴더를 파인더 또는 탐색기에서 열어준 뒤, AWS에 접속한다.

스토리지를 이용할 것이기 때문에, S3 를 검색한다.
S3란, Simple Storage Service이다.

새로운 버킷 만들기를 클릭하고, 버킷 이름은 도메인 이름과 똑같이 설정해준다.
리전은 서울 리전으로 설정해준다.

ACL 비활성화를 한다면, 보안쪽으로 더 좋을 수 있다 그래서 recommended인가.. 일단은 활성화로 설정해준다.

다음으로는 Public Access 설정이다. 보안 측면에서 매우 중요한 부분이다. 기본값으로 모든 접근을 차단시킨다고 되어있다. 이것을 해놓아야 아무나 나의 사이트에 접속해서 내 스토리지의 파일들을 다운 받을 수 없게 할 수 있다. 하지만, 나는 지금 내 파일들(html,css,js)를 누구나 받을 수 있게 해야하므로 기본값을 해제해준다.

일단 이 정도만 해놓고 버킷을 생성해준다.

그리고 버킷을 클릭해 파일 및 폴더 업로드 창을 띄워주고 아까 띄워놓았던 파인더의 파일들을 드래그 앤 드롭해준다. 파인더를 켜놓지 않았다면, 업로드 버튼을 클릭해서 out폴더 내부의 파일들을 전부 선택해서 업로드 해주면 된다.

이렇게 업로드한 후, 다시 버킷으로 돌아와서 index.html을 클릭하면 나오는 주소를 클릭해서 들어가보면 Access Denied 접근 거부가 뜨는 것을 볼 수 있다. 기본적으로는 이렇게 접근이 차단되는 것이 정상이다.

아까 나는 ACL을 활성화시켜주었으므로, 파일을 전체 선택하고 Action 또는 작업을 클릭해서 맨 밑의 퍼블릭으로 설정 버튼을 클릭해준다.

이렇게 한 뒤 다시 index.html에 접속하면, 정상적으로 접속이 되는 것을 볼 수 있다. 하지만 사이트가 뭔가 이상하다. CSS가 없는 것을 눈치챘다면, 정답이다.

위의 작업들을 묶음으로 호스팅 해주기 위해, 속성 탭에 들어가서 맨 밑의 정적 웹 사이트 호스팅에서 편집을 눌러서 다음과 같이 설정해줘야한다.

이렇게 설정해주면 다음과 같은 엔드 포인트가 하나 나오게 되는데, 이 주소로 접속하면 스타일링까지 포함된 사이트가 나온다.

여기까지가 스토리지를 이용한 정적 배포이다.

이 무지막지한 주소를 외우고 다닐 순 없기에, 보통 도메인을 구매해서 연결시켜서 사용한다. 이를 가능케 해주는 도구가 DNS (Domain Name System)이다.

AWS에서 DNS를 사용하기 위해서는 Route53이라고 검색하면 된다.

검색 후, 호스팅 영역 생성하기를 클릭하고 첫 번째 칸에 내가 구매한 도메인 이름을 입력하고 생성하면 된다.

Record Type

A : 도메인을 입력하면 IPv4주소로 변환해주는 역할. (가장 많이 사용하는 레코드 타입)
AAAA : 도메인을 입력하면 IPv6주소로 변환해주는 역할.
CNAME : www.naver.com -> naver.com
TXT : 도메인 주소가 특정 기관으로부터 인증을 받아야 할 때(예) http -> https 변환할 때 외부 기관의 인증을 받아야 한다.) 사용하는 레코드 타입

만약 도메인 네임이 아닌 클라우드에서 만든 이름으로 사용하고 싶다면, 도메인 네임을 구매한 사이트(예) 가비아, 고대디, 카페24)에 가서 기존 NS(Name Server)를 다 지우고, 클라우드의 NS를 넣어서 바꿔치기 해주면 된다. 이렇게 하면 가비아나 고대디에서의 NS가 중지되고, 클라우드 NS로 통합된다.

NS가 적용되었는지 확인하는 방법

터미널을 연다.
dig 내 주소 NS 입력 후 엔터
NS가 awsdns로 올라오면 통합이 된 것이다.

클라우드 NS로 통합까지 되었다면, 이제 record를 생성해보자.

AWS의 Route53에 다시 들어가서 Quick create record를 클릭 후, 서브 도메인은 일단 제쳐두고, 레코드 타입은 A로 설정해준 뒤, 스토리지를 사용하는 것이기 때문에 S3 website endpoint로 설정하고 리전은 당연히 우리나라로 설정하면 마지막 항목은 자동완성이 되는데 그대로 해주면 된다.