Технологии и Инфраструктура → Serverless-подход и функции
Serverless-подход и функции
1) Что такое serverless и когда он нужен
Serverless — модель, где облако берет на себя управление серверами, масштабирование и патчи, а команда пишет обработчики событий и использует FaaS (Functions-as-a-Service) и BaaS (managed сервисы: очереди, БД, хранилища). Вы выигрываете в скорости поставки, платите за фактическое исполнение и легко масштабируете «шипучие» нагрузки.
Где это особенно полезно в iGaming/финтех:- Вебхуки PSP/KYC (много коротких запросов, непредсказуемые пики).
- Антифрод/скоринг (событийные функции, enrichment, feature store).
- Отчетность/CDC → DWH (пакетная и стриминговая обработка).
- Маркетинг/CRM (триггерные события, пуши, купоны, сегментация).
- Легкие backend-API и служебные задачи (throttling, cron-функции).
- Требуется постоянная низкая P99-латентность (суб-10мс) без колебаний.
- Долгоживущие соединения/протоколы (высокочастотный real-time без прокси).
- Большие, stateful вычисления с длительным CPU/GPU и tight coupling.
2) Архитектурные кирпичики
2.1 FaaS
Обработчики на события: HTTP/API-шлюз, очереди, стримы, таймеры, объектное хранилище, БД-триггеры.
Тонкий старт/пакетирование: слои/образ-функции, прогрев.
2.2 BaaS и интеграции
Очереди/стриминг (at-least-once), Pub/Sub для событий домена.
Хранилища: объектное (сырье/артефакты), KV/кэш, документы/реляционка.
Оркестрация: state machines/step functions, саги и компенсации.
API-шлюз: аутентификация (OAuth/OIDC/HMAC), лимиты, трансформации.
2.3 Сетевой контур
Публичный фронт (edge/API-шлюз) + приватные функции в VPC для доступа к БД/секретам/PSP.
Egress-контроль: allow-list к PSP/KYC, фиксированные NAT-IP.
3) Производительность: холодный старт, конкурентность, длительность
Холодный старт: первый запуск контейнера функции после простоя.
Митигируйте: минимизируйте зависимости, используйте «прогрев» (periodic invoke), держите функции в одной зоне с источниками, применяйте длительные таймауты осторожно.
Конкурентность: задавайте `max_concurrency` и лимиты на источник (очереди/шлюз), чтобы не «залить» PSP/БД.
Длительность исполнения: для долгих задач — разбивка на шаги + оркестрация (step functions), для тяжелых вычислений — batch/containers.
4) Надежность: идемпотентность, ретраи, DLQ
Идемпотентность: `Idempotency-Key` / дедупликация на приеме (ключ + TTL-хранилище).
Ретраи: экспоненциальный backoff + jitter, лимиты попыток; отделяйте бизнес-ошибки (4xx) от временных (5xx/timeout).
DLQ (dead-letter queue): для сообщений, не прошедших после N попыток; обязательна replay-консоль и трассировка.
Exactly-once (практически): шаблоны outbox/inbox, транзакционный журнал событий.
5) Состояние и оркестрация
Без состояния в функции, состояние — во внешних хранилищах.
State machines: шаги платежа/вывода, KYC-workflow, антифрод-проверки; четкая модель ошибок/компенсаций.
Саги: «зарезервировать → подтвердить → компенсировать» при откате.
6) Безопасность и соответствие
IAM по принципу наименьших привилегий: роли per-функция, scoping на очереди/бакеты/таблицы.
Секреты: менеджер секретов/KMS, ротация, HSM-уровень для ключей.
mTLS/HMAC для вебхуков, подпись тела, окно времени ±5 мин.
Встроенные WAF/бот-защита на API-шлюзе, rate-limits/quotas.
Сегментация: прод/стейдж, сервисные аккаунты, приватные сабсети.
PII/PCI: токенизация PAN, маскирование логов, «минимизация данных».
Аудит: неизменяемые логи (WORM), трассировка вызовов, хранение по регуляторике.
7) Наблюдаемость и контроль качества
Метрики: RPS, P50/P95/P99, ошибки по кодам, длительность, холодные старты, конвейер ретраев, DLQ size.
Трейсинг (OTel): корреляция `trace_id` сквозь шлюз → функцию → очереди → БД/PSP; обязательные лейблы `api_version`, `region`, `partner`.
Логи: структурированные, с маскированием PII.
Алерты по симптомам: burn-rate SLO, рост ретраев, хвост P99.
Синтетика: проверки из целевых стран (TR/BR/EU), имитация вебхуков.
8) FinOps и стоимость
Платите «за вызовы и миллисекунды». Слежение за: частотой запусков, длительностью, памятью, трафиком.
Профилируйте горячие пути: вынесите тяжелые зависимости в слой/образ, кэшируйте соединения.
Сдерживайте фан-аут (массовые параллельные вызовы) лимитами и батчингом.
Распознавайте «утечки»: бесконечные ретраи, сообщения в DLQ без обработки.
Планируйте пиковые окна (турниры/ивенты) — предиктивный прогрев и квоты.
9) CI/CD и управление версиями
IaC: Terraform/CloudFormation/SAM/CDK — шаблоны функций, очередей, прав, шлюзов.
Пакетирование: lock-файлы зависимостей, минимальный образ/слои.
Тестирование: контракт-тесты (OpenAPI/gRPC), интеграционные с локальным рантаймом, тесты идемпотентности.
Деплой: canary/blue-green, feature flags, быстрый rollback.
Версионирование API: `/vN/` или медиатипы; Deprecation/Sunset и совместимость схем событий.
10) Паттерны для iGaming/финтех
Вебхуки платежей/выводов: прием → валидация подписи → идемпотентность → публикация события `payout.updated` → оркестрация обновлений кошелька/отчетов.
Антифрод-скоринг: функция-enricher (IP/девайс/гео/история), асинхронное решение, таймауты и fallback-стратегии.
KYC/AML пайплайн: параллельные проверки (документы, санкции, PEP), агрегация результатов, саги для повторных запросов.
Турниры/рейтинги: события раундов → streaming-агрегации → обновление таблиц лидеров, TTL-кэш на чтение.
Отчетность регуляторам: CDC → функции трансформации → витрины в DWH, SLA по свежести данных.
Маркетинг/CRM: триггеры поведения → купоны/пуши, дедупликация и лимиты на пользователя.
11) Примеры фрагментов
11.1 Идемпотентный прием вебхука (псевдокод)
python def handler(event):
assert verify_hmac(event. headers, event. body, secret)
key = f"idemp:{event. headers['Idempotency-Key']}"
if kv. exists(key):
return kv. get (key) # repeat - give the same result result = process (event. body) # public event, state record kv. set(key, result, ttl=86400)
return result
11.2 Оркестрация вывода средств (state machine, идея)
1. `validate_request` → 2) `lock_balance` → 3) `call_psp` (с ретраями) →
2. `await_webhook` (таймаут → компенсация) → 5) `finalize/notify`.
12) Чек-лист внедрения serverless
1. Определены источники событий и договоренности по контрактам (схемы/версии).
2. Настроены лимиты конкурентности и «бережные» ретраи, есть DLQ и replay.
3. Включены приватные сети/VPC, egress-allow-list, фиксированные IP к PSP.
4. IAM по принципу наименьших привилегий, секреты в KMS/Secret Manager.
5. Observability: трассировка OTel, дашборды по P99/ошибкам/холодным стартам.
6. FinOps: бюджеты, алерты на стоимость, контроль длительности/памяти.
7. CI/CD: canary/blue-green, автотесты контрактов/идемпотентности.
8. Документация: DevPortal/коллекции Postman, примеры payload’ов, Deprecation/Sunset.
13) Анти-паттерны
«Толстые» функции с кучей зависимостей → медленные холодные старты.
Отсутствие идемпотентности и подписи вебхуков → дубликаты/мошенничество.
Фан-аут без лимитов → шторма конкуренции, троттлинг у провайдера.
Логика в таймерах/кронах без трассировки/алертов → «тихие» провалы SLA.
Смешивание прод-секретов в переменных окружения без шифрования.
Контракты событий без Schema Registry и правил совместимости.
14) Итог
Serverless — это событийная операционная система облака: вы фокусируетесь на бизнес-логике, а масштабирование и инфраструктура — «по требованию». Соедините FaaS + управляемые сервисы, добавьте идемпотентность, оркестрацию и наблюдаемость, дисциплинируйте стоимость — и получите платформу, которая выдерживает пики, быстро эволюционирует и остается экономной.