떠나갈까 고민할때 출시된 Vercel fluid compute


플루이드 컴퓨팅이란?

플루이드 컴퓨팅(Fluid Compute)은 Vercel Functions에 새롭게 도입된 서버리스 실행 모델. 기존 Vercel Serverless Functions(단일 호출 기반)과 달리 여러 요청을 하나의 인스턴스에서 동시에 처리하고, 응답 후에도 추가 작업(배경 처리)을 진행하는 등 서버리스와 서버 기반의 장점을 결합한 형태


  • 서버리스(Serverless):
    • 장점: 자동 확장, 사용량 기반 청구, 간단한 배포
    • 단점: 콜드 스타트, 단순한 단일 요청 단위 실행으로 I/O 바운드 상황에서 리소스 낭비
  • 플루이드 컴퓨팅:
    • 같은 인스턴스에서 동시 요청 처리(동시성), 콜드 스타트 빈도 감소
    • waitUntil을 통한 응답 후 배경 처리 가능
    • 바이트코드 캐싱, 멀티 리전 지원 등 다양한 기능 강화


현재 프로젝트 상황

  • 현재 사용 중: Vercel Serverless Functions
  • 이슈/고민:
    • 간헐적인 콜드 스타트로 초기 지연 발생
    • I/O 바운드 작업(외부 API, DB 호출 등)이 많아, 단일 요청 단위 모델에서 비효율 발생 가능
    • 트래픽 변동이 심할 수 있어 유연한 확장성과 비용 관리가 필요

이러한 요구사항을 충족하기 위해 플루이드 컴퓨팅이 좋은 대안일 수 있으나, 가격 등 여러 요인을 종합적으로 고려할 필요가 있음.


플루이드 컴퓨팅의 주요 특징


1) 최적화된 동시성(Optimized Concurrency)

  • 동일 인스턴스에서 여러 요청 처리
    기존 서버리스에서는 요청마다 별도 컨테이너(또는 MicroVM)가 생성될 수 있어, I/O 대기 시간이 긴 경우 리소스 낭비가 발생합니다.
    플루이드 컴퓨팅은 한 인스턴스가 여러 요청을 동시에 처리할 수 있으므로, 동일 함수에 대한 여러 요청이 동시에 들어와도 추가 콜드 스타트가 줄어들고 CPU 활용도가 높아집니다.


2) 동적 스케일링(Dynamic Scaling)

  • 유휴 인스턴스 재사용
    • 이미 활성화된(따뜻한) 인스턴스가 있다면 거기에 추가 요청을 배정해 콜드 스타트 횟수를 줄임
  • 급격한 트래픽 변화 대응
    • 트래픽 상승 시 필요한 만큼 빠르게 인스턴스를 확장하고, 감소 시 자동으로 줄임


3) 배경 작업(Background Processing)

  • waitUntil API
    • 사용자에게 빠르게 응답한 뒤에도, 로그 저장, 통계, AI 모델 업데이트 등 추가 작업을 진행 가능
    • 사용자 체감 성능이 개선되면서도 서버 측에서 필요한 작업은 놓치지 않고 처리 가능


4) 자동 콜드 스타트 최적화(Automatic Cold Start Optimizations)

  • 프리-웜(Pre-warm) 전략
    • 프로덕션 배포 시 함수 인스턴스를 사전에 준비해두어, 실제 요청 시 콜드 스타트 지연을 줄임
  • 바이트코드 캐싱(Bytecode Caching)
    • Node.js 20+ 환경에서 첫 실행 시 컴파일된 코드를 재사용 → 재시작(콜드 스타트) 시 로드 시간을 단축


5) 크로스 리전 및 AZ 장애 조치(Cross-region and AZ Failover)

  • 고가용성(HA)
    • 특정 가용 영역(AZ)에서 장애가 나면, 동일 리전 내 다른 AZ로 자동 라우팅
    • 리전 전체 장애 시 다른 리전으로 트래픽이 이동
  • 멀티 리전 배포
    • Enterprise 플랜에서는 전 세계 모든 리전에 배포 가능
    • Pro 플랜은 최대 3개 리전까지 확장 가능


6) 바이트코드 캐싱(Bytecode Caching)

  • Node.js 20+ 환경
    • JS 파일을 바이트코드로 캐싱해 이후 콜드 스타트 시 재컴파일 과정을 생략
  • ESM / CommonJS 모두 지원
    • CommonJS 종속성(react, node-fetch 등)도 캐싱 대상이 되며, 호출 빈도가 높은 함수일수록 이점을 체감하기 쉬움.


7) 격리(Isolation)와 글로벌 스테이트(Global State)

  • 전통 서버리스:
    • 호출마다 독립된 MicroVM 할당 → 보안 측면 유리하나, 유휴 상태가 생기면 비용 비효율
  • 플루이드 컴퓨팅:
    • 여러 요청이 동일 물리 인스턴스에서 동시 실행될 수 있음
    • CPU, 메모리를 더 효율적으로 쓰고, 공유 가능한 스테이트(캐시, DB 커넥션 등)에 대한 활용성이 높아짐
    • 단, 동시성 이슈가 발생하지 않도록 주의가 필요


사실 지금까지의 구조가 좀 구식? 이었다고 생각

가격(플랜별 차이)


과금 방식 개요

  • Vercel Serverless와 마찬가지로, 플루이드 컴퓨팅도 사용한 만큼 요금을 지불하는 구조를 가집니다.
  • 다만, 동시성을 높임으로써 인스턴스 수를 줄이고, 응답 후 배경 처리도 가능해 실제로 필요한 CPU/메모리 사용 시간이 줄어드는 효과가 있을 수 있습니다.


Hobby / Pro / Enterprise 비교

플랜 CPU 설정(유형) 기본/최대 실행 시간 Multi-Region Functions Multi-Region Failover
Hobby Managed (자동 설정) 60s / 60s 지원 안 함 단일 리전 + AZ Failover
Pro / Team Standard 또는 Performance 90s / 800s 최대 3개 리전 3개 리전 간 Failover 가능
Enterprise Standard 또는 Performance 90s / 800s 모든 리전에 배포 가능 리전 제한 없음
  • Hobby:
    • 개인 프로젝트나 규모가 작은 사이트에 적합
    • CPU, 최대 실행 시간 제한이 상대적으로 낮으며, 멀티 리전 확장 기능이 제한적
  • Pro / Team:
    • 최대 800초까지 실행 시간을 늘릴 수 있으므로, 일정 수준 이상의 비동기/AI 작업도 가능
    • 3개 리전까지 배포 지원, 글로벌 사용자 대상 서비스 운영에 어느 정도 대응 가능
  • Enterprise:
    • 가장 폭넓은 리전 배포, CPU/메모리 옵션, SLA(서비스 수준 협약) 등을 제공
    • 고가용성, 대규모 트래픽을 처리하는 기업 환경에서 사용


비용 절감 효과

  • 동시 요청 처리
    • 예를 들어, 1초에 100개의 요청이 들어올 때 기존 서버리스 모델이라면 100개의 함수 인스턴스가 동시에 떠야 할 수 있음.
    • 플루이드 컴퓨팅에서는 하나의 인스턴스가 여러 요청을 처리해, 인스턴스 수 자체가 줄어듦 → 청구되는 총 컴퓨트 시간도 줄어들 수 있음.
  • AI/ML, I/O 바운드 작업
    • I/O 대기 시간이 긴 경우, 기존에는 함수 인스턴스가 놀고 있어도 비용 계산에는 포함될 수 있었음.
    • 플루이드 환경에서는 I/O 대기 중에도 다른 요청을 처리해, 불필요한 리소스 낭비가 줄어듬.
  • 실제로 절감되는 비율은 트래픽 패턴에 따라 달라질 수 있음.
    • 어떤 사용 사례에선 30% 정도, 어떤 경우엔 80% 가까이 절감된다는 보고도 있지만, 이는 실제 부하 테스트나 운영 패턴에 따라 달라짐.


타 서비스와의 비교


플루이드 컴퓨팅을 도입하기 전, 다른 서버리스 및 엣지 서비스와의 차이를 간단히 체크해보았음.


AWS Lambda (전통적 서버리스)

  • 장점:
    • 대규모 사용자 기반, 풍부한 AWS 연동 서비스
    • 확실한 사용량 기반 청구(짧은 기간 무료 사용량 존재)
  • 단점:
    • 함수별 MicroVM 실행으로 I/O 바운드 작업 시 비효율이 커질 수 있음
    • 콜드 스타트가 발생할 때 지연이 길어질 수 있으며(특히 VPC 연동 시), 이는 트래픽 스파이크 대응에 영향을 줄 수 있음
  • 플루이드 컴퓨팅과의 차이점:
    • 플루이드 컴퓨팅은 동시에 여러 요청을 처리해 콜드 스타트와 리소스 낭비를 줄이는 데 초점
    • Vercel과 결합 시 프론트엔드(Next.js 등)와의 배포 연동이 매우 단순


Google Cloud Run

  • 장점:
    • 컨테이너 기반(도커 이미지)으로, 원하는 언어나 환경을 비교적 자유롭게 설정 가능
    • 요청 기반 자동 확장
  • 단점:
    • 컨테이너 빌드/배포 과정을 직접 관리해야 하며, 서버리스보다는 설정이 복잡
    • 예약 인스턴스(Min Instances) 옵션 등이 없으면 처음 콜드 스타트가 발생할 수 있음
  • 플루이드 컴퓨팅과의 차이점:
    • 플루이드 컴퓨팅은 Vercel의 함수 단위 배포 모델과 긴밀히 연결, 제로 설정으로 동시성 / 배경 작업을 활용 가능
    • Cloud Run은 좀 더 광범위한 언어/런타임을 지원하나, 초심자에겐 배포 및 설정 과정이 다소 복잡


Netlify Functions

  • 장점:
    • 간단한 사이트 및 웹 프로젝트 호스팅과 연동에 유리
    • Functions 배포가 쉬우며, 여러 빌드 플러그인을 지원
  • 단점:
    • 함수별 동시성 옵션이나 장시간 실행, 멀티 리전 기능이 상대적으로 제한적
    • Node.js 버전 제약이 있을 수 있음
  • 플루이드 컴퓨팅과의 차이점:
    • Vercel의 플루이드 컴퓨팅은 멀티 리전 배포, 배경 작업 등 좀 더 고급 서버리스 기능을 제공
    • Netlify Functions는 단순 웹사이트/프로젝트에 적합하지만, 고부하·고동시성 업무에는 한계가 있을 수 있음


Cloudflare Workers

  • 장점:
    • 전 세계에 분산된 엣지 네트워크로, 지연 시간이 매우 짧고, 콜드 스타트가 극도로 빠름
    • HTMLRewriter 등 엣지 레벨에서 다양한 작업을 수행할 수 있는 API 제공
  • 단점:
    • V8 기반 자체 런타임으로, Node.js 표준 라이브러리나 Python 환경을 그대로 사용하기 어려움
    • CPU 사용 시간, 메모리 등에 대한 제한이 존재해 장시간/고성능 연산에는 제약
  • 플루이드 컴퓨팅과의 차이점:
    • 플루이드 컴퓨팅은 Node.js/Python 런타임을 그대로 사용 가능(데이터 사이언스, AI 라이브러리 등)
    • Cloudflare Workers는 극저지연 엣지 처리가 필요할 때 최적, 그러나 리소스 제약이 있어 복잡 연산엔 맞지 않을 수 있음
    • 제제미미 프로젝트처럼 AI/ML 후처리가 필요하면, Cloudflare Workers보다는 플루이드 컴퓨팅이 적합할 수 있음


플루이드 컴퓨팅이 적합한 경우 / 고려 사항

  1. I/O 바운드 API 요청이 많아 동시성 활용 효과가 큰 경우
    • 외부 API, DB 응답 대기가 긴 프로젝트
    • 함수가 놀고 있는 시간이 줄어들어 비용 효율이 좋아짐
  2. 콜드 스타트 지연이 문제인 경우
    • 이미 동작 중인 인스턴스를 재사용함으로써, 요청 빈도가 일정 수준 이상이면 체감되는 콜드 스타트 횟수가 줄어듦
  3. 배경 작업(로깅, AI 후처리) 필요
    • 응답 시간을 단축하면서도 필요한 작업을 놓치지 않음
  4. 멀티 리전 및 AZ 장애 조치를 활용해야 하는 경우
    • 글로벌 서비스, SLA가 중요한 프로덕션 환경
  5. 가격 측면
    • 트래픽 패턴, 동시성, 함수 실행 시간에 따라 비용 절감 폭이 달라질 수 있음
    • 짧고 잦은 호출(특히 AI/ML, I/O 바운드)일수록 플루이드 컴퓨팅으로 이점을 보기 쉽지만, 그렇지 않은 경우에는 기존 서버리스와 큰 차이가 없을 수도 있음


마무리

결론은 플루이드 컴퓨팅(Fluid Compute)을 통한 콜드 스타트 감소, 동시성 처리 강화, 배경 작업 지원이 유의미한 이점이 될 가능성이 높다고 생각.

  • 핵심 요약:
    1. 동시성으로 인한 인스턴스 수 감소 → 비용 절감 가능
    2. 배경 작업, AI/ML 후처리에 유용
    3. 멀티 리전, AZ 장애 조치 지원 (플랜에 따라 차등 적용)
    4. 제로 설정으로 빠른 적용(대시보드에서 토글)

오늘부터 적용해보기로, aws amplify g2로 옮겨갈 계획이었는데 이사를 안할수도 있겠다고 생각