Vercel의 배포 방식과 느릴 수밖에 없는 이유

Vercel 프로세스

※  일부 Vercel 내부에서 사용되는 기술적 세부사항은 추측으로, 이해하기 쉽도록 예시를 드는 것으로 한다.

배포 프로세스

1. 배포 트리거

2. 프로젝트의 코드와 파일 업로드

프로젝트의 코드와 파일이 데이터 저장소(Amazon S3와 같은)에 POST 요청으로 업로드된다.

3. 검증 및 권한 부여

Vercel의 내부 API에 의해 POST 요청으로 vercel.json, 유저 권한 등에 대한 검증이 이루어지고 성공 시 배포 권한이 주어진다.
4. 배포 대기열 추가

배포가 준비되었다는 메세지를 배포 대기열(Amazon SQS 추측)에 추가한다.

※ Amazon SQS (Amazon Simple Queue Service)
MSA나 분산 서비스에 자주 사용되는 큐 방식의 대기열 데이터 구조로 클라우드에 있고, API를 사용한다.

5. 빌드 컨테이너 실행

대기열에서 제거되면 빌드 컨테이너 (AWS Fargate에서 관리하는 AWS EC2 서버)가 실행된다.

※  AWS Fargate
필요에 따라 동적으로 EC2 인스턴스를 시작하도록 설계된 서비스.
요청에 따라 수요에 충족하는 데 필요한 인스턴스를 자동 시작하며, 인스턴스가 필요없어지면 인스턴스를 종료하거나 필요에 따라 규모를 축소하기도 한다.

6. 빌더 스크립트 설치

빌드 컨테이너의 빌드 단계에서 배포되는 프레임워크에 따른 '빌더' 스크립트를 설치한다. (35개 이상의 프런트엔드 프레임워크를 자동으로 감지)

7. 빌드 출력 생성

빌드 출력 API를 통해 프로젝트를 Vercel 배포로 변환하는 작업을 시작한다.

8. 배포 과정

1) 데이터 저장소에 업로드 된 코드를 가져와 배포로 변환한다. (프로젝트를 빌드하고 자바스크립트, CSS, 폰트, 정적 페이지 등을 다른 데이터 저장소(S3)에 업로드 후 저장)

2) 이미지 최적화

3) 서버리스 함수 생성 (AWS Lambda와 같은 것 이용)

4) 미들웨어에서 사용하는 엣지 함수(Edge Function) 배포 (Vercel 자체 인프라에서 배포되는 것으로 추측)

9. 배포 상태 업데이트

빌드가 진행되는 동안 빌드 컨테이너가 Vercel의 API를 호출하여 배포 상태를 업데이트하고 로그로 출력한다.

10. 배포 데이터베이스에 배포 정보 기록

빌드 컨테이너가 완료되면 배포에 대한 정보가 포함된 레코드가 Vercel의 자체적인 배포 데이터베이스에 생성한다.

11. 메타 데이터 저장

배포 정보를 포함한 메타 데이터를 S3에 업로드 한다.

사용자 요청 프로세스

1. 배포된 Vercel URL에 대한 요청

2. 요청 수신 및 라우팅

글로벌 네트워크 서비스(Anycast DNS, AWS Global Accelerator)가 요청을 수신, 모든 트래픽이 통과하는 고정 IP를 Vercel에 부여한다.

※  AWS Global Accelerator
DDos 보호 기능 제공, 자동 장애 조치(장애 발생 시 다른 정상 지역으로 리디렉션)

3. 데이터 센터 선택

해당 IP로 요청이 들어오면 글로벌 네트워크 서비스는 유저와 가장 가깝고 상태가 양호한 데이터 센터로 라우팅시킨다.

4. 요청 처리

Kubernetes 클러스터 처리 (Amazon Elastic Kubernetes Service)

5. 보안 처리

악성 요청 필터링

6. 리버스 프록시 라우팅

통과된 요청은 Vercel 리버스 프록시로 라우팅

7. 메타데이터 검색

리버스 프록시는 요청에 대해 배포 데이터베이스에서 검색하고 배포 메타데이터를 가져온다.

8. 캐시 검색

요청을 파악해 리버스 프록시 내 캐시에서 검색한다.

9. 캐시 처리

A) 다른 유저가 요청한 적이 있는 요청일 경우 리버스 프록시가 해당 내용으로 응답 반환

B-1) 캐시에 없는 새로운 요청일 경우

정적 파일 요청 - S3에서 호스팅되는 정적 파일들을 제공

SSR, API 요청 등 - AWS Lambda 함수 중 하나를 호출.

이미지 요청 - 이미지 최적화 서버를 호출해 이미지를 최적화하는 작업을 시행

미들웨어 실행

B-2) 요청을 캐시에 저장한다.

 

참고자료

https://vercel.com/blog/behind-the-scenes-of-vercels-infrastructure

https://www.youtube.com/watch?v=8q-jCvLWwKc

 

Vercel로 배포했을 경우 느린 이유

보통 Vercel이 EC2와 같은 환경으로 배포했을 때보다 느리다고 하는데 그 이유는 위 배포 과정을 통해 알아볼 수 있다.

이유 1: 서버리스 아키텍처의 사용

먼저 Vercel은 서버리스 아키텍처를 사용한다.

※ 서버리스 아키텍처
전통적인 아키텍처와는 다르게 코드의 실행만을 관리하고, 기반 하드웨어, 운영 시스템, 또는 서버의 일반적인 관리 작업을 클라우드 서비스 제공업체가 서버리스 플랫폼(AWS Lambda 등) 을 이용해 담당하는 구조를 말한다.
서버가 없다는 뜻은 아니고, 개발자들이 서버 관리에 대한 걱정 없이 애플리케이션의 개별 기능이나 이벤트 처리 로직을 실행할 수 있게 해주기 때문에 붙은 이름이다.

※ 서버리스 함수
서버리스 환경에서 실행되는 함수를 말한다.

- 특징 -
1) 이벤트 기반 실행 - HTTP 요청, 데이터베이스 이벤트, 파일 업로드 등과 같은 이벤트가 발생할 때만 활성화되며, 그 외 시간에는 실행되지 않는다.
2) 상태 비저장 (Stateless) - 각 함수 호출은 독립적으로 처리된다. 이전 호출의 상태를 유지하지 않기 때문에  함수가 독립적이고 예측 가능한 동작을 유지하게 된다.
3) 자동 스케일링 - 서버리스 플랫폼은 자동으로 함수 호출에 필요한 리소스를 할당하고, 트래픽이 증가하거나 감소함에 따라 이를 조절한다. (함수 인스턴스의 수를 자동 조정한다.)
4) 비용 효율성 - 사용자는 함수가 실행되는 동안 발생하는 계산 리소스에 대해서만 비용을 지불하며 함수가 활성화되지 않은 시간에는 비용이 발생하지 않는다.

vercel은 수 많은 이용자들에게 무료로 플랫폼을 제공하기 위해 '사용한 만큼만 지불'하는 서버리스 모델을 채택했다.

 

그러나 효율을 위해 설계된 서버리스 함수의 이벤트 기반 실행이 바로 문제가 되는 부분인데, 이 때문에 Vercel로 배포하게 될 경우 필연적으로 콜드 스타트 문제가 발생하게 된다.

 

콜드 스타트란?

만약 어떤 함수나 서비스가 장시간 호출되지 않아 "쉬고" 있다가 다시 요청을 받게 될 때, 이 리소스를 다시 할당하고 초기화하는 데 필요한 시간으로 인해 응답 시간이 길어지게 되는데 이를 "콜드 스타트" 지연이라고 한다.

 

아래를 통해 좀 더 상세한 과정을 살펴보자.

 

- 콜드 스타트 문제가 발생하는 원인 -

1. 이벤트 발생

2. 인스턴스(컨테이너 또는 가상 머신) 시작

3. 서버리스 함수 실행

4. 리소스 해제(일정 기간 요청 없다면)

- 2~3번 사이의 과정 -

1. 인스턴스 프로비저닝 - 새로운 컴퓨팅 인스턴스를 생성합니다.

2. 런타임 초기화 - 실행에 필요한 런타임 환경을 설정합니다.

3. 애플리케이션 코드 로딩 - 함수 코드와 필요한 라이브러리를 로드합니다.

4. 시작 실행 - 초기화 코드나 콜드 스타트 로직을 실행합니다.

이유 2: 서버와 물리적 거리, 환경적 차이

서버와 물리적 거리, 환경적 차이도 있을 수 있겠다.

Vercel은 요청의 위치를 확인해 전 세계 다양한 데이터 센터로 라우팅할 수 있는 글로벌 CDN을 제공한다.

이는 정적 자원에 대한 빠른 액세스를 가능하게 하지만, CDN을 사용할 수 없는 서버리스 함수가 실행될 경우 Vercel 네트워크의 영역의 Default Region인 Washington, D.C., USA (East)에서 실행되게 된다.

함수의 실행 지역을 최적화하기 위해 Region을 서울로 바꾸면 좀 낫지만, 아무래도 하나의 EC2에서 서버와 프론트 같이 배포된 환경보다야 당연히 느릴 수밖에 없을 것이다.