Облачные вычисления

Serverless: Lambda и Cloud Functions

AWS Lambda обрабатывает 10 триллионов запросов в месяц. Каждый запрос - отдельный контейнер. 10 триллионов запусков и остановок за 30 дней. 2014 год: AWS Lambda. Первый serverless сервис. Идея: код без управления сервером. Платишь только когда функция выполняется. Amazon S3 event -> Lambda -> DynamoDB. Никакого EC2.

  • Vercel Edge Functions: Next.js API routes как Lambda под капотом - каждый /api/* endpoint это serverless function
  • GitHub Actions: каждый job - serverless контейнер, оплата только за время выполнения
  • Stripe webhooks: Lambda обрабатывает 100 событий/сек без EC2 - burst traffic при чёрной пятнице
  • ML pipeline: S3 event -> Lambda -> Bedrock inference -> DynamoDB - полный pipeline без серверов

Cold Start и модель выполнения

**AWS Lambda** выполняет код без управления серверами. Каждый вызов - изолированный контейнер (microVM на базе Firecracker). Жизненный цикл выполнения состоит из двух фаз: **Init Phase** и **Invoke Phase**. Init Phase включает три шага: создание контейнера (Container Init), инициализацию runtime - загрузка интерпретатора Python/Node/Java (Runtime Init), и инициализацию функции - выполнение кода вне handler (Function Init). Если warm контейнер уже существует - Lambda пропускает Init Phase и сразу переходит к Invoke. Это разница между cold start и warm invocation.

**Cold start: сколько это в миллисекундах?** Node.js: 100-300ms. Python: 200-500ms. Java (с JVM): 1-4 секунды. Python с PyTorch: 3-8 секунд. Go/Rust: 50-150ms. Размер deployment package напрямую влияет - каждый MB добавляет ~10-20ms. VPC cold start добавляет 1-2 секунды: Lambda должна создать ENI (Elastic Network Interface) в VPC.

**Provisioned Concurrency** полностью устраняет cold start: Lambda держит N прогретых экземпляров постоянно. Цена: оплата за время простоя (~0.015 USD/GB-час). Для API с SLA < 100ms - это единственное решение. Application Auto Scaling может настраивать Provisioned Concurrency по расписанию (больше в рабочие часы).

Lambda-функция на Python с PyTorch показывает p99 latency 9 секунд. p50 при этом 300ms. Что происходит?

Модель concurrency

Lambda масштабирует горизонтально автоматически: каждый параллельный запрос получает собственный экземпляр функции. 1000 одновременных запросов = 1000 параллельных экземпляров. Лимит по умолчанию на аккаунт: **1000 concurrent executions** (можно поднять через Service Quotas). Burst concurrency: Lambda может запускать до 3000 новых экземпляров в первую минуту, затем 500 новых/минуту. При превышении лимита функция получает **ThrottlingException (HTTP 429)**. Клиент должен реализовывать exponential backoff.

**Reserved Concurrency** - резервирование N экземпляров под конкретную функцию. Гарантирует, что функция всегда получит N слотов даже если другие функции перегружены аккаунт-лимит. Одновременно - потолок: функция не превысит N независимо от нагрузки. **Provisioned Concurrency** - N pre-warmed экземпляров (нет cold start), оплата за резерв.

**LLM webhook обработка**: Anthropic или OpenAI отправляют батч уведомлений одновременно (100-500 запросов/сек при популярном приложении). Lambda автоматически создаёт 100-500 параллельных экземпляров. Без Reserved Concurrency - этот burst может вытеснить другие функции аккаунта. С SQS перед Lambda - батч обрабатывается с управляемым concurrency через batch size.

Production аккаунт имеет 5 Lambda-функций. Критичная payment-функция внезапно начинает получать ThrottlingException. Остальные функции работают нормально. Что произошло?

Event Sources и триггеры

Lambda вызывается событиями из различных источников. Два паттерна интеграции: **Push model** - сервис напрямую вызывает Lambda (API Gateway, S3, SNS, EventBridge); **Poll model** - Lambda сама читает из очереди/стрима (SQS, Kinesis, DynamoDB Streams). Разница критична для retry-семантики: async invocations (S3, SNS) Lambda пытается повторить 2 раза при ошибке, затем отправляет в Dead Letter Queue. SQS poll model - сообщение возвращается в очередь и переобрабатывается до maxReceiveCount раз.

**API Gateway + Lambda**: синхронный вызов, клиент ждёт ответа. Timeout API Gateway - 29 секунд (жёсткий лимит). Lambda timeout - до 15 минут, но для API Gateway связки важен именно 29s. **S3 Event + Lambda**: асинхронный. S3 уведомляет Lambda о новом объекте, Lambda обрабатывает. При ошибке - 2 ретрая автоматически. Для гарантированной обработки: S3 -> SQS -> Lambda (at-least-once delivery через очередь).

Lambda обрабатывает S3-события. Иногда один и тот же файл обрабатывается дважды. Почему это происходит?

Экономика serverless

Lambda тарифицируется по двум измерениям: **количество запросов** (1 млн запросов/месяц бесплатно, затем 0.20 USD за миллион) и **длительность** в GB-секундах (время выполнения * выделенная память). Free tier: 400 000 GB-секунд в месяц. Пример: функция 128MB работает 200ms - это 0.025 GB-секунды. 1 млн вызовов = 25 000 GB-секунд - укладывается во free tier. Точка безубыточности Lambda vs EC2: при утилизации меньше ~15% Lambda дешевле. При постоянной 24/7 нагрузке EC2 (особенно с Reserved Instances) выигрывает в 3-10 раз.

**Скрытые расходы serverless**: API Gateway стоит отдельно - 3.50 USD за 1 млн запросов (HTTP API) или 3.50 USD (REST API). Data transfer: исходящий трафик из Lambda тарифицируется как EC2 egress - 0.09 USD/GB. Provisioned Concurrency: дополнительно 0.015 USD/GB-час. При высокой нагрузке эти расходы могут превысить стоимость EC2 instance.

**Serverless не всегда дешевле**: для постоянной нагрузки (24/7) EC2 Reserved Instances дешевле в 3-10 раз. Lambda оптимальна для: событийных workloads (S3 events, webhooks), нечастых задач (cron jobs, scheduled jobs), непредсказуемых пиков, минимальной operational overhead. Сравнивать нужно полную стоимость: Lambda + API Gateway + data transfer vs EC2 + ALB + EBS.

Serverless означает нет серверов - код выполняется в облаке без физического железа

Serverless = отсутствие управления серверами, не отсутствие самих серверов. AWS Firecracker microVM запускается на физических серверах Amazon. Serverless - это операционная модель, а не архитектура выполнения

Понимание физической реальности serverless помогает объяснить cold start (контейнер нужно создать на реальном железе), network latency (физически данные путешествуют между датацентрами) и billing model (время выполнения = реальное использование CPU на физическом сервере).

API на Lambda (256MB, 100ms avg) обрабатывает 500M запросов/месяц. Команда рассматривает миграцию на EC2 (t3.medium, On-Demand, 33 USD/мес). Lambda стоит 200 USD/мес. Что предпочтительнее?

Ключевые идеи

  • **Cold start** - Init Phase (container + runtime + function init). Тяжёлые runtime (PyTorch, JVM) = 3-8s cold start. Mitigation: ONNX вместо PyTorch, Provisioned Concurrency, код вне handler
  • **Concurrency** - 1 запрос = 1 экземпляр, auto-scaling до 1000 (аккаунт-лимит). Reserved Concurrency гарантирует слоты критичным функциям. Throttling = 429, реализовывать backoff
  • **Триггеры** - Push model (API Gateway, S3, SNS) и Poll model (SQS, Kinesis). Async invocations: 2 ретрая + DLQ. At-least-once семантика - handler должен быть idempotent
  • **Экономика** - Pay-per-use выгоден при < 15% утилизации и spiky трафике. Постоянная нагрузка 24/7 - EC2 Reserved в 3-10x дешевле. Скрытые расходы: API Gateway + egress + Provisioned Concurrency

Связанные концепции

Serverless пересекается с несколькими областями облачных и распределённых систем

  • EC2 и виртуальные машины — Lambda vs EC2 - основной trade-off: управление vs pay-per-use
  • Kubernetes и контейнеры — Knative/EKS на Fargate - serverless Kubernetes как мост между Lambda и EC2
  • Очереди и стриминг — SQS перед Lambda - буферизация burst трафика и управление concurrency

Вопросы для размышления

  • Стартап строит real-time голосовой ассистент: микрофон -> API -> ML модель (Whisper + LLM) -> ответ. Команда предлагает Lambda для всей цепочки. Cold start Python + Whisper = 6-8 секунд. Как архитектурно решить проблему latency, сохранив serverless преимущества там где это разумно?

Связанные уроки

  • cloud-01
  • cloud-02
  • cloud-03
  • cloud-04
  • devops-05
  • ds-05-replication
  • aie-05-api-integration
  • devops-22
Serverless: Lambda и Cloud Functions

0

1

Войти