Şəbəkə düyünlərini ölçmək
(Bölmə: Ekosistem və Şəbəkə)
1) Düyün rolları və trafik konturları
Doğrulayıcı/prodüser (consensus/block/rollub-sequencer): kritik sonlandırma yolu.
Reader/indeksator (read-only/API/arxiv): proqram və analitik sorğulara xidmət edir.
Releaser/Bridge (cross-domain): domenlər arasında mesajların/aktivlərin köçürülməsi.
Şluz/edge (ingress/gRPC/WebSocket/QUIC): müştəri sorğularının qəbulu, rate-limit, cache.
Tele metriya/müşahidə: metrik/yuva/treys toplamaq, sintetik nümunələr.
Hər bir rol üçün - öz SLO, səhv büdcəsi və miqyas siyasəti.
2) Ölçmə modelləri
2. 1 Şaquli (scale-up)
CPU/RAM/SSD/NIC artırın. Zirvələr üçün sürətli, lakin dəmir ilə məhdudlaşır və trafik vahidinin dəyərini artıra bilər.
2. 2 Üfüqi (scale-out)
Balanslayıcılar/növbələr üçün replikaların əlavə edilməsi. İdempotentlik, sticky-siyasətçi, kvorum və razılaşdırılmış caches (və ya onların əlilliyi) tələb edir.
2. 3 Funksional yayılma
Vəzifə ayrılması: consensus düyünlər təcrid olunur; RPC/API - ayrıca; indeksator/arxiv - ayrıca; bridge/relayer - ayrıca.
2. 4 Geo Skale
Regional klasterlər (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; finalizasiya/gecikmələr və yerli caches ilə replikasiya.
2. 5 Şarding/Partizan
Növbələr/indeksatorlar və sütunlu anbarlar üçün açarlar (chainId, shard, topic).
3) Sorğu yolu: balans, caching, QoS
L4/L7 balans: health-checks, sticky token/trace-id, circuit-breaker, outlier-ejection.
Keşlər:- edge (tez-tez oxunan RPC üçün short-TTL);
- prosessor daxilində (indekslər üçün read-through, write-around);
- mənfi caches (tapılmadı).
- QoS sinifləri: P0 (sonlandırma/körpü/ödənişlər), P1 (ərzaq), P2 (bulk/arxiv).
- Backpressure: tokenlər/kreditlər, concur-sorğuların məhdudlaşdırılması, DLQ ilə növbələr.
- Admissions: pre-filter (auth, limitlər, geo/sanksiyalar), «bahalı» sorğuların erkən rədd edilməsi.
4) Vəziyyətin idarə edilməsi: snapshots, pruninq, arxiv
Full/Pruned: RPC üçün pruned-düyünlər; Arxiv - ayrı bir hovuzda retrospektiv sorğular üçün.
Snapshot/fast-sync: müntəzəm snapshot, sürətli bootstrap yeni replikalar.
Hot/Warm/Cold saxlama: NVMe isti vəziyyət, tarixi bloklar - S3/indeks ilə obyekt.
Garbadge-collect/compaction: planlı pəncərələr, zirvə zamanı deyil.
DA/Batch tamponları (L2/körpülər üçün): çatdırılma zəmanəti və pruf qəbzləri ilə təmizləmə müddəti.
5) Növbələr və axın emalı
Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Konsumer qrupları: partiyalar üzrə miqyaslandırma, idempotent prosessor (outbox/inbox).
DLQ və retrajlar: eksponensial backoff, poison-message karantin.
Razılaşdırılmış prosedur: determinizm üçün partiya çərçivəsində.
6) Nəqliyyat və şəbəkə optimallaşdırma
QUIC/HTTP/2: multiplex, head-of-line korreksiyası.
TCP sazlama: BBR/CUBIC, böyüdülmüş tamponlar, 'SO _ REUSEPORT'.
Kernel/eBPF: tezləşdirilmiş şəbəkə yığın, balans üçün konsistent hash.
NIC offload и pinning IRQ к NUMA.
gRPC: keepalive/ping parametrləri, max-inflight məhdudiyyətləri.
WebSocket: bağlantı hovuzları, ping/pong, müştəriyə abunə məhdudiyyətləri.
7) Etibarlılıq: kvorumlar, deqradasiya, xaos testləri
Oxu/yazma kvorumu (mümkünsə), liderin fensinqi.
Deqradasiya rejimləri: readonly, «yalnız yekunlaşdırılmış», ağır üsulları söndürmək.
Chaos mühəndisliyi: gecikmələr/itkilər, yenidən başlamalar, disk/şəbəkənin nasazlığı, «sürətli reorq» ssenariləri.
8) SLI/SLO və hədəf göstəriciləri
SLI (nümunə):- p95 RPC latency metodları siniflərinə görə;
- Success-rate; Queue-lag p95;
- Time-to-finality p95 (relay/körpülər üçün);
- Snapshot bootstrap time;
- State growth/day; CPU/IO saturation.
- P0 RPC p95 ≤ 400 ms; Availability ≥ 99. 95%;
- Finality relay p95 ≤ 3 dəq;
- Queue-lag P0 p95 ≤ 2 с;
- Bootstrap new reader ≤ 30 мин (fast-sync+snapshot);
- Error budget burn 2 saatlıq pəncərə ≤ 2 ×.
9) Müşahidə və alertinq
Metriklər: latency (histogram), RPS, errors (siniflər üzrə), queue-lag, GC/heap, disk-io, p2p peers, gossip-rate.
Traces: edge → RPC → indeksator → saxlama → körpü vasitəsilə 'trace _ id' vasitəsilə.
Qeydlər: strukturlaşdırılmış, 'request _ id' ilə korrelyasiya.
Alertlər: burn-rate P0, queue-lag, peer-count, reorg-spikes, snapshot-drift.
10) Avtoskeylinq nümunələri
HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; Topiklərin uzunluğuna görə KEDA.
Step-scaling: gündüz zirvələrinin profilləri; Predictive ML/mövsümi.
Warm-spares: trafiksiz qızdırılmış replikalar (graceful promote).
Safe rollout: canary + outlier-ejection + SLO-гейты.
11) Təhlükəsizlik və izolyasiya
mTLS/pinning açarları; RBAC/ABAC metodları; QoS limitləri per org/tenant.
Rate-limit və DoS-shield: ictimai RPC üçün tokenlər, kapçalar, detektiv anomaliyalar.
Gizli idarəetmə: qısa ömürlü tokenlər, rotasiya.
Qum qutuları: arxiv/ictimai müştərilər üçün ayrı boşluqlar.
12) Referans konfiqurasiyası
12. 1 K8s: RPC qapısı (üfüqi miqyaslı)
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: prioritetləşdirmə və 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: domenlərə görə partizan
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 və Limitlər Siyasəti
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) Məlumat sxemləri və sorğu nümunələri
13. 1 Düyün ölçüləri (kataloq)
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-nəzarət və 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 Yük planlaşdırma
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) Əməliyyat qaydaları
Gündəlik: SLO, kapasiti-delta, snapshot vəziyyəti, peer-health.
Həftəlik: limitlərin təftişi/QoS, DR testi (snapshot bootstrap), pruninq və kompakşenlərin yoxlanılması.
Buraxılışdan əvvəl: kanarya rollout, SLO geytaları və müşahidə olunan metriklər, geri dönüş planı.
Dəyər uçotu: CTS per 1k sorğular, TPS_per_$ (dollar başına effektivlik).
15) Playbook hadisələr
A. RPC p95 gecikmə partlayışı
1. P2-throttle aktiv və aşağı sampling; 2) gateway/reader replikaları artırmaq;
2. trafikin bir hissəsini yalnız cache köçürmək; 4) isti metodların analizini açmaq, lazım olduqda - deny-rules.
B. şin Queue-lag> SLO
1. Avtoskeyl konsumerləri (KEDA), 2) partiyalar yenidən bölüşdürün, 3) bulk jobları müvəqqəti dayandırın.
C. validator/releydə peer-count düşməsi
1. p2p modullarının yenidən başlaması, 2) oturacaqların dəyişdirilməsi, 3) şəbəkə ACL/NAT yoxlaması, 4) ehtiyat keçid.
D. Uzun bootstrap yeni replika
1. Təzə snapshot keçid, 2) IO bant genişliyini artırmaq, 3) müvəqqəti arxiv indeksləri çıxarmaq.
E. reorg/körpü gecikmələri
1. K-təsdiq/pəncərə artırmaq, 2) «finalized-only» rejimi yandırmaq, 3) istehlakçıları məlumatlandırmaq.
16) Giriş çek siyahısı
1. Düyünlərin rollarını və onların SLO/səhv büdcələrini müəyyənləşdirin.
2. Funksiyalar: consensus/RPC/indeksator/arxiv/körpü/edge.
3. Balans, QoS, backpressure və DLQ ilə növbə daxil edin.
4. Snapshot/fast-sync, pruning və çox səviyyəli saxlama konfiqurasiya.
5. Metrik/treys/log, dashboard və burn-rate alert qoşun.
6. Avtoskeylinq (HPA/KEDA) və kanarya buraxılışlarını konfiqurasiya edin.
7. Xaos testləri və müntəzəm DR təlimləri keçirin.
8. Əməliyyat qaydaları və dəyər nəzarəti tətbiq edin.
17) Lüğət
Backpressure - həddindən artıq yükləmə zamanı giriş axını idarəetmə mexanizmləri.
DLQ - problemli mesajlar üçün «ölü növbə».
Pruning - mövcud pəncərədən kənarda tarixi vəziyyəti silmək.
Fast-sync/Snapshot - yeni replika sinxronizasiyasının sürətləndirilmiş yolu.
Outlier-ejection - deqradasiyaya uğramış instansiyaların hovuzdan çıxarılması.
Burn-rate - SLO ilə bağlı büdcə xərclərinin sürəti.
Nəticə: şəbəkə qovşaqlarının miqyası yalnız «replika əlavə etmək» deyil, memarlıq, QoS, vəziyyətin idarə edilməsi və əməliyyat sərtliyinin sistem intizamıdır. Bu çərçivəni (rolların bölünməsi, növbələr, keşlər, avtoskeyl, müşahidə və aydın SLO) izləyən ekosistem proqnozlaşdırıla bilən performans, pik müqavimət və vahid trafikə nəzarət olunan qiymət əldə edir.