Створення NaaS-платформи: оркестрація нод, K8s, білінг

Запуск блокчейн-ноди вручну — просте завдання для однієї ноди. Коли їх стає сотня, це вже інфраструктурний проєкт з K8s, StatefulSet, snapshot bootstrap та білінгом. Ми займаємося Node-as-a-Service розробкою під ключ і побудували не одну таку платформу: від вибору клієнтів (Ethereum, Solana, BNB) до production-grade API Gateway з rate limiting та compute units. З нашої практики: один із клієнтів Fortune 500 замінив ручне управління нодами на NaaS — витрати на інфраструктуру знизилися на 40%, що принесло економію $15 000 на місяць, а річна економія перевищила $180 000. Зв'яжіться з нами — оцінимо ваш проєкт за 2 дні.

Як працює Node-as-a-Service платформа?

NaaS-платформа надає клієнтам єдиний RPC-ендпоінт, за яким прихована оркестрація десятків і сотень нод. Кожна нода запускається в K8s як StatefulSet з власним PersistentVolumeClaim. Для бюджетного сегменту ноди розділяються між клієнтами (shared), для вимогливих — виділяються цілком (dedicated) або кластерами з балансуванням (node clusters).

Чому стандартний Kubernetes не підходить для блокчейн-нод?

Звичайний Deployment в K8s не враховує специфіку блокчейн-нод, тому Kubernetes для блокчейн-інфраструктури вимагає використання StatefulSet. Ноди потребують stateful-сховища (сотні гігабайт), фіксованих P2P-портів та захисту від перезапусків без втрати синхронізації. Використовуємо StatefulSet з PVC та headless service — це гарантує, що при збої под не перествориться на іншому вузлі, а дані залишаться прив'язаними до storage.

Приклад конфігурації StatefulSet для Ethereum ноди:

apiVersion: apps/v1 kind: StatefulSet metadata: name: ethereum-geth spec: serviceName: "geth" replicas: 1 selector: matchLabels: app: ethereum-geth template: spec: containers: - name: geth image: ethereum/client-go:v1.13.14 args: ["--datadir=/data", "--http", "--http.addr=0.0.0.0", "--http.vhosts=*", "--http.api=eth,net,web3,txpool", "--ws", "--ws.addr=0.0.0.0", "--maxpeers=50", "--cache=4096"] ports: - containerPort: 8545 - containerPort: 8546 - containerPort: 30303 protocol: TCP - containerPort: 30303 protocol: UDP volumeMounts: - name: data mountPath: /data resources: requests: memory: "16Gi" cpu: "4" limits: memory: "32Gi" cpu: "8" volumeClaimTemplates: - metadata: name: data spec: accessModes: ["ReadWriteOnce"] storageClassName: "fast-nvme" resources: requests: storage: 3Ti 

Проблеми, які вирішуємо

Snapshot bootstrapping

Синхронізація Ethereum mainnet з нуля (snap sync) займає 12–24 години, а архівна нода (archive node) — до 5 тижнів. Для NaaS це критично: клієнт платить з першої хвилини. Ми використовуємо snapshot distribution: кожні 7 днів створюємо актуальну копію бази даних, інкрементальні diffs — щоденно. Bootstrap ноди з snapshot займає 10–15 хвилин.

Порівняння режимів синхронізації нод Ethereum:

Ізоляція клієнтів

В одній платформі можуть працювати як стартапи з free tier, так і enterprise з гарантіями SLA. Розділяємо ресурси через три моделі мультитенантності, кожна зі своїм підходом до білінгу блокчейн-інфраструктури.

Для білінгу блокчейн-інфраструктури використовуємо compute units — кожен RPC-метод має вагу в CU: eth_blockNumber — 10 CU, eth_call — 26 CU, trace_replayTransaction — 75 CU.

Як ми це робимо: стек і кейси

RPC-проксі з інтелектуальною маршрутизацією

Кастомний проксі на Go фільтрує небезпечні методи (наприклад, debug_* тільки для premium), розподіляє запити між archive та full нодами та кешує відповіді (TTL — 1 секунда для eth_blockNumber). Rate limiting реалізовано через Redis sliding window — він точніше token bucket для RPC-навантажень.

// Приклад RPC проксі з routing logic
package proxy

type RPCRouter struct {
	archivePool   NodePool
	fullNodePool  NodePool
	cacheClient   *redis.Client
}

var archiveMethods = map[string]bool{
	"eth_getBalance":           true,
	"eth_call":                 true,
	"eth_getStorageAt":         true,
	"trace_call":               true,
	"trace_replayTransaction":  true,
}

func (r *RPCRouter) Route(req *RPCRequest) NodePool {
	if archiveMethods[req.Method] {
		if req.RequiresHistoricalBlock() {
			return r.archivePool
		}
	}
	return r.fullNodePool
}

func (r *RPCRouter) Handle(w http.ResponseWriter, req *RPCRequest, apiKey string) {
	cacheKey := req.CacheKey()
	if cached, err := r.cacheClient.Get(ctx, cacheKey).Bytes(); err == nil {
		w.Write(cached)
		return
	}
	pool := r.Route(req)
	node := pool.GetHealthyNode()
	resp := node.Forward(req)
	if req.IsCacheable() {
		r.cacheClient.Set(ctx, cacheKey, resp, req.CacheTTL())
	}
	r.billing.RecordRequest(apiKey, req.Method, resp.ComputeUnits())
	w.Write(resp)
}

Health checking з урахуванням стану ноди

Ping не гарантує, що нода обробляє запити. Використовуємо перевірку синхронізації: якщо SyncProgress не nil або блок старше 2 хвилин — нода виключається з пулу. Health перевірки запускаємо кожні 15 секунд.

type NodeHealthChecker struct {
    client *ethclient.Client
}

func (h *NodeHealthChecker) IsHealthy(ctx context.Context) (bool, error) {
    syncing, err := h.client.SyncProgress(ctx)
    if err != nil {
        return false, err
    }
    if syncing != nil {
        return false, fmt.Errorf("node is syncing: %d/%d", syncing.CurrentBlock, syncing.HighestBlock)
    }
    header, err := h.client.HeaderByNumber(ctx, nil)
    if err != nil {
        return false, err
    }
    blockAge := time.Since(time.Unix(int64(header.Time), 0))
    if blockAge > 2*time.Minute {
        return false, fmt.Errorf("block too old: %v", blockAge)
    }
    return true, nil
}

Rate limiting на Redis

func (rl *RateLimiter) Allow(ctx context.Context, apiKey string, rps int) (bool, error) {
	now := time.Now().UnixMilli()
	window := int64(1000)
	pipe := rl.redis.Pipeline()
	pipe.ZRemRangeByScore(ctx, apiKey, "0", strconv.FormatInt(now-window, 10))
	pipe.ZCard(ctx, apiKey)
	pipe.ZAdd(ctx, apiKey, redis.Z{Score: float64(now), Member: now})
	pipe.Expire(ctx, apiKey, 2*time.Second)
	results, err := pipe.Exec(ctx)
	count := results[1].(*redis.IntCmd).Val()
	return count < int64(rps), nil
}

Білінг на основі compute units

CREATE TABLE api_keys (
    id UUID PRIMARY KEY,
    customer_id UUID NOT NULL,
    key_hash BYTEA NOT NULL,
    tier VARCHAR(20) NOT NULL,
    rate_limit_rps INTEGER NOT NULL,
    monthly_cu_limit BIGINT,
    node_type VARCHAR(20) NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE usage_records (
    id BIGSERIAL PRIMARY KEY,
    api_key_id UUID NOT NULL REFERENCES api_keys(id),
    method VARCHAR(100) NOT NULL,
    chain_id INTEGER NOT NULL,
    compute_units INTEGER NOT NULL,
    response_time_ms INTEGER,
    recorded_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_usage_billing ON usage_records (api_key_id, recorded_at);

Як ми будуємо NaaS-платформу: етапи та терміни

1. Аналітика та аудит (1–2 тижні): визначаємо цільові блокчейни, модель мультитенантності, вимоги до SLA та регіону.
2. Проектування архітектури (1–2 тижні): обираємо клієнти (Geth, Reth, Erigon, Solana Agave), готуємо схеми K8s, API Gateway, білінгу.
3. Реалізація core infrastructure (4–6 тижнів): StatefulSet templates, snapshot bootstrap pipeline, health checker.
4. Розробка API Gateway та білінгу (6–8 тижнів): RPC проксі, rate limiting, compute units, інтеграція Stripe.
5. Observability та self-service portal (6–9 тижнів): Prometheus + Grafana, alerting, веб-інтерфейс для управління ключами та перегляду метрик.
6. Тестування та деплой (2–3 тижні): навантажувальне тестування, security audit, запуск у production.

Разом: від 16 до 23 тижнів до production-ready платформи. Якщо ви хочете прискорити етап, зв'яжіться з нашими інженерами — ми запропонуємо відповідний темп.

Що входить у роботу

• Документація: архітектурна схема, інструкції з додавання нових ланцюгів, runbook для on-call.
• Доступи: репозиторій з шаблонами, CI/CD pipeline, моніторинг (Grafana dashboards).
• Навчання: 2–3 сесії для вашої команди (DevOps та backend).
• Підтримка: 3 місяці після запуску (багфікс, консультації).

Типові помилки при розробці NaaS

• Використання hostNetwork для P2P портів — втрачається ізоляція. Краще NodePort або LoadBalancer з фіксованим портом на ноду.
• Відсутність кешування частих RPC-методів (eth_chainId, eth_blockNumber) — збільшує навантаження на ноду та білінг.
• Health check тільки по TCP — нода може бути живою, але відставати від мережі на сотні блоків.

Якщо ви зіткнулися з подібними проблемами або хочете уникнути їх, замовте розробку NaaS-платформи у нас. Детальніше про StatefulSet. Ми накопичили 10+ років досвіду в блокчейн-інфраструктурі та реалізували 50+ проєктів, включаючи платформи для Fortune 500. Зв'яжіться з нами — оцінимо вашу задачу та запропонуємо оптимальне рішення.