AWS ) 정적 웹 사이트 배포 방식 비교 ( nginx / cloudFront / amplify )

앞서 AWS 배포 과정을 포스팅하면서 EC2 + WebServer를 활용하여 실습을 해보았는데요.

그 외에도 웹사이트를 배포하는 방법에는 여러가지 방법들이 있어서 한번 비교해보려고 합니다.

 

1. AWS - EC2 + WebServer(Nginx) 를 활용한 배포

2. AWS - CloudFront + S3를 활용한 배포

3. AWS - Amplify를 활용한 배포

 

1. EC2 + WebServer ( Nginx ) 를 활용한 배포

- AWS EC2 인스턴스 위에 Nginx 웹서버를 이용하여 서버 호스팅을 진행하는 방법. EC2는 하나의 작은 가상의 서버이고, Nginx는 OS위에 웹 서비스를 띄우기 위한 웹 서버. EC2와 Nginx를 이용해서 간단하게 정적인 사이트를 배포할 수 있다.

 

장점 

1) Nginx는 대용량 트래픽을 처리하기 위해 가벼움과 높은 성능을 목표로 하는 경량 웹서버입니다. 따라서 안정적인 성능으로 정적 파일 호스팅의 역할을 수행합니다.

2) Nginx를 이용하여 배포하면 Nginx 환경을 직접 구성할 수 있기 떄문에 정적 웹사이트 호스팅 뿐만 아니라 Nginx의 다른 기능을 활용하여 백엔드 서비스, Proxy 환경, 동적인 페이지 구축 등 여러 서비스들을 편의에 맞게 활용이 가능합니다. 

3) 하나의 웹루트를 통해 여러 Demo들을 관리할 수 있기 떄문에 관리가 용이합니다. 

- 예를 들어, example.com 이라는 도메인을 소유하였을 때 https://example.com/demo1 , https://example.com/demo2 와 같이 2개의 웹페이지를 배포할 수 있습니다.

 

 

단점 

1) 관리를 위해 nginx.conf 문법 및 리눅스 기반 터미널 명령을 숙지하여야 함. 즉 웹서버를 관리하는 서비스 관리자가 필요하다.

2) 실제 EC2서버가 있는 리전이 아닌 전 세계에 지역이 있는 클라이언트가 EC2 서버로 정적인 페이지를 요청할 때 latency( 응답시간 )가 더 오래 걸릴 수 있습니다. 이유는 클라이언트와 서버 간의 물리적인 거리 떄문 !

3) 라우터를 사용하는 SPA앱을 이용할 때 추가적인 설정이 필요하다. 예를 들어 React를 사용할 때 react-router-dom이라는 라이브러리의  BrowserRouter를 통해 Router를 사용하게 됩니다. 여기서 BrowserRouter는 Single Page인 React 페이지에 경로를 주기 위해서 사용이 됩니다. 

 

- BrowserRouter는 URL 주소가 바뀔 때 이를 바탕으로 컴포넌트를 렌더링 해주는 기능을 하는데, 실제로 페이지를 불러오는게 아니라 React 앱의 경로를 읽기 위해서 React 내부적으로 사용됩니다. 이 때문에 웹 브라우저에서 경로를 바꾼 뒤 브라우저 새로고침을 누르게 되면 404에러가 발생하는데, 이는 BrowserRouter가 동작하기 전에 해당 경로로 웹 리소스 요청이 일어나는데 이에 대한 404에러 발생. 

-> 실제로 어떤 리소스가 존재하는 경로가 아닌 리액트 내부의 경로이기 때문 ! 

 

- 이와 같은 문제를 해결하기 위해서는 Nginx로 들어오는 모든 웹 request의 경로를 실제 리액트 SPA앱의 index.html로 치환시켜주는 try-files 라는 옵션이 필요 !

 

 

2. CloudFront + S3 를 활용한 배포

- S3는 AWS에서 제공하는 스토리지 서비스. 안정적인 내구성, 가용성 및 확장성을 가지기 떄문에 많은 기업들이 클라우드 파일서버로 서비스를 구축하는데 사용하고 있다. 또 S3만을 이용하여 정적 웹사이트를 구축하는 기능도 가지고 있다. 

 

1) 내구성 ? 장애가 발생했을 때 빠른 시간 내로 복구할 수 있는 능력. 예를 들어 어떤 서비스의 장애가 발생하였을 때 얼마나 빨리 해당 서비스의 장애를 고치고 서비스를 지속할 수 있는지가 좋은 내구성을 판단하는 기준.

 

2) 가용성 ? 장애가 발생했을 떄 서비스를 지속할 수 있는 능력. 내구성이랑 다른 점은 장애복구가 아니라 장애가 복구되기 전에 서비스가 장애로 인해 중단되지 않도록 대처할 수 있도록 구성을 하는 것이 높은 가용성의 기준입니다. 높은 가용성을 가진 서비스들을 보통 장애가 생기게 될 떄를 대비해 대응책을 만들어놔서 장애발생 시 다른 쪽으로 우회하여 서비스를 지속시킴. 

 

3) 확장성 ? 쉽고 빠르게 규모를 늘릴 수 있는 능력. 트래픽이나 유저 접속이 많아져서 서버가 부담이 되는 경우 서버를 스케일업하거나 스케일 아웃 해야함. 이 때 해당 서버가 받는 높은 부하를 분산할 수 있도록 얼마나 빠르게 탄력적으로 서버의 스케일링을 해줄 수 있는지가 높은 확장성의 기준.

 

=> S3는 이와 같은 높은 내구성, 가용성, 확장성을 기반으로 스토리지 서비스를 제공하는데, 스토리지 서비스 뿐만 아니라 정적 웹 사이트를 손쉽게 구성하도록 도와주는 기능도 가지고 있다. 

 

CloudFront ?

- 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 CDN서비스. CDN서비스란 Content Delivery Network 의 약자로 지리,물리적으로 떨어져 있는 사용자에게 콘텐츠를 더 빠르게 제공할 수 있도록 도와주는 서비스. 

 

- CloudFront를 이용하며 사용자가 가까운 곳에 캐시서버가 위치하고, 사용자가 콘텐츠를 요청 시 가까운 곳에 있는 캐시서버가 응답해주는데 이러한 AWS의 CloudFront의 캐시서버를 보통 엣지 로케이션이라고 함.

 

CloudFront + S3 

- 같이 이용하면 정적 웹사이트를 여러 나라에 빠르고 쉽게 배포할 수 있음. S3를 통해서 배포하는 기능도 있지만, S3만을 이용해서는 도메인을 연결하거나 SSL을 이용한 https 사이트를 구축할 수 없음. 이때, S3를 리소스의 원본으로 두고 CloudFront 서버와 연동하고 정적 웹사이트를 배포하면 CloudFront 서버가 해당 홈페이지 자원들을 원하는 지역의 엣지 로케이션으로 배포하여 클라이언트들에게 빠른 웹 호스팅 서비스를 제공할 수 있습니다. 

 

장점 ! 

1) CDN 서비스 이기 때문에 여러 나라에서 서비스를 할 때 안정적인 속도를 보장.

2) AWS 콘솔에서 S3업로드, 엣지 로케이션의 캐시 무효화, 요청에 대한 리다렉션 처리 등의 작업을 간편하게 진행할 수 있다.

3) CloudFront를 이용하여 Route53 도메인 연결 및 SSL 인증서 연결을 등록할 수 있다. 

4) 서버를 직접 임대하는 것이 아니기 때문에 서버 운용 비용이 부과되지 않고, 실제 엣지와 클라이언트 사이에 발생한 트래픽 만큼만 요금이 부과된다. 각각의 Edge별로 트래픽 요금이 상이하다. 예를 들면 한국 Edge에서는 GB당 0.12$, 미국은 0.085$이다.

5) 트래픽 요금에 대한 과금은 EC2와 유사하다. EC2도 어느 리전에 있는지에 따라 트래픽 요금이 달라짐.

6) S3의 특징으로 항상 고가용성 및 내구성을 보장 한다.

 

단점 !

1) 초기 구축 시 S3와 CloudFront 설정에 대해 상세히 알아야한다. SSL 연결을 위해 ACM 및 Route53에 대해서도 이해해야한다. 

2) React와 같은 SPA 사이트 구축시에 403, 404 리다이렉트 등의 추가 설정이 필요하다. 하나의 리액트 앱을 위해 CloudFront + S3 구성이 각각 개별적으로 필요하다.

3) Nginx + EC2 배포 처럼 여러 정적인 웹사이트들을 호스팅 할 수는 있다. 하지만, S3의 정적 웹사이트 호스팅은 버킷의 가장 사위에 있는 index.html 만을 바라보기 때문에 S3버킷의 서브 디렉터리에서 index.html을 생략할 수 없는 문제가 생김.

 

 

3. Amplify를 이용한 배포

- Amplify는 CI/CD 워크플로를 통해 정적 웹 애플리케이션의 글로벌 배포 및 호스팅을 지원하는 서비스. Amplify 콘솔에서 애플리케이션 리포지토리를 연결하고 커밋할 때마다 자동으로 배포할 수 있도록 도와준다. 내부적으로 CloudFront+ S3로 구성되어 있다.  => 빌드 완료시 자동 배포.

 

장점 ?

1) 깃헙 연결 + 클릭만으로 쉽게 정적 웹사이트 호스팅이 가능하다. 

2) Amplify를 통해 정적 사이트를 배포하면 Amplify는 내부적으로 S3+ CloudFront 배포를 사용. 직접 구축할 필요가 없음. 

3) Amplify에서 제공하는 모니터링 기능을 적극 활용하여 서비스를 관리하기 용이. 호스팅 서비스 별로 모니터링이 가능.

4) 빌드 시간 + 데이터 트래픽 송수신 비용 + 저장공간 사용량에 대한 비용만 청구되기 때문에 EC2서버를 운용할 때 처럼 계속 과금이 되는 것이 아니라 사용한 만큼만 과금되기 때문에 잘 구축하면 비용 절감면에서 효율적. 

5) 깃헙 푸시가 일어날 때마다 auto-deploy 와 같은 기능을 통해 자동으로 배포가 일어나도록 설정할 수 있다.

 

단점 ? 

1) S3 규칙, CloudFront 규칙을 상세하게 커스터마이징 해야할 때는 Amplify로 불가능. 

2) 트래픽 요금이 30프로 더 비쌈. 

3) 빌드 시간당 요금 발생, 빌드 시간이 오래걸리는 프로젝트라면 과금이 많이 될 수 있음.