Edge
DDoS, CDN, WAF, API gateway
Первый слой принимает внешний трафик, фильтрует атаки и ограничивает прямой доступ к origin.
Anycast / scrubbing · TLS · WAF · rate limits
Architecture
Референсная архитектура для production iGaming-платформы
Типовая схема разделяет публичный edge, приложения, базы данных, management и recovery-контуры. Конкретное размещение зависит от рынка, лицензии, нагрузки и требуемых RPO/RTO.
Reference flow
Базовый путь пользовательского трафика
Эта схема намеренно упрощена: она показывает границы ответственности и место защитных компонентов, а не конкретный vendor stack.
Internet
→DDoS
→WAF / API
→Load Balancer
→Web / App
→DB Cluster
MonitoringSIEM / LogsBackupsManagement NetworkDR Site
CDN или WAF перед сайтом не отменяет требования к местоположению origin, базы данных или других критических систем, если такие требования установлены для конкретной лицензии.
System layers
Разделяйте функции и blast radius
Delivery
Load balancing и web tier
Распределяет запросы между несколькими инстансами и позволяет выводить узлы из rotation без полной остановки сервиса.
Health checks · session strategy · autoscaling where applicable
Application
Game API, wallet, integrations
Бизнес-логика и внешние integrations разделяются на сервисы с минимально необходимыми сетевыми разрешениями.
Private network · service ACL · secrets management
Data
Player, financial и gaming databases
Критические базы размещаются в приватном сегменте, реплицируются по выбранной модели и не имеют прямого публичного ingress.
Replication · encryption · backup policy · query monitoring
Management
Административный доступ
Management plane отделяется от пользовательского трафика. Доступ выдаётся по ролям и фиксируется в журналах.
MFA · bastion / VPN · PAM · admin audit logs
Recovery
Backups и DR
Копии и DR-среда не должны зависеть от тех же отказов и учётных данных, что production.
RPO/RTO · isolated copies · restore/failover tests
Deployment patterns
Четыре распространённые модели
Модель выбирается не по моде, а по regulatory boundary, latency, уровню доступности и операционным возможностям команды.
Single-site HA
Несколько узлов внутри одной площадки. Хорошая защита от отказа сервера, но не от потери всего дата-центра.
Primary + DR
Основная площадка и отдельная recovery-среда. Подходит, если бизнес допускает контролируемое переключение.
Multi-site active/active
Трафик обслуживается несколькими площадками одновременно. Сложнее в данных и эксплуатации, но уменьшает downtime.
Local + external services
Критические regulated компоненты остаются в обязательной локальной зоне, а допустимые вспомогательные сервисы выносятся отдельно.
Availability
HA и DR решают разные проблемы
High Availability
HA уменьшает влияние отказа отдельного узла, сетевого элемента или процесса. Для этого используются несколько application nodes, health checks, redundant network paths и database replication.
Disaster Recovery
DR отвечает на более крупный сценарий: потеря площадки, критического сегмента или невозможность продолжать работу в основном окружении. Здесь нужны отдельная среда, данные, инструкции и регулярные failover tests.
RPO и RTO
RPO определяет допустимую потерю данных во времени. RTO — сколько времени допустимо потратить на восстановление сервиса. Эти числа задают требования к replication, backup frequency и типу DR-модели.
Go-live
Пять этапов запуска production
- 1
Аудит требований
Страна, лицензия, игроки, данные, нагрузка, integrations и ограничения.
- 2
Архитектура
Compute, сеть, DDoS, HA, backup, DR, monitoring и доступ.
- 3
Развёртывание
Сети, security policies, compute, logs и миграционная среда.
- 4
Тестирование
Load, failover, restore, access и критические пользовательские сценарии.
- 5
Operations 24/7
Monitoring, инциденты, capacity management и регулярные recovery tests.
Связанные разделы
Архитектура опирается на три входных набора требований
Architecture review