Vercel 인프라의 뒷면, 최적의 확장성 달성과 성능(번역)

구름미각·2024년 4월 3일
3

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

Vercel 빌드와 서버리스 어플리케이션 배포하는 법

Vercel 플랫폼은 속도, 신뢰성, 그리고 인프라를 설정하고 관리해야 하는 걱정하지 않아도 되는 편리함을 제공합니다.
하지만 Vercel로 프로젝트를 배포하고, 플랫폼에 있는 사이트에 요청 걸 경우 그 뒷면에 어떤 일이 일어나는 지 정확히 아시나요?

이 게시물은 그 뒷면으로 가서, Vercel이 어떻게 최대의 확장성, 성능, 그리고 빠른 반복을 위한 서버리스 어플리케이션을 빌드하고 배포를 하는 지 설명합니다.

무슨 프레임워크든지 빌드하고 배포하기

배포는 Vercel에서 지원하는 35개 이상의 프레임워크 중 하나에 작성된 코드로 시작하거나 Build Output API를 사용합니다.
Vercel이나 git repository에 코드를 push하는 방법으로 배포를 생성할 수 있습니다.
Vercel GIt Integration(Vercel Git 통합)으로 커밋을 자동으로 감지해서 새로운 배포를 작동시킬 수 있습니다.

배포 프로세스는 다음 두 가지 요청으로 시작하는 CLI로 작동할 수 있습니다.

1. 프로젝트 파일 업로드

확장 가능하고 안전하며, 내구성이 뛰어난 데이터 스토리지 서비스에 업로드할 수 있는 프로젝트 파일을 포함해서 POST 요청이 생성됩니다.

2. 배포 생성

스토리지 서비스에 성공적으로 파일이 업로드 되었다면, 또 다른 POST요청이 생성됩니다.

배포가 생성되기 전, Vercel 은 먼저 사용자를 인증하고, 인증되지 않은 접근을 거부, 무결성 손실을 예방하기 위한 배포를 생성하기 위해 인증서와 사용자 허가를 확인할 요청을 점검합니다.
또한 vercel.file에 있는 Vercel 구성을 검증합니다.


CLI에서 정적 스토리지와 API 엔드포인트에 요청하는 흐름

모든 것이 확인되면 빌드를 하기 위한 배포를 관리합니다.
Vercel build container는 프로젝트 요금제에 따라 사용 가능한 빌드 동시성이 충분한 경우 빌드 프로세스를 즉시 시작할 수 있습니다.
Hobby teams는 하나의 빌드 동시성을 생성할 수 있고, Pro teams는 12개까지 구매할 수 있고, Enterprise teams는 최대의동시성을 위해 커스텀 빌드 슬롯을 구매할 수 있습니다.

빌드 단계에서는 소스 코드에 있는 빌더를 작동시켜 Vercel development로 전환할 수 있습니다.
Vercel에서 내부적으로 제공되거나 npm 레지스트리에서 설치를 요구하는 커스텀 빌더를 사용할 수 있습니다.
자동으로 35개 이상의 프론트엔드 프레임워크를 감지하거나, Build Output API 스펙으로 미리 만들어진 프로젝트를 인식해 Vercel build 시스템을 구성할 수 있습니다.
이 API는 Vercel development 플랫폼과 호환되는 빌드 아웃풋을 생성할 수 있게 하고, 플랫폼 기능의 모든 것을 활용할 수 있게 할 수 있습니다.

빌드 컨테이너가 파일을 처리하고 있을 때, 컨테이너는 API 엔드포인트와 핑을 주고 받아 배포 상태를 확인합니다.
CLI와 대시보드에서 사용자에게 상태를 보여줄 때 이 엔드포인트를 활용합니다.

빌드 컨테이너는 Vercel의 지원되는 런타임 중 하나에서 실행되는 빌드 출력을 생성하고 프로비저닝합니다. 다음과 같습니다:

  • API 라우트 핸들링과 서버 사이드 렌더링 페이지를 위한 서버리스 함수
  • edge런타임을 사용하는 미들웨어와 다른 함수를 위해 엣지 함수
  • 최적화된 이미지
  • 정적 아웃풋


배포는 리소스를 프로비저닝하고 배포 상태를 업데이트하는 빌드 컨테이너 속 빌드를 작동시킨다.

오직 필요한 리소스만 프로비저닝되어, 배포 데이터베이스 문서가 생성되고 배포 메타데이터가 정적 스토리지에 업로드된다.
메타데이터는 정확한 위치에 사용자를 라우트 시키기 위한 요청 단계를 나중에 사용하는 동안 사용되고 수신 요청 경로를 기반으로 적절한 리소스를 호출합니다.

새롭게 생성된 배포는 Vercel CDN을 통해 제공될 준비가 되었습니다.
사용자가 Vercel에 호스팅된 웹사이트에 요청할 때 요청 단계의 일부가 발생합니다.

요청 단계

브라우저가 배포 URL의 웹사이트를 보여주기 전에, 먼저 IP 주소를 찾기 위해 DNS Lookup을 수행합니다.
Vercel에 호스팅된 웹사이트를 위해, 이 단계에서는 Vercel이 가진 애니케스트 IP 주소와 cname.vercel-dns.com CNAME 레코드를 사용합니다.

GeoDNS가 위치에 따라 사용자를 고유한 엔드포인트로 라우팅하는 반면, Vercel은 애니캐스트 라우팅을 사용하여 홉 수, 왕복 시간 및 사용 가능한 대역폭의 양에 따라 결정되는 최적의 데이터 센터로 트래픽을 라우팅하는 네트워킹 서비스를 사용합니다.
출처와 가장 가깝고 세계적으로 낮은 지연 시간 연결을 할 수 있도록 보장하는 목적지로 가는 트래픽을 라우팅해 네트워크 성능을 높일 수 있습니다.


GeoDNS(위) vs 애니캐스팅 라우팅(아래)

게다가 애니캐스팅 라우팅의 이점으로 네트워킹 서비스는 Vercel에서 호스팅되는 어플리케이션을 자동으로 대체 작동시키고 디도스 예방, 그리고 회복성을 발전시키고 공격의 영향을 제거하도록 설계된 성능 강화 기능을 제공합니다.

Vercel IP 주소는 사용자와 가장 가까운 엣지 위치에 연결시키며, 위치는 네트워크 인프라와 게이트웨이처럼 행동합니다.

여기서 요청은 Vercel k8s 클러스터로 들어갑니다.
요청은 먼저 악성 사용자를 검사하고 거르고, 그 다음 리버스 프록시 처럼 제공되는 가상 머신에 라우팅됩니다.
게이트웨이는 다시 쓰기와 프록시 요청을 담당합니다.

먼저, 어떤 배포판이 수신 요청에 따라 호스트 이름과 같은 데이터를 기반으로 사용자에게 제공되어야 하는 지 생각하고 배포 메타 데이터를 가져옵니다.
요청 경로가 배포 메타데이터에 지정된 경로와 일치하는 지에 따라 요청 404 상태 코드를 돌려보내거나 계속해서 응답을 만들어야 합니다.

응답 단계로 계속하기 전에, 요청은 Vercel 엣지 미들웨어가 활성화 될 경우 수정되야 하며, 요청은 먼저 엣지 기능을 실행을 담당하는 플랫폼으로 전달됩니다.


클라이언트에서 요청된 리소스로 요청의 흐름

응답 단계는 리소스의 타입마다 다르게 작동합니다.

  • 정적 리소스: 정적 페이지, 폰트, 그리고 최적화되지 않은 이미지 같은 경우에, 정적 스토리지에서 리소스를 게이트웨이가 다운로드합니다.
  • Vercel 서버리스 함수: 서버 렌더링된 페이지나 API 라우트 같은 경우에, 게이트 웨이는 배포된 리전에 함수에 있는 서버리스 함수를 작동시킵니다.
  • 엣지 함수: edge 런타임을 사용하는 서버 렌더링된 페이지나 API 라우트 같은 경우에, 게이트웨이는 엣지에 있는 엣지 함수 실행을 호출하기 위해 요청을 포맷합니다.
  • 점진적인 정적 재생을 사용하는 페이지: 게이트웨이가 해당 페이지는 이전에 렌더링 되었는 지 확인하고, 정적 스토리지에 정적 아웃풋을 사용할 수 있도록 합니다.
    그렇지 않은 경우, 게이트웨이는 동적으로 콘텐츠를 (다시)생성하기 위해 서버리스 함수 실행을 호출할 것입니다.
    이 함수를 호출하는 것은 오래된 콘텐츠의 경우에도 발생하는데, 정적 콘텐츠가 이전에 캐시되었지만 기간(TTL)이 지났기 때문입니다.
    이러한 경우에는 오래된 콘텐츠는 사용자에게 제공되고 콘텐츠를 다시 생성하기 위해 백그라운드에서 함수가 호출됩니다.
  • 최적화된 이미지: 요청은 이미지를 즉석으로 최적화하는 전용 서비스로 전달되고 후속 요청을 위해 캐시되어 파일 크기를 줄이고, 클라이언트가 사용하는 브라우저에서 지원되는 최신 포맷을 사용합니다.
    최적화된 이미지는 만료될 때까지 제공되며, 만료될 경우 백그라운드에서 이미지가 다시 최적화 될 때까지 오래된 버전이 제공될 것입니다.
    이미지 만료 시간은 구성 설정 또는 업스트림 이미지의 Cache-Control헤더에 의해 결정될 것입니다.

위에서 말한 모든 응답은 캐시 헤더를 기반으로 캐시되어 나중의 조회 속도를 높입니다.
응답 단계에서 Vercel에 요청의 라이프 사이클이 종료되었습니다.

결론

인프라를 설정하고 관리하는 과정은 지루합니다, 그리고 선택과 적절한 서버 하드웨어와 운영체제를 구성하고, 네트워크 인프라 설정과 구성하고, 필요한 소프트웨어 스택을 구성하고 관리하는 등등 많은 것들이 필요합니다.

인프라를 안전하고 크기 조절이 가능하도록 보장하는 것은 지속적인 감시, 관리, 업데이트가 필요합니다.
위협과 취약성으로부터 보호하기 위한 보안 프로토콜 및 솔루션 구현은 물론 인프라가 트래픽 급증을 효율적으로 처리할 수 있도록 보장하는 것도 포함됩니다.
이러한 모든 작업은 시간이 많이 걸리고 복잡하며 대규모로 처리하려면 숙련된 엔지니어로 구성된 전담 팀이 필요합니다.


배포와 요청 라이프사이클 완성 흐름

Vercel에 배포하면 자체 인프라 설정 및 유지 관리에 대해 걱정할 필요 없이 배포 프로세스를 간소화하고 간소화할 수 있습니다. 플랫폼의 배포 프로세스는 확장 가능하고 안전하도록 설계되어 있어 항상 프로젝트 개발에만 전적으로 집중할 수 있습니다. Vercel은 글로벌 성능과 접근성을 위해 배포를 최적화하여 위치에 관계없이 최고의 사용자 경험을 보장합니다.

Vercel은 또한 제품의 개발자 경험과 반복 속도를 크게 향상시킵니다. 자동 Git 통합은 모든 커밋에 대한 미리보기 배포를 생성합니다. 변경 사항이 적용되고 커밋되자마자 업데이트된 제품의 미리 보기를 즉시 검토할 수 있습니다. 이 기능을 사용하면 개발 주기가 빨라지고 팀 협업이 더욱 효율적으로 이루어집니다.

협업 및 개발 프로세스를 더욱 개선하기 위해 Vercel은 미리보기 배포에 대한 의견도 제공하여 팀 구성원이 전용 환경에서 모든 변경 사항에 대한 피드백과 제안을 제공할 수 있도록 합니다.

지금 Vercel을 사용해 보고 편의성, 보안, 성능상의 이점을 직접 경험해 보세요.

profile
(돈과 인맥을 만들어 나가는)학생 개발자

0개의 댓글

관련 채용 정보