GH GambleHub

Желілік тораптарды масштабтау

(Бөлім: Экожүйе және Желі)

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 (жиі оқылатын RPC үшін short-TTL);
  • процессордың ішінде (индекстер үшін read-through, write-around);
  • теріс кэштер (табылмады).
  • QoS-сыныптар: P0 (аяқтау/көпір/төлемдер), P1 (азық-түлік), P2 (bulk/мұрағат).
  • Backpressure: токендер/кредиттер, concur-сұрауларды шектеу, DLQ кезектері.
  • Admissions: pre-сүзгі (auth, лимиттер, гео/санкциялар), «қымбат» сұрауларды ерте қабылдамау.

4) Жай-күйін басқару: снапшот, прунинг, мұрағат

Full/Pruned: RPC үшін pruned-тораптар; Archive - жеке пулдағы ретроспективті сұрау үшін.
Snapshotlar/fast-sync: тұрақты snapshotlar, жылдам bootstrap жаңа репликалар.
Hot/Warm/Cold сақтау: NVMe ыстық күйі, тарихи блоктар - S3/индекстері бар объекті.
Garbadge-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.
SLO (бағдарлар):
  • 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: 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. 2) партияларды қайта бөлу, 3) bulk-джобтарды уақытша тоқтату.

С, Валидатордағы/релеевтегі 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. Snapshot/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) сүйене отырып, экожүйе болжамды өнімділікті, шыңға төзімділікті және трафик бірлігіне бақыланатын құнды алады.

Contact

Бізбен байланысыңыз

Кез келген сұрақ немесе қолдау қажет болса, бізге жазыңыз.Біз әрдайым көмектесуге дайынбыз!

Telegram
@Gamble_GC
Интеграцияны бастау

Email — міндетті. Telegram немесе WhatsApp — қосымша.

Сіздің атыңыз міндетті емес
Email міндетті емес
Тақырып міндетті емес
Хабарлама міндетті емес
Telegram міндетті емес
@
Егер Telegram-ды көрсетсеңіз — Email-ге қоса, сол жерге де жауап береміз.
WhatsApp міндетті емес
Пішім: +ел коды және номер (мысалы, +7XXXXXXXXXX).

Батырманы басу арқылы деректерді өңдеуге келісім бересіз.