E-Commerce Exitosos en Black Friday con AWS – Parte 1

Por Adler Oliveira, Arquitecto de Soluciones AWS y Bruno Laurenti, Arquitecto de Soluciones AWS.

Bienvenidos a la primera parte de este blog post dedicada a los e-commerce y a las fechas comerciales de alta demanda.

Comencemos con un poco de contexto.

No hay duda que la industria del e-commerce ha tomado un rol importante durante el 2020 y las fechas comerciales como Black Friday y Cyber Monday se han consolidado como fundamentales para el éxito de cualquier empresa que comercialice productos en forma virtual. Sabemos que durante estos periodos existe una expectativa muy grande de los compradores, no solo por encontrar buenas ofertas si no también por tener una buena experiencia de compra y eso incluye, contar con un sitio que les permita navegar de forma fluida, tener buenas imágenes y detalles claros de los productos, contar con un sistema eficiente de búsqueda y un proceso de pago simple y consistente. Todos estos factores y muchos otros contribuyen significativamente en la decisión de los clientes sobre donde comprar.

Por otro lado, durante las fechas de alta demanda existen numerosos desafíos que complejizan la tarea de poder preparar la infraestructura tecnología para soportar un evento masivo y algunos ejemplos son: Tiempos acotados para mejorar la infraestructura, poco presupuesto, limitada capacidad tecnológica, procesos burocráticos que demoran los procesos de cambio, entre otros.

En el caso de nuestros clientes de retail, ellos han podido mitigar estos desafíos utilizando servicios de AWS, recuperando la agilidad que el negocio requiere, incorporando nuevas técnicas de despliegues agiles, capacidades elásticas para adaptarse dinámicamente a la demanda y fundamentalmente han podido robustecer los niveles de disponibilidad incorporando servicios nativos y administrados por AWS que ya cuentan con esas características.

En base a lo que hemos podido observar en estos eventos junto a nuestros clientes, nuestra intención es poder compartir en este blog post de dos partes, las diferentes estrategias tecnológicas que permiten preparar sus sitios de e-commerce de la mejor forma posible, considerando los plazos de tiempo que tengan disponibles para hacerlo. Abordaremos acciones desde las mas rápidas y sencillas que pueden entregar valor inmediato, hasta las mas complejas como la refactorización utilizando practicas modernas de desarrollo, orientadas a transformar su e-commerce en una solución elástica y con agilidad para adaptarse a los cambios.

¿Por donde empezamos?

Conocer los Números como Primer Paso

Una de los puntos mas importantes en el proceso de planificación para un evento masivo es asegurarse de conocer muy bien como se ha comportado su sitio de e-commerce en fechas pasadas. Como punto de partida, buscar métricas históricas de algunas de estas fechas será de gran ayuda para establecer las bases del trabajo que tendrán que realizar para el próximo evento. Algunos ejemplos de estas métricas pueden ser: Usuarios simultáneos conectados, promedio de tiempos de carga de paginas, transacciones por segundo (TPS), cantidad de llamadas concurrentes a APIs, consumo de recursos de cómputo (CPU, memoria, almacenamiento y red) tanto para bases de datos como servicios de back-end, entre muchos otros.
Una vez que cuenten con esa información, recomendamos ajustar la arquitectura, según las proyecciones de venta que el negocio haya establecido como objetivo, para que luego comiencen a trabajar en la siguiente etapa que viene a continuación.

Es Hora de Definir como Diseñar…

… Y la clave esta en el tiempo que ustedes tengan para preparase para el evento sumado a la cantidad de profesionales que podrán enfocarse en las tareas.

Tenemos claro que no todas las empresas pueden dedicar la misma cantidad de tiempo para enfocarse en su sitio de e-commerce. Algunos cuentan con poco tiempo, por lo que sus decisiones de diseño tienen que seleccionarse y priorizarse cuidadosamente. Otros por ejemplo, planifican con mucha anticipación lo que van a hacer. También tenemos claro que los equipos que operan con nuestra nube, son diversos en conocimiento y cantidad de personas, lo que también puede afectar el tiempo total necesario para poder implementar cambios evolutivos en sus sitios.

Por estas razones, hemos decido estructurar esta sección en tres estrategias de arquitectura que se basan en el corto, mediano y largo plazo. Es importante comprender que para cada empresa, estas tres estrategias, pueden significar diferentes plazos de tiempo. Esto básicamente significa que lo que algunos podrían implementar en el mediano plazo otros podrían hacerlo en el corto, dependiendo de los recursos que tengan para poder ejecutarlo.

Para el ejercicio vamos a asumir una arquitectura genérica y simplificada que podría representar la mayoría de los e-commerce en el mercado. Vamos a considerar una arquitectura de tres capas con una conexión a un ambiente On-Premises (a través de una VPN Site-to-Site) que permite al e-commerce comunicarse con sistemas legados. Además consideramos que en todas las capas ya existen replicas de los servicios y servidores para entregar alta disponibilidad, pero no necesariamente desplegadas en diferentes zonas de disponibilidad. Para nuestra revisión consideraremos buenas prácticas basadas en el Well Architected Framework, que nos va ayudar a crear un arquitectura segura, de alto rendimiento, resistente y eficiente:

Veamos la arquitectura que utilizaremos como punto de partida.

Ahora comencemos por lo mas sencillo e inmediato.

El Corto Plazo

Los cambios de corto plazo son ideales para cuando la fecha del evento masivo se encuentra a pocas semanas de distancia, o cuando exista un presupuesto limitado que no permitan otras alternativas. Por consecuente, las siguientes recomendaciones están basadas en cambios de infraestructura que demandan muy pocos cambios a nivel de aplicación. De esta manera, puede ser ejecutados y probados por el equipo de infraestructura fuera de los ciclos de desarrollo.

A continuación los cambios que recomendamos para el corto plazo.

Mejoras en el front-end con el Uso de la Content Delivery Network (CDN)

El front-end es la cara digital visible del negocio, dependiendo de cómo esté diseñada la arquitectura del e-commerce, el acceso al contenido y el renderizado de las páginas web puede consumir una gran cantidad de recursos de computo. Estos procesos suelen incorporar latencia extra al tiempo total de carga de las paginas y así entregar una experiencia poco ideal a los consumidores. Una forma eficiente que recomendamos para acelerar los tiempos de carga y además alivianar los recursos de computo, es utilizar el servicio Amazon CloudFront para crear una capa de cache para los contenidos estáticos (Imágenes, Scripts, Estilo). CloudFront almacena una copia de estos contenidos en una ubicación geográficamente mas cercana de los consumidores, disminuyendo así los tiempos de carga asociados a la distancia entre el origen de los contenidos, respecto de los usuarios.

Incorporar Alta Disponibilidad con Zonas de Disponibilidad

Todas nuestras regiones estan diseñadas con dos o mas zonas de disponibilidad (Clusters de centros de datos geográficamente dispersos). La idea es que, con muy poca complejidad adicional, pueden aumentar la disponibilidad y eliminar únicos puntos de falla, distribuyendo en dos o mas zonas de disponibilidad los componentes del e-commerce, mitigando de esta forma, la perdida de servicio que pueda ocurrirle a cualquiera de ellos. Para el ejemplo de esta arquitectura recomendamos dos zonas por una cuestión de simplicidad, pero su e-commerce de ser necesario, podría estar distribuido en mas de dos.

De la misma manera que para la capa de computo, con el servicio de bases de datos Amazon Relational Database Service (RDS), es posible habilitar «Multi-AZ Deployment» que se encargará de disponibilizar una base de datos Standby con replicación sincrónica en otra zona de disponibilidad lista para recibir carga en caso de una falla o un mantenimiento programado en la base primaria. Es importante mencionar que asumimos el uso de RDS para la bases de datos, pero si ustedes cuentan con instancias de cómputo EC2, deberán diseñar la alta disponibilidad con las tecnologías que les brinde el motor de base de datos que estén utilizando.

Aumentar la Capacidad con Réplicas de Lectura para Bases de Datos

Una de las maneras mas escalables y eficientes que recomendamos para asegurar la capacidad durante una situación de alta demanda es el escalamiento horizontal. Esta estrategia de escalamiento permite adicionar mas capacidad con el mínimo de disrupción a los sistemas que están corriendo. RDS permite trabajar con replicas de lectura en motores como: MySQL, MariaDB, PostgreSQL, Oracle y SQL Server. Además la utilización de réplicas de lectura permite la correcta distribución de esas peticiones a mas de un servidor, evitando que la base de datos primaria se vea sobre cargada con peticiones.

Aumentar la Capacidad del Cómputo con Grupos de Auto Scaling

Para el caso de la capa de cómputo recomendamos implementar grupos de Auto Scaling, el cual consiste en una colección de instancias Amazon EC2 que se tratan como una única agrupación lógica en lo que respecta al escalado y la administración. El escalado puede ocurrir en respuesta a un aumento en la demanda de diferentes métricas o incluso de forma programada. Además los grupos de Auto Scaling pueden hacer comprobaciones relacionadas a la salud de los servidores y gestionar su reemplazo en caso que se detecte una perdida en el servicio.

Tengan en cuenta que durante las variaciones de demanda experimentadas en las fechas comerciales, es importante mantener una capacidad rápida de respuestas ante posibles fluctuaciones de trafico, para lo cual, los grupos de Auto Scaling forman parte de la primera línea de defensa en una arquitectura robusta y elástica.

Incorporar Visibilidad y Monitoreo a través de CloudWatch

Para poder monitorear la salud de los componentes del e-commerce y responder adecuadamente a cualquier evento anómalo durante las fechas comerciales, es necesario tener visibilidad de los recursos y aplicaciones responsables de entregar a los clientes la experiencia de compra. Para tal fin, recomendamos configurar Amazon CloudWatch para el monitoreo centralizado del entorno. Con CloudWatch la idea es que puedan recopilar, visualizar y correlacionar los recursos, aplicaciones y servicios de AWS como también los recursos en el centro de datos local.

Es posible además establecer alarmas y automatizar acciones en función de umbrales predefinidos o de algoritmos de aprendizaje automático que identifican los comportamientos anómalos en sus métricas. La idea detrás de estas configuraciones es poder responder rápidamente de forma automatizada y con la información adecuada de los eventos anómalos. La rapidez de la respuesta en caso de problemas es fundamental para la entrega de la mejor experiencia de compra en especial cuando ocurren inestabilidades en el entorno. Hablaremos mas de este tema, en la sección de «Operando durante el evento»

El Mediano Plazo

Continuando con el mediano plazo y asumiendo que los cambios de corto plazo fueron implementados, nuestro siguiente paso consistirá principalmente en buscar desacoplar y micro segmentar varios componentes de la arquitectura mediante servicios de caching, pooling de conexiones, almacenamiento y contenedores. Por otro lado, robustecer la solución final desde el punto de vista de la seguridad y las comunicaciones es otro de los objetivos que pretendemos cumplir para esta estrategia de mediano plazo.

Veamos como seria la arquitectura en el siguiente diagrama.

Desacoplar el Front-end

Como pueden ver en el diagrama, seguimos manteniendo el front-end con grupo de auto escalamiento pero la diferencia esta en que varias de las funcionalidades se desacoplaron del cómputo y se delegaron a servicios Serverless, administrados por AWS. En primer lugar la incorporación del API Gateway permite mover toda la lógica y gestión de APIs a un servicio que cuenta con escalabilidad y alta disponibilidad en forma nativa y en segundo lugar, la incorporación del servicio de almacenamiento de objetos S3 tiene la finalidad de almacenar en forma redundante y desacoplada del front-end, todo el contenido estático que tiene el sitio.

Desacoplar el Back-end

Usar un paradigma de desarrollo de aplicaciones basada en micro servicios tiene muchas ventajas. Implementado para un caso de uso como un e-commerce, este paradigma es particularmente eficiente ya que combina bien con la naturaleza de segregación de responsabilidades frecuentemente encontrada en este tipo de soluciones. Una tienda virtual suele estar hecha de componentes que poseen límites claros. Funcionalidades como carro de compra, procesamiento de ordenes, búsqueda de productos, recomendaciones de productos, gestión de logística, gestión de inventarios, y procesos de pago, puede ser manejadas de manera independiente, utilizando diferentes tecnologías e incluso diferentes bases de datos. Por eso, en búsqueda de tener un back-end mas modularizado, se busca ir desacoplando la capa de cómputo EC2 en micro servicios y para lograr esta tarea se puede optar por trabajar con contenedores. La idea es poder contar con una tecnología que permita adoptar metodologías mas robustas para orquestar y operar micro servicios a gran escala y que se ajusten nativamente a metodologías de despliegue mas agiles.

A la hora de seleccionar una tecnología de orquestación de contenedores les recomendamos evaluar principalmente tres cosas: Primero el conocimiento que tengan de AWS, en segundo lugar el nivel de experiencia que el equipo tenga y en tercer lugar el nivel de responsabilidad sobre la operación que quieren tener sobre la plataforma de contenedores. A partir de esa información estarán en mejores condiciones para seleccionar si utilizar ECS o EKS y el uso de Fargate como motor de cómputo para delegar la tarea definir el cómputo y las configuraciones de auto escalamiento a un servicio administrado.

Por ultimo, buscando también desacoplar el flujo de comunicaciones, este back-end tiene como característica que se accede directamente desde el API Gateway donde para cada micro servicio existe una API diferente que representa una funcionalidad del sitio de e-commerce.

Como mensaje final, queremos decirles que utilizar los micro servicios para la construcción del e-commerce, no solo es buena idea, también permite aislar el alcance que una potencial falla podría generar. Además, permite que diferentes equipos de desarrollo trabajen de manera independiente en cada uno de estos módulos logrando que el proceso de mejora continua pueda ser ejecutado en paralelo y de forma mas eficiente.

Desacoplar la Capa de Base de Datos

En la capa de base de datos el objetivo que se busca con esta arquitectura desacoplada, es reducir la carga hacia las bases de datos primarias mediante un ElastiCache Redis en alta disponibilidad, permitiendo además, independizar aun mas el back-end de las bases de datos, reduciendo el impacto que pueda producir aplicar aquellas nuevas configuraciones que requieren reinicio o incluso un problema que afecte la disponibilidad en este capa.
En particular para los e-commerce con largos catálogos de productos, la posibilidad de contar con una capa de caching intermedia, puede contribuir en mejorar los tiempos de respuesta de cara al cliente durante estas fechas de alta demanda.

Por otro lado esta arquitectura incorpora DynamoDB como base datos no relacional que actúa como una fuente de información para aquellos micro servicios del back-end que requieran rápidas respuestas sin necesidad de realizar consultas complejas o información relacional para cumplir su función, independizando aun mas las bases de datos primarias.

Por último hemos incorporado el servicio de RDS Proxy para desacoplar la gestión de pool de conexiones de las base de datos y delegarla a un servicio administrado que además cuenta con alta disponibilidad nativa. Debido a que la gestión de conexiones es un proceso computacionalmente costoso que consume tiempo, este servicio también ayuda a reducir los tiempos de respuesta en especial cuando trabajamos a gran escala con miles de conexiones simultáneas.

Mejoras de Seguridad en el Front-end

Durante el mediano plazo, recomendamos robustecer la seguridad del front-end con servicios que se integran en forma transparente con el resto de los servicios. En primer lugar el uso de AWS WAF para bloquear/mitigar ataques de capa siete mediante el uso de reglas provistas por AWS o provenientes de los principales fabricantes de seguridad de la industria.

En segundo lugar para ataques DDOS, hacer uso de Shield Advance que aporta mejoras sobre el servicio standard en lo que respecta a la detección de ataques mas sofisticados en la capa de red y transporte, protección de costos y finalmente la posibilidad de contar con el apoyo proactivo de un equipo de respuesta de AWS encargado de ayudarlos en la mitigación de estos ataques en un momento tan critico como el de un evento masivo.

Les recomendamos que evalúen el uso de estos servicios, no como un gasto adicional si no como una inversión que permite evitar o ayudar a mitigar rápidamente ataques, que de lo contrario, podrían significar una perdida financiera importante que los alejaría de poder cumplir con los objetivos comerciales del negocio.

Mejoras de Conectividad

Por ultimo y no por eso menos importante, sabemos que muchos clientes han optado por arquitecturas hibridas en donde varios componentes críticos del e-commerce aun siguen funcionando en sus data centers locales. Por esta razón sugerimos incorporar en la arquitectura, un diseño de conectividad mas robusto con la incorporación del servicio de conectividad Direct Connect. Este servicio, provisto por un proveedor de comunicaciones, ofrece un SLA de servicio y anchos de banda y latencias mas consistentes que los enlaces de VPN tradicionales. El diseño, si bien se encuentra simplificado, pretende demostrar que la solución debe contar con un enlace de conectividad primario y otro secundario para evitar la perdida de servicio que una potencial falla de un enlace de red podría causar sobre el sitio de e-commerce.

El siguiente Paso

 En esta primera parte nos enfocamos en estrategias evolutivas para su e-commerce enfocadas en cambios de baja y mediana complejidad para el corto y mediano plazo, las cuales, les permitirán afrontar de mejor manera los periodos de alta demanda garantizando una mejor experiencia de compra.

Pero esta travesía continua y hay mucho mas camino por recorrer.

Es por eso que los invitamos a la segunda parte, para que puedan profundizar los grandes cambios que podrían implementar para operar de manera mas eficiente y escalable conforme su e-commerce continúa creciendo.

Sobre los Autores

Adler Oliveira es Arquitecto de Soluciones en AWS con foco en clientes del segmento Enterprise Retail.

Bruno Laurenti es Arquitecto de Soluciones en AWS con foco en clientes del segmento Enterprise Financiero y Retail.

Sobre los Revisores

Sergio Barraza es Technical Account Manager en AWS con foco en clientes del segmento Enterprise Retail.

Angel Goñi es Arquitecto de Soluciones en AWS con foco en SAP y la industria CPG (Consumer Packaged Goods)