🗓 22 октября 2025 ⚡ Разработка

Serverless 2.0: контейнеры без оркестрации

Представляем Serverless 2.0 — платформу для запуска контейнеров без необходимости управлять Kubernetes кластерами. Просто загружаете Docker image, указываете память и CPU, а мы автоматически масштабируем, балансируем нагрузку и обеспечиваем fault tolerance. Платите только за фактическое время выполнения.

Проблема классического serverless

AWS Lambda и подобные FaaS платформы отлично работают для небольших функций, но имеют серьезные ограничения:

Время выполнения — обычно лимит 15 минут, что недостаточно для ML inference или обработки больших датасетов
Размер пакета — ограничение 250 МБ (50 МБ для zip) делает невозможным использование больших зависимостей
Cold start — задержка до 10+ секунд при первом вызове или после периода неактивности
Vendor lock-in — код тесно связан с платформой, сложно мигрировать
Debugging — локальная разработка требует эмуляторов и отличается от продакшена

Serverless 2.0 решает эти проблемы, давая вам полный контроль над окружением через Docker, но при этом сохраняя простоту деплоя и автоматическое масштабирование.

Как это работает

Архитектура построена на трех ключевых компонентах:

1. Image Registry
Собираете Docker image локально или в CI/CD и пушите в наш приватный registry. Мы автоматически сканируем image на уязвимости (Trivy + Snyk) и оптимизируем слои для быстрого пуллинга. Поддерживаются как x86_64, так и ARM64 архитектуры.

2. Scheduler
Вместо Kubernetes API мы используем собственный легковесный scheduler, написанный на Rust. Он принимает HTTP запросы и мгновенно (< 50ms) находит свободный слот для запуска контейнера. Если все ноды заняты, scheduler автоматически провизионит новые через 20-30 секунд.

3. Runtime
Контейнеры запускаются через Firecracker microVM — технологию AWS Lambda. Каждый контейнер изолирован на уровне виртуализации, что дает security comparable с традиционными VM, но с overhead всего ~125 МБ памяти и 5 мс на старт.

Cold start оптимизация

Главная боль serverless — это cold start. Мы решили эту проблему комплексом мер:

Pre-warming pool
Для популярных base images (node:20, python:3.12, golang:1.21) мы держим пул уже запущенных контейнеров. При входящем запросе scheduler просто перенаправляет трафик в готовый контейнер, минуя фазу загрузки image и инициализации. Время отклика: 5-15 мс.

Intelligent caching
Система анализирует паттерны использования и предсказывает, какие контейнеры понадобятся в ближайшее время. ML-модель учитывает время суток, день недели, исторические данные и текущие тренды. Точность предсказания: 87%.

Snapshot/restore
После первого запуска контейнера мы делаем snapshot его состояния в памяти (включая загруженные библиотеки, инициализированные connection pools, etc). При следующем холодном старте просто восстанавливаем snapshot вместо полной инициализации. Экономия: 3-10x.

Lazy loading
Вместо загрузки всего Docker image целиком (может быть гигабайты), мы используем технологию CRFS (Container Registry Filesystem). Контейнер стартует сразу, а слои подгружаются on-demand по мере обращения к файлам. Это особенно эффективно для больших ML моделей.

Автоматическое масштабирование

Scaling происходит по множеству метрик одновременно:

RPS (requests per second) — если load > 80% capacity, запускаем новые инстансы
Response time — если p99 latency превышает заданный SLA, добавляем capacity
CPU/Memory — если utilization > 70% в течение 30 секунд, scale up
Queue depth — если запросы начинают накапливаться, это сигнал для scaling
Custom metrics — можете определить свои метрики (например, размер очереди задач)

Scale down происходит постепенно с graceful shutdown. Мы ждем завершения всех активных запросов (с timeout), дренируем соединения и только потом останавливаем контейнер. Это предотвращает dropped requests.

Есть защита от thrashing — если система видит, что инстансы постоянно стартуют и останавливаются (признак нестабильной нагрузки), она увеличивает cooldown период и держит минимальный warm pool.

Persistent storage

В отличие от чистого FaaS, где состояние теряется после выполнения, мы предоставляем несколько опций:

Ephemeral disk
Каждый контейнер получает локальный SSD (NVMe) для временных файлов. Размер: 10-500 ГБ, скорость: 3+ GB/s sequential, 500k+ IOPS random. Отлично для кэшей, промежуточных результатов, temp files. Данные очищаются после завершения.

Shared volumes
Можете монтировать network filesystem (NFS, CephFS) для шаринга данных между контейнерами. Латентность: 1-2 мс, throughput: 10+ GB/s. Полезно для ML checkpoints, shared datasets, coordination.

Object storage
Прямая интеграция с S3-совместимым хранилищем. SDK автоматически использует internal endpoints без NAT gateway, что дает zero egress costs и latency < 5 мс. Можете читать/писать терабайты данных практически бесплатно.

Networking и service mesh

Каждый контейнер автоматически получает:

Публичный HTTPS endpoint с автоматическим TLS сертификатом (Let's Encrypt)
Internal DNS для service discovery внутри вашего проекта
Load balancer с поддержкой HTTP/2, WebSocket, gRPC
DDoS protection на уровне L3/L4 и L7 (rate limiting, geo-blocking)
CDN integration для статических ресурсов (opt-in)

Встроенный service mesh (на базе Envoy) дает distributed tracing, circuit breaking, retry logic, и automatic failover. Вы видите полный граф зависимостей сервисов в real-time dashboard.

Observability

Без дополнительной настройки получаете:

Logs — все stdout/stderr автоматически агрегируются и индексируются (Loki). Полнотекстовый поиск, фильтрация по уровню (info/warn/error), экспорт в Elasticsearch или Datadog.

Metrics — CPU, memory, network, disk I/O, custom application metrics (Prometheus). Retention: 15 дней high-resolution, 1 год downsampled. Alerting через Alertmanager.

Traces — распределенная трассировка через OpenTelemetry. Видите полный путь запроса через все микросервисы с timing каждого hop. Интеграция с Jaeger и Tempo.

Profiling — continuous profiling (CPU, memory, goroutines) с возможностью анализа flame graphs для оптимизации производительности.

Pricing model

Платите только за фактическое использование с точностью до 100 миллисекунд:

Compute: $0.00001667 за GB-секунду памяти ($0.06/GB-час)
vCPU: $0.00002083 за vCPU-секунду ($0.075/vCPU-час)
Requests: $0.20 за миллион запросов
Data transfer: первые 100 GB/месяц бесплатно, далее $0.09/GB

Пример: сервис с 1 vCPU + 2 GB RAM, обрабатывающий 10M requests/месяц, работающий ~100 часов = $7.50 (CPU) + $12 (RAM) + $2 (requests) = $21.50/месяц. Это на 40-60% дешевле managed Kubernetes.

Migration guide

Миграция с других платформ занимает минимум времени:

Из Kubernetes
Берете существующий Dockerfile, возможно упрощаете (убираете sidecars, service mesh config), и деплоите. Большинство приложений работают без изменений. Health checks, readiness probes, environment variables — все поддерживается.

Из AWS Lambda
Упаковываете код в Docker image (или используем наши builder images для Node.js/Python/Go). Меняете handler function на HTTP server (мы предоставляем адаптеры). Deploy занимает 5-10 минут.

Из VM/bare metal
Контейнеризируете приложение (обычно достаточно простого Dockerfile с копированием бинарника). Настраиваете environment variables для конфигурации. Готово.

Use cases

Serverless 2.0 особенно эффективен для:

API backends — REST, GraphQL, gRPC сервисы с автоматическим масштабированием
Event processing — обработка очередей (Kafka, RabbitMQ, SQS) с параллелизацией
ML inference — запуск моделей on-demand без содержания постоянной инфраструктуры
Scheduled jobs — cron-like задачи с гарантированным выполнением
ETL pipelines — обработка данных с динамическим ресурсным allocation
Webhooks — обработка incoming webhooks от третьих сервисов

← Вернуться к блогу