S3와 CloudFront란?

• 정적 콘텐츠를 대규모로 저장, 보호, 전송할 수 있는 조합
• 먼저 S3(Simple Storage Service)로 콘텐츠를 보안성 높고 확장 가능한 방법으로 저장

S3 장점

• 파일을 “버킷(Bucket)”에 무제한으로 저장하고 가져올 수 있음
• 손쉽게 확장 가능
  • 버킷이 자동으로 확장 및 축소되기 때문에 스토리지 공간을 계획하여 특정 크기를 할당할 필요가 없음
• 비용 저렴
• 서버리스(Serverless) 서비스
  • 파일이 저장되는 서버를 관리할 필요 없이 콘텐츠 저장 및 요청만 하면 됨

CloudFront

• 전 세계의 정적/동적 웹 콘텐츠, 비디오 스트림 및 API를 안전하게 대규모로 전송할 수 있는 CDN(Contents Delivery Network) 서비스
• 설계상 S3에서 직접 사용자에게 전송하는 것보다 더욱 비용 절감 + 보안적으로 안전
• 엣지 서버를 사용해 사용자와 더 가까운 곳에 위치하고 콘텐츠를 캐싱하여 성능이 향상

비교

S3(Origin 서버)에서 직접 가져올 때 (검은색 화살표)

CloudFront를 활용할 때

사용자가 콘텐츠를 가져오는 거리가 훨씬 짧아짐 (작은 녹색 화살표)

• 요청이 가까운 엣지 로케이션으로 라우팅됨
• CloudFront에 캐시 사본이 있으면 빠르게 사용자에게 전송
• 요청한 파일이 캐싱되어 있지 않으면 CloudFront가 S3 버킷 같은 Origin 서버에서 파일을 가져오고 해당 파일을 캐싱

동적 콘텐츠여서 콘텐츠 캐싱이 불필요하더라도 전송 거리 자체가 가깝기 때문에 CloudFront를 사용하는 것이 더 이득이다.

그 밖에 AWS global private 네트워크를 이용해 worldwide 네트워크 문제를 피해서 보안적으로도 더 우수하다.

배포 중 마주한 문제

배포는 투더문 님 블로그를 참고하여 진행했다.

처음에는 배포된 URL에 들어가니 AccessDenied가 떴다.

알고보니 S3에 빌드 내용을 업로드할 때 '폴더'만 올리고 '파일'을 안 올려서였다.
CloudFront가 index.html 파일을 찾지 못함

파일을 마저 올려주고 다시 배포했는데 이후에는 네트워크 탭에서 문제를 발견했다.

바로 앞에 테스트 삼아 S3를 해보느라고 S3에 올린 폰트 파일 경로가 그대로 남아 있었던 것이었다. 여기 블로그를 읽으며 다시 재배포했다.

글에서 처음에 빌드 파일을 교체해주는 부분과 '무효화' 탭 부분만 참고했는데 읽다보니 '무효화 기능 = 캐시 삭제'라는 걸 알게 되었다.

그래서 '신규 복사' 버튼 클릭 + '/*' 경로를 다시 넣어주고 등록했더니 재배포에 성공했다.

여기까지는 수동으로 일일이 재배포했는데 앞으로도 반복할 걸 생각하니 너무 귀찮아졌다. (S3에 올렸던 파일을 모두 지우고 다시 업로드한 다음... 등등)

CI/CD의 필요성을 절실하게 느껴서 Github Actions를 적용해보기로 했다.

(다음 글 👉 Github Actions를 활용한 CI/CD 구축기)