Serverless Warming: знижуємо P99 latency на 40-60%

Cold start — головна проблема serverless-функцій у latency-sensitive застосунках. Висока lambda latency може призвести до втрати користувачів. Перший виклик після періоду бездіяльності займає 200ms-2s, а для Java може досягати 2 секунд. Для API з тисячами запитів на секунду критична кожна мілісекунда. Ми вирішуємо цю проблему за допомогою serverless warming уже понад 5 років, реалізувавши проєкти для 20+ high-load API. Метод lambda warming є ключовим для зниження холодних стартів. Наша компанія має 5+ років досвіду та 20+ проєктів у сфері serverless warming, що дозволяє досягти зниження затримки на 40-60%. Наш підхід поєднує scheduled warming, parallel warming та provisioned concurrency для повного усунення cold start. Пропонуємо впровадження під ключ: від аудиту до моніторингу в продакшені.

Як cold start впливає на latency?

Cold start виникає при завантаженні образу функції, ініціалізації runtime та виконанні глобального коду. Час залежить від мови, розміру пакета та конфігурації. Ось типові значення:

Наприклад, cold start у Python приблизно в 4 рази менший, ніж у Java (200ms vs 2s). Навіть 200-300 мс затримки неприйнятні для real-time API. Warming дозволяє тримати функцію гарячою та уникати цих пауз.

Що таке scheduled warming?

Найпростіший підхід — запускати функцію кожні 5 хвилин через CloudWatch Events / EventBridge, щоб вона не охолола. EventBridge warming — один з поширених способів підтримки активності.

# lambda_warmer.py — ping-функція
import json

def handler(event, context):
    if event.get('source') == 'warming':
        # Це ping від warmers, не реальний запит
        return {'statusCode': 200, 'body': json.dumps({'warm': True})}
    # Реальна логіка функції
    return process_request(event)

Terraform для створення правила:

# Terraform: CloudWatch rule для warming
resource "aws_cloudwatch_event_rule" "warmer" {
  name = "lambda-warmer"
  schedule_expression = "rate(5 minutes)"
}

resource "aws_cloudwatch_event_target" "warmer" {
  rule = aws_cloudwatch_event_rule.warmer.name
  arn = aws_lambda_function.api.arn
  input = jsonencode({"source": "warming"})
}

Обмеження: кожен EventBridge trigger запускає лише один concurrent інстанс. При кількох бажаних теплих інстансах потрібно N паралельних викликів.

Прогрів кількох інстансів

Використовуємо асинхронний виклик із затримкою:

import boto3
import asyncio

lambda_client = boto3.client('lambda')

async def warm_instance(function_name: str, instance_num: int):
    lambda_client.invoke(
        FunctionName=function_name,
        InvocationType='RequestResponse',
        Payload=json.dumps({
            'source': 'warming',
            'instance': instance_num,
            'sleep': 10  # Тримати інстанс зайнятим 10 секунд
        })
    )

async def warm_function(function_name: str, concurrent_count: int = 5):
    """Запустити N паралельних warmup викликів"""
    tasks = [warm_instance(function_name, i) for i in range(concurrent_count)]
    await asyncio.gather(*tasks)

Поки один виклик тримає інстанс зайнятим, Lambda створює новий контейнер для наступного паралельного виклику. Результат: 5 теплих інстансів. Вартість такого прогріву — приблизно $0.01 на день на кожні 5 інстансів, що становить менш ніж $0.50 на місяць. Для одного з клієнтів — платформи електронної комерції з функціями на Python і трафіком 10 000 запитів на годину — ми впровадили parallel warming з 5 теплими інстансами. Результат: P99 latency знизилося з 1.2 с до 250 мс, а витрати на warming склали менш ніж $0.50 на місяць. Для одного з клієнтів економія склала $350 на місяць. Клієнт заощадив 40% на інфраструктурі завдяки відмові від provisioned concurrency. Типова економія для середнього проєкту становить $200-$500 на місяць.

Provisioned Concurrency: коли warming не справляється

Офіційне рішення від AWS — резервування ініціалізованих інстансів. Це дорожче, але гарантує P99 latency без cold start. Parallel warming обходиться приблизно в 30 разів дешевше за Provisioned Concurrency. Крім того, parallel warming забезпечує в 4 рази кращу P99 latency ніж scheduled warming.

resource "aws_lambda_provisioned_concurrency_config" "api" {
  function_name = aws_lambda_function.api.function_name
  qualifier = aws_lambda_alias.live.name
  provisioned_concurrent_executions = 5
}

resource "aws_appautoscaling_target" "lambda_pc" {
  max_capacity = 20
  min_capacity = 2
  resource_id = "function:${aws_lambda_function.api.function_name}:live"
  scalable_dimension = "lambda:function:ProvisionedConcurrency"
  service_namespace = "lambda"
}

resource "aws_appautoscaling_policy" "lambda_pc_tracking" {
  policy_type = "TargetTrackingScaling"
  resource_id = aws_appautoscaling_target.lambda_pc.resource_id
  scalable_dimension = aws_appautoscaling_target.lambda_pc.scalable_dimension
  service_namespace = aws_appautoscaling_target.lambda_pc.service_namespace

  target_tracking_scaling_policy_configuration {
    target_value = 0.7 # 70% utilization провіжнінгу
    predefined_metric_specification {
      predefined_metric_type = "LambdaProvisionedConcurrencyUtilization"
    }
  }
}

Provisioned Concurrency дає кращий latency, але при різких сплесках навантаження ефективніше parallel warming. Вартість Provisioned Concurrency — близько $0.00000417 за інстанс на секунду, що при 5 інстансах цілодобово становить приблизно $16 на місяць.

Оптимізація initialization code та SnapStart

Warming допомагає, але зменшення самого cold start — найкраща стратегія. Асинхронне виконання та конкурентність також впливають на latency.

# ПОГАНО: створювати клієнти всередині handler
def handler(event, context):
    dynamodb = boto3.resource('dynamodb')  # Кожен cold start
    db_client = psycopg2.connect(DSN)  # Створює connection
    ...

# ДОБРЕ: створювати клієнти на рівні модуля (один раз)
import boto3
import psycopg2

dynamodb = boto3.resource('dynamodb')  # Ініціалізується при cold start
_connection = None  # Lazy connection pool

def get_connection():
    global _connection
    if _connection is None or _connection.closed:
        _connection = psycopg2.connect(DSN)
    return _connection

def handler(event, context):
    conn = get_connection()  # Перевикористовує існуюче з'єднання
    ...

Для Java AWS пропонує SnapStart: створюється снепшот ініціалізованого стану, скорочуючи cold start з 1-2 с до 100-200 мс. Рішення активується однією опцією. Детальніше в документації AWS.

Підбір стратегії warming

Ми підбираємо комбінацію методів під ваше навантаження. Процес включає:

1. Аналіз — вивчаємо профіль cold start, визначаємо порогові значення latency.
2. Проектування — вибираємо стек: EventBridge, Parallel warming або Provisioned Concurrency.
3. Реалізація — пишемо код warmer'ів, налаштовуємо автоскейлінг.
4. Тест — запускаємо навантажувальне тестування, порівнюємо latency до та після.
5. Деплой — впроваджуємо в CI/CD, налаштовуємо моніторинг.

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

Ми надаємо повний пакет: аудит поточної архітектури, проектування стратегії warming, реалізацію коду warmer'ів, налаштування моніторингу та алертингу, документацію з експлуатації. Після впровадження ви отримуєте зниження P99 latency, скорочення витрат на інфраструктуру до 30%, доступ до нашої експертизи — понад 5 років роботи з serverless, 20+ успішних проєктів. Також проводимо навчання команди та підтримуємо протягом місяця після деплою. Для підбору оптимальної стратегії зв'яжіться з нами. Замовте аудит вашої serverless архітектури.

Порівняння методів та результати