Fonctions serverless et cold start

1) Qu'est-ce que cold start et pourquoi il se produit

1. Allocation de l'environnement (conteneur/micro-VM, chargement runtime).

2. Primalisation VPC/ENI, secrets, fichiers, configuration.

3. Initialisation du code (importation de modules, connexion à la base de données, chargement de modèles).

4. Exécution d'un handler.

Warm start (reuse) manque les étapes 1 à 3. La probabilité de cold start augmente en cas de pics, d'inactivité, de parallélisme et de mises à jour de code/configues.

2) Comment mesurer et fixer des objectifs (SLO)

Métriques : 'init _ duration' (initialisation), 'duration _ total', 'proportion de démarrage à froid', p95/p99 latency, erreurs de connexion aux dépendances après arrêt.
Retrait de la télémétrie : logs de plateforme + étiquettes natives (par exemple 'cold = true/false' s'il y a 'context. isColdStart 'ou son propre drapeau en fermeture statique).
Objectifs SLO (exemple) : API « login » p95 ≤ 200 ms, proportion cold ≤ 3 %; Les tâches de fond - p95 ≤ 1 s. Pour les itinéraires « monétaires » - sont séparées, plus strictes.

3) Principaux leviers de réduction cold start

3. 1 Contrôle de concarrensy et chauffage

Provisioned Concurrency/Min Instances : maintient N environnements chauds. Utiliser pour les stylos critiques.
Warmers/échauffement : appels planifiés (cron/scheduler) pour garder les workers au chaud. Faites-le intelligemment (région, temps, charge).
Tampons Burst : augmentez la limite de parallélisme avant les pics attendus.

3. 2 Emballage et dépendances

Petit artefact deploy : tree-shaking, '--only prod'addictions, couches (AWS Layers) pour les grandes feuilles.
Lazy-init : Importez des modules lourds à l'intérieur du handler dès le premier accès ; Ouvrez paresseusement les joints.
Ressources tièdes : Mettez en cache les clients SDK/connexions dans la zone globale pour lancer reuse sur warm.

3. 3 Réseau et VPC

Sans VPC pour les fonctions qui n'ont pas besoin d'une private (sinon ENI-attach ajoute des dizaines à des centaines de ms).
Si le VPC est obligatoire, utilisez le mode VPC économique du fournisseur (ENI pools/optimisation), proxy à la base de données (RDS Proxy/Cloud SQL Auth Proxy) et connection pooling.

3. 4 Langues et rantaymes

Node. js/Go démarrent le plus rapidement ; Python - généralement rapide, mais sensible aux importations importantes ; Java/.NET est plus lourd sans GraalVM/AOT et profil.
Pour JVM, considérer SnapStart/CRaC/Graal Native ; Pour. NET — trimmed Self-Contained.

3. 5 Initialisation et état

L'initialisation coûteuse est placée dans le crochet d'initialisation (init phase) et non dans le chemin de requête.
Utilisez le téléchargement à la demande de configues/secrets avec cache local (TTL).
Ne conservez pas l'état personnalisé en mémoire - seulement les signaux cache/connecteurs.

4) Modèles architecturaux qui réduisent l'impact de cold start

4. 1 Asynchron et files d'attente

Nous acceptons la demande → валидируем → nous mettons au tour/pneu (SQS/PubSub/Queue Storage) → nous répondons 202/Accepted → nous travaillons par le fond.
Convient pour les opérations non interactives (paiements, rapports, calculs lourds).

4. 2 Precompute/Pre-cache

Génération des accès/répertoires/drapeaux fich à l'avance par déclenchement (CRON/événements) et stockage dans KV/cache/edge.

4. 3 Fan-out/Fan-in

Nous divisons une opération longue en plusieurs fonctions courtes (Map/Reduce-like) → moins de risque de temporisation et de recold.

4. 4 Edge-offload

Les contrôles les plus simples (JWT/HMAC, géo-redirect, antibot) sont effectués sur edge (Workers/Functions @ Edge) pour économiser le RTT et décharger l'origin.

5) Pratique : configis et techniques

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)

Plans Premium/Elastic avec AlwaysOn ; pre-warmed instances ≥ le parallélisme prédictif p95.

6) Taimauts, retraits, dédelines

Passez à travers l'en-tête ('x-deadline-ms'/' grpc-timeout'), raccourciez 'per-hop timeout' à l'intérieur de la fonction.
Répétitions uniquement pour les opérations idempotentes ; Utilisez Idempotency-Key et la déduplication.
Pour l'API Front - hedging (demande en double après p90) et circuit breaker sur les dépendances lointaines.

7) Travailler avec des bases de données/caches/secrets

Pools/proxy (RDS Proxy/Cloud SQL Proxy/pgBouncer) au lieu de milliers de connexions courtes.
Court TTL secret + en mémoire cache avec mise à jour en arrière-plan.
Cache (Redis/Memcached/KV) : Dogging des manuels « lourds » sur init, mais avec une limite de temps.

8) Organisation du code et assemblage

Handler individuels pour les cas d'utilisation étroits ; un « gros » bandle = long init.
ESBuild/Rollup : excluez les inutilisés, combinez uniquement les critiques.
Calques (Layers/Extensions) : Permet aux grands Libs (modèle OpenSSL, SDK) de réutiliser le cache du fournisseur.

9) Test et simulation des pics

Les synthétiques de démarrage « à froid » : éteignez de force min instances et conduisez le trafic parallèle avec des marches.
A/B : comparer la proportion de cold, p95, erreur de connecteur aux OBD/secrets, coûts.
GameDay : charge de pointe × 2 du maximum historique, débranchement du chauffage.

10) Coût (FinOps)

Min instances/concurrency provisioned coûtent de l'argent - incluez uniquement pour les itinéraires chauds.
Réduisez la durée d'exécution : cache, délais courts, refus des SDK inutiles.
Tenez compte de l'egress (appels vers des API externes) et du logging (le volume de logs augmente rapidement sur les pics cold).

11) Anti-modèles

Un handler monolithique avec des dizaines de mégaoctets de dépendances.
Connexion obligatoire à la base de données à chaque appel (sans reuse/proxy).
VPC pour toutes les fonctions « au cas où ».
Les longs timates et les retraits aveugles → les « queues » et les déclassements fantômes.
En chauffant « seulement » 24 heures sur 24.
Initialisation secrète dans le chemin d'accès à la requête (lentisya init> 100 ms - passer à init/cache).

12) Spécificité de l'iGaming/Finance

Chemins d'argent (dépôts/conclusions) : garder provisioned/min instances, SLO séparés, limitation stricte des délais et des répétitions (idempotence obligatoire).
KYC/PSP : API externes instables - envelopper dans queue + worker, sur le front - 202/polling/webhook.
Réglementation et audit : Logs invariables (WORM), journal des événements entrants avec 'Idempotency-Key', corrélation 'trace _ id'.
Data residency : les fonctions qui gèrent les IPI sont déployées dans des comptes/projets régionaux ; pas de cache edge avec PII.

13) Chèque-liste prod-prêt

• Défini par SLI/SLO : p95/p99, part cold, valeurs cibles par itinéraire.
• Inclus provisioned/min instances sur les fonctions critiques ; prévisions de la concarrensi.
• Bandle est minimisé ; les feuilles lourdes sont mises en couches ; lazy-import/initialisation.
• Reuse clients SDK/OBD ; RDS/SQL Proxy configuré ; un pool de connexions.
• VPC uniquement là où vous en avez besoin ; Les IEV/proxy sont optimisés ; secrets via le gestionnaire + cache TTL local.
• Taymauths/dédelines/retraits : backoff + jitter ; seulement les répétitions idempotentes.
• Synthétique "cold' + tests de charge ; alerte sur la croissance de la part cold et p99.
• Runbooks : comment augmenter provisioned, comment changer minScale, comment inclure la dégradation.
• Pour iGaming : SLO/dashboards individuels « money way », Idempotency-Key, audit WORM.

14) TL; DR

Cold start est inévitable, mais nous contrôlons : gardez les instances chaudes là où c'est important, réduisez les bandles, appliquez les connexions lazy-init et reuse, évitez les VPC superflus, supportez les opérations lourdes dans la file d'attente/workers et utilisez edge pour des règles faciles. Pour les voies financières critiques - SLO, idempotence et délais stricts ; mesurez la proportion de cold et incluez l'échauffement uniquement lorsque cela est payant.