기존 서버리스의 콜드 스타트 ​​문제

2024년 Datadog 분석에 따르면 프로덕션 환경에서 Lambda 호출의 40%가 발생했습니다. 500ms를 초과하는 콜드 스타트가 발생합니다. Python 또는 Java 함수의 경우 이 숫자는 1~3초로 늘어납니다. 콜드 스타트는 요청이 도착하는 순간부터 요청이 들어오는 순간까지 경과되는 시간입니다. 함수는 실제로 처리할 준비가 되어 있습니다. 시작하는 데 걸리는 시간입니다. 컨테이너, 런타임 로드, 종속성 초기화

Cloudflare Workers는 근본적으로 다른 접근 방식을 취합니다. 즉, 컨테이너 대신 V8 분리. 측정 가능한 결과: 평균 시작 시간 미만 1ms, 전통적인 의미에서 "콜드 스타트"가 없습니다. 왜 내려와야 하는지 이해하기 V8 엔진 아키텍처 및 프로세스 격리 모델을 자세히 설명합니다.

무엇을 배울 것인가

  • V8 Isolate란 무엇이며 OS 프로세스 또는 Docker 컨테이너와 어떻게 다른가요?
  • 컨테이너가 구조적 콜드 스타트로 인해 어려움을 겪는 이유와 이것이 어떻게 나타나는지
  • Cloudflare Workers 실행 모델: 요청 라우팅에서 풀 분리까지
  • Snapshot V8: JavaScript 초기화 비용을 없애는 기술
  • 격리된 모델 제한 사항: CPU 시간, 메모리, 사용 가능한 API
  • 벤치마크 비교: 작업자 vs Lambda vs Lambda@Edge
  • 작업자를 사용해야 하는 경우와 컨테이너가 올바른 선택으로 유지되는 경우

컨테이너, 프로세스 및 분리물: 분류

분리를 이해하려면 먼저 분리가 무엇을 대체하는지 이해해야 합니다. 모든 레벨 추상화의 시작 비용은 다릅니다.

원어 격리 일반적인 시작 메모리 오버헤드 Esempi
VM(하이퍼바이저) 하드웨어 10~60초 512MB - 2GB EC2, GCE, 애저 VM
컨테이너(Linux 네임스페이스) 커널(cgroups + 네임스페이스) 100ms - 2s 50-500MB 도커, 람다, 클라우드런
OS 프로세스 커널(PID, VAS) 10-100ms 10-100MB Node.js, Python 프로세스
V8 절연 런타임(별도의 힙, 공유 메모리 없음) < 1ms 1~10MB Cloudflare 작업자, Deno Deploy

Un V8 절연 V8 JavaScript 힙의 격리된 인스턴스입니다. 나만의 힙 할당자, 나만의 JavaScript 개체, 나만의 가비지 수집기. 두 개의 분리 JavaScript 메모리를 공유하지 않으며 서로 간섭할 수 없습니다. 이것이다 작업자 안전 격리의 기초이지만 건축학적 결과는 다음과 같습니다. 격리를 생성하는 작업은 밀리초가 아닌 마이크로초가 소요됩니다.

Lambda가 콜드 스타트로 인해 어려움을 겪는 이유

요청이 컨테이너 없이 "콜드"(웜이 아님) Lambda 함수에 도착하는 경우 사전 할당됨) AWS는 다음 시퀀스를 실행해야 합니다. 

# Sequenza di cold start Lambda (Node.js 20)
1. Allocazione risorse compute (EC2/Firecracker VM)      ~50-200ms
2. Download immagine container dal registro              ~50-300ms (dipende dalla dimensione)
3. Setup rete: VPC, ENI attachment (se VPC configurata) ~200-1000ms (!)
4. Avvio runtime Node.js                                 ~30-80ms
5. Caricamento dependencies (node_modules)               ~20-200ms
6. Esecuzione handler initialization code               ~10-500ms
7. Prima invocazione effettiva                           ----------

Totale cold start: 360ms - 2.28 secondi (VPC worst case: fino a 3-5s)

Firecracker(AWS에서 사용하는 microVM)는 VM 시작 시간을 약 125ms로 줄였습니다. 그러나 구조적 문제는 여전히 남아 있습니다. 각 실행 환경은 격리된 컨테이너입니다. 콜드 스타트할 때마다 처음부터 시작해야 하는 커널 수준에서.

V8 격리: 작업자 아키텍처

Cloudflare Workers는 다음에서 실행됩니다. 일한, 에서 출시한 오픈 소스 런타임 2022년의 Cloudflare. 모든 PoP(Point of Presence, 전 세계적으로 300개 이상이 있음)가 실행됩니다. 일련의 작업자 프로세스. 요청이 도착하면: 

Sequenza di gestione richiesta in Cloudflare Workers:

1. Richiesta arriva al PoP Cloudflare piu vicino        ~0ms (BGP anycast routing)
2. Routing al processo workerd appropriato               ~0.1ms
3. Lookup/allocation dell'isolate per questo Worker      ~0.5ms (da pool precreato)
4. Esecuzione del fetch handler                          ~0.1ms overhead
5. Risposta

Totale "startup": < 1ms

핵심은 3단계에 있습니다. Workerd는 격리 풀 사전 초기화된. 각 격리에는 이미 작업자 코드가 로드되어 있습니다. 덕분에 V8 스냅샷.

V8 스냅샷: 힙 상태 직렬화

V8은 "스냅샷"이라는 바이너리 형식의 힙 직렬화를 지원합니다. 언제 작업자, Cloudflare를 배포합니다.

  1. 임시 격리에서 작업자의 JavaScript 코드를 실행합니다.
  2. 코드가 초기화를 완료하도록 합니다(모듈 평가).
  3. 격리 힙을 바이너리 스냅샷으로 직렬화
  4. 이 스냅샷을 PoP에 배포합니다.
  5. 처음부터가 아닌 이 스냅샷에서 새로운 격리가 생성됩니다(역직렬화).
// Il tuo Worker ha questa struttura:
import { Router } from 'itty-router';

// Questo codice viene eseguito durante il "module evaluation"
// e serializzato nello snapshot
const router = new Router();

router.get('/users/:id', async ({ params, env }) => {
  const user = await env.DB.get(`user:${params.id}`);
  return Response.json({ user });
});

// Il fetch handler e il punto di ingresso per ogni richiesta
export default {
  fetch: router.fetch
};

// Quando un isolate viene creato dallo snapshot:
// - router e gia costruito e configurato
// - tutte le route sono gia registrate
// - NON c'e alcun costo di module evaluation per ogni richiesta

이는 Lambda에서 발생하는 것과 근본적으로 다릅니다. Lambda에서는 콜드 스타트할 때마다 모든 모듈 초기화 코드를 다시 실행해야 합니다. 노동자에서는, 이 단계는 배포 시 한 번만 발생했습니다.

보안 격리: V8 샌드박스

일반적인 반대 의견은 다음과 같습니다. "여러 작업자가 동일한 프로세스에서 실행되는 경우 어떻게 그들은 고립되어 있나요?" 대답은 V8 샌드박스, 메커니즘 다층:

V8 절연층

  • 힙 분리: 각 격리에는 완전히 별도의 힙이 있습니다. 다른 격리의 메모리는 JavaScript를 통해 액세스할 수 없습니다.
  • 공유된 변경 가능 상태 없음: 작업자의 전역 변수는 다음과 같습니다. 다른 작업자에게 표시됩니다.
  • 제어되는 API: 위험한 기능(파일 시스템, 네트워크 원시, 프로세스)은 V8 자체가 아닌 작업자 런타임에 의해 제어됩니다.
  • 샌드박스 V8: V8에는 다음을 방지하는 샌드박스 메커니즘이 포함되어 있습니다. 임의의 기계어 코드를 실행하거나 외부 메모리에 액세스하는 JavaScript 그 힙의.
  • 추가 프로세스 격리: 일할 수있다 사용 가능한 syscall을 필터링하기 위해 secmp-bpf로 구성됩니다.

모델에 위험이 없는 것은 아닙니다. V8 파서의 취약점으로 인해 이론적으로 격리에서 탈출을 허용합니다. Cloudflare에는 버그 보상 프로그램이 있습니다. 전용이며 정기적으로 V8을 업데이트합니다. Cloudflare는 보안 수준이 높은 워크로드를 위해 다음을 제공합니다. 더욱 엄격한 격리 방법.

격리 모델의 한계

콜드 스타트가 없으면 비용이 발생합니다. 격리된 모델은 컨테이너에 제약을 부과합니다. 그들은 가지고 있지 않습니다:

한계 Cloudflare 작업자(무료/유료) AWS 람다
요청당 CPU 시간 10ms(무료) / 30초(유료, 일시정지 포함) 15분
최대 메모리 128MB 10GB
번들 크기 10MB(압축) / 1MB(무료) 압축 해제 시 250MB
직접 TCP 제한됨(작업자 TCP 소켓 API) 전체 액세스
파일 시스템 사용할 수 없음 /tmp (512MB)
런타임 언어 자바스크립트/타입스크립트/WASM 어느
Node.js 호환성 부분(nodejs_compat 플래그) 완벽한

한도 CPU 시간 이해하는 것이 가장 중요합니다. 벽시계 시간 초과가 아닙니다. 작업자는 실제로 CPU 시간을 측정합니다. 소비되었습니다. 작업자는 그렇지 않은 경우보다 많은 비동기 I/O 호출(가져오기, KV)을 수행할 수 있습니다. CPU 시간을 소모합니다. 이 제한은 실행 중인 JavaScript 코드에만 적용됩니다.

벤치마크: 작업자 vs Lambda vs Lambda@Edge

다음은 공개 벤치마크와 공식 문서(2025)를 기반으로 한 비교입니다.

미터법 Cloudflare 작업자 AWS 람다(Node.js) 람다@엣지 Vercel 엣지 기능
콜드 스타트 ​​P50 < 1ms ~200ms ~100ms < 5ms
콜드 스타트 ​​P99 < 5ms ~1500ms ~500ms < 50ms
글로벌 PoP 300+ ~30개 지역 ~450(그러나 제한됨) ~100+
글로벌 평균 지연 시간 ~10ms(가장자리에서) ~50-200ms(지역) ~25-100ms ~30ms
무료 등급 100K 요청/일 100만 요청/월 100만 요청/월(공유 Lambda) 100GB-시간/월

최소 작업자: 실행 모델 이해

설명된 내용을 구체적으로 만들기 위해 가능한 가장 간단한 코드는 다음과 같습니다. 작업자의 수명주기를 보여줍니다. 

// worker.ts - formato ES Module (obbligatorio con isolates moderni)

// FASE 1: Module evaluation (eseguita UNA VOLTA, serializzata nello snapshot)
console.log('Questo viene eseguito solo al deploy, non per ogni richiesta');

const CONFIG = {
  version: '1.0',
  region: 'auto',
};

// FASE 2: Export del handler - il punto di ingresso per ogni richiesta
export default {
  // Chiamato per ogni HTTP request
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    // request: la richiesta HTTP
    // env: i binding (KV, R2, D1, secrets, variables)
    // ctx: context per waitUntil() - operazioni post-risposta

    const url = new URL(request.url);
    const path = url.pathname;

    // ctx.waitUntil() permette operazioni asincrone dopo la risposta
    ctx.waitUntil(logRequest(request, env));

    if (path === '/health') {
      return new Response(JSON.stringify({
        status: 'ok',
        config: CONFIG,
        timestamp: Date.now(),
      }), {
        headers: { 'Content-Type': 'application/json' },
      });
    }

    return new Response('Not Found', { status: 404 });
  },
};

async function logRequest(request: Request, env: Env): Promise<void> {
  // Questo viene eseguito dopo che la risposta e gia stata inviata
  // Non blocca il client
  await env.ANALYTICS_KV.put(
    `log:${Date.now()}`,
    JSON.stringify({
      url: request.url,
      method: request.method,
      cf: request.cf, // Informazioni Cloudflare: paese, ASN, datacenter, etc.
    })
  );
}

// Interfaccia per i binding definiti in wrangler.toml
interface Env {
  ANALYTICS_KV: KVNamespace;
  API_KEY: string; // secret
}

동시성 모델: 하나의 분리, 많은 요청

미묘하지만 중요한 측면: 각 호출이 작업자의 격리된 환경 동일한 격리가 처리할 수 있습니다. 여러 경쟁 요청. 이것이 가능한 이유는 JavaScript는 이벤트 루프가 포함된 단일 스레드이므로 실제적인 내용은 없습니다. 공유 상태에서는 동시성이 있지만 I/O 바인딩 요청은 다중화될 수 있습니다. 

// ATTENZIONE: stato globale condiviso tra richieste
// In Lambda questo non sarebbe un problema (ogni invocazione ha il suo processo)
// In Workers, piu richieste possono condividere lo stesso isolate

// SBAGLIATO: questo contatore e condiviso tra tutte le richieste
let requestCount = 0;

export default {
  async fetch(request: Request): Promise<Response> {
    requestCount++; // Race condition! Non fare questo.
    return new Response(`Request #${requestCount}`);
  },
};

// CORRETTO: usa ctx.waitUntil() per operazioni post-risposta
// e storage esterno (KV) per contatori condivisi
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    const count = parseInt(await env.COUNTERS.get('requests') ?? '0') + 1;
    ctx.waitUntil(env.COUNTERS.put('requests', String(count)));
    return new Response(`Requests: ${count}`);
  },
};

근로자의 글로벌 현황: 주목

각 호출이 격리된 Lambda와 달리 Workers에서는 상태가 내부 동시 요청 간에 전역 JavaScript를 공유할 수 있습니다. 같은 것의 고립. 필요한 데이터에는 항상 외부 저장소(KV, D1, R2)를 사용하십시오. 지속하거나 공유할 수 있습니다. 불변 전역 변수(구성, 라우터) 그들은 안전하다; 변경 가능한 변수는 위험합니다.

Workerd: 오픈 소스 런타임

2022년 9월 Cloudflare는 이를 오픈 소스로 만들었습니다. 일한 (github.com/cloudflare/workerd), 작업자를 지원하는 런타임입니다. 그가 가지고 있던 이거였어 중요한 결과:

  • 데노 배포 유사한 아키텍처를 갖춘 V8 격리를 채택했습니다.
  • 미니플레어 (로컬 시뮬레이터)은 v3부터 내부적으로 Workerd를 사용해 왔습니다.
  • 개인 환경을 위해 온프레미스에서 Worked를 실행할 수 있습니다.
  • 커뮤니티는 런타임에 기여하고 보안 코드를 검사할 수 있습니다.
# Architettura workerd (semplificata)

┌─────────────────────────────────────────────────┐
│                  workerd process                │
│                                                 │
│  ┌──────────────┐  ┌──────────────┐            │
│  │  Isolate #1  │  │  Isolate #2  │   ...      │
│  │  (Worker A)  │  │  (Worker B)  │            │
│  │              │  │              │            │
│  │  V8 Heap A   │  │  V8 Heap B   │            │
│  │  (isolato)   │  │  (isolato)   │            │
│  └──────┬───────┘  └──────┬───────┘            │
│         │                 │                    │
│  ┌──────▼─────────────────▼───────┐            │
│  │        I/O Subsystem           │            │
│  │  (fetch, KV, R2, D1, DO, AI)  │            │
│  └───────────────────────────────┘            │
│                                                 │
│  ┌─────────────────────────────────────────┐   │
│  │        Network Layer                    │   │
│  │  (Cloudflare anycast, TLS, HTTP/3)     │   │
│  └─────────────────────────────────────────┘   │
└─────────────────────────────────────────────────┘

작업자를 사용하지 말아야 할 경우

V8 분리가 모든 것에 대한 답은 아닙니다. Lambda 또는 컨테이너가 올바른 선택을 유지하십시오:

  • 긴 CPU 집약적 계산: ML 학습, 비디오 렌더링, 오디오 인코딩. 30초의 CPU 시간과 128MB의 RAM 제한은 금지되어 있습니다.
  • 자바스크립트가 아닌 코드: 작업자는 WebAssembly를 지원하지만 전부는 아닙니다. 언어는 WASM으로 잘 컴파일됩니다. 기본 Python, Java, Ruby에는 Lambda가 필요합니다.
  • 완전한 Node.js 생태계: 많은 npm 라이브러리는 기본 Node.js API를 사용합니다. (fs, 고급 암호화, 버퍼 조작)은 Workers에서 사용할 수 없습니다.
  • 복잡한 상태 관리: WebSocket 세션이 필요한 경우 상태가 많은 지속형 개체인 경우 지속형 개체를 고려하세요(시리즈의 기사 4 참조).
  • 영구 연결 데이터베이스: 작업자는 연결을 유지하지 않습니다. 요청 간 지속적인 TCP. 기존 데이터베이스에 대한 풀링을 위해 Hyperdrive를 사용합니다.

결론 및 다음 단계

V8 분리는 단순한 최적화가 아닌 아키텍처 패러다임 전환을 나타냅니다. 격리 경계를 커널 수준에서 런타임 수준으로 이동하므로 멀티 테넌트 에지 컴퓨팅을 위한 충분한 보안을 갖춘 밀리초 미만의 부팅. 비용 이는 기존 컨테이너보다 더 제한된 실행 환경입니다.

대부분의 RESTful API, 인증 미들웨어, 변환 요청 및 콘텐츠 맞춤화로 인해 작업자의 제약은 그 이상입니다. 허용 가능하며 대기 시간의 증가는 전역적이고 측정 가능합니다.

시리즈의 다음 기사

  • 제2조: 첫 번째 Cloudflare 작업자 — 가져오기 핸들러 Wrangler 및 Deploy: 생산 현장 작업자와 함께 개념부터 실습까지.
  • 제3조: 에지 지속성 - 작업자 KV, R2 및 D1 SQLite: Workers에서 사용 가능한 각 스토리지 레이어를 언제, 어떻게 사용하는지.
  • 제4조: 내구성 있는 개체 - 강력한 일관성을 갖춘 상태 e WebSocket: 엣지의 상태 저장 애플리케이션을 위한 가장 강력한 기본 요소입니다.