S3 와 CloudFront를 이용해 정적 웹사이트 배포하기

안녕하세요. 휴몬랩 개발자 진(JIN) 입니다.

휴몬랩은 AWS를 적극 활용해 serverless하게 서비스를 운영해오고 있습니다. api들과 함께 flowcoding 웹도 EC2를 생성해서 배포하고 있었는데,  이번에 랜딩페이지를 수정하면서 비용적인 S3와 CloudFront를 이용해 SPA(Single Page Application)인 저희 플로우코딩 웹을 배포한 경험을 공유하려고 합니다.

 

우선, EC2와 S3의 차이점을 좀 알아보면 좋겠습니다.

 

EC2

 EC2가 클라우드에서 제공해주는 가상의 컴퓨터라고 할 수 있습니다. 컴퓨터라서 사용자가 용도에 맞게 다양한 선택지를 aws에서 제공해주고 있습니다. 딥 러닝 학습을 위한 EC2라면 GPU 성능이 좋은 딥 러닝용 인스턴스를 선택해야 합니다 (물론, 시간당 더 비싼 요금이 들어가겠죠ㅎㅎ..) 

 클라우드를 기반으로 서버에 access 하는 서비스로 이런 EC2 서비스를 통해 서버용 컴퓨터를 사고, OS를 설치하고 세팅하고 운영하는데 드는 비용을 줄일 수 있다는 점에서 많은 스타트업에서 AWS나 GCP(Google Cloud Platform) 같은 클라우드 서비스를 많이 사용하고 있습니다.

 

EC2의 장점

 - 필요한 시점에 많은 서버를 구축하려고 한다면 금방 준비가 가능합니다. 

 - 특정 OS / 개발 언어 / 프레임워크에 종속적이지 않습니다.

 - 다양한 성능의 인스턴스를 선택적으로 사용할 수 있습니다. ( CPU / 코어 / RAM / 디스크 공간)

 

S3 

 S3는 AWS에서 제공하는 스토리지 서비스입니다. EC2와는 다른 성격의 서비스입니다. 사용자는 거의 모든 유형의 데이터(우리가 올릴 HTML/CSS/JS는 물론 이미지, 멀티미디어까지도)를 클라우드에 저장하고 AWS CLI 또는 AWS API를 통해 스토리지를 관리합니다.

 S3에는 "버킷"이라는 것을 생성해야 사용할 수 있는데, 이 버킷에 데이터를 저장하고 검색하는 데 사용하는 객체입니다.

S3의 장점

 - 저렴하고 

 - 무제한 용량에 

 - 빠르고 안전하게 데이터를 저장할 수 있습니다.

 

EC2와 S3는 근본적으로 다른 유형의 서비스입니다. 

EC2는 최소한의 노력으로 클라우드에서 서버를 실행하고 있게 하고, S3는 AWS에서 제공해주는 여러 스토리지 서비스 중 하나입니다(하드 드라이브 같은).

따라서 기존에 EC2에 SPA를 그대로 올리는 건 비용적인 면이나 사용 측면에서 과할 수 있다고 생각했습니다! S3를 웹서버처럼 안전하고 더 저렴하게 사용해보려고 했습니다.

 

CloudFront 

 클라우드 프론트는 웹사이트를 글로벌 엣지(edge) 서버 네트워크에서 호스팅해 유저가 웹 사이트를 더 빠르게 로드하게 지원하는 CDN입니다. 일종의 프록시 서버입니다.

(예를 들면, 서울에 컨텐츠 서버가 있습니다. 미국에서 이 컨텐츠를 이용하려면 1만KM를 이동해 컨텐츠를 배포해야 합니다. 그런데, AWS에서 배치한 엣지를 통해 해당 캐시에 요청된 파일들이 있다면 전송하고 없다면 오리진에서 블러와 캐시에 저장하고 보냅니다. 그렇다면 다음에 인근에서 요청되면 캐시에서 빠르게 데이터를 전송할 수 있습니다.)

 

---

배포해보기

CRA(create-react-app)을 이용해 만든 앱이 있다면 보통  buildbuild 하는 과정을 거쳐 배포를 하게 됩니다.

저희는 기존의 flowcoding을 빌드한  후 빌드가 완료된 프로젝트를 S3 스토리지에 올려보겠습니다

 

1. IAM 은 사용자 access 및 암호화 키 관리를 해주는데  IAM에서 계정 생성 후 권한을 줘야 합니다..

(기존 사용자에서  권한 설정해도 가능)

AWS에서  IAM을 검색하고  왼편의 사용자를 검색해 사용자 추가

버튼을 클릭하거나 기존 IAM을 만들어 놨다면 그 계정을 들어갑니다.

 

 

2. 사용자 이름을 추가하고 액세스 유형에 ‘프로그래밍 방식 액세스’를 체크합니다.

 

3. '기존 정책 직접 연결'에서 정책을 추가해줘야 하는데 

AmazonS3FullAccess

CloudFrontFullAccess

AWSCertificateManagerFullAccess를 추가해 사용권한을 부여합니다.

(마지막은 https 환경으로 배포하기 위해 저희가 구매한 도메인에서 SSL 인증서를 AWS CertificateManager를 이용해 받았습니다! 우선 도메인이 없다면 넘어가 주세요!)

 

다음으로 넘어가 사용자 만들기를 누르면 액세스 키가 만들어지고. csv 다운로드합니다. 분실하면 안 되니까 꼭! 안전한 곳에 저장해주세요!!!

 

4. AWS CLI설치

AWS CLI를 설치해봅시다. 이 AWS CLI를 이용해 CLI환경에서 AWS를 처리할 수 있게됩니다있게 됩니다. (Git Bash환경에서도)

https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html

 

5. 유저 추가

Aws cli 설치 후 cli (저는 git bash)를 통해 유저를 추가해줍니다.

 $ aws configure –profile project-deploy-s3 

AWS Access Key ID [None]: .csv참조해서 입력
AWS Secret Access Key[None] : .csv참조해서 입력
Default region name[None]: ap-northeast-2 처럼 각 리전의 이름
Default output format [None] : json

 6. S3설정

Aws 검색으로 S3 관리 페이지로 이동해봅시다.

[+버킷 만들기]를버킷을 생성합니다. 버킷 이름은 유일한 key

입니다.  고유한 이름이니 보통 서비스명을 넣어주거나 합니다.

 쭉쭉 다음을 눌러 ‘버킷 만들기’를 눌러 생성해줍니다. (기존에 만들어 놓은 버킷 이름을 치니 이미 버킷이 있다고 뜹니다.)

 

7. S3에 읽기 전용 권한 부여

 S3 버킷을 만들었으면 사용자들이 들어와 파일을 조회하려면 권한을 설정해줘야 합니다.

버킷을 클릭해 ‘권한’ – ‘버킷 정책’을 클릭하고 정책을 추가해줍니다.

저장 후  ‘이 버킷에 퍼블릭 액세스 권한이 있음’ 이란 경고가 뜨는 데 정상적으로 잘 된 것입니다!

 

[버킷 정책 참고]

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/example-bucket-policies.html

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/example-bucket-policies.html

 

 위의 코드 내용을 아래 버킷 정책에 입력해줍니다.

 

8. 배포해봅시다

이전에 설치한 AWS CLI를 이용해서 배포하려고 합니다.

그냥 올리기보다 빌드를 통해 더 압축한 파일을 올리는 게 더 용량도 줄이고 읽는 속도도 더 빠를 것 같습니다! 해서./build파일들을 올리는데 fc-web-deploy버킷에  project-deploy-s3란 IAM을 만들었는데 사용자가  올린다고 보시면 좋겠습니다. 

 

CLI 환경에서 작업하면 S3버킷에 직접 업로드하는 것보다 훨씬 편하고  프로젝트에 script로 추가해서 변경된다면 빌드 – 배포로 바로 이어서 할 수 있습니다.

 

9. CloudFront 설정하기

 

CloudFront를 사용하는 이유

- HTTP접근이  HTTPS로 리다이렉트

- CDN을 이용해 전 세계의 사용자에게 더 가까운

      edge로 캐싱되어 사용자는 더 빠르게 페이지에

     응답받을 수 있다

 

 CloudFront  검색.

 ‘Create Distribution’ 클릭 후 Web/RTMP 가 나오면 Web의 ‘Get Started’를 눌러준다.

 

다음으로 넘어가  Origin Domain Name를 클릭하면 우리가 만든 S3 버킷의 호스팅 주소가 보이는 데, 그 이름을 누르고

Viewer Protocol Policy는 Redirected HTTP to HTTPS로 리다이렉트 시켜준다. (인증서 구매를 했다면! 안 했다면 패스해줍니다!)

그리고 ‘Create Distribution’을 누르면 In Progress라고 뜨고 10분 넘게 걸리면 deployed 라 뜨면 생성이되는 것을 확인할 수 있습니다.

 

Domain Name에 *.cloudfront.net*. cloudfront.net으로 생성된 주소가 CDN이 적용된 주소입니다.

 

10.  도메인 구입한 경우

 도메인을 구입했다면  CloudFront CloudFront의 Cname으로  .cloudfront.netCname으로. cloudfront.net 이 아닌 고유 도메인으로 지정할 수 있습니다.

Alternate Domain Names(CNAMEs)에  구매한 도메인 입력.

 

또한, 사용자 도메인을 사용하기 위해 Custom SSL Certificate를 선택하고 도메인의 Certificate를 선택합니다

구매한 도메인의  SSL Certificate가 없다면 신규 증명서 발급

‘Request or Import a Certificate with ACM’에서 발급 처리! (인증되는데 시간이 꽤 걸렸습니다)

 

 

11. Route53과 CloudFront 연결

DNS 관리의레코드 세트들이 나옵니다.

 

‘레코드 세트 생성’을 클릭 후   CloudFront의 CNAME에 입력했던 도메인을 Name에 입력합니다.

Alias Target을 클릭하면 앞에서 생성한 CloudFront가 있으니 클릭 후 Create로 생성해줍니다.

저희는 기존에 flowcoding.org도메인에 A유형으로 만들어진 것이 있어서 Alias Target만 Cloud Front로 연결했습니다!

 

 

* Route 53은 AWS에서 제공해주는 확장성 좋은 클라우드 DNS 웹서비스입니다.  

 

AWS가 좋은 SaaS(Software as a Service)이라 간단하게 EC2 만 이용해봤었는데, 이렇게 다른 제품들과 차이점을 알아보니 많은 제품들이 있었습니다. 또 자신의 서비스에 알맞은 제품을 선별해서 비용 / 성능 등을 비교해서 선택하는 게 불필요한 낭비를 줄일 수 있을 것 같습니다! 역시 많은 공부가 필요해 보입니다:)