Skalierung von Netzwerkknoten

(Abschnitt: Ökosystem und Netzwerk)

1) Knotenrollen und Verkehrskonturen

Validieren/Produzieren (Consensus/Block/Rollup-Sequencer): der kritische Weg der Finalisierung.
Reader/Indexer (nur lesen/API/Archiv): Dient Anwendungs- und Analyseanfragen.
Relayer/Bridge (Cross-Domain): Übertragung von Nachrichten/Assets zwischen Domains.
Gateway/edge (ingress/gRPC/WebSocket/QUIC): Empfang von Client-Anfragen, Rate-Limit, Cache.
Körpermetrik/Beobachtbarkeit: Sammlung von Metriken/Logs/Traces, synthetische Proben.

Für jede Rolle gibt es ein eigenes SLO, ein Fehlerbudget und eine Skalierungsrichtlinie.

2) Skalierungsmodelle

2. 1 Vertikal (scale-up)

CPU/RAM/SSD/NIC-Vergrößerung. Schnell für Spitzen, aber begrenzt durch Hardware und kann die Kosten der Verkehrseinheit erhöhen.

2. 2 Horizontal (scale-out)

Hinzufügen von Replikaten hinter Balancern/Warteschlangen. Erfordert Idempotenz, Sticky Policies, Quorum und konsistente Caches (oder deren Behinderung).

2. 3 Funktionsabstand

Aufgabenteilung: consensus Knoten sind isoliert; RPC/API - separat; Indexer/Archiv - separat; bridge/relayer - separat.

2. 4 Geo-Scale

Regionale Cluster (EU/US/AP) + Anycast/GeoDNS/Latency Aware LB; Replikation mit Finalisierung/Latenz und lokalen Caches.

2. 5 Scharding/Partitionierung

Schlüsseltrennung (chainId, shard, topic) für Warteschlangen/Indexer und Säulenspeicher.

3) Anfragepfad: Balancing, Caching, QoS

L4/L7 balancing: health-checks, sticky by token/trace-id, circuit-breaker, outlier-ejection.

• am Rand (short-TTL für häufig gelesene RPCs);
• innerhalb des Prozessors (read-through, write-around für Indizes);
• negative Caches (nicht gefunden).
• QoS-Klassen: P0 (Finalisierung/Bridge/Auszahlung), P1 (Produkt), P2 (Masse/Archiv).
• Backpressure: Token/Credits, Einschränkung von Concur-Anfragen, Warteschlangen mit DLQ.
• Admissions: Pre-Filter (auth, limits, geo/sanctions), frühzeitige Ablehnung von „teuren“ Anfragen.

4) Zustandsmanagement: Schnappschüsse, Pruning, Archiv

Full/Pruned: Pruned-Knoten für RPC; Archiv - für rückblickende Anfragen in einem separaten Pool.
Schnappschüsse/Fast-Sync: regelmäßige Schnappschüsse, schnelles Bootstrap neuer Replikate.
Hot/Warm/Cold Storage: Heißer Zustand auf NVMe, historische Blöcke - S3/Objekt mit Indizes.
Garbadge-collect/compaction: geplante Fenster, nicht während der Spitzen.
DA/Batch-Puffer (für L2/Brücken): Liefergarantien und Reinigungszeitraum mit Prüfbelegen.

5) Warteschlangen und Streaming-Verarbeitung

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Consumer-Gruppen: Skalierung nach Partitionen, idempotenter Handler (outbox/inbox).
DLQ und Retrays: exponentieller Backoff, Poison-Message-Quarantäne.
Vereinbarte Ordnung: innerhalb der Partei für Determinismus.

6) Transport- und Netzwerkoptimierungen

QUIC/HTTP/2: Multiplexing, Head-of-Line-Korrektur.
TCP-Tuning: BBR/CUBIC, erhöhte Puffer, 'SO _ REUSEPORT'.
Kernel/eBPF: beschleunigter Netzwerk-Stack, konsistenter Hash zum Ausgleich.
NIC offload и pinning IRQ к NUMA.
gRPC: keepalive/ping Parameter, max-inflight Einschränkungen.
WebSocket: Verbindungspools, Ping/Pong, Begrenzung der Abonnements pro Client.

7) Zuverlässigkeit: Quorums, Degradation, Chaos-Tests

Lese-/Schreibquorum (falls zutreffend), Leader-Fensing.
Degradierungsmodi: readonly, „nur finalisiert“, Abschaltung schwerer Methoden.
Chaos-Engineering: Verzögerungen/Verluste, Neustarts, Festplatten-/Netzwerkfehler, „High-Speed-Reorg“ -Szenarien.

8) SLI/SLO und Ziele

• p95 RPC-Latenz nach Methodenklassen;
• Success-rate; Queue-lag p95;
• Time-to-finality p95 (für Relais/Brücken);
• Snapshot bootstrap time;
• State growth/day; CPU/IO saturation.

• P0 RPC p95 ≤ 400 ms Availability ≥ 99. 95%;
• Finality Relay p95 ≤ 3 Minuten
• Queue-lag P0 p95 ≤ 2 с;
• Bootstrap new reader ≤ 30 мин (fast-sync+snapshot);
• Error budget burn durch das 2-Stunden-Fenster ≤ 2 ×.

9) Beobachtbarkeit und Alarmierung

Metriken: Latenz (Histogramm), RPS, errors (nach Klassen), queue-lag, GC/heap, disk-io, p2p peers, gossip-rate.
Traces: Ende-zu-Ende' trace _ id 'durch die edge→RPC→indeksator→khraneniye→most.
Logs: strukturiert, Korrelation durch 'request _ id'.
Alerts: burn-rate P0, queue-lag, peer-count unter der Schwelle, reorg-spikes, snapshot-drift.

10) Auto-Scale-Muster

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; KEDA durch die Länge der Spitzen.
Step-Scaling: Profile von Tagesspitzen; Predictive durch ML/Saisonalität.
Warm-spares: erwärmte Repliken ohne Verkehr (graceful promote).
Safe rollout: canary + outlier-ejection + SLO-гейты.

11) Sicherheit und Isolierung

mTLS/Schlüsselpinning; RBAC/ABAC auf Methoden; QoS-Limits per org/tenant.
Rate-Limit und DoS-Shield: Token, Captchas für öffentliche RPCs, Anomalie-Detect.
Secret Management: kurzlebige Token, Rotation.
Sandboxes: separate Pools für Archive/öffentliche Kunden.

12) Referenzkonfigurationen

12. 1 K8s: RPC-Gateway (horizontale Skalierung)

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: Priorisierung und 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: Partitionierung nach Domains

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 QoS und Limits

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) Datenschemata und Beispielabfragen

13. 1 Knotenmetriken (Katalog)

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 SLO-Steuerung und 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 Lastplanung

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) Betriebsvorschriften

Täglich: SLO-Bericht, Capacity-Delta, Snap-Shots-Status, Peer-Health.
Wöchentlich: Limit-/QoS-Revision, DR-Test (Bootstrap aus Snap-Shot), Überprüfung von Pruning und Compaksen.
Vor der Veröffentlichung: Kanarienrollout, SLO-Gates und beobachtbare Metriken, Rollback-Plan.
Kostenrechnung: CTS per 1k Anfragen, TPS_per_$ (Effizienz pro Dollar).

15) Playbook der Vorfälle

A. Latenzexplosion RPC p95

1. Aktivieren Sie P2-throttle und senken Sie die sampling; 2) Vergrößern Sie die Gateway/Reader-Repliken;

2. Übertragen Sie einen Teil des Datenverkehrs auf Cache-only; 4) Öffnen Sie die Analyse der heißen Methoden, falls erforderlich - deny-rules.

B. Queue-lag auf dem Bus> SLO

1. Auto-Scale Consumer (KEDA), 2) Parteien neu verteilen, 3) Bulk-Jobs vorübergehend stoppen.

C. Fallender Peer-Count im Validator/Relay

1. Neustart der p2p-Module, 2) Wechsel der Sitze, 3) Überprüfung der Netzwerk-ACL/NAT, 4) Umschaltung auf Reserve.

D. Lange bootstrap neue Replik

1. Wechseln Sie zu einem frischen Snapshot, 2) erhöhen Sie die IO-Bandbreite, 3) entfernen Sie vorübergehend archivierte Indizes.

E. Spike reorg/Brückenverzögerungen

1. K-Bestätigungen/Fenster vergrößern, 2) Modus „nur finalisiert“ aktivieren, 3) Verbraucher informieren.

16) Checkliste Umsetzung

1. Definieren Sie die Rollen der Knoten und deren SLOs/Fehlerbudgets.
2. Die Funktionen zu verbreiten: consensus / RPC / indeksator / Archiv / Brücke / edge.
3. Aktivieren Sie Balancing, QoS, Backpressure und Queue mit DLQ.
4. Konfigurieren Sie Snapshots/Fast-Sync, Pruning und Tiering.
5. Verbinden Sie Metriken/Traces/Protokolle, Dashboards und Burn-Rate-Alerts.
6. Konfigurieren Sie Auto-Scaling (HPA/KEDA) und Kanarienfreigaben.
7. Durchführung von Chaos-Tests und regelmäßigen DR-Übungen.
8. Einführung von Betriebsvorschriften und Kostenkontrolle.

17) Glossar

Backpressure - Mechanismen zur Steuerung des Eingangsstroms bei Überlastung.
DLQ ist eine „tote Warteschlange“ für problematische Nachrichten.
Pruning - Löscht den historischen Zustand außerhalb des aktuellen Fensters.
Fast-Sync/Snapshot ist eine beschleunigte Möglichkeit, ein neues Replikat zu synchronisieren.
Outlier-ejection - Schließt degradierte Instances aus dem Pool aus.
Burn-Rate - Die Rate des Fehlerbudgets im Verhältnis zum SLO.

Fazit: Bei der Skalierung von Netzwerkknoten geht es nicht nur um das „Hinzufügen von Replikaten“, sondern um die Systemdisziplin Architektur, QoS, Condition Management und Operational Strength. Nach diesem Framework (Rollenteilung, Warteschlangen, Caches, Auto-Scale, Beobachtbarkeit und klare SLOs) erhält das Ökosystem vorhersehbare Leistung, Peak-Resistenz und kontrollierte Kosten pro Traffic-Einheit.