Github Actions, S3, CloudFront OAC로 CICD 전략 구축하기 (1) - S3에 CloudFront 끼얹기

들어가며

네이버 부스트캠프의 그룹프로젝트 과정에서 진행했던 AlgoITNi의 배포전략, 선택한 이유, 방법들을 기록해두고자 한다.

 

프론트엔드에서 배포는 어떻게 이뤄지는가?

프론트엔드의 배포는 결국 html,css,js 정적파일을 서빙하면 끝이다. (SSR 제외)

좀더 세부적인 동작은 이전에 작성한 아래의 게시글을 참고해주면 좋을 것 같다.

https://0422.tistory.com/312

프론트엔드 웹서버 직접 만들기 (1) - Content-Type, MIME

 

정적파일을 어떻게 제공하지?

정적파일을 제공하는 건 결국 웹서버가 필요하다.

 

이건 사실 github의 웹호스팅을 사용해도되고, netlify를 사용하는등...

방법은 많고, 더 간단하게 배포할 수 있는 방법도 매우매우 많다.

 

하지만, 이번 프로젝트를 진행하면서 프론트엔드의 배포, 그리고 CDN을 어떤식으로 연결하는지 큰 그림을 이해해보고싶었다. 

 

S3 vs NCP Object Storage

부스트캠프에서 NCP크레딧을 지원해줬기때문에 처음에는 사실 NCP Object Storage를 사용해서 배포하려고 했고, 사실 이미 한번 파이프라인을 구축하기도 했다.

하지만,,,, NCP Object Storage는 커스텀 도메인설정이 불가능하다는 것을 알 수 있었다.

https://romcanrom.tistory.com/208

그래서 S3와 CloudFront를 사용해서 CICD를 구성하였다.

 

CloudFront, S3

그런데 S3로만 배포하는게 아니라 왜 CloudFront를 추가했을까?

그러려면 CloudFront에 대해 알아봐야한다.

 

CloudFront란

Cloud Front는 AWS에서 제공하는 CDN서비스이다.

캐싱을 통해 사용자에게 좀 더 빠른 속도로 컨텐츠를 제공하는 것을 목표로한다.

CloudFront는 전세계 이곳 저곳에 Edge서버를 두고, 클라이언트에게서 가장 가까운 Edge서버를 찾아 빠르게 컨텐츠를 제공한다.

1. Origin Server : 원본을 가진 서버이다. 우리의 경우 원본 서버는 S3이다.
2. Edge Server(Location) : AWS에서 실질적으로 제공하는 전세계에 퍼져있는 서버다. Edge Server에는 요청 데이터에 대해 빠르게 응답하기위해 Cache기능을 제공한다.

즉, S3원본에 대한 캐시를 미리 Edge Server에 떠놓아서 빠르게 접속할 수 있는 것이다.

그림을 그려보면 아래와 같은 구조가 된다.

그래서 뭐가 좋은데요?

파일 서버 자체가 물리적으로 사용자와 가까이에 위치하기때문에 사용자는 더 빠르게 접속할 수 있다.

관련자료를 찾아보니 아래와 같은 자료를 찾을 수 있었다.

https://dev.classmethod.jp/articles/how-fast-is-cloudfront-speed-test/

같은 서울리전이라도 10%가량 더 빠른 것을 확인할 수 있다.

 

CloudFont를 적용시킨 데이터 전송과정

위 구조 그림의 데이터 흐름을 글로 적어보면 아래와 같다.

1. 클라이언트로부터 Edge서버로 요청이 발생한다.
2. Edge서버는 요청 데이터의 캐싱 여부를 확인한다.
3. 사용자 근거리에 있는 Edge서버 중 캐싱 데이터가 존재한다면 사용자의 요청에 맞는 데이터를 응답한다.
4. 사용자의 요청에 적합한 데이터가 캐싱되어있지않다면 Origin 서버로 요청이 포워딩된다.
5. 요청 데이터를 Origin에서 획득한 후에 Edge서버에 캐싱 데이터를 생성하고, 클라이언트에게 응답을 준다.

 

오 그럼 S3에는 직접 접속안하는거네요?

그렇다 사용자는 cloudfront를 통해서만 접속하므로 더이상 s3에 접근하지 않아도 된다.

그래서 OAC(Origin Access Control)을 적용시켜서 접근할 수 없게 만들 것이다.

OAC를 적용하면 S3는 Cloudfront를 통해서만 접근할 수 있게된다.

이제 직접 CI/CD를 구성해보자.