▲

Cloudflare Workers CPU 성능 벤치마크 분석

 (blog.cloudflare.com)
1P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 독립 개발자 Theo Browne의 벤치마크에서 Cloudflare Workers가 Vercel Node.js보다 최대 3.5배 느린 성능을 보임
  • 벤치마크 결과의 원인은 여러 인프라·라이브러리 설정 및 벤치마크 방법론상의 문제 때문임
  • 스케줄링 알고리듬 개선, V8 가비지 컬렉터 튜닝, OpenNext 최적화 등 다수의 플랫폼 및 프레임워크 개선이 이루어짐
  • 주요 패치로 인해 현재 대부분의 벤치마크에서 Cloudflare와 Vercel 간 성능 차이가 크게 감소하였음
  • 앞으로도 Cloudflare는 공개 인프라와 프레임워크 개선에 기여하며, 지속적인 최적화와 벤치마크 검증을 이어갈 계획임

개요 및 벤치마크 논란

  • 2023년 10월, 개발자 Theo Browne가 Cloudflare Workers와 Vercel(AWS Lambda 기반)의 서버측 JavaScript 실행 속도를 비교하는 벤치마크를 공개함
  • Cloudflare Workers는 V8 자바스크립트 엔진을 기반으로 Vercel과 같지만, 최대 3.5배의 성능 저하가 관찰됨
  • 인프라 미세 튜닝, 자바스크립트 라이브러리 차이, 테스트 방식 문제 등 다양한 원인으로 불합리한 성능 격차가 발생함
  • 이 문제점들을 개선하는 과정에서 Cloudflare Workers 전체 성능이 향상됨
  • 주요 수정 사항 중에는 삼각함수 연산 속도 개선 등 타 플랫폼에 영향을 줄 수 있는 개선도 포함됨

벤치마크 방법론

  • Theo의 최초 테스트 클라이언트는 샌프란시스코에서 Webpass로 접근, Vercel은 sfo1 지역에서 실행됨
  • Cloudflare에서는 AWS us-east-1 데이터센터 내에서 Vercel의 iad1 인스턴스와 직접 통신함으로써 네트워크 지연의 영향을 최소화함
  • 벤치마크는 모두 단일 스레드(vCPU 1개) 환경에서 이루어졌으며, 가격 비교도 쉽게 맞춤
  • 테스트 중에 발견된 버그는 Pull Request로 업스트림에 제출되어 수정됨

Cloudflare 플랫폼의 성능 개선

Workers Runtime의 스케줄링 및 격리 처리 개선

  • 기존에는 트래픽을 "웜" 격리(빠르게 처리가능한 인스턴스)로 라우팅하는 알고리듬을 사용해 대규모 앱의 레이턴시 및 처리량을 최적화했으나, CPU 집약적인 워크로드에 비효율적이었음
  • CPU 점유가 큰 요청이 몰릴 경우, 대기열이 길어지고 지연이 커진 현상이 벤치마크에서 드러남
  • Cloudflare Workers는 빌링 기준이 CPU 사용 시간이므로, 대기 시간(격리 준비 대기)은 비용이 부과되지 않음
  • 알고리듬 개편을 통해 CPU 사용량이 큰 워크로드를 더 빨리 감지, 신규 격리를 빠르게 생성하도록 개선함
  • I/O 바운드와 CPU 바운드 워크로드 모두에 효율적으로 대응, 전 세계적으로 배포되어 즉시 반영됨

V8 가비지 컬렉터 설정 개선

  • 테스트 과정에서 JavaScript 가비지 컬렉션과 메모리 관리 이슈가 성능 저하에 큰 영향을 미침을 확인
  • V8 엔진의 "young generation" 메모리 영역 크기 설정이 너무 제한적으로 고정되어 있었음 (과거 권장치인 128MB에 맞춤)
  • 최신 V8에서는 해당 설정 방식이 오히려 불필요한 빈번한 GC 발생을 유발
  • 수동 튜닝을 해제하고, V8 자체의 휴리스틱 기반 동적 메모리 할당 허용
  • 약 25% 벤치마크 성능 향상을 확인, 모든 Workers에 적용

OpenNext 기반 Next.js 성능 최적화

불필요한 메모리 할당 및 복제 제거

  • 분석 결과, 요청 처리 시간 중 10–25%가 메모리 해제(GC) 에 소모
  • OpenNext, Next.js, React는 내부 데이터 버퍼를 과도하게 복제하는 코드 패턴이 다수 있었음
  • 스트림 출력 데이터 전체를 불필요하게 복사하는 작업, Buffer.concat으로 단순 길이 측정 목적으로 대량 데이터 복사가 이루어짐
  • 관련 이슈들을 OpenNext 저장소에 Pull Request로 개선 중
  • 전체 플랫폼에서 공통적으로 성능 개선될 수 있도록 계속해서 고도화 계획

비효율적인 스트림 어댑터 최적화

  • Workers는 Web Streams API, Next.js는 Node.js의 스트림 API 위주로 설계되어 변환 어댑터가 필요함
  • 불필요하게 중첩된 어댑터 사용, 메모리 복제 및 버퍼링 오버헤드 다수 발생
  • 단순히 ReadableStream.from(chunks)로 코드를 축소해 중간 복제를 제거
  • 기본적으로 단일 값 스트림(highWaterMark=1) 구조를 바이트 스트림(highWaterMark=4096 등)으로 개선해 대량 데이터 처리를 최적화
  • 향후 Next.js 및 React의 스트림 처리 개선 패치도 상위 플랫폼으로 upstream 예정

JSON.parse() 성능 문제와 V8 패치

  • Next.js 및 React 전반에서 reviver 옵션이 포함된 JSON.parse() 사용 시 과도한 호출이 발생(100,000회 이상)
  • 최신 ECMAScript 표준에서 세 번째 인자(소스 컨텍스트)를 reviver에서 받을 수 있게 되어, 성능이 추가 악화됨(파이어폭스, Chrome 등 공통)
  • Cloudflare Workers 팀이 V8 엔진에 패치 제공(33% 성능 개선) , Node.js와 크롬 브라우저, Deno 등 전 생태계에 이득이 돌아갈 예정

Node.js의 삼각함수 성능 문제

  • Theo의 벤치마크와 별개로, 수학 삼각함수(sin, cos 등) 반복 호출 벤치마크에서 Cloudflare Workers가 3배 빠른 결과 보고됨
  • 원인은 Node.js가 V8에서 제공하는 최신/고속 삼각함수 경로(compile-time flag)에 미처 대응하지 못했던 것임
  • Cloudflare Workers는 우연히 해당 플래그를 기본 활성화, Node.js에는 Pull Request로 패치 제출
  • 이 문제 역시 오픈소스 생태계 공통성이므로, AWS Lambda와 Vercel까지 반영 시 전반적인 속도 안정화 기대

벤치마크 설계/측정상의 한계와 교훈

  • 벤치마크는 대부분 클라이언트에서 요청 시간(latency) 측정 방식으로, 실제 서버측 CPU 사용 시간을 직접 측정하지 않음
  • 네트워크 경로, 데이터센터 위치, 하드웨어 세대, 멀티테넌시 등 다양한 비교 불가능한 변수가 결과에 영향을 줄 수 있음
  • 응답의 첫 바이트 도달 시간(TTFB)만 측정한 경우, 전체 렌더링/전송 시간 반영 어려움. TTFL로 바꾸면 네트워크 속도 차이에 더 민감해질 수 있음
  • 서버 하드웨어/소프트웨어 다양성, 인스턴스 할당 운 등에 따라 일시적/연관성 있는 노이즈도 존재함
  • 벤치마크용 환경 및 업무 흐름 정확화, 변수를 맞추는 과정에서 실무적 개선점을 도출, 자사·타사 플랫폼 모두에 유익을 줌

실험 중 발견된 벤치마크 및 환경 설정 문제

  • Next.js의 force-dynamic 설정 미적용, 캐시 처리 로직, 응답 스트리밍 방식 차이 등으로 결과 오해 위험이 있었음
  • React SSR 벤치마크에서 NODE_ENV 환경 변수 미설정으로 dev mode 동작, 실제보다 느린 결과 반환
  • 이러한 오류는 환경 변수를 명시적으로 설정하여 수정

앞으로의 계획 및 결론

  • Cloudflare Workers Runtime의 다양한 성능 개선 사항이 이미 전면 적용, 사용자는 별도 조치 없이 이득 효과
  • Theo에게 테스트 코드, OpenNext 최적화 등이 반영된 Pull Request를 제공
  • OpenNext와 Vercel 기반 Next.js 간 격차 해소를 위한 추가 개선 예정
  • 스케줄링 알고리듬 및 오픈소스 엔진(V8, Node.js) 지속적 업그레이드 및 커뮤니티 기여 방침
  • 더 나은 벤치마크와 프로파일링으로 잠재 이슈 조기 발견, 최적화 및 공유 문화 유지 예정

참고 자료 및 추가 링크

▲
GN⁺ 4일전  [-]
Hacker News 의견

  • CF가 실제로 제품을 개선하려고 노력하는 것은 좋은 일임. 그러나 너무 빠른 속도로 변화가 일어나서 따라가기가 어렵고, 출시가 완성도를 앞서는 경우도 많음. 예를 들어 R2 Data Catalog에는 여전히 Iceberg v3 지원이 부족하고, Wrangler도 불과 몇 달 만에 크게 바뀌었으며, Pages는 곧 사라질 것 같아서 Workers Assets로의 마이그레이션이 굉장히 번거로움. Wrangler 3에서 잘 되던 설정이 Wrangler 4에는 제대로 적용되지 않았고, Wrangler 5에서는 또 새로운 인터랙션 모델이 나올 느낌임

    • "Pages가 사라질 것 같다"는 말에 대해, 실제로 CF에서는 Workers가 Pages와 동일한 수준이 될 때까지 Pages를 없애지 않는다고 커뮤니티 포스트에서 언급했음 관련 포스트 공식적으로 Pages가 폐지된다는 내용을 찾기 어렵고, pages.cloudflare.com과 developer.cloudflare.com/pages 모두 활발히 운영 중임. Reddit의 한 게시글은 Pages 마이그레이션을 암시하지만, 해당 링크에서도 공식적인 중단 언급이 없음 나머지 의견에는 공감하며, 특히 그 부분 때문에 놀랐음 Reddit 참고 링크

    • Wrangler 3의 설정이 Wrangler 4에서도 그대로 동작하지 않는다는 말에는 동의할 수 없음. Wrangler 4에서 설정 형식에는 아무런 변화가 없었고, 메이저 버전 증가의 이유는 99.99%의 사용자에겐 영향이 없었음. 관련 변경 내역은 여기에서 확인 가능함. 단순 메이저 버전 업만으로도 불편함이 커서 자체적으로 반대 의견도 냈었으나, 극히 드문 예외 케이스 때문에 팀에서는 신중을 기했음. 앞으로는 이런 이슈를 메이저 버전 업 없이 관리할 수 있는 방법(예: esbuild 버전의 병행 지원 등)을 개발할 것임. 런타임 측면에서는 특히 하위 호환성을 엄청나게 신경 씀 하위 호환성 관련 블로그 Pages는 사라지는 것이 아니며, Workers Assets는 Pages의 더 유연한 구현 버전임. 추가 기능이 필요 없다면 굳이 이전하지 않아도 되고, 나중에는 자동 마이그레이션도 진행될 예정임

    • 중요한 프로젝트나 몇 년간 유지될 시스템을 만들 때는 '따분한 기술(boring tech)'을 사용하는 것이 좋음을 다시 한번 상기시킴

    • "Pages가 사라질 것 같다"는 근거를 어디서 봤는지 궁금함. 본인은 여러 프로젝트에 Pages를 잘 쓰고 있음

    • 흥미로운 사실은 이 논란이 Cloudflare가 Vercel보다 빠르다는 주장에서 시작되었다는 점임. 이후 제대로 알고 있는 누군가가 벤치마크를 진행해 실제로는 반대 결과가 나왔고, 결과적으로 Cloudflare가 성능을 높이기 위해 실제 개선 작업을 진행함

  • 기사에서 경쟁을 비난하기보다는 개선점을 찾아내고 강조하는 태도가 정말 마음에 들었음. OpenNext 구현에도 발전이 있어서, 다른 공급업체에서도 재활용할 수 있다는 점이 인상적임

  • NextJS를 Vercel에서 호스팅하다가 Astro/React를 Cloudflare로 이전 중임. 놀라운 점은, “엣지”에서 모든 요청마다 웹앱을 렌더링하는 상황에서도 응답 시간이 100-200ms 정도로, 거의 정적 페이지와 비교해도 손색없는 속도를 보인다는 것임. 최근 몇 주간 Cloudflare Worker의 개선도 확실히 체감했는데, 콜드 스타트가 거의 사라지고 응답 속도도 훨씬 안정적임 포팅 중인 웹앱 링크

    • 안녕하세요! 엣지 환경에서 데이터베이스와 어떻게 연결하고 계신지 궁금함. Cloudflare의 데이터베이스를 사용 중이신지요? 애플리케이션과 데이터베이스 간 왕복 횟수가 많아져서 엣지 호스팅 시 오히려 성능 저하를 경험한 바 있음. 한 번 직접 사용해보고 싶었음

  • 규모가 크지 않은 유튜버가 올린 영상이 이런 방식으로 효과적으로 퍼져나가, Cloudflare 측에서 실제 의미 있는 개선과 플랫폼 이슈 해결로 이어진 점이 신기함

  • 너무 잘 짜여진 PR임. 이 포스트를 준비한 분들께 칭찬을 보냄

    • 오래된 cf 고객으로서 이야기하자면, cf는 블로그나 오픈소스 글쓰기도 멋지지만 인프라 회사 중 서비스 지원 면에서 최고임. 팀원(kenton 포함)들이 Discord에서 직접 사용자를 도와주거나 피드백을 수용하는 경우가 많고, 버그나 이슈도 실제 담당 엔지니어와 바로 소통할 수 있음. 실제로 본인이 제안한 PR이나 피처 요청도 별다른 절차 없이 빠르게 반영된 적 있음. 타 대형 기업 대비 매우 저렴한 요금제로도 훨씬 더 나은 지원을 받고 있음

    • 고마움! 이 PR과 포스트는 Workers 팀 엔지니어들이 100% 주도적으로 기획, 제작한 것임(나도 참여함)

  • 이 포스트의 작성 방식, 정보 분해, 공개적 논의 모두가 정말 마음에 듦. Cloudflare workers 팀에 대한 신뢰도가 올라감

  • 내 생각엔 SvelteKit이 엄청 빠르고, Next.js는 상대적으로 매우 느림

    • 그럴듯한 결론임

    • SvelteKit, Astro, TanStack 같은 실용적인 프레임워크가 곧 NextJS의 복잡함을 대체했으면 하는 바람임

  • 이런 사례가 경쟁과 독립적인 벤치마크가 필요한 이유임. 성능이 부족한 서비스도 개선을 위해 노력하게 만듦

    • 그런 노력도, 제품을 소중하게 생각해야만 효과가 있음

    • 이미 독립적인 벤치마크는 존재함

  • Cloudflare가 결과를 겸허히 받아들이고, 건설적으로 개선한 점이 인상적임

  • 내용에 초점을 맞추고, 비난하지 않은 멋진 글임.하지만 Cloudflare가 기존에 generation 크기 등을 사전에 더 잘 모니터링하고 조정하지 않았다는 점은 의외였음. JVM 성능 튜닝에서는 generation size 세팅이 기본인 경험이 있었음

    • 우리는 뭔가를 고칠 때마다 항상 투명성을 우선함, 심지어 다소 바보처럼 보일 수 있더라도 말임. 앞으로는 이 부분 로깅과 추적도 더 강화할 예정임. 일반적으로 GC가 최대한 스스로 자동으로 환경에 적응해야 한다고 생각함. 즉, 사용자가 파라미터를 일일이 맞추는 과정이 많다면 GC 작성자 측면에서 패배나 다름없다고 느껴짐. 이번에는 제대로 동작하지 않던 튜닝을 <i>제거</i>하고, V8이 자체적으로 young gen size를 더 잘 결정하도록 허용하는 방향임
답변달기