Caso de éxito
Lepok
E-commerce y ERP con escalado estacional: más capacidad en temporada alta y menor costo en temporada baja.
Sobre el cliente
Comercio minorista: papelería e informática
Lepok trabaja en los segmentos de papelería e informática, con comercio físico, ventas corporativas y e-commerce, en un mercado competitivo y de marcada estacionalidad.
A fines de 2018, la empresa llegó a un punto de inflexión: el ERP en uso empezó a exigir una infraestructura más robusta, elástica y alineada con las nuevas arquitecturas. El modelo on-premises, basado en un CAPEX elevado y con limitaciones físicas, ya no acompañaba al negocio ni ofrecía previsibilidad.
La dirección decidió entonces trasladar la inversión en infraestructura de CAPEX a OPEX, en busca de flexibilidad, escalabilidad y control financiero, y contrató a KXC para diseñar e implementar una arquitectura en AWS capaz de sostener el crecimiento, reducir los riesgos y preparar a la empresa para su evolución futura.
El proyecto comenzó con la migración del e-commerce y continuó con la migración completa de la infraestructura del ERP, siempre con foco en la continuidad, el desempeño y la alineación con los objetivos estratégicos.
Problema a resolver
Lepok opera tiendas físicas, ventas B2B y e-commerce, y su ERP, basado en SQL Server on-premises, enfrentaba estos problemas:
- Estacionalidad extrema: la demanda se triplica en picos como la vuelta a clases (enero y febrero en Brasil) y el fin de año. En esos períodos, el uso de CPU superaba el 95 %, lo que causaba lentitud severa e indisponibilidad.
- Pérdida de pedidos: estimada en un 20 % durante los picos, porque los sistemas lentos o caídos impedían procesar los pedidos.
- Modelo de CAPEX rígido: la infraestructura dimensionada para el pico quedaba ociosa (CPU por debajo del 20 %) durante los 9 meses de baja demanda, con un costo fijo de R$ 15 000 (reales) por mes.
- E-commerce limitado: la infraestructura estática impedía escalar horizontalmente para las campañas estacionales.
- Respaldos sin validación: los respaldos se hacían en almacenamiento local, sin pruebas formales de restauración. El RPO real era desconocido y el RTO estimado superaba las 6 horas.
- VPN precaria: la conexión de las tiendas con el servidor central sufría tiempos de espera agotados frecuentes en el punto de venta durante los picos de ventas.
Solución propuesta
Fase 1: Assessment y arquitectura para el escalado estacional
- Análisis de 12 meses de métricas de SQL Server para identificar los picos de 3 veces la línea base. Línea base: db.r6i.large; pico: db.r6i.xlarge.
- TCO a 3 años comparando CAPEX (hardware on-premises) y OPEX (AWS), con un ahorro del 57 % en el costo fuera del pico. El pico exige escalar a db.r6i.xlarge durante 6 a 8 semanas por año.
- Arquitectura elástica: Auto Scaling Group en la capa de aplicación (Amazon EC2), instancia de RDS escalable y réplica de lectura para el e-commerce en los picos.
Fase 2: Migración con AWS DMS
- AWS Schema Conversion Tool para analizar el esquema del ERP.
- AWS Database Migration Service con Full Load y CDC, para migrar sin tiempo de inactividad durante la sincronización.
- Migración concluida antes del pico de octubre de 2025, para estabilizar la producción antes de fin de año.
- Corte en una ventana de 3 horas, en la madrugada de un domingo, con validación de integridad (conteo de filas y DBCC CHECKDB) y sin pérdida de datos.
Fase 3: Infraestructura en AWS con escalado elástico
- Amazon RDS for SQL Server Standard: db.r6i.large en operación normal, en Multi-AZ (principal en sa-east-1a y réplica en espera en sa-east-1b). En los picos, escala a db.r6i.xlarge mediante RDS Modify, en una ventana de mantenimiento programada.
- Réplica de lectura: se crea en los picos para aliviar las consultas del e-commerce y los informes, aislando la carga de lectura del OLTP del ERP.
- EC2 Auto Scaling Group (Windows Server): escala de 2 a 6 instancias cuando el uso de CPU supera el 60 % y se reduce después del pico.
- AWS Site-to-Site VPN (IPSec AES-256): conexión cifrada entre las tiendas y la VPC, que eliminó los tiempos de espera agotados en el punto de venta.
- EBS gp3 con Storage Auto Scaling: el almacenamiento crece cuando el espacio libre baja del 20 %, sin intervención manual.
Fase 4: Automatización del escalado estacional
- AWS Systems Manager Automation: documentos "seasonal-scale-up" y "seasonal-scale-down", activados manualmente o de forma programada, que escalan o reducen toda la pila.
- Amazon CloudWatch Anomaly Detection: umbrales dinámicos que se ajustan al patrón estacional, sin calibración manual.
- AWS Backup: retención de 90 días en el pico y de 30 días fuera de él, con una instantánea manual antes de cada evento de escalado.
- AWS Systems Manager Patch Manager: parches automatizados fuera de los períodos pico.
Resultados obtenidos
La alianza entre Lepok y KXC, que ya supera los siete años, transformó el entorno tecnológico de la empresa. Los principales resultados fueron:
- Migración del e-commerce a AWS, con estabilidad incluso en los períodos de alta estacionalidad.
- Migración del ERP sin tiempo de inactividad, sin interrumpir las operaciones críticas.
- Arquitectura moderna y escalable, con Amazon RDS y AWS WAF, que mejoró el desempeño, la seguridad y la confiabilidad.
- Optimización recurrente de costos, incluidas revisiones para mitigar las variaciones del tipo de cambio.
- Evolución continua, con pruebas de arquitecturas serverless y de escalado automático.
- Mayor madurez tecnológica, con cercanía a los eventos y a las buenas prácticas de AWS, y la inteligencia artificial como próxima etapa.
Así, la tecnología pasó a ser un habilitador estratégico del negocio, y no solo un soporte operativo.
Resultados e indicadores clave (KPI)
| Indicador | Resultado | Observación |
|---|---|---|
| Capacidad de pedidos en el pico | 2000 pedidos/h | Antes: 500/h (aumento del 300 %). Se superó la meta de 1500/h. |
| Costo de infraestructura fuera del pico | R$ 6500/mes | Antes: R$ 15 000/mes fijos (reducción del 57 %). |
| Disponibilidad en el pico estacional | 99.97 % | Antes: ERP fuera de servicio en los picos. Sin inactividad en el pico de fines de 2025. |
| Latencia de las consultas del ERP | Menos de 50 ms | Antes: de 190 a 230 ms. Mejora con Performance Insights y rightsizing. |
| RTO después de la migración | Menos de 5 min | Conmutación por error Multi-AZ. Antes: más de 6 horas. |
| RPO después de la migración | Menos de 5 min | Respaldos del registro cada 5 minutos. Antes: desconocido. |
| Pedidos perdidos por indisponibilidad | Cerca del 0 % | Antes: entre el 15 % y el 25 % en los picos. |
| Ahorro en TCO a 3 años | 57 % | En comparación con el costo on-premises (hardware, mantenimiento, licencias y DBA). |
Servicios de AWS utilizados
Migración
- AWS Database Migration Service
- AWS Schema Conversion Tool
- AWS Migration Hub
Base de datos y cómputo
- Amazon RDS SQL Server Standard Multi-AZ
- Réplica de lectura de RDS (estacional)
- Amazon EC2 Windows Server (Auto Scaling Group)
- Application Load Balancer
- Amazon S3 (respaldos y archivos)
Operaciones y seguridad
- AWS Site-to-Site VPN (IPSec)
- Amazon CloudWatch con Anomaly Detection
- AWS Systems Manager (Automation y Patch)
- AWS Backup (políticas estacionales)
- AWS KMS (RDS, EBS y S3)
- Amazon VPC con Security Groups
Otros casos de éxito
Agende una conversación con nuestro especialista
Complete sus datos y el servicio que necesita. Nos pondremos en contacto con usted para agendar un horario.