Tecnología e Infraestructura → Arquitectura en la nube y SLA
Arquitectura en la nube y SLA
1) Por qué los SLA y cómo administrarlos
SLA (Service Level Agreement) es una promesa externa a empresas/socios sobre la disponibilidad, velocidad y corrección del servicio.
SLO (Service Level Objective): niveles de destino internos para los comandos.
SLI (Service Level Indicator) son métricas medibles en base a las cuales se evalúa el SLO.
iGaming/Fintech se caracteriza por sus ventanas de picos rígidos (torneos, apuestas en vivo, períodos de informes, días de «nómina»), fuerte dependencia de los proveedores de PSP/KYC y la geografía. Los SLA deben tener en cuenta este comportamiento, y la arquitectura debe proporcionar garantías no sólo medianas, sino también percentiles.
2) Terminología básica
Disponibilidad (Availability): porcentaje de solicitudes válidas por intervalo.
Latencia - P50/P95/P99 para operaciones clave.
Error: defina exactamente (5xx, tiempo de espera, error de negocio?).
RTO (Recovery Time Objective) - cuánto tiempo se permite recuperar.
RPO (Recovery Point Objective) - Cuántos datos se pueden perder en un accidente.
Error Budget - 1 − SLO, «stock» para cambios e incidentes.
3) Marco de arquitectura en la nube bajo SLA
3. 1 Multizonalidad (Multi-AZ)
Replicación de estado (DB, caché, colas) en un mínimo de 2-3 AZ.
Standbai frío/caliente, failover automático.
Balanceadores locales (L4/L7) con cheques de salud per-AZ.
3. 2 Multirregión
Activo-activo: RTO/RPO bajos, consistencia y costo más complejos.
Activo pasivo (hot/warm): más barato, RTO más grande, pero más fácil de controlar los datos.
Routing geográfico (GeoDNS/Anycast), aislamiento de «blast radius».
3. 3 Almacenamiento y datos
DB transaccional: replicación sincrónica dentro de una región, asíncrona interregional.
Caché: réplicas regionales cruzadas, modo «local reads + async warmup».
Almacenamiento de objetos: versionamiento, bucles de vida, replicación cross-region.
Colas/streaming: clústeres espejados/flujos multi-regionales.
3. 4 Aislamiento de contornos
Separación de servicios críticos (payments/wallet) y tareas analíticas «pesadas».
Rate-limits/quotas entre contornos para que los informes no se «coman» el prod.
4) Patrones de alta disponibilidad
Bulkhead & Pool Isolation - Aislamiento de agrupaciones de conexiones y recursos.
Circuit Breaker + Timeouts - Protección contra las restricciones de las integraciones externas.
Idempotency - Repetimos las solicitudes sin dobles cargos.
Degradación Graceful - Cuando se degradan, desactivamos los fiches nefundamentales (avatares, filtros extendidos).
Backpressure - Controle el flujo entrante, no permita colas «hasta el horizonte».
Chaos/Failure Injection son «fallas» planificadas para probar hipótesis de fiabilidad.
5) Estrategias de DR (Disaster Recovery)
Selección: pagos/billetera - mínimo de Hot Standby; contenido/catálogo - Warm; informes - Backup & Restore con ventanas claras.
6) Sobre SLI/SLO: cómo medir correctamente
6. 1 SLI por nivel
SLI cliente: end-to-end (incluyendo gateway y proveedores externos).
SLI de servicio: «pura» latencia/error del servicio.
SLI Business: CR (registratsiya→depozit), T2W (time-to-wallet), PSP-decline rate.
6. 2 Ejemplos de SLO
Disponibilidad de la API de Core: ≥ 99. 95% en 30 días.
Latencia de iniciación de payout: P95 ≤ 350 ms, P99 ≤ 700 ms.
Entrega de webhooks PSP: ≥ 99. 9% durante 60 segundos (con retrés).
Informes de Freshness de Datos: ≤ 10 min lag en el 95% del tiempo.
6. 3 Error Budget Policy
El 50% del presupuesto es para cambios (lanzamientos/experimentos), el 50% para incidentes.
La combustión del presupuesto → friso fich, sólo estabilización.
7) Rendimiento y escalabilidad
HPA/VPA con señales orientadas a SLO (no solo CPU, sino también colas/latencia).
Skaling predictivo basado en horarios y picos históricos.
Warm pools/pre-calentamiento de las conexiones a la DAB/PSP antes de los torneos.
Almacenamiento en caché y edge: reduzca el RTT, especialmente para directorios de juegos y conjuntos estáticos.
8) Capa de red y tráfico global
Anycast/GeoDNS para minimizar la latencia y localización de accidentes.
Políticas de fallas: muestras de salud de la región, umbrales, «stickiness» con TTL.
mTLS/WAF/Rate Limit en el borde, protección contra el tráfico de bot.
Control Egress a PSP/KYC por allow-list y SLA-aware retrés.
9) Datos y consistencia
Selección del nivel de consistencia: riguroso (payments) vs eventual (directory/ratings).
CQRS para descargar lecturas y verticales de comandos críticos.
Outbox/Inbox para la entrega de eventos «exactamente una vez».
Migraciones sin downtime: expand-migrate-contract, grabación doble durante cambios MAJOR.
10) Observabilidad (Observabilidad) bajo SLA
Tracks a través de la puerta de enlace: correlación de 'trace _ id' con el socio/región/versión de la API.
SLO-dashboards con burn-rate, «tiempo» por región y proveedor.
Alertas por síntomas, no por síntomas proxy (no CPU, sino P99/errores).
Synthetics: inspecciones externas de países de destino (TR, BR, EU...).
Auditoría e informes: exportar SLI/SLO a un portal de afiliados.
11) Seguridad y cumplimiento
Segmentación de redes y gestión secreta (KMS/Vault).
Encriptación en vuelo/reposo, tokenización PAN/PII.
Políticas de acceso por roles para Almirantes/Operadores.
Los registros son inmutables (WORM) y se retoca para la auditoría.
Regulación: almacenamiento en la región, informes, probabilidad de la ejecución de SLA.
12) FinOps: SLA como controlador de valor
Apuesta por las desviaciones de SLO: cuánto cuesta + 0. 01% de disponibilidad?
Perfila las ventanas de pico, no infles la potencia constante.
Right-sizing y «spot donde se puede» para las tareas de fondo.
Cuotas y presupuestos para los circuitos, no permitir la degradación «gratuita».
13) Pruebas de confiabilidad
Sesión GameDay/Chaos: apaga AZ/PSP, retrasos en las colas, saltos BGP.
DR-drili: formación regular para cambiar de región con objetivos de RTO.
Load & Soak: carreras largas con perfiles de apuestas/torneos reales.
Incidentes de Replay: biblioteca de fails conocidos y scripts de reproducción.
14) Lado del procesador SLA
Catálogo SLO: propietario, fórmula, métricas, fuentes, alertas.
Cambios a través de RFC/ADR: evaluación del impacto sobre el error budget.
Postmortem: mejora de la arquitectura y ranbooks, ajuste de SLO.
Comunicaciones con socios: mails, status page, mantenimiento planificado.
15) Ejemplos de SLI/SLO/informes
15. 1 Fórmulas
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15. 2 Ejemplo de conjunto de SLO para la API de Core
Disponibilidad (30 días): 99. 95%
P95 de endpoint '/v2/payouts/create ': ≤ 350 ms
Errores 5xx (deslizante 1 h): <0. 3%
Webhook delivery ≤ 60 сек (P99): ≥ 99. 9%
RPO para billetera: ≤ 60 segundos, RTO ≤ 5 minutos
15. 3 Informe SLA (apretón)
Completado: 99. 97% (SLO 99. 95%) +
Infracciones: 2 episodios por región BR debido a Timauts PSP (acumulados 8 min).
Medidas: agregado smart-routing por códigos de falla, aumento de las conexiones de pool warm a PSP-B.
16) Lista de verificación de implementación
1. Se han definido rutas de usuario críticas y los SLI correspondientes.
2. SLO para 30/90 días + error budget policy.
3. Multizonalidad y plan de DR con objetivos de RTO/RPO, driles regulares.
4. Synthetics de geo-target, dashboards per-region/per-PSP.
5. Patrones de sostenibilidad: circuit breaker, backpressure, idempotency.
6. Política de degradación y flagelos feature para fiches inhabilitables.
7. FinOps: presupuestos por circuitos, pronóstico de picos, warm pools.
8. Seguridad: segmentación, cifrado, auditoría.
9. Documentación de SLA para socios, proceso de comunicación.
10. Retrospectivas y revisiones de SLO cada Q1-2.
17) Anti-patrones
Promete un SLA sin SLI medibles y una técnica de recuento transparente.
Contar la disponibilidad «en la entrada del servicio», ignorando la puerta de enlace/proveedores.
Apoyarse sólo en la latencia media, ignorando las colas de P99.
DR «por papel», falta de entrenamiento real.
Recursos «eternos» sin límites: un informe valora el prod.
Mezclar prod y análisis pesado en un solo clúster/DB.
18) Resultado
La arquitectura en la nube bajo SLA es una combinación de patrones técnicos (multi-AZ/región, aislamiento, datos tolerantes a fallas), procesos (SLO, error budget, DR-driley) y economía (FinOps). Date derecho a las fallas proyectadas: prueba la tolerancia a fallas, mide los percentiles, limita el «radio explosivo» y comunica abiertamente. Entonces las promesas de SLA no se convertirán en marketing, sino en prácticas de ingeniería guiada.