Amplify Cache & Cold Start 성능 개선

Amplify is so slow

Aug 27, 2024

Contents

Amplify와 그 한계 SSR Application이란?EC2, EB를 사용한 배포 방식 서버리스에 대한 설명 Amplify란?Amplify의 성능 문제 Amplify 캐시 문제 캐시 우선순위 기본 관리형 캐시 정책 브라우저에서 캐시 헤더 확인 특이사항 Amplify Cold Start 문제 Cold Start란?Route53 Health Check란?참고 자료

Amplify와 그 한계

SSR Application이란?
EC2, EB를 사용한 배포 방식
서버리스에 대한 설명
Amplify란?
Amplify 성능 문제

SSR Application이란?

SSR*은 이름 그대로 서버 기능을 할 컴퓨팅 리소스가 필요합니다.
즉 SSR 방식의 Next.js는 CloudFront + S3를 선택할 수 없습니다.

SSR* : Server Side Application

EC2, EB를 사용한 배포 방식

컴퓨팅이 필요한 경우 일반적으로 EC2*, EB* 등을 사용할 수 있습니다.
또한 부하 분산을 위해서 ELB(ALB)*을 추가로 사용해야 합니다.

EC2* : Elastic Compute Cloud
EB* : Elastic Beanstalk

이 경우 다음과 최소 20~24$ 정도의 비용이 발생합니다. — [Ref]

EC2 (t3.nano) 1개를 이용해서 배포
Resource
Instance Type
Per Hour($)
Per Month($)
EC2
t3.nano
0.0052
3.8064
ELB(ALB)
-
0.0225
16.47
SUM
0.2302
20.2764
EC2 (t3.micro) 1개를 이용해서 배포
Resource
Instance Type
Per Hour($)
Per Month($)
EC2
t3.micro
0.0104
7.6128
ELB(ALB)
-
0.0225
16.47
SUM
0.2302
24.0828

Resource	Instance Type	Per Hour($)	Per Month($)
EC2	t3.nano	0.0052	3.8064
ELB(ALB)	-	0.0225	16.47
SUM	0.2302	20.2764

Resource	Instance Type	Per Hour($)	Per Month($)
EC2	t3.micro	0.0104	7.6128
ELB(ALB)	-	0.0225	16.47
SUM	0.2302	24.0828

하지만 SLO*에 따라서 제품 및 배포를 위해 다음의 기능들이 필요합니다.

SLO에 맞게 적정 수의 AZs에 EC2 배포
CI/CD Pipeline 구축

SLO* : Service Level Objective

최소 가용영역이 2개, 3개로 늘어남에 따라서 비용은 60~72$의 비용이 발생합니다.

서버리스에 대한 설명

SSR Application의 특성상 서버가 필요합니다.
하지만 비용, 가용성, 확장성, CI/CD 등의 구성을 모두 하는 것이 어려울 수 있습니다.
따라서 Lambda, Amplify 등을 활용해서 이 부분을 개선할 수 있습니다.

Amplify란?

Amplify는 여러 SSR*, SPA*, SSG*를 배포 가능한 서버리스 웹 앱 서비스입니다.
GitHub 등과 연동, 빌드 설정, 빌드 알림, 사용자 지정 도메인, 환경 변수, 모니터링 등의 기능을 지원합니다.

SSR* : Server Side Rendering로서 Next.js, Nuxt 등을 배포 가능
SPA* : Single Page Application로서 React, Angular 등을 배포 가능
SSG* : Static Site Generators로서 Gatsby, Hugo 등을 배포 가능

이 서비스를 사용하면 CI/CD, 캐시, 호스팅 등을 손쉽게 사용할 수 있습니다.

Amplify의 성능 문제

Amplify는 호스팅을 위해 CloudFront, Edge Lambda를 사용합니다.
따라서 아래와 같은 이유로 성능 상의 문제가 발생할 수 있습니다.

CloudFront 캐시 문제
Edge Lambda의 Cold Start 문제 발생

Amplify 캐시 문제

Amplify는 캐시를 관리하기 위해 Platform Type 및 Rewrite Rule을 참조합니다.
일반적으로 SSG*은 WEB으로 SSR*은 WEB_COMPUTE의 타입을 따라갑니다.

캐시 우선순위
기본 관리형 캐시 정책
브라우저에서 캐시 헤더 확인
특이사항

캐시 우선순위

Amplify는 다음의 캐시 우선순위에 따라서 캐시가 처리됩니다.

SSR Framework에 있는 설정파일(next.config.js) 등에 있는 Cache-Control
customHeaders.yaml 파일에 적혀있는 Cache-Control
Amplify 기본 Cache-Control

기본 관리형 캐시 정책

기본 Cache-Control은 각 유형의 콘텐츠 별로 지정된 관리형 캐시 정책를 적용합니다.

Static : Amplify-StaticContent
Image Optimization : Amplify-ImageOptimization
Compute : Amplify-DefaultNoCookies
Reservse-Proxy : Amplify-DefaultNoCookies

브라우저에서 캐시 헤더 확인

실제로 브라우저에서 헤더를 확인해보면 아래와 같은 값이 보입니다.

Cache-Control: max-age=0

여기에 적혀 있는 Cache-Control max-age 만큼 CDN에서 응답을 캐싱합니다.

특이사항

추가적으로 아래와 같은 특이사항이 존재합니다.

CI/CD 앱 배포 시, 캐시가 지워집니다.
Cache-Control의 s-maxage를 통해 앱의 성능 모드를 활성화할 수 있습니다.

이 값은 Amplify Console에서 사용자 지정 헤더 및 캐시에서 수정하거나
코드 저장소에 customHttp.yml 파일을 작성하는 것으로 이를 해결 할 수 있습니다.

AWS Amplify Console

AWS customHttp.yml

# See: https://docs.aws.amazon.com/amplify/latest/userguide/custom-headers.html#setting-custom-headers
applications:
  - appRoot: docs
    customHeaders:
      - pattern: '**/*'
        headers:
          - key: 'Strict-Transport-Security'
            value: 'max-age=31536000; includeSubDomains'
          - key: 'X-Frame-Options'
            value: 'SAMEORIGIN'
          - key: 'X-XSS-Protection'
            value: '1; mode=block'
          - key: 'X-Content-Type-Options'
            value: 'nosniff'
          # CSP set in _document.page.tsx meta tag
          - key: 'Cache-Control'
            value: 'public, max-age=300'