Масштабирование сетевых узлов
(Раздел: Экосистема и Сеть)
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 и целевые показатели
SLI (пример):- 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→индексатор→хранение→мост.
Логи: структурированные, корреляция по `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: 10012.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: delete12.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), экосистема получает предсказуемую производительность, устойчивость к пикам и контролируемую стоимость на единицу трафика.