Funciones Serverless y cold start

1) ¿Qué es cold start y por qué surge

1. Alocación del entorno (contenedor/micro-VM, carga runtime).

2. Montaje de VPC/ENI, secretos, archivos, configuración.

3. Inicialización de código (importación de módulos, conexión a la DB, carga de modelos).

4. Ejecución de handler.

Warm start (reuse) omite los pasos 1-3. La probabilidad de cold start aumenta en picos, después del tiempo de inactividad, cuando aumenta el paralelismo y cuando se actualizan el código/las confecciones.

2) Cómo medir y establecer objetivos (SLO)

Métricas: 'init _ duration' (inicialización), 'duration _ total', 'framework share', p95/p99 latencia, errores de conexión a dependencias después del tiempo de inactividad.
Eliminación de telemetría: registros de plataforma + etiquetas propias (por ejemplo, 'cold = true/false' si tiene 'context. isColdStart 'o su propia bandera en un cierre estático).
Objetivos SLO (ejemplo): API «login» p95 ≤ 200 ms, fracción cold ≤ 3%; trabajos de fondo - p95 ≤ 1 p. Para las rutas «monetarias» - separados, más rigurosos.

3) Principales palancas de reducción de cold start

3. 1 Gestión de concarrency y calentamiento

Concurrency/Min Instances Provisioned: mantiene N ambientes cálidos. Utilice para bolígrafos críticos.
Warmers/calentamiento: llamadas programadas (cron/scheduler) para mantener los workers calientes. Hágalo razonablemente (región, tiempo, carga).
Búferes de Burst: aumente el límite de concurrencia de antemano antes de los picos esperados.

3. 2 Envases y dependencias

Pequeño artefacto deploy: tree-shaking, '--only prod' de dependencia, capas (AWS Layers) para grandes liebs.
Lazy-init: importe módulos pesados dentro del handler la primera vez que acceda; abra perezosamente las conexiones.
Recursos cálidos: Almacene en caché los clientes de SDK/conexiones en el ámbito global para reuse-eye en el inicio de la guerra.

3. 3 Red y VPC

Sin VPC para funciones que no necesitan privacidad (de lo contrario ENI-attach añade decenas a cientos de ms).
Si VPC es obligatorio, utilice el modo VPC del proveedor (ENI-pools/optimización), proxy a la DB (RDS Proxy/Cloud SQL Auth Proxy) y connection pooling.

3. 4 Idiomas y atributos

Node. js/Go comienzan más rápido; Python - generalmente rápido, pero sensible a las grandes importaciones; Java/.NET - más pesado sin GraalVM/AOT y perfilado.
Para JVM, considere SnapStart/CRaC/Graal Native; para. NET — trimmed Self-Contained.

3. 5 Inicialización y estado

Lleve la costosa inicialización a la fase de inicialización (init phase) en lugar de a la ruta de consulta.
Aplique la descarga on-demand de configuraciones/secretos con caché local (TTL).
No almacene el estado personalizado en la memoria - sólo las señales de caché/conectores.

4) Patrones arquitectónicos que reducen el impacto de cold start

4. 1 Asinchron y colas

Aceptamos la interpelación → validiruem → ponemos en el turno/neumático (SQS/PubSub/Queue Storage) → respondemos 202/Accepted → tratamos por el fondo.
Adecuado para operaciones no interactivas (pagos, informes, cálculos pesados).

4. 2 Precompute/Pre-cache

Genere accesos/directorios/banderas de fichas de antemano por desencadenadores (CRON/eventos) y almacene en KV/caché/edge.

4. 3 Fan-out/Fan-in

Dividimos la operación de larga duración en varias funciones cortas (Map/Reducir-similar) → menos riesgo de temporización y repetición de cold.

4. 4 Edge-offload

Las verificaciones más simples (JWT/HMAC, geo-redirect, antibot) se realizan en edge (Workers/Functions @ Edge) para ahorrar RTT y descargar origin.

5) Práctica: confecciones y recepciones

5. 1 AWS Lambda (provisioned + RDS Proxy)

hcl
Terraform sketch: enable provisioned concurrency on the sales version of the resource "aws_lambda_provisioned_concurrency_config" "api" {
function_name = aws_lambda_function. api. function_name qualifier   = aws_lambda_alias. prod. name provisioned_concurrent_executions = 20
}

RDS Proxy for connection pool "aws_db_proxy" "rds_proxy" {
name          = "pg-proxy"
engine_family     = "POSTGRESQL"
idle_client_timeout  = 1800 require_tls      = true
}

js let pgClient ;//reuse between warm runs let cold = true;

exports. handler = async (event, ctx) => {
const isCold = cold; cold = false;
if (!pgClient) {
const { Client } = await import('pg');     // lazy import pgClient = new Client({ host: process. env. PG_PROXY, ssl: true });
await pgClient. connect();
}
const t0 = Date. now();
const data = await pgClient. query('select 1');
return {
statusCode: 200,
headers: { 'x-cold-start': String(isCold), 'x-elapsed-ms': String(Date. now()-t0) },
body: JSON. stringify({ ok: true })
};
};

5. 2 GCP Cloud Run / Cloud Functions (min instances)

yaml
Cloud Run service. yaml apiVersion: serving. knative. dev/v1 kind: Service metadata: { name: api }
spec:
template:
metadata:
annotations:
autoscaling. knative. dev/minScale: "5" # keep warm run containers. googleapis. com/cpu-throttling: "false"
spec:
containerConcurrency: 80 containers:
- image: gcr. io/proj/api:latest env:
- { name: DB_HOST, value: "10. 0. 0. 5" }

5. 3 Azure Functions (AlwaysOn/PreWarm)

Planes Premium/Elastic con AlwaysOn; pre-warmed instances ≥ predicción p95 paralelismo.

6) Taimouts, Retraídas, Deadlines

El deadline compartido (client-side) pasa a través del título ('x-deadline-ms'/' grpc-timeout'), dentro de la función acorta el 'per-hop timeout'.
Repeticiones sólo para operaciones idempotentes; utilice Idempotency-Key y deduplicación.
Para la API del frente, hedging (una consulta duplicada después de p90) y circuit breaker para dependencias de larga distancia.

7) Trabajo con el DB/cachés/secretos

Pools/proxy (RDS Proxy/Cloud SQL Proxy/pgBouncer) en lugar de miles de conexiones cortas.
TTL de secreto corto + en memoria caché con actualización en segundo plano.
Caché (Redis/Memcached/KV): carga de referencia «pesada» en init, pero con un límite de tiempo.

8) Organización del código y montaje

Handlers individuales para uso estrecho's; un «gordo» bandl = largo init.
ESBuild/Rollup: elimina el no utilizado, combina sólo el crítico.
Capas (Layers/Extensions): para los liebs grandes (modelo OpenSSL, SDK), para volver a utilizar la caché del proveedor.

9) Pruebas y simulación de picos

Sintética de inicio «frío»: apague por la fuerza el min instances y ejecute el tráfico paralelo con escalones.
A/B: compare la fracción de cold, p95, error del connect a la DB/secretos, costos.
GameDay: carga máxima × 2 desde un máximo histórico, desconexión de calentamiento.

10) Costo (FinOps)

Min instances/provisioned concurrency cuesta dinero - activar sólo para rutas calientes.
Reduzca la duración de la ejecución: caché, tiempos cortos, eliminación de SDK innecesarios.
Tenga en cuenta el egress (llamadas a APIs externas) y la lógica (el volumen de registros crece rápidamente en picos de cold).

11) Antipattern

Un handler monolítico con decenas de megabytes de dependencias.
Conexión obligatoria a la base de datos en cada llamada (sin reuse/proxy).
VPC para todas las funciones «por si acaso».
Largos temporizadores y retraídos ciegos → «colas» y descargas fantasma.
Calentar «todo de forma consecutiva» las 24 horas del día.
Inicialización secreta en la ruta de consulta (lentisya init> 100 ms - llevar a init/caché).

12) Especificidad de iGaming/finanzas

Maneras del dinero (depósitos/retiros): mantenga provisioned/min instances, SLO separados, restricción estricta de los tiempos de espera y repeticiones (idempotencia obligatoria).
KYC/PSP: API externas inestables - envuelva en queue + worker, en el frente - 202/polling/webhook.
Regulación y auditoría: registros inmutables (WORM), registro de eventos entrantes con 'Idempotency-Key', correlación 'trace _ id'.
Residencia de datos: las funciones que procesan PII se despliegan en cuentas/proyectos regionales; no hay caché edge con PII.

13) Lista de comprobación prod

• SLI/SLO: p95/p99, fracción cold, valores objetivo por ruta.
• Habilitado provisioned/min instances en funciones críticas; el pronóstico del concarrency.
• El bandido se minimiza; Las libretas pesadas se colocan en capas; lazy-nat/inicialización.
• Reuse clientes SDK/DB; configurado RDS/SQL Proxy; agrupación de conexiones.
• VPC sólo donde se necesita; ENI/proxy optimizados; secretos a través del administrador + caché TTL local.
• Timeouts/dlines/retraims: backoff + jitter; sólo repeticiones idempotivas.
• Sintética "cold' + pruebas de carga; alertas para aumentar la proporción de cold y p99.
• Runbooks: cómo aumentar provisioned, cómo cambiar minScale, cómo activar la degradación.
• Para iGaming: SLO/dashboards individuales «caminos del dinero», Idempotency-Key, auditoría WORM.

14) TL; DR

Cold start es inevitable, pero es manejable: mantenga las instancias cálidas donde sea importante, reduzca el bundle, aplique conexiones lazy-init y reuse, evite el VPC extra, saque operaciones pesadas en la cola/workers y use edge para reglas fáciles. Para las rutas financieras críticas - SLO individuales, idempotencia y tiempos de espera estrictos; mida la fracción de cold e implique el calentamiento sólo cuando esto dé sus frutos.