-
Notifications
You must be signed in to change notification settings - Fork 5
프론트엔드 리소스 빌드 및 배포 환경 구축
jinyoung edited this page Oct 8, 2024
·
1 revision
CloudFront + S3
- EC2 + Nginx
- S3 + CloudFront
두가지 선택지가 있었고, S3 + CloudFront 방식으로 배포하는 것을 선택했다.
-
높은 러닝 커브
- 팀원 대부분이 팀 프로젝트가 처음인데, 프론트엔드 지식을 넘어서 인프라까지 신경 쓰기엔 너무 벅차다고 판단했다.
-
근거
- S3와 CloudFront는 자동으로 확장(AWS에서 관리하여 사용량이 증가하면 자동으로 용량을 늘려준다!)되므로, 트래픽 증가에 따른 별도의 서버 확장 작업이 필요 없다.
- CloudFront를 통해 HTTPS를 쉽게 설정할 수 있다.
-
근거
- 팀원 대부분이 팀 프로젝트가 처음인데, 프론트엔드 지식을 넘어서 인프라까지 신경 쓰기엔 너무 벅차다고 판단했다.
-
위험성
- EC2에 프론트엔드 리소스를 올리는 과정에서 EC2 인스턴스가 뻗어버린다면 서버도 같이 뻗어버리기 때문에 서비스가 운영되지 못할 위험성이 존재한다고 생각했다.
-
비용 효율적인 프론트엔드 호스팅 방식
- 백엔드의 경우 빌드 파일을 서버 컴퓨터에 올라와 있어야 하지만, 프론트엔드 리소스의 경우 정적 컨텐츠이기 때문에 EC2로 올리는 것이 불필요하며 이런 서비스에 최적화된 S3 + CloudFront가 적절하다고 생각했다.
-
글로벌 확장성
- 우리 서비스의 경우 여행 서비스인 만큼 전 세계 어디서도 여행 계획 및 여행기를 빠르게 확인할 수 있어야 한다.
- CloudFront는 전 세계 수많은 네트워크를 통해 콘텐츠 서비스를 제공(엣지 로케이션)하기 때문에 누구나 빠른 속도로 우리 서비스를 이용할 수 있기 때문이다.
- 우리 서비스의 경우 여행 서비스인 만큼 전 세계 어디서도 여행 계획 및 여행기를 빠르게 확인할 수 있어야 한다.
- 유저가 CloudFront에 접근하면 요청이 가까운 엣지 로케이션으로 라우팅
- CloudFront의 요청된 파일의 캐시 사본이 있다면 CloudFront에서 빠르게 응답해 사본을 사용자에게 전송
- 아직 캐싱되어 있지 않다면 S3 버킷 같은 오리진 서버에서 파일을 가져와 사용자에게 제공