NextJS 를 AWS EC2, ECS 및 EKS를 사용하여 운영할 때 서버 비용도 줄일 수 있고 성능도 개선할 수 있는 방법을 알려 드립니다.
Next JS 의 자원 제공
NextJS 를 빌드를 하게 되면 아래와 같은 이미지를 볼 수 있습니다.
$ npm run build주의 깊게 봐야 할 것 들은 Server 폴더와 Static 폴더 입니다.
- Server 폴더는
서버사이드 렌더링을 통해 생성되는 HTML 파일 즉, 동적으로 생성되는 파일 및 NextJS 가 서버로서 역할을 할 때 쓰이는 리소스가 있는 폴더 입니다. - Static 폴더는 빌드시 생성되고, 그 후 변경되지 않는 리소스가 있는 폴더 입니다. 가장 큰 예로
JS, CSS, 웹폰트등이 있습니다. 또한, SSG(Static Site Generation) 로 생성된 HTML 파일도 포함 될 수 있습니다.
이 리소스들은, 유저가 요청을 할때, NextJS 가 구동되는 서버 (EC2, ECS Task, EKS Pod 등) 에서 트래픽을 일으키며 유저에게 제공을 해줍니다.
하지만, 자주 변경되지 않는 정적 파일의 경우 유저의 매 요청에 서버에서 응답을 주면 트래픽 낭비가 될 수 있습니다.
이럴 때 가장 간단한 방법은 CDN(Content Delivery Network) 을 이용해 정적파일을 제공 하는 것입니다.
요청 데이터를 캐싱 서버에 저장 합니다. 그 후, 동일한 요청이 오면 오리진 서버가 아닌 캐싱 서버가 응답을 보냅니다.
CDN (CloudFront) 장점
1. 성능
정적파일을 더 적은 용량으로 유저 에게 제공하여 비용 절감 및 컨텐츠를 보여주는 성능 개선의 효과를 줄 수 있습니다.
2. 가까운 서버에서 리소스 제공
전세계에 있는 CDN 서버를 이용하여, 지리적으로 사용자와 가까운 CDN 서버에 원본 리소스가 저장되며 컴퓨터에 훨씬 빨리 제공 할 수 있도록 도와줍니다.
3. 대역폭 비용 절감
캐싱 및 기타 최적화를 통해 CDN은 오리진 서버가 제공해야 하는 데이터의 양을 줄여 웹 사이트 소유자의 호스팅 비용을 절감할 수 있습니다.
물론 CloudFront 를 사용하면, Cloudfront 의 설정 및 캐시 에 따른 복잡도가 생길 수 있으나, 얻는 장점에 비해 단점은 미비하다고 생각 합니다.
실습
정적 폴더 확인하고 S3에 업로드 하기
앞서 빌드 에 따라 위와 같은 이미지를 볼 수 있음 을 확인 하였습니다. 이 파일 중 static 폴더를 S3에 업로드 해줍니다.
- S3 버킷 생성 및 폴더 및 파일 업로드 방법은 생략 하겠습니다.
S3 버킷에 _next 폴더를 만들어 그 안에 static 폴더를 업로드 하였습니다.
그 이유는 next 에서 static 안에 있는 파일을 요청 하는 경우 ~/_next/static/* 의 경로로 요청 하기 때문입니다.
Cloudfront 에서 요청받은 경로와 동일한 위치에 있는 파일을 원본으로 하여 캐싱 될 수 있도록 함
Cloudfront 설정하기
방금 만든 S3 버킷 을 원본으로 하는 Cloudfront 배포를 생성 합니다. 그 후 각 상황에 맞게 설정 후
배포 ID 클릭 > 동작 탭 > 동작 생성 으로 들어가 경로 패턴에 /_next/static/* 을 넣어 줍니다.
원본 및 원본 그룹으로는 방금 생성한 S3 버킷을 원본으로 설정 해줍니다.
NextJS 설정 하기
NextJS 의 config 파일인 next.config.mjs 폴더에 들어가서 생성 하였던 CloudFront 의 배포 도메인 이름을 넣어 줍니다.
NextJS 캐시 동작 확인 하기
개발자 탭을 켜서 네트워크를 확인 해보면, Cloudfront 로 부터 Cache가 Hit 했음을 확인 할 수 있었습니다.
그럼 얼마나 비용적 으로 이득 일까요?
Cloudfront 를 이용 했을때 비용적 이득
먼저, Cloudfront 를 통해 응답된 네트워크 용량은 40KB 정도 되었습니다.
하루에 10,000건의 요청이 들어온다고 했을 때 한이면 에 30만건의 요청이 들어옵니다.
즉, 120GB 가 한달에 요청/응답 되는 트래픽 용량 입니다.
| EC2 | Cloudfront | |
|---|---|---|
| Internet Traffic GB | 120GB | 120GB |
| Internet Traffic Cost | 0.126(1GB) * 120GB = $15.12 | $0 (Free tier) |
| HTTP/HTTPS Request | - | 300000건 ( $0 - Free tier) |
EC2 등 AWS 컴퓨팅 서비스를 이용하여 정적 자원을 제공 했을 때 보다, Cloudfront 를 이용하면 널널한 Free Tier 덕분에 무료로 트래픽을 제공 할 수 있습니다. (월 1TB 까지 무료)
물론 Free Tier 제공량 을 넘어선 트래픽 비용도 EC2등이 제공하는 인터넷으로의 트래픽 비용보다 저렴 합니다.
또한, Cloudfront 를 통한 파일 제공은 Cloudfront의 압축 알고리즘 덕분에 대략 3~4% 정도의 용량을 더 압축 하기 때문에 용량 감소에 따른 비용 및 성능의 이점을 볼 수 있다는 장점이 있습니다.
바로 전 글 에서 작성한 Noting 서비스는 이러한 방법으로 호스팅 하였습니다.
이유는 1인 개발의 사이드 프로젝트 이기 때문에 비용 절감이 첫번째 이유이고, 그다음으론 Lambda URL + Cloudfront 호스팅 방식을 이용해 서비스를 구성 하였기 때문에 그대로 Cloudfront 에 S3원본과 해당 원본으로 정적 파일로 가도록 동작만 수정 하면 되기 때문에 서비스 복잡도가 떨어지지 않았기 때문 입니다.
Noting 에 대해 관심이 있으신 분은 아래 링크를 통해 확인 해보시면 좋을 것 같습니다 :)
