Масштабування мережевих вузлів

(Розділ: Екосистема та Мережа)

1) Ролі вузлів і контури трафіку

Валідуючі/продюсуючі (consensus/block/rollup-sequencer): критичний шлях фіналізації.
Рідер/індексатор (read-only/API/архів): обслуговує запити додатків та аналітики.
Релеєр/міст (cross-domain): перенесення повідомлень/активів між доменами.
Шлюз/edge (ingress/gRPC/WebSocket/QUIC): прийом клієнтських запитів, rate-limit, кеш.
Теле метрія/спостережуваність: збір метрик/логів/трейсів, синтетичні проби.

Для кожної ролі - власні SLO, бюджет помилок і політика масштабування.

2) Моделі масштабування

2. 1 Вертикальне (scale-up)

Збільшення CPU/RAM/SSD/NIC. Швидко для піків, але обмежена залізом і може підвищувати вартість одиниці трафіку.

2. 2 Горизонтальне (scale-out)

Додавання реплік за балансувальниками/чергами. Вимагає ідемпотентності, sticky-політик, кворуму та узгоджених кешів (або їх інвалідації).

2. 3 Функціональне рознесення

Поділ обов'язків: consensus вузли ізолюються; RPC/API - окремо; індексатор/архів - окремо; bridge/relayer - окремо.

2. 4 Гео-скейл

Регіональні кластери (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; реплікація з фіналізацією/затримками та місцевими кешами.

2. 5 Шардинг/партіонування

Розділення за ключами (chainId, shard, topic) для черг/індексаторів і колонкових сховищ.

3) Шлях запиту: балансування, кешування, QoS

L4/L7 балансування: health-checks, sticky по токену/trace-id, circuit-breaker, outlier-ejection.

• на edge (short-TTL для часто читаних RPC);
• усередині процесора (read-through, write-around для індексів);
• негативні кеші (не знайдено).
• QoS-класи: P0 (фіналізація/міст/виплати), P1 (продуктові), P2 (bulk/архів).
• Backpressure: токени/кредити, обмеження concur-запитів, черги з DLQ.
• Admissions: pre-фільтр (auth, ліміти, гео/санкції), раннє відхилення «дорогих» запитів.

4) Управління станом: снапшоти, прунінг, архів

Full/Pruned: pruned-вузли для RPC; Archive - для ретроспективних запитів в окремому пулі.
Снапшоти/fast-sync: регулярні снапшоти, швидкий bootstrap нових реплік.
Hot/Warm/Cold зберігання: гарячий стан на NVMe, історичні блоки - S3/об'єктне з індексами.
Гарbadge-collect/compaction: планові вікна, не під час піків.
DA/Batch-буфери (для L2/мостів): гарантії доставки та період очищення з пруф-квитанціями.

5) Черги та потокова обробка

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Консьюмер-групи: масштабування по партіях, ідемпотентний обробник (outbox/inbox).
DLQ і ретраї: експоненційний backoff, poison-message карантин.
Узгоджений порядок: в рамках партії для детермінізму.

6) Транспорт і мережеві оптимізації

QUIC/HTTP/2: мультиплексування, head-of-line корекція.
TCP-тюнінг: BBR/CUBIC, збільшені буфери,'SO _ REUSEPORT'.
Kernel/eBPF: прискорений мережевий стек, консистентний хеш для балансування.
NIC offload и pinning IRQ к NUMA.
gRPC: параметри keepalive/ping, обмеження max-inflight.
WebSocket: пули з'єднань, ping/pong, обмеження підписок на клієнта.

7) Надійність: кворуми, деградація, хаос-тести

Кворум читання/запису (якщо застосовується), фенсинг лідера.
Деградаційні режими: readonly, «тільки фіналізовані», вимкнення важких методів.
Chaos-інженерія: затримки/втрати, перезапуски, відмова диска/мережі, «швидкісний реорг» сценарії.

8) SLI/SLO та цільові показники

• p95 RPC latency за класами методів;
• Success-rate; Queue-lag p95;
• Time-to-finality p95 (для релеїв/мостів);
• Snapshot bootstrap time;
• State growth/day; CPU/IO saturation.

• P0 RPC p95 ≤ 400 мс; Availability ≥ 99. 95%;
• Finality relay p95 ≤ 3 хв;
• Queue-lag P0 p95 ≤ 2 с;
• Bootstrap new reader ≤ 30 мин (fast-sync+snapshot);
• Error budget burn по 2-годинному вікну ≤ 2 ×.

9) Спостережуваність і алертинг

Метрики: latency (histogram), RPS, errors (по классам), queue-lag, GC/heap, disk-io, p2p peers, gossip-rate.
Трейси: наскрізний'trace _ id'через edge→RPC→indeksator→khraneniye→most.
Логи: структуровані, кореляція по'request _ id'.
Алерти: burn-rate P0, queue-lag, peer-count нижче порога, reorg-спайки, snapshot-drift.

10) Патерни автоскейлінгу

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; KEDA по довжині топіків.
Step-scaling: профілі денних піків; Predictive по ML/сезонності.
Warm-spares: прогріті репліки без трафіку (graceful promote).
Safe rollout: canary + outlier-ejection + SLO-гейти.

11) Безпека та ізоляція

mTLS/пінінг ключів; RBAC/ABAC на методи; QoS-ліміти per org/tenant.
Rate-limit и DoS-shield: токени, капчі для публічних RPC, аномалія-детект.
Секрет-менеджмент: короткоживучі токени, ротація.
Пісочниці: роздільні пуули для архів/публічних клієнтів.

12) Референс-конфігурації

12. 1 K8s: RPC-шлюз (горизонтальне масштабування)

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: пріоритизація та 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: партіонування по доменах

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 і лімітів

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) Схеми даних і приклади запитів

13. 1 Метрики вузлів (каталог)

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-контроль і 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 Навантажувальне планування

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) Експлуатаційні регламенти

Щодня: звіт по SLO, капасіті-дельта, стан снапшотів, peer-health.
Щотижня: ревізія лімітів/QoS, тест DR (bootstrap зі снапшоту), перевірка прунінгу і компакшенів.
Перед релізом: канарний rollout, SLO-гейти і спостережувані метрики, план відкату.
Облік вартості: CTS per 1k запитів, TPS_per_$ (ефективність на долар).

15) Playbook інцидентів

A. вибух латентності RPC p95

1. Включити P2-throttle і знизити sampling; 2) збільшити репліки gateway/reader;

2. перевести частину трафіку на кеш-тільки; 4) відкрити аналіз гарячих методів, при необхідності - deny-rules.

B. queue-lag на шині> SLO

1. Автоскейл консьюмерів (KEDA), 2) перерозподілити партії, 3) тимчасово зупинити bulk-джоби.

C. Падіння peer-count у валідатора/релєєва

1. Перезапуск p2p модулів, 2) зміна сидів, 3) перевірка мережевих ACL/NAT, 4) перемикання на резерв.

D. довгий bootstrap нової репліки

1. Переключитися на свіжий снапшот, 2) підняти пропускну здатність IO, 3) тимчасово зняти архівні індекси.

E. Спайк reorg/мостових затримок

1. Збільшити K-підтверджень/вікно, 2) включити режим «finalized-only», 3) інформувати споживачів.

16) Чек-лист впровадження

1. Визначити ролі вузлів і їх SLO/бюджети помилок.
2. Рознести функції: consensus/RPC/індексатор/архів/міст/edge.
3. Включити балансування, QoS, backpressure і чергу з DLQ.
4. Налаштувати снапшоти/fast-sync, прунінг і багаторівневе зберігання.
5. Підключити метрики/трейси/логи, дашборди і burn-rate алерти.
6. Налаштувати автоскейлінг (HPA/KEDA) і канарські релізи.
7. Провести хаос-тести і регулярні DR-навчання.
8. Ввести операційні регламенти і контроль вартості.

17) Глосарій

Backpressure - механізми управління вхідним потоком при перевантаженні.
DLQ - «мертва черга» для проблемних повідомлень.
Pruning - видалення історичного стану поза актуального вікна.
Fast-sync/Snapshot - прискорений спосіб синхронізації нової репліки.
Outlier-ejection - виключення деградованих інстансів з пулу.
Burn-rate - швидкість витрати бюджету помилок щодо SLO.

Підсумок: масштабування мережевих вузлів - це не тільки «додати реплік», а системна дисципліна архітектури, QoS, управління станом і операційної строгості. Слідуючи цьому фреймворку (поділ ролей, черги, кеші, автоскейл, спостережуваність і чіткі SLO), екосистема отримує передбачувану продуктивність, стійкість до піків і контрольовану вартість на одиницю трафіку.