[AWS 입문] AWS CLI 에서 S3 + CloudFront 로 Vue.js 웹페이지 배포하기

AWS CLI에서 Vue.js 웹사이트를 S3 + CloudFront로 배포하는 방법을 소개합니다.
2020.08.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요! 클래스메소드 신입 엔지니어 정하은입니다?

지난 블로그에서 언급했듯이 DevIO Korea 블로그 사이트 프로젝트를 재개하고자 블로그에도 기록을 남겨가고자 하는데요. 이 프로젝트에 대한 내용은 아직 완전히 공개해드릴 수는 없지만, 웹프로젝트를 진행하고 있다는 사실만 이해해주시면 감사드려요!

AWS에 입문하시는 분들을 위해 S3와 CloudFront를 사용하는 이유와 함께 AWS CLI로 배포하는 방법 대해 차례대로 진행해보도록 할게요~

S3 + CloudFront로 배포하는 이유

먼저 Amazon S3에 대해 간단히 설명드리면, 버킷이라고 하는 공간에 정적 콘텐츠를 저장하여 인터넷을 통해 접근할 수 있도록 할 수 있는 서비스인데요.

S3에서 웹사이트를 호스팅 했을 때의 이점은 아래와 같이 요약할 수 있습니다.

  • 버킷이 자동으로 확대되고 축소되기 때문에, 스토리지 저장 공간을 미리 계산할 필요가 없음
  • 서버를 따로 설치하지 않기 때문에, 서버 관리에 대한 걱정도 필요 없음
  • 동적인 앱 구현을 위해 서버를 사용하게 되더라도, 서버가 정적 콘텐츠 요청 처리를 하지 않아도 되기 때문에 비용 부담을 덜 수 있음

위와 같은 이유때문에 S3는 정적 웹페이지 뿐만 아니라 이미지, 동영상과 같은 콘텐츠를 저장하는 스토리지로 최적화 되어 있답니다.

그런데 Amazon S3에 대해서는 이해가 가지만 돌연 의문점이 떠오릅니다.

S3만 있어도 인터넷에서 웹사이트 접속이 가능한데, CloudFront라는 서비스는 왜 같이 사용하나요?

아래와 같은 상황을 가정해봅시다.

위 상황 자체는 좀 과장이 포함되어 있지만, 실제로 S3 버킷은 선택한 리전 내에만 생성되기 때문에 해당 리전에서 멀어질수록 접속 속도가 느려지게 되는데요. 또한, 동시 접속수가 많아질수록 느려진다는 것은 피해갈 수 없는 사실입니다. 그렇기 때문에 이 문제를 해결하기 위해 Amazon CloudFront 라는 서비스를 S3와 함께 사용하게 된답니다.

즉, Amazon CloudFront란 전 세계의 정적/동적 웹 콘텐츠, 비디오 스트림 및 API를 안전하게 대규모로 전송할 수 있는 콘텐츠 전송 네트워크 서비스라고 할 수 있어요.

CloudFront는 전 세계에 분포된 엣지 로케이션이라고 하는 데이터 센터의 엣지 서버를 사용해 콘텐츠를 캐싱하고, 사용자가 위치한 곳에서 가장 가까운 엣지 로케이션에서 콘텐츠를 제공받을 수 있도록 해주는 역할을 합니다. 또 호스팅을 HTTPS로 하게 할 수도 있는 점에서 보안적인 부분도 향상시킬 수 있답니다.

시작하기에 앞서

본격적으로 작업을 시작하기 전에 제 실행 환경에 대해서 간단히 남겨두겠습니다!

  • macOS
  • AWS CLI v2 설치
  • AWS CLI 계정 설정을 마침
  • homebrew, npm, yarn이 설치되어 있음
  • Vue.js 프로젝트 생성을 마침

Vue.js 빌드하기

우선 개발된 Vue.js 웹페이지 배포를 하기 위해서는 빌드를 할 필요가 있습니다. 터미널에 yarn build 을 입력하여 빌드를 해주세요.

성공하시면 위와 같이 결과가 나오며, 프로젝트 폴더에 dist 라는 폴더가 새로 생긴 것을 확인하실 수 있습니다. 저희는 이 dist 폴더를 S3 버킷에 업로드하게 된답니다.

Amazon S3에 업로드하기

S3 버킷 생성 + 정책 설정하기

그럼 먼저 Vue.js 정적 웹페이지를 배포하기 위한 버킷을 새로 생성해보도록 할게요. 아래의 명령어를 입력해주세요.

aws s3 mb s3://버킷명 --region 리전명

버킷명은 다른 버킷과 이름이 중복되서는 안 되기 때문에 다른 사람들이 사용하지 않을만한 이름으로 지어주세요. --region 리전명 부분은 프로파일 설정에서 이미 리전 설정을 하신 경우면 생략하셔도 무관합니다.

버킷 생성이 되시면 설정을 추가 해야합니다. vi policy.json 이라고 입력해서 아래의 내용을 추가해주세요. (참고로, policy라는 이름은 제가 임의로 정한 것이기 때문에 다른 이름을 사용하셔도 괜찮아요!)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow", 
      "Principal": "*", 
      "Action": "s3:GetObject", 
      "Resource": "arn:aws:s3:::버킷명/*" 
    } 
  ] 
}

위의 policy.json은 외부에서 S3 버킷에 접근할 수 있도록 도와주는 역할을 한답니다.

저장을 마치시면 아래의 명령어를 입력하여 S3에 json의 내용을 반영시켜주세요.

aws s3api put-pocket-policy --bucket 버킷명 --policy policy.json

반영이 되면 S3 콘솔에서 해당 버킷의 Permissions 아래에 Public이라고 쓰인 노란색 타원이 생긴 것을 확인할 수 있답니다.

S3 버킷에 파일 업로드하기

이제 S3 버킷 접근 설정을 마쳤으니 S3 버킷에 웹사이트를 업로드 해봅시다. 아래의 명령어를 입력하시면 dist 폴더 안에 있는 파일들이 차례로 업로드 되는 것을 확인할 수 있습니다.

aws s3 sync ./dist s3://버킷명

S3 콘솔에서도 파일이 업로드 된 것을 확인할 수 있답니다.

정적 웹 호스팅 설정하기

마지막으로 S3에 업로드한 웹사이트에 접근하기 위해 호스팅 설정을 해주어야합니다. 아래의 명령어를 터미널에 입력해주세요.

aws s3 website s3://버킷명/ --index-document index.html

S3 콘솔에서 확인하시면 정적 호스팅 설정이 된 것을 확인할 수 있습니다.

호스팅 설정이 끝난 후, 엔드포인트 주소를 브라우저에 입력하시면 웹사이트에 제대로 접속되는 것을 확인할 수 있답니다! 엔드포인트 주소는 아래와 같은 형식으로 입력해주세요.

http://버킷명.s3-website-리전명.amazonaws.com

S3 콘솔의 정적 호스팅 설정 안의 엔드포인트를 클릭하셔도 동일하게 접속 가능하니 편한 방법을 사용해주세요?

실제로 잘 접속 되는 것을 확인할 수 있네요!

Amazon CloudFront로 배포하기

S3 버킷에 웹사이트 업로드를 마쳤으니, 이제 Amazon CloudFront로 웹사이트 배포를 해봅시다! 아래의 명령어를 입력해서 CloudFront 배포 작업을 생성할게요.

aws cloudfront create-distribution --origin-domain-name 버킷명.s3.amazonaws.com --default-root-object index.html

입력하시면, 관련 정보가 출력됩니다. 각 설정 사항에 대한 자세한 내용은 공식 문서를 참고해주세요.

(원래는 사용 목적에 맞춰 세부적으로 설정을 해줄 필요가 있지만, 이번에는 기본 설정으로 생성해주었어요.)

CloudFront 콘솔로 가시면 생성이 진행중일텐데, 5분 정도 기다리시면 아래와 같이 생성이 완료된 것을 확인할 수 있답니다.

 

중간에 Domain name 이라고 하는 게 나올텐데요. 지금은 아직 도메인명 변경이 불가능하기 때문에 이대로 복사해서 브라우저로 이동해볼게요.

AWS CLI에도 처음에 생성하셨을 때 나오는 정보 안에 도메인명이 나와 있으니, 편하신 방법을 사용해주세요.

S3 엔드포인트 주소로 접속할 때와 마찬가지로 웹사이트에 잘 접속 되는 걸 확인할 수 있습니다!

비교해보기

그럼 처음에 이야기했던 것처럼 S3 엔드포인트로 접속했을 때와 CloudFront 도메인으로 접속했을 때 시간 차가 어느 정도 되는지 확인해보도록 합시다!

먼저 S3 엔드포인트로 접속했을 때, 600ms 가까이 걸린 것을 확인할 수 있습니다.

그리고 CloudFront 도메인으로 접속했을 때는 150ms 조금 넘는 정도로 확연히 줄어든 것을 확인할 수 있네요!

(여러번 새로고침해서 확인해 본 결과, S3 엔드포인트에 직접적으로 접근할 때보다 CloudFront 도메인에 접속했을 때 평균적으로 더 적은 시간이 걸렸어요.)

사실 밀리초 단위이면 체감상 큰 차이는 없지만, 콘텐츠가 많아진다면 밀리초 단위가 아닌 초 단위까지 차이가 벌어질 수 있습니다. 그렇기 때문에 접속량이 많아지거나 전세계의 사용자로부터 접속이 예상되는 경우 CloudFront를 사용하는 것이 더 효율적이 겠죠?

덤으로 아래쪽을 보면, 서버가 Amazon S3인 것과 CloudFront에서 캐싱을 동작시키는 것을 확인할 수 있어요.

마무리하며

자격증 공부를 했을 때 Amazon S3 + Amazon CloudFront 조합에서 궁금했던 부분이 CloudFront에 배포를 설정했을 때 빨라지는가였는데요. 실제로 비교를 해보면서 꽤나 차이가 있다는 사실에 놀랐습니다!

평소에는 Management Console을 주로 사용했기 때문에 커맨드를 찾는데 어려움도 있었지만, 명령어 한 줄로 반영이 되는 것도 쾌감이 있었어요ㅎㅎ

AWS 입문자 분들 뿐만아니라 지금까지 Management Console만 사용하셨던 분들도 이번 기회에 AWS CLI 사용해보시길 바라며,

이번 글도 읽어주셔서 감사합니다!

참고사이트

실전 AWS S3와 CloudFront로 정적 파일 배포하기

AWS CLI Command Reference