pile·
인프라 / DevOps·vercel-blogVercel Blog·

Fluid Compute 내부 구조 — Rust 코어, TCP 터널, 요청 다중화로 서버리스 재정의

Vercel이 Fluid Compute 아키텍처의 기술적 내부를 공개했다. AWS Lambda의 단일 요청 모델 한계를 극복하기 위해 Rust 기반 코어, TCP 커스텀 전송 계층, 요청 다중화를 구현했으며, 2년 개발 끝에 주간 450억 요청을 처리하고 I/O 집약적 워크로드에서 비용 90% 이상 절감을 달성했다.

핵심 포인트
  • AWS Lambda는 HTTP 스트리밍 미지원이라 ResponseStarted/ResponseBody/ResponseEnd 패킷을 쓰는 TCP 기반 커스텀 전송 계층을 직접 구현했다.
  • Rust 코어가 사용자 언어 프로세스(Node.js/Python)와 Function Router 사이에서 패킷 변환과 인스턴스 상태 관리를 담당한다.
  • compute-resolver가 피크 시 초당 10만 건, p99.99 서브밀리초 지연으로 Proxy와 Function Router를 연결한다.
  • CPU·메모리·스로틀링·파일 디스크립터·오류율을 실시간 추적해 최적 인스턴스에 라우팅한다.
  • Active CPU 가격으로 I/O 집약적 워크로드에서 기존 대비 90% 이상 추가 절감을 달성했다.
상세 정리
  • 문제: AWS Lambda는 요청-응답 모델만 지원. HTTP 스트리밍 불가, I/O 대기 중 전체 벽시계 시간 과금.
  • 커스텀 전송 계층: TCP 기반 터널로 Lambda와 Vercel 인프라를 연결. ResponseStarted, ResponseBody(복수), ResponseEnd 패킷으로 청크 스트리밍 구현.
  • Rust 코어: 언어 프로세스(Node.js/Python)와 HTTP, Function Router와 TCP로 각각 통신. 패킷 변환과 인스턴스 상태 관리를 담당.
  • 요청 다중화: 유휴 인스턴스에 추가 트래픽을 전송해 콜드 스타트 감소 및 비용 절감.
  • compute-resolver: DNS 유사 리졸버로 Proxy와 Function Router를 연결. 피크 시 10만+ req/s, p99.99 서브밀리초 지연. 요청 99% 이상이 기존 TCP 연결 재사용 포드로 라우팅.
  • 헬스 모니터링: CPU·메모리·CPU 스로틀링·파일 디스크립터 한계·오류율을 Rust 코어가 독립적으로 실시간 추적.
  • nack 프로토콜: 인스턴스 한계 도달 시 nack 신호 → Function Router 트래픽 일시 중지 → 상태 복구 후 재개.
  • 요청 선택 알고리즘: 가용 리소스 최다·동시 요청 최소 인스턴스 선택. 라운드 로빈보다 효과적임을 검증.
  • Active CPU 가격: 실제 활성 CPU 시간(밀리초)과 프로비저닝 메모리(GB-시간)만 과금. I/O 대기 중 CPU 요금 없음.
  • 현황: Vercel Function 호출의 75% 이상이 Fluid Compute 사용. 주간 450억 요청 처리. 비용 최대 95% 절감.
  • 언어 지원: Node.js·Python 현재 지원, 추가 언어 예정.
왜 읽나서버리스 컴퓨팅의 I/O 대기 비용 문제와 HTTP 스트리밍 구현 방식에 관심 있는 인프라·백엔드 엔지니어에게 실제 프로덕션 아키텍처와 성능 수치를 제공한다.
vercel-blog
Vercel Blog 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 인프라 / DevOps·vercel-blogVercel Blog·

    Vercel CLI 드라이런 배포로 실제 배포 전 구성 미리 확인하기

    Vercel CLI v54.17.2부터 vercel deploy --dry 명령으로 실제 파일 업로드 없이 배포 구성을 미리 검사할 수 있다. 프레임워크 감지 결과, 포함/제외 파일 목록, 디렉터리 크기 분포, 콘텐츠 해시까지 사전에 확인하고 나서 배포를 결정할 수 있어 의도치 않은 배포 실패를 예방한다.

    #deployment#ci-cd#vercel-cli+1