ქსელის კვანძების მასშტაბები

(განყოფილება: ეკოსისტემა და ქსელი)

1) კვანძების და ტრაფიკის კონტურების როლები

Consensus/block/rollup-sequencer): ფინალიზაციის კრიტიკული გზა.
რიდერი/ინდექსატორი (read-only/API/არქივი): ემსახურება განაცხადებისა და ანალიტიკის მოთხოვნებს.
მიმღები/ხიდი: დომენებს შორის შეტყობინებების/აქტივების გადაცემა.
კარიბჭე/edge (ingress/gRPC/WebSocket/QUIC): კლიენტის მოთხოვნების მიღება, საბაზო-ლიმიტი, ქეში.
მეტრიუმის სხეული/დაკვირვება: მეტრიკის/ლოგოების/ტრეისების შეგროვება, სინთეზური ნიმუშები.

თითოეული როლისთვის - საკუთარი SLO, შეცდომების ბიუჯეტი და მასშტაბის პოლიტიკა.

2) მასშტაბის მოდელები

2. 1 ვერტიკალური (სკალარული)

ზრდა CPU/RAM/SSD/NIC. სწრაფად მწვერვალებისთვის, მაგრამ შემოიფარგლება რკინით და შეუძლია გაზარდოს ტრეფიკის ერთეულის ღირებულება.

2. 2 ჰორიზონტალური

რეპლიკების დამატება დაბალანსებული/რიგებისთვის. მოითხოვს idempotence, sticky პოლიტიკოსი, კვორუმი და შეთანხმებული ქეში (ან მათი ინვალიდობა).

2. 3 ფუნქციონალური გავრცელება

პასუხისმგებლობის გამიჯვნა: consensus კვანძები იზოლირებულია; RPC/API - ცალკე; ინდექსატორი/არქივი - ცალკე; bridge/relayer - ცალკე.

2. 4 Geo Skale

რეგიონალური მტევანი (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; რეპლიკაცია ფინალიზაციით/შეფერხებებით და ადგილობრივი ქეშებით.

2. 5 შარდინგი/პარტიზანული

დაყოფა კლავიშებზე (chainid, shard, topic) რიგების/ინდექსატორებისა და სვეტების საცავებისთვის.

3) მოთხოვნის გზა: დაბალანსება, ქეშირება, QoS

L4/L7 დაბალანსება: health checks, docky/trace-id, circuit-breaker, outlier-ejection.

• edge (მოკლე TTL ხშირად წაკითხული RPC);
• პროცესორის შიგნით (read-through, write-around ინდექსებისთვის);
• უარყოფითი ქეში (არ არის ნაპოვნი).
• QoS კლასები: P0 (ფინალიზაცია/ხიდი/გადახდა), P1 (საკვები), P2 (bulk/არქივი).
• Backpressure: ნიშნები/სესხები, concur მოთხოვნების შეზღუდვა, ხაზები DLQ- ით.
• Admissions: pre ფილტრი (aut, limits, geo/სანქციები), „ძვირადღირებული“ მოთხოვნების ადრეული გადახრა.

4) სახელმწიფო კონტროლი: სნაიპშოტები, პრუინინგი, არქივი

Full/Pruned: pruned კვანძები RPC- სთვის; Archive - რეტროსპექტული მოთხოვნებისთვის ცალკეულ აუზში.
Snapshots/fast-sync: რეგულარული snepshots, სწრაფი bootstrap ახალი რეპლიკები.
Hot/Warm/Cold: ცხელი მდგომარეობა NVMe- ზე, ისტორიული ბლოკები - S3/ობიექტი ინდექსებით.
Garbadge-collection/compaction: დაგეგმილი ფანჯრები, არა მწვერვალების დროს.
DA/Batch ბუფერები (L2/ხიდისთვის): მიწოდების გარანტიები და გაწმენდის პერიოდი პრუფის ქვითრებით.

5) რიგები და ნაკადის დამუშავება

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Consumer band: წვეულებების მასშტაბები, idempotent დამუშავება (outbox/inbox).
DLQ და retrai: ექსპონენციალური backoff, poison მესინჯერი კარანტინი.
შეთანხმებული ბრძანება: როგორც დეტერმინიზმის ნაწილი.

6) ტრანსპორტი და ქსელის ოპტიმიზაცია

QUIC/HTTP/2: მულტიპლექსაცია, head-of-line კორექტირება.
TCP tuning: BBR/CUBIC, გაზრდილი ბუფერები, 'SO _ REUSEPORT'.
Kernel/eBPF: დაჩქარებული ქსელის დასტის, თანმიმდევრული ჰაში დაბალანსებისთვის.
NIC offload и pinning IRQ к NUMA.
GRPC: keepalive/ping პარამეტრები, შეზღუდვები max-inflight.
WebSocket: კავშირების აუზები, პინგ/პონგი, კლიენტზე ხელმოწერების შეზღუდვა.

7) საიმედოობა: კვორუმი, დეგრადაცია, ქაოსის ტესტები

კითხვის/ჩაწერის კვორუმი (თუ გამოიყენება), ლიდერის ფენსინგი.
დეგრადაციის რეჟიმები: readonly, „მხოლოდ ფინალიზაცია“, მძიმე მეთოდების გამორთვა.
Chaos ინჟინერია: შეფერხებები/დანაკარგები, გადატვირთვა, დისკის/ქსელის უკმარისობა, სცენარის „მაღალსიჩქარიანი რეორდი“.

8) SLI/SLO და სამიზნეები

• p95 RPC ლიტერატურა მეთოდების კლასებში;
• Success-rate; Queue-lag p95;
• დრო finality p95 (რელიებისთვის/ხიდებისთვის);
• Snapshot bootstrap time;
• State growth/day; CPU/IO saturation.

• P0 RPC p95-400 ms; 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: 'Trace _ id' მეშვეობით edge - RPC - ინდექსატორი და შენახვა - ხიდი.
ლოგოები: სტრუქტურირებული, კორელაცია 'request _ id'.
ალერტები: burn-rate P0, queue-lag, peer-count ბარიერის ქვემოთ, reorg-spikes, snapshot-drift.

10) ავტო სკეილინგის ნიმუშები

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; KEDA ტოპიკის სიგრძით.
ეტაპი: დღის მწვერვალების პროფილები; Predictive ML/სეზონური.
Warm-spares: გაცხელებული რეპლიკები ტრაფიკის გარეშე (graceful promote).
Safe rollout: canary + outlier-ejection + SLO-гейты.

11) უსაფრთხოება და იზოლაცია

mTLS/pining გასაღებები; RBAC/ABAC მეთოდებზე; QoS ლიმიტები porg/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 კაფკა: დომენის განლაგება

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 კონტროლი და ბურნის კონტროლი

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- ს შესახებ, კაპასიტი დელტა, სნაიპშოტების მდგომარეობა, მეკობრე.
ყოველკვირეულად: ლიმიტის/QoS გადასინჯვა, DR ტესტი (snapshot bootstrap), pruning და compaccents შემოწმება.
გამოშვებამდე: კანარის rollout, SLO კარიბჭეები და დაკვირვებული მეტრიკა, დაბრუნების გეგმა.
ღირებულების აღრიცხვა: CTS per 1k მოთხოვნა, TPS _ per _ $ (ეფექტურობა დოლარზე).

15) Playbook ინციდენტები

A. ლატენტობის აფეთქება RPC p95

1. ჩართეთ P2-throttle და შეამცირეთ sampling; 2) გაზარდოს შენიშვნები gateway/reader;

2. ტრაფიკის ნაწილის ქეშზე გადატანა; 4) ცხელი მეთოდების ანალიზის გახსნა, საჭიროების შემთხვევაში - დენის რულეტები.

B. Queue-lag საბურავზე> SLO

1. კონსიუმერების სკეიტი (KEDA), 2) პარტიების გადანაწილება, 3) დროებით შეჩერდეს ბულკის ჯობი.

C. peer-count- ის ვარდნა validator/reley- ში

1. p2p მოდულების გადატვირთვა, 2) სიდების შეცვლა, 3) ქსელის ACL/NAT, 4) რეზერვში გადასვლა.

დ გრძელი bootstrap ახალი შენიშვნა

1. ახალ Snapshot- ზე გადასვლა, 2) IO გამტარუნარიანობის ამაღლება, 3) საარქივო ინდექსების დროებით ამოღება.

E. reorg/ხიდის შეფერხება

1. გაზარდეთ K- მტკიცებულებები/ფანჯარა, 2) ჩართეთ რეჟიმი „ფინალიზებული - მხოლოდ“, 3) აცნობეთ მომხმარებლებს.

16) განხორციელების შემოწმების სია

1. განსაზღვრეთ კვანძების როლები და მათი SLO/შეცდომების ბიუჯეტები.
2. განაწილეთ ფუნქციები: consensus/RPC/ინდექსატორი/არქივი/ხიდი/edge.
3. ჩართეთ დაბალანსება, QoS, backpressure და ხაზი DLQ- ით.
4. Snapshots/fast-sync, pruning და მრავალ დონის შენახვა.
5. დააკავშიროთ მეტრიკა/ტრეისი/ლოგები, დაშბორდები და ბურნი ალერტები.
6. Autoscaling (HPA/KEDA) და კანარის გამოშვებების კონფიგურაცია.
7. ჩაატარეთ ქაოსის ტესტები და რეგულარული DR სწავლებები.
8. შემოიღეთ ოპერაციული რეგულაციები და ხარჯების კონტროლი.

17) გლოსარიუმი

Backpressure - შეყვანის ნაკადის კონტროლის მექანიზმები გადატვირთვის დროს.
DLQ არის „მკვდარი ხაზი“ პრობლემური შეტყობინებებისთვის.
Pruning - ისტორიული მდგომარეობის წაშლა მიმდინარე ფანჯრის მიღმა.
Fast-sync/Snapshot არის ახალი რეპლიკის სინქრონიზაციის დაჩქარებული გზა.
Outlier-ejection არის აუზიდან დეგრადირებული ინსტანციების გამორიცხვა.
Burn-rate - შეცდომების ბიუჯეტის მოხმარების სიჩქარე SLO- სთან შედარებით.

შედეგი: ქსელის კვანძების მასშტაბები არა მხოლოდ „რეპლიკის დამატება“, არამედ არქიტექტურის სისტემის დისციპლინა, QoS, სახელმწიფო კონტროლი და ოპერაციული სიმკაცრე. ამ ჩარჩოს შემდეგ (როლების დაყოფა, რიგები, ქეში, სკეიტი, დაკვირვება და მკაფიო SLO), ეკოსისტემა იღებს პროგნოზირებულ პროდუქტიულობას, წინააღმდეგობას მწვერვალებზე და კონტროლირებად ღირებულებას ტრაფიკის ერთეულზე.