Mise à l'échelle des sites réseau

(Section : Écosystème et réseau)

1) Rôles des nœuds et contours du trafic

Validation/production (consensus/block/rollup-sequencer) : un chemin critique de finalisation.
Lecteur/indexeur (read-only/API/archive) : sert les demandes d'applications et les analyses.
Relais/pont (cross-domain) : transfert de messages/actifs entre domaines.
Passerelle/edge (ingress/gRPC/WebSocket/QUIC) : réception des requêtes client, rate-limit, cache.
Métrie/observabilité du corps : collecte de métriques/loges/tracés, échantillons synthétiques.

Pour chaque rôle - propre SLO, budget d'erreur et politique d'échelle.

2) Modèles de mise à l'échelle

2. 1 Vertical (scale-up)

Augmentation du CPU/RAM/SSD/NIC. Rapide pour les pics, mais limité au fer et peut augmenter le coût unitaire du trafic.

2. 2 Horizontal (scale-out)

Ajoute des répliques aux équilibreurs/files d'attente. Exige l'idempotence, les politiques de sticky, le quorum et les caches convenus (ou leur invalidité).

2. 3 Diversité fonctionnelle

Partage des responsabilités : les nœuds consensus sont isolés ; RPC/API - séparément ; indexeur/archive - séparément ; pont/relais - séparément.

2. 4 Géo-skale

Clusters régionaux (EU/US/AP) + anycast/GeoDNS/Latency Aware LB ; réplication avec finalisation/latence et cache local.

2. 5 Charding/partitionnement

Séparation par clé (chainId, shard, topic) pour les files d'attente/indexeurs et les colonnes de stockage.

3) Chemin de requête : équilibrage, mise en cache, QoS

équilibrage L4/L7 : health-checks, sticky par token/trace-id, circuit-breaker, outlier-ejection.

• sur edge (short-TTL pour les RPC souvent lus) ;
• au sein du processeur (read-through, write-around pour les index) ;
• caches négatifs (introuvables).
• Classes QoS : P0 (finalisation/pont/paiements), P1 (produits), P2 (bulk/archives).
• Backpressure : tokens/crédits, limitation des requêtes concur, files d'attente avec DLQ.
• Admissions : pré-filtre (auth, limites, géo/sanctions), rejet précoce des demandes « chères ».

4) Gestion de l'état : snapshots, pruning, archive

Full/Pruned : nœuds pruned pour RPC ; Archive - pour les demandes rétrospectives dans un pool séparé.
Snapshots/fast-sync : snapshots réguliers, bootstrap rapide de nouvelles répliques.
Stockage Hot/Warm/Cold : état chaud sur NVMe, blocs historiques - S3/objet avec index.
Garbadge-collect/compaction : fenêtres planifiées, pas pendant les pics.
Tampons DA/Batch (pour L2/ponts) : garanties de livraison et période de nettoyage avec reçus de pruf.

5) Files d'attente et traitement en continu

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Groupes Consumer : mise à l'échelle par lots, processeur idempotent (outbox/inbox).
DLQ et retraits : backoff exponentiel, quarantaine poison-message.
Ordre convenu : dans le cadre d'un parti pour le déterminisme.

6) Transport et optimisation du réseau

QUIC/HTTP/2 : multiplexage, correction head-of-line.
tuning TCP : BBR/CUBIC, tampons agrandis, 'SO _ REUSEPORT'.
Kernel/eBPF : pile réseau accélérée, hachage constant pour équilibrer.
NIC offload и pinning IRQ к NUMA.
gRPC : paramètres keepalive/ping, limites max-inflight.
WebSocket : pools de connexion, ping/pong, limitation des abonnements client.

7) Fiabilité : quorums, dégradations, tests de chaos

Quorum de lecture/écriture (le cas échéant), fensing leader.
Modes de dégradation : readonly, « finalisé seulement », désactivation des méthodes lourdes.
Chaos-engineering : retards/pertes, redémarrages, panne disque/réseau, scénarios de « vitesse ».

8) SLI/SLO et objectifs

• p95 RPC latitude par classe de méthode ;
• Success-rate; Queue-lag p95;
• Time-to-finality p95 (pour les relais/ponts) ;
• Snapshot bootstrap time;
• State growth/day; CPU/IO saturation.

• P0 RPC p95 ≤ 400 ms ; Availability ≥ 99. 95%;
• Finality relay p95 ≤ 3 min ;
• Queue-lag P0 p95 ≤ 2 с;
• Bootstrap new reader ≤ 30 мин (fast-sync+snapshot);
• Error budget burn par fenêtre de 2 heures ≤ 2 ×.

9) Observabilité et alerting

Métriques : latency (histogramme), RPS, errors (par classe), queue-lag, GC/heap, disk-io, p2p peers, gossip-rate.
Traces : "trace _ id'à travers le edge→RPC→indeksator→khraneniye→most.
Logs : structurés, corrélation par "request _ id'.
Alert : burn-rate P0, queue-lag, peer-count en dessous du seuil, spike reorg, snapshot-drift.

10) Patterns de skating automatique

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; KEDA sur la longueur des tops.
Step-scaling : profils des pics diurnes ; Predictive par ML/saisonnalité.
Warm-spares : répliques chauffées sans trafic (graceful promote).
Safe rollout: canary + outlier-ejection + SLO-гейты.

11) Sécurité et isolation

mTLS/pincement de clés ; RBAC/ABAC sur les méthodes ; Limites de QoS per org/tenant.
Rate-limit et DoS-shield : tokens, gouttes pour RPC publics, anomalie-detect.
Gestion des secrets : jetons à courte durée de vie, rotation.
Bac à sable : pools séparés pour les archives/clients publics.

12) Configurations de référence

12. 1 K8s : passerelle RPC (mise à l'échelle horizontale)

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: rpc-gateway }
spec:
replicas: 6 strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 2, maxUnavailable: 0 } }
selector: { matchLabels: { app: rpc-gateway } }
template:
metadata: { labels: { app: rpc-gateway, qos: P0 } }
spec:
containers:
- name: gateway image: org/rpc-gateway:2. 4. 1 ports: [{ containerPort: 443 }]
resources:
requests: { cpu: "1", memory: "2Gi" }
limits:  { cpu: "4", memory: "6Gi" }
env:
- { name: MAX_CONCURRENCY, value: "400" }
- { name: CACHE_TTL_MS, value: "200" }
readinessProbe: { httpGet: { path: /healthz, port: 443 }, initialDelaySeconds: 5, periodSeconds: 5 }
livenessProbe: { httpGet: { path: /livez, port: 443 }, initialDelaySeconds: 10, periodSeconds: 10 }
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: rpc-gateway-hpa }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: rpc-gateway }
minReplicas: 6 maxReplicas: 36 metrics:
- type: Pods pods:
metric:
name: request_latency_p95_ms target:
type: AverageValue averageValue: 350m  # 350 мс

12. 2 Envoy : priorisation et outlier-ejection

yaml clusters:
- name: readers type: EDS lb_policy: LEAST_REQUEST outlier_detection:
consecutive_5xx: 5 interval: 2s base_ejection_time: 30s circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 20000 max_pending_requests: 5000 max_requests: 20000 health_checks:
- timeout: 1s interval: 3s http_health_check: { path: /healthz }
route_config:
request_headers_to_add:
- header: { key: x-trace-id, value: "%REQ(X-TRACE-ID)%" }
weighted_clusters:
clusters:
- name: readers weight: 100

12. 3 Kafka : répartition par domaine

yaml topic: "rpc. events"
partitions: 48 replicationFactor: 3 config:
retention. ms:  604800000 # 7 days max. message. bytes: 1048576 min. insync. replicas: 2 cleanup. policy: delete

12. 4 Politiques de QoS et limites

yaml qos:
P0:
rps_limit_per_org: 1500 queue_lag_p95_ms: 2000 retry: { attempts: 3, backoff_ms: [100,400,800] }
P1:
rps_limit_per_org: 800
P2:
rps_limit_per_org: 200 admissions:
denylist_methods: ["eth_getLogs(>10k blocks)"]
heavy_query_guard: { max_range_blocks: 5000, require_token: true }

13) Schémas de données et exemples de demandes

13. 1 Métriques de nœuds (catalogue)

sql
CREATE TABLE node_metrics (
ts TIMESTAMPTZ,
node_id TEXT, role TEXT, region TEXT,
rps INT, latency_p95_ms INT, errors_5xx INT,
queue_lag_ms INT, cpu NUMERIC, mem NUMERIC, io_wait NUMERIC
);

13. 2 contrôles SLO et burn-rate

sql
SELECT date_trunc('hour', ts) AS h, role,
AVG(latency_p95_ms) AS p95,
100. 0 SUM(CASE WHEN latency_p95_ms <= 400 THEN 1 ELSE 0 END)/COUNT() AS slo_hit_pct
FROM node_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY 1,2;

13. 3 Planification des charges

sql
SELECT region, role,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY rps) AS rps_p95,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY queue_lag_ms) AS lag_p95
FROM node_metrics
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY region, role;

14) Règlements d'exploitation

Au quotidien : rapport SLO, capasiti delta, état des snapshots, peer-health.
Chaque semaine : révision des limites/QoS, test DR (bootstrap de snapshot), vérification de l'étang et des compaxhen.
Avant la sortie : rollout canarien, SLO-gates et métriques observées, plan de recul.
Comptabilisation des coûts : CTS per 1k demandes, TPS_per_$ (efficacité par dollar).

15) Playbook des incidents

A. Explosion de latence RPC p95

1. Activer le P2-throttle et abaisser le sampling ; 2) augmenter les répliques gateway/reader ;

2. Transférer une partie du trafic vers le cache uniquement ; 4) ouvrir l'analyse des méthodes chaudes, si nécessaire - deny-rules.

B. Queue-lag sur pneumatique> SLO

1. Auto-Skale Consumers (KEDA), 2) redistribuer les lots, 3) arrêter temporairement les jobs bulk.

C. Chute de peer count chez le validateur/relais

1. Redémarrage de p2p modules, 2) changement de siège, 3) vérification du réseau ACL/NAT, 4) mise en réserve.

D. Long bootstrap nouvelle réplique

1. Passer à un nouveau snapshot, 2) augmenter la bande passante IO, 3) retirer temporairement les index d'archives.

E. Spike Reorg/Ponts retardés

1. Augmenter K-confirmations/fenêtre, 2) activer le mode « finalized-only », 3) informer les consommateurs.

16) Chèque de mise en œuvre

1. Définir les rôles des nœuds et leurs budgets SLO/bogues.
2. Porter la fonction : consensus / RPC / l'indexeur / les archives / le pont / edge.
3. Activer l'équilibrage, QoS, backpressure et file d'attente avec DLQ.
4. Configurer les snapshots/fast-sync, le trunk et le stockage hiérarchisé.
5. Connectez les métriques/trajets/logs, dashboards et burn-rate alerts.
6. Configurer le skating automatique (HPA/KEDA) et les versions canaries.
7. Effectuer des tests de chaos et des exercices de DR réguliers.
8. Introduire les règlements opérationnels et le contrôle de la valeur.

17) Glossaire

Backpressure - Mécanismes de contrôle du flux d'entrée en cas de surcharge.
DLQ est la « file d'attente morte » pour les messages problématiques.
Pruning : supprime l'état historique en dehors de la fenêtre actuelle.
Fast-sync/Snapshot est un moyen accéléré de synchroniser une nouvelle réplique.
Outlier-ejection est l'exclusion des instances dégradées du pool.
Burn-rate est le taux de consommation du budget d'erreur par rapport au SLO.

Résultat : la mise à l'échelle des nœuds de réseau n'est pas seulement « ajouter une réplique », mais aussi la discipline système de l'architecture, de la QoS, de la gestion de l'état et de la rigueur opérationnelle. En suivant ce cadre (répartition des rôles, files d'attente, caches, scale automatique, observabilité et SLO clair), l'écosystème obtient des performances prévisibles, une résistance aux pics et un coût par unité de trafic contrôlé.