내배캠 React 최종 프로젝트 [BOOKER] Vercel에서 AWS S3로 배포해보기(마지막 성능 비교)

규갓 God Gyu·2024년 5월 3일

TIL

프로젝트

목록 보기

55/81

우선 기존 BOOKER 같은 경우 10000원짜리 도메인을 구매하여
가장 편한 방법인 VERCEL로 배포를 진행하였었다.

그래서 좀 더 커뮤니티가 활성화가 잘되있고 많이 이용하는 AWS 배포로 연습해보려하는데, 우선

Vercel이란?

정적 오ㅞㅂ 사이트 및 서버리스 함수를 배포하는 데 사용되는 클라우드 플랫폼

Vercel의 특징

정적 사이트 호스팅
: 정적 파일을 호스팅하고 빠르게 전 세계적으로 배포할 수 있는 기능 제공
서버리스 함수
: 서버리스 함수를 지원하여 사용자가 작성한 코드를 실행하고 API 엔드포인트를 제공
배포 자동화
: Git 저장소와 연동하여 코드가 업데이트될 때 자동으로 배포
글로벌 네트워크
: 전 세계적으로 분산된 CDN(Content Delivery Network)을 통해 빠르고 안정적인 배포 제공
통합된 개발 경험
: 다양한 프레임워크와 통합되어 있으며, 특히 React,Next.js 등의 프레임워크와의 호환성이 우수

AWS란?

Amazon Web Services의 약자로 아마존이 제공하는 클라우드 컴퓨팅 서비스

AWS의 특징

인프라 서비스
: 가상 서버(EC2), 스토리지(S3), 데이터베이스(RDS), 네트워킹 등 다양한 인프라 서비스를 제공
서버리스 컴퓨팅
: AWS Lambda를 사용하여 서버리스 아키텍처를 구축할 수 있으며, 코드 실행에 대한 요금만 지불하면 됩니다.
데이터베이스
: 다양한 데이터베이스 서비스를 제공하여 관계형 데이터베이스부터 NoSQL 데이터베이스까지 다양한 요구 사항을 지원
인공지능 및 기계 학습
: Amazon SageMaker를 사용하여 기계 학습 모델을 빌드, 학습 및 배포
보안
: 다양한 보안 서비스를 제공하여 애플리케이션과 데이터 보호
확장성
: 거의 무제한의 확장성을 제공하여 대규모 애플리케이션을 지원

Vercel vs AWS

vercel은 주로 정적인 웹 사이트 및 서버리스 함수를 위한 호스팅 플랫폼으로, 개발자들이 빠르고 쉽게 웹 애플리케이션을 배포하고 관리할 수 있도록 지원(프론트엔드 개발자)
aws는 다양한 클라우드 서비스가 있어서 다양한 용도로 활용 가능
AWS는 더 많은 유연성과 기능을 제공, Vercel은 더 쉽고 빠른 배포 경험을 제공
Vercel이 정말 프론트엔드 배포에만 최적화되어 있다 보니, 백엔드 기능이 필요할 땐 별도의 구성이 필요하다(서버리스)
SPA 배포에 최적화되어 있어서, Next.js를 만들었음에도 MPA 배포를 하려다보면 Next의 라우팅 설정과 Vercel의 라우팅 설정을 잘 해줘야 에러에 직면하지 않을 수 있다..!

여기까지 배포 서비스에 대해 알아보았고
실제로 Vercel로 배포한 우리 프로젝트를 AWS로 배포해보자!!

우선 팀원들과 같이 협업한 깃허브 repository를 건들 순 없기에 Fork를 시도해보자!!

새로운 Repository 이름을 정해주고
Create fork!!

깃허브에는 성공적으로 repository 생성하였고,

클론을 하기 위하여 repository 주소 복사!!

그 후 새로 만든 폴더에 git clone [주소] . 해주면되는데,
여기서 띄워쓰기 . 이 중요한 이유는 저 . 없이 그냥 복사하면 내가 새로 생성한 폴더 안에 또 폴더로 만들어진다.
폴더도 알아서 만들게 할거면 . 을 의식해서 잘 생성하자!!

그 후 node_modules 설치를 위해서 yarn install을 해주면되는데 npm 도 상관없다 취향차이!!
(근데 하도 오랜만에 생성해서 헤깔린다.. 하.. 망각의 제왕인가ㅠ)

그 다음 오랜만에 다시 만든 프로젝트니까 잘 실행되는지 체크하기 위해 yarn start를 해보면??

짠~~~
.........
.............
데이터 베이스로 사용하던 supabase도 새로 세팅을 해줘야하는구나.. ㅠㅠ
그래서 새로 수파베이스를 연결시켜줘야 하나 싶었는데,

다행히 .env.local 이 기억이 나서 기존 supabase를 연결해주었다..!!

결국 원래 페이지 구현 성공~~!!!!

이제 AWS로 배포 시도를 해보자!!
AWS 중에서도 정적 웹사이트 배포를 위해 AWS S3를 이용하게 되었는데

단순 http 배포를 S3 한가지로도 가능
S3 엔드포인트에 도메인 적용을 위해 필요한 AWS 서비스
: 도메인 구입 후 Route 53에서 DNS 관리해주면 바로 도메인 적용됨
https 프로토콜 설정을 위해 추가적으로 필요한 AWS 서비스
: Certificate Manager를 통해 도메인에 대한 SSL 인증서 발급 및 검증 진행
: CloudFront를 통해 SSL인증서를 적용하고 도메인을 통한 모든 요청을 https 프로토콜로 라디렉션 처리

일단 배포를 위해선!!!!
터미널에서 yarn build를 해준다
그러면 build라는 폴더가 생성되는데 그 안에 있는 파일들이 실제 배포 사이트에 업로드 되어야할 파일들임!!
그 배포되어야할 곳은 바로 S3!! ( Simple storage service)
정적 웹사이트 호스팅이 가능한 서버이다(동영상 등등)
이 S3에 배포만 성공해서 클라이언트가 도메인을 통해 웹 사이트로 보여질 순 있다!!

but!!!

이렇게만 배포할 시 http 프로토콜로만 배포를 진행한 것이기 때문에

로그인 / 회원가입 등 개인정보를 기입하는걸 하면 안되어서 추가적으로 https 프로토콜로 배포를 하여야한다!

왜?? 보안이 약해서 제3자가 개인정보를 알아낼 수도 있기 때문에!!!!!

그렇기 때문에 최소한의 보안장치로는 https프로토콜을 사용하여야 한다!!

그럴려면!!!

추가 AWS 서비스를 붙여야하는데,

순서는

도메인 구매(ex) 가비아)
도메인 관리 권한을 name server를 통해 Route 53에 넘겨준다
도메인에 대한 SSL인증서를 Certificate Manager를 통해 발급 받는다
도메인 소유권 검증 처리도 Certificate Manager를 통해 진행한다
마지막으로 CloudFront(CDN-Content Delivery Network)을 연결해준다
: client와 server의 요청에 대하여 전달 받고 처리해주는 서비스
심지어 CloudFront는 https 프로토콜 적용까지 해준다(S3와 별개로 따로 CloudFront 서버 배포도 진행해야함)
배포할때 전에 발급받은 SSL 인증서를 연결해주기까지하면 끝!!

처음이다보니 굉장히 복잡하지만 위의 사진을 참고하면 어느정도 흐름은 이해가 된다!! 훗

그러면 실제 구현이 아닌 실행과정은!!

client에서 Route 53에 도메인 IP주소를 요청한다
그러면 CloudFront 주소를 알려주게 된다
그 후 Client에서 CloudFront에 페이지 주소를 요청한다
CloudFront는 그 요청을 S3 엔드포인트로 요청한다
S3는 index.html 파일을 응답하여 CloudFront에 전달한다
응답받은 CloudFront는 client에 index.html을 전달한다
여기서 CDN인 CloudFront는 응답받은 index.html을 캐싱해놓는다(복사)
그러면 Client2가 똑같은 요청을 하게되면 CloudFront는 S3에 요청하지 않고 캐싱된 데이터를 보내준다
client1이 최초로 요청해서 1초가 걸려 웹사이트를 열었다면 client2는 0.1초만에 열게된다(캐싱덕분)
심지어 아까 말한 https 프로토콜로 전환해주는 아주 기특한 CloudFront(CDN) 서버!!

우와 이거 공부안하고 그냥 적용하려했으면 겉핧기 식으로 알았을거같은데 이렇게 정리하니까 확실히 이해가 쫙쫙된다 ㅎㅎ

자~~ 그러면 실전 스타트!!!

도메인 구매하기

S3 정적 호스팅은 직접적인 ip주소를 제공하지 않고 버킷이름이 들어간 고유의 엔드포인트(url)를 제공
이때 도메인을 적용할 때 ip주소를 따로 제공하지 않기 때문에
도메인명과 S3 Bucket Name이 일치해야만 S3 엔드포인트에 도메인 적용이 가능
이렇게 해야만 해당 도메인명이 S3주소를 가리킬 수 있게 됨
그렇기 때문에 S3배포보다 도메인 구매가 우선시 되어야하는 것임!!!
권장 도메인 구입처 : gabia, GoDaddy, namecheap
나는 gabia밖에 사용안해보았기 때문에 가비아로 드가좌~~
주의사항
: 도메인 유효기간 '1년'으로 구매(그래야 할인된 가격 1000원정도로 구매 가능!!)
: 별도의 SSL 인증서 구매 X(무료발급이 가능하기 때문)

실제로 우리 프로젝트는 book-er.site로 사용중이므로 aws 배포 연습용이기 때문에
booker-aws로 검색했더니 아주 저렴한 store 500원짜리가 있어서 이걸로 선택!!

추후에 타사 네임서버 사용할 예정이지만 최초로는 가비아 네임서버 사용으로 세팅하면
부가세 10% 합친 550원 결제 금액!!

1000원 미만은 카드결제가 안되므로 실시간 계좌이체 혹은 무통장 선택!!
(550원 현금영수증 신청하는 클라스 ㅋㅋㅋ)

결제 성공적으로 완료~!

이제 저기 보이는 네임서버를 gabia가 아닌 Route53에 권한을 주면 된다~!! 아따 할거 많누

자 이제 S3 Bucket부터 만들어보자

우선 AWS 회원가입 후 콘솔로 이동하여 S3 검색해주시고~

버킷 만들기 눌러 주시고~

버킷 지역을 서울로 세팅해주기!!
맨 처음에 시드니로 기본세팅 되어있는데 어디서 바꿔야하는지 몰라서 당황;;

도메인 이름과 버킷 이름을 일치 시키기!

그 후 모든 사람들이 내 사이트에 접근하는게 가능하도록
ACL 비활성화
모든 퍼블릭 엑세스 차단 해제
현재 설정으로 인해 이 버킷과 그 안에 포함된 객체가 퍼블릭 상태가 될 수 있음을 알고있습니다 체크
(여기서 객체는 내가 업로드한 모든 파일)

그 후 버킷을 만든 다음에

속성 안에 있는 정적 웹 사이트 호스팅을 위해 활성화를 시틴다.
index.html은 react의 기본 첫 페이지로 보여주는 화면이 되기 위해 기본 값으로 세팅해놓기!

그러면 이제 S3 정적 웹 사이트 호스팅은 배포를 성공한 상태다
물론 가비아와 연결이 안되있어서 아직 들어가도 뭐 없음!

여기서부터 굉장히 복잡한데..

권한을 주기 위해서 버킷정책을 들어가서
정책 아래 코드를 작성하기 위해 정책 생성기를 클릭

그러면 이러한 페이지가 나오고
S3 Bucket Policy선택해주고
Principal - * <-- 모든 대상
Actions <-- Get Object 선택
Amazon Resource Name <-- 버킷정책에 있는 ARN 복사해서 붙여넣기
그 후 Add Statement -> Generate Policy 선택

그러면 이러한 코드를 받았는데 어디다 넣어야하는지 감이 오쥬~?

이제 권한 json 형식으로 넣어주고 저장하면

403 정책 권한때문에 들어갈 수 없던 홈페이지가
어라..? 또 403이네?..

저장할 때 알 수 없는 오류가 뜨는데.. 왜지?

아하 여기서 /*를 작성해줘야 모든 사람에게 권한이 주어진다네... 참..

드디어 권한때문에 홈페이지가 막히지는 않은 모습... 후..
(404 권한은 있으나 아무것도 없다)

이제 코드로 가서 yarn build를 하면 좌측 상단에 build 폴더가 생성이 되었고
마우스 우측 클릭 - 파일탐색기에 표시를 누른다

그 다음에 build폴더 안에 있는 내용을 전부 객체에 업로드 시키기!!

그러면 업로드가 완료되었고 다시 정적 웹 호스팅을 실행시켜보면~?

캬~~ 정상적으로 실행된다 그러나???
http 프로토콜을 사용하기 때문에 보안에 아주 취약한 상태이므로 이렇게 배포를 끝내면 절대 안된다!!!!

이젠 Route53 설정할 차례!!!

aws에서 Route53 검색 후 호스팅 영역 생성하기
여기서 호스팅 영역은 도메인을 관리할 수 있는 하나의 영역이라 생각하자!

가비아 도메인이랑 똑같이 적어서 영역 생성!

그렇면 이렇게 NS SOA 유형 2개가 자연스럽게 생성되는데
NS - name server 일종의 ip주소 혹은 엔드포인트와 연결되어 있는 레코드라 볼 수 있고
soa - 도메인에 대한 메타데이터가 들어있는 레코드라 생각

여기에서 NS유형의 값을 가비아에 있는 name server로 바꿔줘야 한다!
근데 왜 url이 4개나 있냐?? 하나의 서버가 불량이 되면 다른 서버가 바로 대체될 수 있게 만든 갓 aws 두둔!

그 다음 가비아에 있는 네임서버 설정을 다 Route 53에 있는 url로 바꿔주면 끝!

여기서 복붙할때 url 마지막에 .이 있는데 꼭 지워서 적용시킬 것!!!

이렇게 원하는대로 세팅이 되면서 이제 가비아에서 세팅해야할 일은 전부 끝!!

이제부터는 ns 즉 네임서버에서 도메인을 관리할 수 있는 권한이 생긴거라 생각하면 된다

그리고 Route 53에서 설정한 레코드 이름에 접근했을때 엔드포인트 S3에 넘겨줄 수 있게만 해주면 진짜 끝!!

다시 Route 53으로 넘어와서 레코드 생성을 누르면 레코드 유형에 A가 있는데

A레코드는 ip주소와 맵핑되는 레코드라 생각하면 되는데,
도메인에 접근을 하면 ip주소로 리다이렉트 시킬 수 있는 그런 역할을 하고 있다 보면 된다.

즉, Route 53의 도메인에 접근하면 S3엔드포인트의 ip주소로 리다이렉트 시켜주는 기능!!

여기서 ip주소가 아니라 AWS 리소스로 트래픽 라우팅을 시킨다고 나와있는데,

S3 엔드포인트는 AWS 리소스이기 때문에 그렇다.

여기서 A는 Alias 레코드라고 AWS 내부에서만 존재하는 레코드인 점 참고할 것(Alias A 레코드)

그 다음 별칭(Alias)을 활성화 시킨 후
S3에 라우팅 대상을 설정하고
버킷 위치는 동일하게 서울로 세팅 후,
S3 엔드포인트 입력에 자동으로 하나가 뜨는데, 이건 AWS에서 자체적으로 버킷 이름과 도메인 이름이 같아서 자동으로 인식을 해서 찾아주는것임

여기서 booker-aws.store에 접근 시 s3 엔드포인트로 라우팅하는데 최초엔 시간이 좀 걸릴 수 있다(약 5분이내?)

5분 뒤 시도하면 잘 될 예정(잘 되었으나 스샷이 너무 많아서 스샷은 생략)

도메인 적용은 끝~~~!!

이젠 SSL 인증서를 받을 차례!!

ACM(amazon certificate manager)에서 받아야함
대신 꼭!!

ACM 리전을 버지니아 북부로 변경해놔야함!!!

그래야 클라우드 프론트에서 인증서에 연결이 가능하다고 하다..

일단 aws에서 certificate manager 클릭하고!

무조건 버지니아 북부로 바꾼 후 인증서 요청 ㄱㄱ

그다음 도메인 이름 제대로 잘 넣고 요청 ㄱㄱ

그러면 정상적으로 인증서는 받았으나 내 인증서가 맞는지 검증 대기중이여서 검증을 해야한다
인증서 id 클릭!

그러면 Route 53에서 레코드 생성을 누르면 몇단계 지나면 인증을 할 수 있음

그 후 정확한 체크를 위해 Route 53으로 다시 가보자

그러면 Cname이라고 하는 레코드 이름이 생성되있고 저 cname이 트레픽 라우팅 대상 값에 있는 cname으로
리다이렉트가 잘 되었다 즉 검증이 되었다는 의미(2분정도 소요)

그러면 짜잔~ 상태 발급됨으로 변경!!

이제 인증서 발급은 끝!!!

Cloud Front 배포 설정(CDN 서버 배포)

일단 AWS에 cloud front 검색해서 배포 생성 클릭하기!

이걸 하게 되면 기존에는 client에서 s3로 직접 요청을 했었다면
중간에 CDN서버 즉 cloudfront 설정을 하면
client에서 cdn을 거쳐 s3로 요청을 그리고 응답도 반대로 하게 된다

여기서 중요한 점은 뷰어 프로토콜 정책을 Redirect HTTP to HTTPS로 설정하는 것인데
이렇게 하게되면 모든 http에 대한 요청을 https프로토콜 요청으로 리다이렉트하게 된다(이걸 위해 우린 달려왔다!)

캐시는 추천하는 권장사항으로 그대로!!

방화벽은 비활성화해서 진행

모든 엣지 로케이션에서 사용으로 설정해서 어느 나라에서든 접속 가능하도록 설정

그리고 꼭 대체 도메인 이름을 우리의 도메인 이름을 넣어놔야
A 레코드에서 S3가 아닌 Route 53을 통해 CDN 서버를 사용하게 된다
(정말 복잡하다 처음하는 입장에서는ㅠㅠ)
이거 좀 더 정확히 설명하면 Route53에 A(Alias) 레코드 추가 시 엔드포이트 인식에 필요하다고 보면 된다.

그리고 기존에 세팅해놨던 SSL 인증서도 여기서 넣을 수 있다!!
(특히 버지니아 북부 리전이 아니면 안됨!!!)

기본 값 루트 객체는 index.html 기입

즉 클라우드프론트 배포생성햇고
기본값 루트 객체 설정했고~
SSL인증서 선택했고~
대체 도메인 똑같이 설정했고~
이제 해야할 일은 사용자 베포 오류 설정을 해야한다.

오류 페이지에서 생성을 할 수 가 있는데,

예를 들어 abc.com/123이라고 사용자가 검색을 하면
없는 주소기 때문에 404 Not Found가 떠야하는데
SPA배포여서 없는 리소스에 대해서 그냥 index.html로 응답을 강제로 주겠다는 그런 오류 응답에 대한 생성이다
200은 정상적으로 확인했다는 의미

그러면 정확히 CDN서버 만들었고 S3 서버를 바라보게 세팅해놨고,
이제는 client가 요청 시 바로 S3로 요청하는 과정을
CDN을 거쳐서 응답받도록 하는 절차를 밟아야 한다

이 설정은 Route53에서 S3엔드포인트 라우팅했었던 기존A레코드를 삭제 후
CloudFront URL로 라우팅하는 신규 A레코드를 생성하면 된다!!

기존 레코드 삭제 후~

트래픽 라우팅을 CloudFront 배포에 대한 별칭으로 세팅 후
그 아래 검색이 되는 이유는 우리가 바로 직전 CloudFront에서 대체 도메인 설정을 해놨기 때문에 검색이 된다
생각하면 된다

결국 사용자는 booker-aws.store에 접속 요청을 하지만 우린 aws에 있는 Route53의 A레코드를 통해
대체 도메인인 d2어쩌구 즉 cloudfront url로 접속을 하게 된다
아까 말했던 client요청에 CDN이 요청에 응답을 받는 구조!

짠~~ https프로토콜로 접속을 하게된 모습~~!

이제 해킹 위험 없이 로그인 회원가입 등 개인정보를 기입해도 되는 상태!

최종 정리하자면

client가 Route53을 통해 도메인ip주소 요청하면 S3엔드포인트가 아닌 CloudFront(CDN)에 대한 url을 보내주고
CloudFront는 S3엔드포인트에 응답을 해서 요청 받은 그 주소를 가리키므로 완벽히 원하는 목적 달성!!
이제 다양한 client가 웹사이트 요청해도 CDN이 캐싱된 데이터를 보내줘서 빠르게 사이트 접속이 가능함~!