AWS : 정적 사이트 배포 하는 4가지 방법 (feat: cloudfront / nginx /amplify / netlify)

웹사이트를 배포하는 방법에는 여러 가지 방법들이 있는 것 같습니다.

 

저도 회사를 다니면서 다양한 방법들로 웹사이트를 배포해 보았는데요,

 

오늘은 AWS, 및 여러 도구들을 활용하여 정적사이트를 배포하는 방법들과 각각의 장단점에 대해서 한번 정리해 보았습니다.

 

목차

1. AWS - EC2 + WebServer(Nginx) 를 활용한 배포
2. AWS - CloudFront + S3를 활용한 배포
3. AWS - Amplify를 활용한 배포
4. Netlify를 활용한 배포

 

위에서 설명드린 배포방법 4가지에 대해서 개념 및 장단점에 대해 설명드리겠습니다.

 

 

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

 

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

 

장점

 

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

 

Nginx를 이용하여 배포하면 Nginx 환경을 직접 구성할 수 있기 때문에 정적 웹사이트 호스팅뿐 아니라 Nginx의 다른 기능을 활용하여 백엔드 서비스, Proxy환경, 동적인 페이지 구축 등 여러 서비스들을 편의에 맞게 활용이 가능합니다. 또 하나의 웹루트를 통해 여러 Demo들을 관리할 수 있기 때문에 관리가 용이합니다. 예를 들어 example.com이라는 도메인을 소유하였을 때 아래와 같이 2개의 웹페이지를 배포할 수 있습니다.

• https://example.com/demo1
• https://example.com/demo2

 

단점

 

Nginx 배포의 단점으로는 관리를 위해 nginx.conf 문법 및 리눅스 기반 터미널 명령을 숙지하여야 합니다.. 즉 웹서버를 관리하는 서비스 관리자가 필요하다는 점이 있습니다.

 

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

 

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

 

BrowserRouter는 URL 주소가 바뀔 때 이를 바탕으로 컴포넌트를 렌더링 해주는 기능을 하는데 실제로 페이지를 불러오는 것이 아니라 React 앱의 경로를 읽기 위해서 React 내부적으로 사용됩니다. 이 때문에 웹브라우저에서 경로를 바꾼 뒤 브라우저 새로고침을 누르게 되면 404 에러가 발생하는데 이는 BrowserRouter가 동작하기 전에 해당 경로로 웹 리소스 요청이 일어나는데 이에 대한 404 에러가 발생하는 것입니다. (실제로 어떤 Resource가 존재하는 경로가 아닌 React 내부의 경로이기 때문) 이와 같은 문제를 해결하기 위해서는, Nginx로  들어오는 모든 웹 request의 경로를 실제 React SPA앱의 index.html로 치환시켜 주는 try-files라는 옵션이 필요합니다.
=> (한 개의 React 앱 배포)

 

React로 되어있는 여러 개의 SPA 앱들을 Nginx로 배포하기 위해서는 nginx.conf에 대한 추가 설정뿐 아니라 react-router-dom 쪽 소스코드 변경이 필요하며 물론 이에 대한 해결법도 존재합니다. 하지만 앱이 늘어날 때마다 Nginx 설정파일과 소스코드를 각각 변경해줘야 하기 때문에 오히려 유지보수포인트가 늘어날 수도 있습니다. 해당 이슈를 해결하는 부분은 추후에 다른 포스트 글로 방법에 대해 정리해 보도록 하겠습니다.

=> (여러 개의 React 앱 배포)

 

 

CloudFront + S3를 활용한 배포

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

 

S3의 여러 장점 중 내구성, 가용성, 확장성에 대해 한번 간단하게 알아보도록 하겠습니다.

 

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

 

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

 

확장성이란 쉽고 빠르게 규모를 늘릴 수 있는 능력을 의미합니다. 예를 들어 트래픽이나 유저접속이 많아져서 서버가 부담이 되는 경우 서버를 scale up 하거나 scale out을 하여야 하는데요, 이때 해당 서버가 받는 높은 부하를 분산할 수 있도록 얼마나 빠르게 탄력적으로 서버의 scaling을 해줄 수 있는지가 높은 확장성의 기준입니다. 

 

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

 

 

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

 

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

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

 

 

 

이번에는 장점 및 단점에 대해 알아보겠습니다.

 

장점

1. CDN 서비스이기 때문에 여러 나라에서 서비스를 할 때 안정적인 속도를 보장합니다.
2. AWS Console에서 S3 업로드, 엣지 로케이션의 캐시 무효화(Cache Invaildation), 요청에 대한 Redirection 처리 등을 작업을 간편하게 진행할 수 있습니다. 
3. CloudFront를 이용하여 Route53 도메인 연결 및 SSL 인증서 연결을 등록할 수 있습니다.
4. 서버를 직접 임대하는 것이 아니기 때문에 서버 운용 비용이 부과되지 않고, 실제 Edge와 Client 사이에 발생한 Traffic 만큼만 요금이 부과됩니다. 알아두셔야 할 점은 각각의 Edge별로 트래픽 요금이 상이하다는 점입니다. 예를 들면 한국 Edge에서는 GB당 0.12$, 미국은 0.085$입니다.
5. 트래픽 요금에 대한 과금은 EC2와 유사합니다. EC2도 어느 region에 있는지에 따라 트래픽 요금이 달라지는데요, 한국 region에서는 EC2 트래픽 요금이 GB당 현재 0.126$입니다. 하지만 트래픽을 많이 쓰게 될 경우 트래픽에 대해 CloudFront에서는 Saving Bunlde을 제공해 주는데 이를 이용하면 요금을 30% 이상 줄일 수 있습니다.
6. S3의 특징으로 항상 고가용성 및 내구성을 보장합니다. (99.999%)

단점

1. 초기 구축 시에 S3쪽과 CloudFront 설정에 대해 상세히 알아야 한다는 단점이 있습니다. 또 SSL 연결을 위해 ACM(Amazon Certification Manager) 및 Route53 에 대해서도 어느정도 이해해야 하기때문에 러닝커브가 존재합니다.
2. React와 같은 SPA 사이트 구축시에 403,404 redirect 등의 추가 설정이 필요하며, 하나의 React 앱을 위해 CloudFront + S3 구성이 각각 개별적으로 필요하기 때문에 관리할 CloudFront와 S3들이 늘어나게 됩니다. 
   1. 여러 React 앱을 하나의 S3 및 CloudFront로 관리하기 위해서는 AWS의 서비스 중 Lambda@Edge 서비스를 이용하여 들어오는 경로에 따라 CloudFront를 제어해야 합니다. 아래 링크를 참고하시면 도움이 되실 수도 있지만, 너무 설정이 복잡해서 저는 성공하지는 못했습니다.  (Host React Apps using S3 & CloudFront)
      
3. Nginx + Ec2 배포처럼 여러 정적인 웹사이트들을 호스팅 할 수는 있습니다. 하지만, S3의 정적 웹사이트 호스팅은 버킷의 가장 상위에 있는 index.html만을 바라보기 때문에 S3 버킷의 서브 디렉터리에서 index.html을 생략할 수 없는 문제가 생깁니다.
   1. https://example.com이라는 웹사이트를 CloudFront + S3로 배포했다고 생각해 보겠습니다. 브라우저에서 https://example.com을 검색하면  뒤의 주소에 index.html이라고 따로 명시하지 않아도 잘 동작하는 것을 알 수 있습니다. 그 이유는 S3에서 index.html을 생략해도 정적 웹사이트 호스팅을 제공하기 때문입니다.
   2. 하지만 서브 디렉터리에 배포한 웹사이트는 index.html을 생략하면 사이트가 동작하지 않습니다. 예를 들어 S3 버킷에서 myapp이라는 폴더를 만들고 https://example.com/myapp으로 배포를 하고 싶다고 했을 때 https://example.com/myapp 은 올바르게 동작하지 않습니다. 실제 해당 myapp 폴더 안의 index.html 파일까지 주소상에 명시해 주어야 웹사이트가 올바르게 동작합니다. 즉 실제로 동작하기 위해서는 https://example.com/myapp/index.html까지 명시해주어야 합니다.

 

 

Amplify를 이용한 배포

 

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

 

Amplify는 CI/CD를 제공하는 AWS 서비스라고 설명드렸는데요, 그렇다면 CI/CD 가 무엇을 의미하는지도 한번 알아보도록 하겠습니다.

 

CI / CD란?

• CI
  • Continuous Integration의 약자입니다. (지속적 통합)
  • 개발을 하면서 코드에 대한 통합을 지속적으로 진행하며 코드를 유지 및 관리해나가는 과정을 의미합니다.
  • CI 없이, 만약에 개발자 10명이 프로젝트를 진행하는데 각자 개발 후 한 번에 통합하게 된다면 Merge를 할 때 많은 Conflict이 발생하게 될 수도 있고 이는 개발속도를 늦추고 산출물의 퀄리티를 낮추게 됩니다.
  • CI를 간단히 표현하면 하면 빌드 테스트 자동화 과정을 의미하는데요 아래와 같은 과정을 의미합니다.
    • CI를 적용하지 않은 상황
      1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.
      2. 통합된 코드에서 본인의 코드가 제대로 동작하는지 테스트한다.
      3. 통합된 코드가 제대로 빌드되는지 테스트한다.
      4. 결과를 정리하고. 버그가 있다면 다음날 업무 목록에 적어둔다.
    • CI를 적용한 상황
      1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.
      2. 다음날 출근 시 메일로 발송된 결과 리포트를 확인하고 버그가 있으면 수정한다.
    • 즉 CI 적용 후 협업 시 개발한 기능들에 대해 빠른 통합과 테스트가 이루어질 수 있습니다.

• CD
  • Continuous Deploy의 약자입니다. (지속적 배포)
  • 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리하자는 개념입니다.
  • 쉽게 말하면 CI의 연장선상이라고 보면 되는데요, 즉 CI 프로세스를 통해 개발 중에도 지속적으로 배포와 테스트를 진행하고 이를 통과한 코드에 대해 테스트서버와 운영서버에 곧바로 해당 내용을 배포해서 반영하는 것을 의미합니다.

 

Amplify를 이용하면 이러한 CI/CD 배포를 쉽게 구성할 수 있습니다. 

 

 

다음으로 Amplify의 장단점에 대해 설명드리겠습니다.

 

장점

• Github 연결과 유저 친화적인 CI/CD 워크플로 구성으로 클릭만으로 쉽게 정적 웹사이트 호스팅이 가능합니다.
• Amplify를 통해 정적사이트를 배포하면 Amplify는 내부적으로 S3 + CloudFront 배포를 사용한다. S3 + CloudFront를 직접 구축할 필요가 없기 때문에 배포환경 구성에 신경 쓸 필요 없이 프로덕트 개발에 집중할 수 있습니다.
• Amplify에서 제공하는 모니터링 기능을 적극 활용하여 서비스를 관리하기 용이합니다. S3 + CloudFront를 직접 구축하게 되면 관리 지점이 많아지지만 해당 부분은 Amplify를 이용하면 세세한 부분까지 신경 쓸 필요 없이 호스팅 서비스별로 모니터링이 가능해집니다.
• 빌드 시간 + 데이터 트래픽 송수신 비용 + 저장공간 사용량에 대한 비용만 청구되기 때문에 EC2 서버를 운용할 때처럼 계속 과금이 되는 것이 아니라 사용한 만큼만 과금되기 때문에 잘 구축하면 비용 절감면에서 효율적입니다.
• Github push가 일어날 때마다 auto-deploy와 같은 기능을 통해 자동으로 배포가 일어나도록 설정할 수 있습니다.

단점

• S3 규칙, CloudFront규칙을 상세하게 Customizing 해야 할 때는 Amplify로는 불가능합니다. 즉 디테일한 설정까지 컨트롤할 수는 없습니다. 예를 들어 CloudFront의 redirection 규칙이나, 배포 후 Cache invalidation(캐시 초기화)와 같은 작업까지는 Amplify에서 설정할 수 없습니다.
• CloudFront를 사용할 때보다 보다 트래픽 요금이 30% 정도 더 비쌉니다. CloudFront는 각 엣지 로케이션에서 전송된 Traffic별로 GB 당 차별된 요금을 부과합니다. 예를 들어 서울의 Edge에서는 0.120$ 일본에서는 0.114$가 트래픽 요금으로 부과됩니다. 하지만  Amplify를 이용할 때는 GB당 일관된 요금을 지불하여야 한다. (GB당 0.15$)
• Amplify는 빌드 시간당 요금이 발생하므로, Build 시간이 오래 걸리는 프로젝트인 경우 과금이 많이 될 수 있습니다.
  

 

 

Netlify를 이용한 배포

 

✏️ Github 등과 연결하여 CI/CD 워크플로를 통해 정적서버로 쉽게 호스팅을 가능하게 해주는 서비스입니다. ⇒ 사용법 실제로 배포를 진행하게 되면 https://프로젝트명. netlify.app/ 과 같은 형태로 독자적인 도메인을 통해 앱이 만들어지게 됩니다.. 웹사이트상에서 배포를 진행하거나 아래와 같은 Cli도 제공하기 때문에 Terminal 명령어로도 쉽게 배포가 가능합니다.

 

사용법 예제

npm i -g netlify-cli
netlify swicth # 프로젝트 전환
netlify deploy --prod # 현재 위치에서 프로젝트 배포 => 링크 생성

 

위와 같이 npm 패키지를 통해 간단하게 netlify를 설치하고 간단하게 프로젝트를 netlify.app 하위 도메인으로 배포할 수 있습니다. 보다 자세한 내용은 netlify 공식문서를 참고하시면 됩니다.

Welcome to Netlify

 

 

 

장점

• Github등과 연결하여 쉽게 클릭 몇 번만으로 정적인 웹사이트 호스팅이 가능합니다.
• CI / CD 파이프라인 구성이 간편합니다.
• 홈페이지가 직관적이고 유저 친화적이기 때문에 배포한 프로젝트들을 한눈에 파악하고 관리할 수 있습니다.
• 문서화가 잘 되어있고 cli를 이용하여 쉽게 정적 웹사이트 배포가 가능합니다.
• Firebase나 Lambda와 같은 서비스들도 쉽게 연결이 가능합니다. 또 자체적으로 제공하는 Netlify functions과 같은 기능을 통해 슬랙봇과 같은 내부 도구등도 쉽게 만들 수 있습니다.
• 100GB 트래픽을 무료로 제공한다. (이후 100GB당 55$, 1GB당 0.55$)

 

단점

• 계정당 총 500개 웹사이트 배포까지 가능합니다.
• Netlify는 한 달에 빌드할 수 있는 최대시간을 제한하기 때문에 무료로 사용할 때 해당 부분 때문에 break가 걸리게 된다.
  (Netlify와 비슷한 서비스인 Vercel은 하루에 빌드할 수 있는 최대 개수를 제한합니다)
• 동아시아 (대한민국, 일본) 기준으로 네트워크 전송 속도가 떨어집니다. 그 이유는 Edge Location의 수가 AWS, Vercel, Cloudflare Pages 등과 같은 타사 서비스에 비해 지원이 부족하기 때문인데요, 참고로 한국과 가장 가까운 Netlify 호스팅 서버는 일본에 있기 때문에 약간의 지연시간이 발생할 수 있습니다.
• 빌드시간이 타사 서비스에 비해 오래 걸립니다.

 

 

 

마무리

 

오늘은 제가 지금까지 경험했던 정적 웹사이트 배포 방법에 대해 알아보았습니다. 

 

각각의 방법의 장단점을 잘 파악해서 현재 자신의 환경에 가장 적합한 방법으로 정적 웹사이트를 배포해 보셨으면 좋겠습니다.

 

다음으로는 위에서 한번 언급한 것처럼, nginx 설정을 통해 여러 SPA 앱들을 하나의 nginx 웹서버에 배포하는 방법에 대해 알아보도록 하겠습니다.

 

감사합니다.