Scalabilità dei siti di rete

(Sezione Ecosistema e Rete)

1) Ruoli di sito e tracciati di traffico

Value/Product (consensus/block/rollup-sequencer) è un percorso di finalizzazione critico.
Reader/indice (read-only/API/archivio) - Gestisce le richieste di applicazioni e analisi.
Releier/ponte (cross-domain) - Sposta messaggi/asset tra domini.
Gateway/edge (ingress/gRPC/WebSocket/QUIC) - Accetta richieste client, rate-limit, cache.
Metria/osservazione corpo - raccolta di metriche/loghi/roulotte, campioni sintetici.

Per ogni ruolo: SLO personalizzato, bilancio degli errori e criteri di scalabilità.

2) Modelli di zoom

2. 1 Verticale (scale-up)

Aumento CPU/RAM/SSD/NIC. Veloce per picchi, ma limitato al ferro e può aumentare il costo dell'unità di traffico.

2. 2 Orizzontale (scale-out)

Aggiunge repliche dietro bilanciatori/code. Richiede idempotenza, sticky policy, quorum e cache coerente (o la loro invalidità).

2. 3 Esplosione funzionale

Separazione dei compiti: i nodi consensus vengono isolati; RPC/API separatamente; indice/archivio, separatamente; bridge/relayer - separato.

2. 4 Geo-scale

Cluster regionali (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; replica con finalizzazione/ritardo e cache locale.

2. 5 Sharding/partitura

Separazione in chiave (chainId, shard, topic) per code/indicizzatori e depositi invertebrati.

3) Percorso query: bilanciamento, cache, QoS

Bilanciamento L4/L7: health-checks, sticky per token/trace-id, circuito-breaker, outler-ejection.

• su edge (short-TTL per RPC spesso letti)
• all'interno del processore (read-through, write-around per gli indici)
• cache negativa (non trovata).
• Classi QoS: P0 (finalizzazione/ponte/pagamento), P1 (alimentari), P2 (bulk/archivio).
• Backpressure: token/crediti, limitazione delle richieste concur, code con DLQ.
• Admissi - Filtro pre (auth, limiti, geo/sanzioni), rigetto precoce di query «costose».

4) Gestione dello stato: snapshot, pruning, archivio

Full/Pruned: nodi pruned per RPC; Archive - per le query retrospettive in un pool separato.
Snapshot/fast-sync: snapshot regolari, bootstrap veloce nuove repliche.
Hot/Warm/Cold Storage: stato caldo su NVMe, blocchi storici - S3/oggetto con indici.
Garbadge-collect/competition - finestre pianificate, non durante i picchi.
DA/Batch buffer (per L2/ponti) - Garanzia di consegna e periodo di pulizia con ricevute.

5) Code e streaming

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Gruppi di notebook: scalabilità per partenze, elaboratore idropotente (outbox/inbox).
DLQ e retrai: backoff esponenziale, quarantena poison-messaggistica.
Ordine coerente, all'interno della partitura per il determinismo.

6) Trasporti e ottimizzazioni di rete

QUIC/HTTP/2: multiplexing, correzione head-of-line.
Sintonizzatore TCP: BBR/CUBIC, buffer ingranditi, 'SO _ REUSEPORT'.
Kernel/eBPF: stack di rete accelerato, hash consistenziale per il bilanciamento.
NIC offload и pinning IRQ к NUMA.
gRPC: impostazioni keepalive/ping, limiti max-influight.
WebSocket: pool di connessione, ping/pong, vincolo di sottoscrizione per client.

7) Affidabilità: quorum, degrado, test di caos

Quorum di lettura/scrittura (se applicabile), fensing del leader.
Modalità di degrado: readonly, «solo finalizzati», disattivazione dei metodi pesanti.
Ingegneria Chaos: ritardi/perdite, riavvio, guasto del disco/rete, script «rapido».

8) SLI/SLO e target

• p95 RPC latency per classe di metodi;
• Success-rate; Queue-lag p95;
• Time-to-finality p95 (per rapporti/ponti)
• Snapshot bootstrap time;
• State growth/day; CPU/IO saturation.

• P0 RPC p95 da 400 ms; Availability ≥ 99. 95%;
• Finality relay p95 ≤ 3 min;
• Queue-lag P0 p95 ≤ 2 с;
• Bootstrap new reader ≤ 30 мин (fast-sync+snapshot);
• Errore budget burn su 2 ore di finestra 2 x.

9) Osservabilità e alerting

Metriche: latency (historogram), RPS, errors (classi), queue-lag, GC/heap, disk-io, p2p peers, gossip-rate.
Trade: trace _ id attraverso il edge→RPC→indeksator→khraneniye→most.
Fogli: strutturati, correlazione per 'sollest _ id'.
Alert: burn-rate P0, queue-lag, peer-count sotto la soglia, reorg-spiegamenti, snapshot-draft.

10) Pattern di skateling automatico

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; KEDA sulla lunghezza dei topic.
Profili di picchi diurni Step-scaling Predictive per ML/stagionalità.
Warm-spares - repliche riscaldate senza traffico (graceful promote).
Safe rollout: canary + outlier-ejection + SLO-гейты.

11) Sicurezza e isolamento

mTLS/pinning chiavi RBAC/ABAC sui metodi; Limiti QoS per org/tenant.
Rate-limit e DoS-shield: token, gocce per RPC pubblici, anomalia-oggetto.
Gestione segreto: token a breve vita, rotazione.
Cassette di sabbia: pool separati per archivi/clienti pubblici.

12) Configurazione arbitrale

12. 1 K8s: gateway RPC (ridimensionamento orizzontale)

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 Avvoy: priorità e outler-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: partizionamento per domini

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 Criteri di QoS e limiti

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) Schemi di dati e esempi di query

13. 1 Metriche nodi (directory)

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 controllo SLO e 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 Pianificazione di carico

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) Regolamenti operativi

Ogni giorno: rapporto SLO, capasiti delta, stato snapshot, peer-health.
Ogni settimana: revisione dei limiti/QoS, test DR (bootstrap da snapshot), verifica dei pruning e dei compagini.
Prima del lancio, rollout canario, gate SLO e metriche osservabili, piano di recupero.
Conteggio dei costi: CTS per 1k richieste, TPS _ per _ $ (efficienza per dollaro).

15) Playbook incidenti

A. Esplosione di latitanza RPC p95

1. Abilita P2-throttle e abbassa sampling; 2) aumentare le repliche gateway/reader;

2. Trasferire parte del traffico alla cache solo 4) aprire l'analisi dei metodi hot, se necessario - deny-rule.

B. Queue-lag su pneumatico> SLO

1. Scale automatico dei costruttori (KEDA), 2) ridistribuire le partenze, 3) interrompere temporaneamente i boolk-jobs.

C. Caduta di peer-count al valico/release

1. Riavvia p2p moduli, 2) cambio sedili, 3) controllo ACL/NAT di rete, 4) cambio a riserva.

D. Bootstrap lunga nuova replica

1. Passare al nuovo snapshot, 2) aumentare la larghezza di banda IO, 3) rimuovere temporaneamente gli indici di archiviazione.

E. Spike reorg/ritardi di ponte

1. Aumenta le conferme K/finestra, 2) abilita finalization-only, 3) informare i consumatori.

16) Assegno-foglio di implementazione

1. Identificare i ruoli dei nodi e i relativi SLO/budget degli errori.
2. Disattiva funzioni: consensus/RPC/indicizzatore/archivio/ponte/edge.
3. Attiva bilanciamento, QoS, backpressure e coda con DLQ.
4. Configura snapshot/fast-sync, pruning e storage su più livelli.
5. Collegare metriche/roulotte/logi, dashboard e burn-rate alert.
6. Configura scale automatico (HPA/KEDA) e release canarie.
7. Eseguire test di caos e esercitazioni DR regolari.
8. Immettere regolamenti operativi e controllo dei costi.

17) Glossario

Backpressure - Meccanismi di controllo del flusso di input in caso di sovraccarico.
DLQ - Coda morta per messaggi problematici.
Pruning - Rimozione dello stato storico fuori dalla finestra attuale.
Fast-sync/Snapshot è un modo più rapido per sincronizzare la nuova replica.
Outler-ejection - Esclude le istanze degradate dal pool.
Burn-rate - la velocità di flusso del budget degli errori rispetto a SLO.

La scalabilità dei nodi di rete non è solo un'aggiunta di repliche ", ma una disciplina di sistema per l'architettura, la gestione dello stato e il rigore operativo. Seguendo questo framework (separazione dei ruoli, code, cache, scale automatico, osservabilità e SLO), l'ecosistema ottiene prestazioni prevedibili, resistenza ai picchi e costi controllati per unità di traffico.