Региональные хабы

(Раздел: Экосистема и Сеть)

1) Зачем нужны региональные хабы

• Латентность и UX: близость к пользователю (RTT↓, TTI/TTF↓).
• Комплаенс и резидентность: хранение/обработка данных внутри юрисдикции.
• Устойчивость и емкость: разгрузка глобального ядра, работа при частичной изоляции региона.
• Экономику: снижение межрегионального трафика, локальные CDN/кэши, выгодные тарифы IX/peering.

2) Роли регионального хаба

1. Edge/Gateway — входной слой (HTTP/2/3, gRPC, WebSocket, QUIC), rate-limit, QoS, WAF.
2. Reader/API — RPC, индексы, поисковые сервисы, локальные materialized views.
3. Compute/Stream — обработка событий, агрегирование, анти-фрод фильтры.
4. Data Plane — TSDB/колоночные витрины, объектное хранилище для «теплых» данных.
5. Compliance/KYC/KYB — локальные интеграции с провайдерами и каталоги санкций.
6. Payments/PSP — локальные методы оплаты и он/офф-рамп.
7. Bridge/Relay — терминал межцепных сообщений с локальным буфером финализации.
8. Observability — метрики/логи/трейсы, синтетические пробы.
9. Governance/Access — каталоги ролей, ключей и лимитов для региональных участников.

3) Топологии развертывания

Hub-and-Spoke: центральный «мастер-хаб» + региональные споуки с частичной автономией.
Active–Active (Multi-Primary): симметричная работа нескольких хабов с конфликт-фри репликацией (CRDT/опережающие журналы).
Active–Passive: горячий резерв с периодической репликацией и DR-ролловером.
Edge-Tiered: «тонкие» edge-узлы (CDN, WebSocket-фан-аут) → «толстый» региональный хаб.

Выбор зависит от требований к финализации/консистентности, стоимости каналов и регуляторных ограничений.

4) Геомаршрутизация и политика резидентности

GeoDNS/Anycast + Latency-Aware LB: отправляем запросы в ближайший здоровый хаб.
Jurisdiction Routing: данные субъектов (EU/UK/TR и т. п.) остаются в соответствующем хабе; межрегиональные пересылки — только по белым спискам.
Traffic SOR (Smart Order Routing) для регионов: учитывает RTT, стоимость канала, комплаенс-флаги, загрузку квот и SLO.
Fail-in-Place: при деградации внешних связей хаб продолжает обслуживать «finalized-only» запросы и локальные операции.

5) Данные: каталоги, репликации, классы хранений

• P0 — платежи/мост/идентификация (строгая резидентность, синхронизация «сигналов» только в агрегатах/хэших).
• P1 — продуктовые события и агрегаты (локальные вью + периодический экспорт).
• P2 — отладка/логи (агрессивная компрессия, длинная ретенция в регионе).

• События — лог-шиппинг с порядком в пределах партиции (region-scoped keys).
• Хранилища — асинхронная MMR/CRDT или snapshot-бэкапы.
• Резидентность: политики DLP/PII, токенизация, раздельные ключи шифрования per-region.

6) Производительность и кэширование

Кэши: edge-кэш (короткий TTL), read-through на API, negative cache.
Warm-data: последние N блоков/батчей, горячие индексы по популярным методам.
DA/Batch-буферы для L2/мостов: локальная очередь публикаций с подтверждениями.
Hardware-Adjusted TPS: планирование емкости по $/TPS и $/RPS с учетом региональных цен.

7) QoS, очереди и backpressure

Классы P0/P1/P2 на уровне шины и шлюзов; раздельные очереди и квоты.
Partitioning: ключ `region|tenant|topic` для прогнозируемого throughput.
DLQ: карантин «ядовитых» сообщений, ретраи с джиттером.
Admission Control: ограничение «дорогих» RPC (по диапазону, фильтрам, лимитам).

8) SLI/SLO регионального хаба

• p95 Latency (Edge/API), Success Rate, Queue-Lag p95, Freshness витрин, Finality p95 (мост/релеи), Geo-Hit Ratio (доля запросов, обслуженных в регионе), Compliance Pass %.

• Edge/API p95 ≤ 350–450 мс, Availability ≥ 99.95%.
• Freshness (P1) p95 ≤ 3 мин; Queue-Lag P0 p95 ≤ 2 с.
• Geo-Hit Ratio ≥ 85% (без межрегионального хопа).
• DR RTO ≤ 15 мин, RPO ≤ 5 мин для P0.

9) Наблюдаемость и дашборды

Ops Core: latency/error/queue-lag/throughput по классам QoS.
Geo View: тепловая карта RTT, Geo-Hit Ratio, межрегиональный трафик.
Compliance: резидентность, санкционные хиты, экспорт-логи.
Bridge/DA: финализация p95, challenge/reorg, отказы публикаций.
Capacity & Cost: TPS_per_$, CTS/1k запросов, Utilization %.

10) DR и устойчивость

Резервные каналы: независимые IX/провайдеры, шифрованные туннели межхабовых связей.
Изолированный режим: «finalized-only», деградационные API, локальные квитанции с последующим reconcile.
Регулярные учения: отключение трансатлантики, потеря DA/пруверов, «джиттер/потери» на границах.

11) Экономика и планирование емкости

CTS (Cost-to-Serve) per 1k ops: каналы + вычисления + хранение + лицензии.
TPS_per_$: устойчивая пропускная способность на 1 доллар инфраструктуры.
Peering/IX-оптимизация: локальные peer-точки, префикс-анонсы, компрессия и батчирование.
Tier-модель: T1 (мин-набор сервисов), T2 (полнокровная аналитика), T3 (полный стек + DA/мост).

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

12.1 Политика маршрутизации (YAML)

yaml routing:
geodns:
regions: [eu, uk, tr, la, apac, na]
policies:
prefer_local: true fallback_chain: [nearest_healthy, master_hub]
compliance:
residency:
eu: ["eu"]
uk: ["uk"]
tr: ["tr"]
export_whitelist:
eu: ["anonymized_metrics","hash_anchors"]
slo_gates:
p0_latency_p95_ms: 400 queue_lag_p95_ms: 2000

12.2 K8s: Edge-шлюз + HPA

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: edge-gw, labels: { region: eu } }
spec:
replicas: 4 template:
spec:
containers:
- name: gw image: org/edge-gw:2. 7. 0 ports: [{ containerPort: 443 }]
env:
- { name: QOS_CLASSES, value: "P0,P1,P2" }
- { name: DENY_HEAVY_RANGE, value: "eth_getLogs>5000" }
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: edge-gw-hpa }
spec:
minReplicas: 4 maxReplicas: 24 metrics:
- type: Pods pods:
metric: { name: request_latency_p95_ms }
target: { type: AverageValue, averageValue: 350m }

12.3 Kafka: партиционирование по региону/тентанту

yaml topic: "events. p0"
partitions: 96 config:
min. insync. replicas: 2 cleanup. policy: delete compression. type: zstd message. timestamp. type: CreateTime

12.4 Политика резидентности и экспортов

yaml data_policy:
pii: { tokenized: true, cross_region_export: "deny" }
exports:
anonymized_metrics: { allowed: ["eu","uk","na"], schedule: "5m" }
hash_anchors: { allowed: ["eu","uk","na","apac"], cadence: "15m" }

13) Схемы данных и запросы

Каталог хабов и связей

sql
CREATE TABLE hubs (
hub_id TEXT PRIMARY KEY,
region TEXT, tier SMALLINT, status TEXT,
rtt_ms INT, cost_per_1k_ops NUMERIC,
created_at TIMESTAMPTZ
);

CREATE TABLE interlinks (
src_hub TEXT, dst_hub TEXT,
capacity_mbps INT, cost_per_gb NUMERIC,
encrypted BOOLEAN, health TEXT,
PRIMARY KEY (src_hub, dst_hub)
);

Geo-Hit Ratio и Freshness

sql
SELECT region,
100. 0 SUM(CASE WHEN served_in_region THEN 1 ELSE 0 END)/COUNT() AS geo_hit_pct,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY freshness_s) AS freshness_p95
FROM req_stats
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY region;

TPS_per_$

sql
SELECT hub_id,
AVG(tps_sustained) / NULLIF(AVG(cost_usd_hour),0) AS tps_per_usd
FROM hub_perf
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY hub_id;

14) Операционные регламенты

Ежедневно: отчет SLO (latency/queue-lag/freshness), аудит экспортов/резидентности, состояние межхабовых ликов.
Еженедельно: калибровка квот/QoS и GeoDNS, пересчет CTS/TPS_per_$, ревизия кэшей и «горячих» индексов.
Ежемесячно: DR-учения (изолированный режим, переключение каналов), проверка DA/мостов.
Перед релизом: канареечный rollout по одному хабу/региону, SLO-гейты и план отката.

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

A. Падение межрегионального канала

1. Переключить на резервный IX, включить сжатие/батчи;

2. Хаб в режим «finalized-only»;

3. Очередь экспортов — в буфер, с лимитом;

4. Коммуникация с участниками, пост-мортем.

B. Локальная деградация API p95

1. Приоритизировать P0, включить P2-throttle;

2. Увеличить реплики edge/API;

3. Включить кэш-только для горячих методов;

4. Диагностика тяжелых запросов, при необходимости deny-rules.

C. Нарушение резидентности

1. Немедленный блок кросс-регионального экспорта;

2. Redaction/реверс экспорта;

3. Уведомление DPO/Compliance;

4. Обновление политик и тестов.

D. Пики reorg/DA отказов

1. Увеличить K/окно спора;

2. Включить «delayed finalization»;

3. Оповестить потребителей;

4. Дополнить отчеты.

E. Неравномерная загрузка хабов

1. Перетюнинг GeoDNS/Latency-LB;

2. Баланс квот/цен;

3. Трафик-шэйпинг для аффилиатов/источников.

16) Чек-лист внедрения

1. Выбрать регионы/юрисдикции и целевые SLO.
2. Спроектировать топологию (Hub-Spoke или Active–Active), каналы/IX.
3. Разнести роли: Edge/API/Compute/Data/Bridge/Compliance.
4. Настроить резидентность, каталоги и экспортные политики.
5. Включить QoS, очереди, кэши и backpressure.
6. Поднять наблюдаемость и дашборды Geo/Compliance/Perf/Cost.
7. Настроить DR (RTO/RPO), учения и изолированный режим.
8. Завести экономические метрики (CTS, TPS_per_$) и бюджет.

17) Глоссарий

Geo-Hit Ratio — доля запросов, обслуженных «своим» хабом.
RPO/RTO — цели по потере данных/времени восстановления.
Hub-and-Spoke — центральный узел с периферийными кластерами.
CRDT — структуры данных для конфликт-фри репликации.
CTS per 1k ops — стоимость обслуживания 1000 операций.
TPS_per_$ — пропускная способность на доллар инфраструктуры.

Итог: региональные хабы превращают глобальную сеть в набор локально оптимизированных, комплаентных и устойчивых доменов. При четких SLO, резидентности, QoS и DR-процедурах они снижают латентность и стоимость, повышают надежность и обеспечивают масштабирование экосистемы без потери управляемости.