Funzioni Serverless e cold start

1) Cos'è cold start e perché si verifica

1. Allocazione dell'ambiente (contenitore/micro-VM, caricamento runtime).

2. Configura VPC/ENI, segreti, file, configurazione.

3. Inizializzazione del codice (importazione dei moduli, connessione al database, caricamento dei modelli).

4. Esecuzione di handler.

Warm start (reuse) ignora i passaggi 1-3. Le probabilità di cold start aumentano con picchi, inattività, parallelismo e aggiornamenti di codice/configure.

2) Come misurare e fissare gli obiettivi (SLO)

Metriche: «init _ duration» (inizializzazione), «duration _ total», «quota di lanci freddi», p95/p99 latency, errori di connessione alle dipendenze dopo l'inattività.
Disinstallazione della telemetria: logi della piattaforma + etichette personalizzate (ad esempio, 'cold = true/false', se disponibile '. isColdStart o bandiera propria in un circuito statico).
Obiettivo SLO (esempio): API "login" p95 "200 ms, percentuale cold 3%; Le operazioni di sfondo sono p95-1. Per le rotte «moneta» sono singole, più rigorose.

3) Principali strumenti di riduzione cold start

3. 1 Controllo concarrense e riscaldamento

Provvisioned Concertency/Min Impianti mantiene il N di ambienti caldi. Usa per le maniglie critiche.
Warmers/riscaldamento: chiamate di routine (cron/scheduler) per tenere caldi i worker. Lo faccia ragionevolmente (regione, tempo, carico).
Buffer burst: aumentare il limite di parallelismo prima dei picchi previsti.

3. 2 Confezione e dipendenze

Piccolo deploy-artefatto: tree-shaking, '--only prod'dipendenze, strati (AWS Layers) per i grandi.
Lazy-init - Importa i moduli pesanti all'interno dell'handler al primo accesso; aprite le connessioni in modo pigro.
Risorse calde: memorizza in cache i client SDK/connessioni nell'area globale per eseguire il reuse-to-warm.

3. 3 Rete e VPC

Senza VPC per le funzioni che non hanno bisogno di privacy (altrimenti ENI-attach aggiunge decine o centinaia di mc).
Se VPC è obbligatorio, utilizzare la modalità di provider VPC (ENI pool/ottimizzazione), proxy a database (RDS Proxy/Cloud SQL Auth Proxy) e connection pooling.

3. 4 Lingue e Rate

Node. js/Go partiranno più velocemente; Python - in genere veloce ma sensibile a grandi importazioni; Java/.NET è più pesante senza GraalVM/AOT e senza profilatura.
Per JVM, considerate il SnapStart/CRaC/Graal Native; per. NET — trimmed Self-Contained.

3. 5 Inizializzazione e state

Immettere l'inizializzazione costosa in un gancio di inizializzazione, anziché nel percorso di query.
Utilizzare il caricamento on-demand di configure/segreti con cache locale (TTL).
Non memorizzare lo state personalizzato nella memoria - solo i segnali cache/connettori.

4) Pattern architettonici che riducono l'impatto di cold start

4. 1 Asincron e code

Accettiamo la richiesta, valutiamo la in coda/bus ( Storage), rispondiamo con 202/Accetted, elaboriamo lo sfondo.
Adatto per operazioni non interattive (pagamenti, report, calcoli pesanti).

4. 2 Precompute/Pre-cache

Generare accesso/directory/flag in anticipo per trigger (CRON/eventi) e memorizzare in KV/cache/edge.

4. 3 Fan-out/Fan-in

Dividiamo un'operazione di lunga durata in più funzioni brevi (Map/Reduce-simile) per ridurre il rischio di timeout e ripetere.

4. 4 Edge-offload

Controlli più semplici (JWT/HMAC, geo-redirect, antibot) eseguiamo su edge (Workers/Functions @ Edge) per risparmiare RTT e scaricare origin.

5) Pratica: configi e tecniche

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)

Piani Premium/Elastic con AlwaysOn; pre-warmed instance di un parallelismo predittivo p95.

6) Timeout, retrai, deadline

Passate la deadline condivisa (client-side) tramite il titolo ('x-deadline-ms'/' grpc-timeout') e ridurrete «per-hop timeout» all'interno della funzione.
Ripetizioni solo per operazioni idipotenti; Utilizzare Idempotency-Key e la deduplicazione.
Per l'API fronte - hedging (una richiesta duplicata dopo p90) e circuito breaker per dipendenze a lungo raggio.

7) Operazioni con database/cache/segreti

Pool/proxy (RDS Proxy/Cloud SQL Proxy/pgBouncer) invece di migliaia di connettori brevi.
Segreti TTL brevi + nella memoria cache con aggiornamento di sfondo.
Cache (Redis/Memcached/KV) - Consente di mappare le guide «pesanti» su init, ma con un limite di tempo.

8) Organizzazione di codice e assemblaggio

Singoli handler per gli use-cas'stretti; Una banda «grassa» = lunga init.
ESBuild/Rollup - Escludi quello non utilizzato, unisci solo quello critico.
Livelli (Layers/Extensions) - Consente di riutilizzare la cache del provider per i grandi modelli SDK.

9) Test e simulazione di picchi

Sintetico di avvio «freddo»: spenga i minuti istanze e scorre il traffico parallelo con le scale.
A/B: confrontare la quota di cold, p95, l'errore di connettività a database/segreti, i costi.
GameDay: carico di picco x 2 dal massimo storico, spegnimento riscaldamento.

10) Costo (FinOps)

Min impianti/procurioned concertency costano denaro - includere solo per le rotte calde.
Riduzione della durata dell'esecuzione: cache, brevi timeout, eliminazione di SDK superflui.
Tenere conto dell'egress (chiamate alle API esterne) e della logica (il volume dei fogli aumenta rapidamente sui picchi cold).

11) Antipattern

Un handler monolitico con decine di megabyte di dipendenze.
Connessione al database obbligatoria per ogni chiamata (senza reuse/proxy).
VPC per tutte le funzioni «per sicurezza».
Timeout lunghi e retrai ciechi, «code» e cancellazioni fantasmagoriche.
Riscaldamento dì solo "24 ore su 24.
Inizializzazione segreta nel percorso di query (lenti init> 100 ms - immettere in init/cache).

12) Specificità iGaming/finanza

Percorsi di denaro (depositi/conclusioni) - Tenere provvisioned/min instanze, SLO separati, limitazione rigorosa dei timeout e delle ripetizioni (Idempotence obbligatoria).
KYC/PSP: API esterne instabili - ruota in queue + worker, 202/polling/webhook sul fronte.
Controllo e regolazione: loghi invariati (WORM), registro eventi in ingresso con'Idempotency-Key ', correlazione «trace _ id».
Data residency: le funzioni che elaborano il PII vengono distribuite su account/progetti regionali; Nessuna cache edge con PII.

13) Assegno-foglio prod-pronto

• Definiti SLI/SLO: p95/p99, quota cold, target percorsi.
• Abilitati provioned/min instance su funzioni critiche prognosi concarrense.
• Bandl minimizzato; fogli pesanti sono stati portati in strati; lazy-import/inizializzazione.
• Reuse dei clienti SDK/DATABASE; configurato RDS/SQL Proxy pool di connessioni.
• VPC solo se necessario; ENI/proxy ottimizzati; segreti tramite gestione + cache locale TTL.
• Timeout/deadline/retrai: backoff + jitter; solo ripetizioni idropotenti.
• Sintetica «cold» + test di carico; alert per la crescita della quota di cold e p99.
• Runbooks: come aumentare i provioned, come cambiare il minScale, come includere la degradazione.
• I singoli SLO/dashboard «percorsi di denaro», Idempotency-Key, controllo WORM.

14) TL; DR

Cold start è inevitabile, ma gestiamo: mantenere le istanze calde dove è importante, ridurre i bandle, applicare lazy-init e reuse connessioni, evitare il VPC in eccesso, portare le operazioni pesanti in coda/worker e utilizzare edge per regole facili. Per i percorsi finanziari critici - SLO separati, idemotia e timeout rigorosi; misurate la quota di cold e accendete il riscaldamento solo laddove questo viene pagato.