GH GambleHub

Технологии и Инфраструктура → 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 + управляемые сервисы, добавьте идемпотентность, оркестрацию и наблюдаемость, дисциплинируйте стоимость — и получите платформу, которая выдерживает пики, быстро эволюционирует и остается экономной.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Telegram
@Gamble_GC
Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.