Usando el marco de buena arquitectura para correr cargas críticas de sector público

Por Eduardo Patiño, Solutions Architect, AWS Public Sector,

y Christian Castro, Solutions Architect, AWS Public Sector

Previamente escribimos un blog acerca de como ejecutar cargas criticas en sector público, en ese blog nos enfocamos en la consulta de resultados de elecciones nacionales o estatales link, sin embargo nuestros clientes han observado que siempre que han tenido el apoyo de AWS para ejecutar este tipo de cargas de trabajo criticas, el equipo de AWS ha utilizado junto con ellos el Servicio AWS Well Architected tool con el fin de revisar el estado de las cargas de trabajo y validarlas con las mejores practicas de arquitectura de AWS. Es por esta razón que nuestros clientes nos han solicitado apoyo para entender cómo el marco de buena Arquitectura de AWS hace sentido con sus cargas de trabajo y cuáles son los puntos importantes a considerar para llevar a cabo una liberación a producción exitosa de cualquier tipo de carga de trabajo. AWS es una compañía orientada hacia nuestros clientes y por esta razón hemos decidido escribir una serie de buenas practicas que han usado cientos de veces los arquitectos de soluciones de Amazon Web Services y cada uno de nuestros socios de negocio para ejecutar cargas de trabajo críticas en instituciones como por ejemplo el Estado de Jalisco quien implementó el proyecto de citas ciudadanas para recibir la vacuna contra el COVID-19 en ese estado, Knotion quien usa AWS para escalar y distribuir sin problemas contenido de manera confiable a 50,000 estudiantes en 150 escuelas, El Gobierno del estado de Guanajuato quien pudo escalar las transacciones del ministerio de finanzas a un menor costo, sin sacrificar la seguridad o el Instituto Nacional Electoral de México quien usó AWS para divulgar los resultados de las elecciones presidenciales de México en 2018 y también ejecutó en 2021 las elecciones mas grandes de su historia corriendo sobre AWS. Estas buenas prácticas están alineadas con nuestro marco de buena arquitectura (Well Architected Framework) y les servirán a ustedes para comprender qué deben hacer si tienen una carga de trabajo crítica próxima a salir a producción.

Las buenas prácticas de arquitectura se deben aplicar en todo momento. Nuestro marco de buena arquitectura está compuesto de 5 pilares los cuales son: seguridad, fiabilidad, excelencia operacional, eficiencia en el rendimiento y optimización de costos. En este blog no abordaremos el detalle de nuestro marco de buena arquitectura, pero nos referiremos a este en varios de sus pilares con el fin de que los lectores puedan comprender de una manera sencilla el como seguir este marco les ayudará a tener éxito a la hora de desplegar cargas criticas o cualquier tipo de carga sobre AWS.

Seguridad

Para iniciar hablaremos sobre el pilar base que es la seguridad, para esto existen diferentes principios de diseño donde debemos considerar una base solida de identidad, facilitar la trazabilidad, aplicar seguridad en todos los niveles, automatizar, proteger los datos en tránsito y en reposo, alejar a las personas de los datos para reducir o eliminar el acceso directo o procesamiento manual de los datos, y por último estar preparados para los eventos de seguridad. Para esto debemos iniciar desde llos fundamentos, y debemos considerar diferentes aspectos como el uso de múltiples cuentas, proteger nuestra cuenta raíz de AWS, priorizar riesgos mediante un modelo de amenazas, entre otros. Estas son algunas buenas prácticas a seguir para operar su carga de trabajo de manera segura:

Separar: Separar las cargas de trabajo mediante el uso de diferentes cuentas le ayudará a organizar las cargas de trabajo de una mejor manera, puede usar cuentas individuales o cuentas de grupos según la función que ejerzan. Algo importante a considerar y que vemos recurrentemente es el no planear lo que esperamos a futuro con respecto a nuestro entorno de seguridad, es primordial comenzar teniendo en cuenta la seguridad y a su vez como esperamos que crezcan nuestra infraestructura y aplicaciones en la nube con el fin de implementar los controles de seguridad necesarios según vayan creciendo nuestras cargas de trabajo. Para esto puede hacer uso de Servicios como AWS Organizations que le permitirá hacer cumplir de manera centralizada la administración en función de políticas para múltiples cuentas de AWS, o por otro lado puede usar AWS Control Tower, que ofrece una forma sencilla de configurar y regular un entorno de AWS de múltiples cuentas, de manera segura utilizando las mejores prácticas de AWS.

Proteger la cuenta de AWS: Proteja el acceso a las cuentas mediante la habilitación de MFA (Multi Factor Authentication) y del uso restringido del usuario raíz, por otro lado se recomienda usar usuarios nombrados para la gestión y administración de su cuenta de AWS.

Administrar Identidades: Es importante diferenciar que existe dos tipos de identidades cuando implemente cargas de trabajo sobre AWS, el primer tipo de identidad es a nivel de personas (administradores, desarrolladores, entre otros) el segundo tipo son las identidades a nivel de máquina (aplicaciones, comunicación entre servicios entre otros). Para estos dos tipos de identidades una buena práctica es utilizar credenciales temporales, para las identidades de personas puede utilizar AWS Single Sign On (SSO) para administrar de forma centralizada toda la organización de AWS, igualmente podrá crear identidades de usuario directamente en AWS SSO o bien puede incorporarlas desde el directorio de Microsoft Active Directory o un proveedor de identidades basado en estándares, como Okta Universal Directory o Azure AD.
Para identidades a nivel de maquina AWS Secrets Manager le podrá ayudar para administrar sus secretos de manera fácil y centralizadamente, en AWS Secrets Manager podrá almacenar sus secretos como son credenciales de bases de datos, contraseñas o claves de API entre otros de una manera segura.

Detectar e Investigar eventos de seguridad: Cuando pensamos en ejecutar eventos críticos es importante capturar y analizar los eventos a partir de registros y métricas con el fin de obtener visibilidad de lo que está pasando en nuestro entorno. Teniendo la visibilidad correcta podrá tomar medidas al respecto sobre los eventos de seguridad y las amenazas potenciales que pudiera enfrentar, por esta razón existen 4 prácticas recomendadas: configurar, analizar, automatizar y accionar; hablemos de cada una de ellas y como puede hacer uso de estas mejores practicas:

Configurar: Para poder analizar es necesario configurar, AWS tiene diferentes servicios que pueden ayudarlo a identificar y capturar información a nivel de aplicaciones, recursos y servicios de AWS, servicios tales como AWS CloudTrail, Amazon CloudWatch Logs, Amazon GuardDuty y AWS Security Hub estos servicios le permitirán tener la información necesaria para poder analizar. Es importante validar que estos servicios se encuentran habilitados y configurados en cada una de las regiones donde desplegó servicios de AWS y validar también que esté recopilando la información de manera centralizada. Por ejemplo AWS Guarduty es un servicio de detección de amenazas que busca continuamente la actividad maliciosa y el comportamiento no autorizado a fin de proteger las cuentas y las cargas de trabajo de AWS.

Analizar: Tener la información de los logs, telemetría, etc. de manera centralizada nos permitirá contar con una visión general y de fácil acceso del estado de nuestros servicios y aplicaciones en tiempo cercano al real, lo que nos dará acceso a tableros de control para una fácil gestión, toma de decisiones y automatización de anomalías o accesos no autorizados.

Automatizar: Automatizar la respuesta a incidentes cuando tenemos eventos críticos es primordial, nos permite enfocarnos en lo que realmente puede llegar a ser crítico y por otro lados nos permite investigar y remediar de manera automatizada. La automatización les ayudará a reducir el esfuerzo y los errores humanos, adicionalmente puede contar con diferentes servicios para poder lograr este objetivo, por ejemplo con AWS lambda puede automatizar el proceso de cierre de puertos en un grupo de seguridad en el evento donde se detecte que se han habilitado más puertos a sus grupos de seguridad que los permitidos en su línea base.

Accionar: Cree alarmas que contengan la información necesaria para que usted y su equipo pueda recibir la alarma y accionar una solución sin depender o tener que buscar en múltiples sitios. En este punto el tiempo es critico, entre más información tengamos de manera rápida y consolidada, más pronto podremos tomar acciones para resolver el problema.

Proteger Recursos: Proteger los recursos ya sea de internet o desde la misma red privada requiere de varios niveles de protección, por ejemplo es clave agrupar en niveles componentes que comparten requisitos de accesibilidad como pueden ser bases de datos en una red sin acceso desde internet, servidores de aplicaciones en una subred diferente, o servidores de capa de presentación (considere el uso de varias zonas de disponibilidad). para este propósito puede usar Amazon VPC .
Por otro lado es necesario proteger nuestros recursos y también nuestros datos, para proteger nuestros datos debemos considerar la protección en reposo y protección en tránsito, la protección en reposo puede ser gestionada a través de un almacén seguro de llaves como AWS Key Management Services (AWS KMS), con él puede cifrar sus datos en reposo en múltiples servicios de AWS, por ejemplo: objetos en Amazon S3 o volúmenes en Amazon EBS. Para proteger los datos en tránsito, considere los diferentes servicios que requiere, estos pueden ser cifrar la información usando HTTPS con CloudFront, Balanceadores de carga, conexiones VPN entre otros.

Fiabilidad

Al hablar de eventos críticos algo que debemos pensar es como podemos desarrollar nuestra aplicación lo más fiable posible, con la capacidad de soportar la cantidad de usuarios concurrentes que tendremos y por otro lado que ante alguna falla de cualquier componente la aplicación este lista para seguir operando sin problema, por esta razón dentro de nuestro marco de buena arquitectura otro pilar, es el pilar de la fiabilidad, para esto normalmente debemos seguir 5 principios de diseño con el fin de obtener la fiabilidad que necesitamos, los principios de diseño que debemos preguntarnos son:
1. ¿Cómo podemos recuperarnos de errores de manera automática?
2. ¿Cómo probamos nuestros procedimientos de recuperación?
3. ¿Cómo escalamos horizontalmente con el fin de aumentar la disponibilidad de nuestra aplicación?
4. ¿Cómo dejamos de adivinar la capacidad que requerimos?
5. ¿Cómo automatizamos los cambios?.

Para responder a estas preguntas usaremos nuestro marco de mejores practicas y servicios de AWS que nos ayudará en cada uno de los casos .

1. ¿Cómo podemos recuperarnos de errores de manera automática?. Para solucionar esta pregunta es importante considerar varios aspectos, el primero de ellos es tener en cuenta el objetivo de tiempo de recuperación (RTO), teniendo en cuenta esto y considerando que estamos hablando de cargas críticas el RTO es lo mas cercano a cero, o cero. Use arquitecturas distribuidas que tengan un bajo acoplamiento esto ayudará a aislar el comportamiento de un componente de los demás componentes que dependen de él, lo que aumenta la resistencia y la agilidad, para esto, servicios como AWS SQS, Amazon Kinesis, Amazon EventBridge o AWS Elastic Load Balancer por ejemplo, lo pueden ayudar a desacoplar los componentes que requieren. Igualmente es primordial tener una arquitectura de red bien diseñada, utilizando diferentes segmentos de red y múltiples zonas de disponibilidad con el fin de distribuir la carga entre múltiples zonas e incluso regiones y así poder mitigar posibles problemas que pudieran suceder en una única zona de disponibilidad o región. Igualmente es importante monitorear todos los componentes de su carga de trabajo, esto con el fin de poder detectar errores de manera temprana teniendo en cuenta sus indicadores de rendimiento clave (KPI) con el fin de tomar acciones automatizadas, por ejemplo, use AWS Autoscaling para escalar de manera automática en las diferentes capas de su aplicación.

2. ¿Cómo probamos nuestros procedimientos de recuperación ? Usted puede probar sus procedimientos utilizando la ingeniería del caos, la cual se menciona a más detalle más adelante en la sección de pruebas del presente blog, por otro lado es recomendable tener sus propios manuales operativos con el fin de garantizar la correcta operación de su carga de trabajo. igualmente este proceso puede ser automatizado haciendo uso de scripting, bien sea en Python o PowerShell y usando nuestro servicio de AWS System manager con el fin de automatizar este proceso, agregar documentación estilo wiki y reducir errores.

3. ¿Cómo escalamos horizontalmente con el fin de aumentar la disponibilidad de nuestra aplicación?. Una carga de trabajo escalable le proporcionará la elasticidad para agregar o eliminar recursos de forma automática con el fin que se adapte a la demanda que su carga de trabajo requiere. Cuando hablamos de escalamiento muchas veces pensamos automáticamente en AWS Auto Scaling sin embargo existen servicios que están relacionados entre sí o que puede usar para cumplir diferentes necesidades, alguno de ellos son AWS Elastic Load Balancer, AWS Application Load Balancer que son usados para distribuir la carga hacia múltiples instancias e incluso hacia múltiples zonas de disponibilidad, por otro lado también puede utilizar AWS Network Load Balancer para distribuir su carga de trabajo mediante el protocolo TCP o a fin de tener un conjunto constante de direcciones IP para su carga de trabajo.
Puede usar servicios que ya escalan de acuerdo a la necesidad que se tenga sin necesidad de configurarlo, esto le permitirá durante el pico de su carga crítica tener menos puntos de falla o menos puntos de que preocuparse, por mencionar algunos ejemplos Amazon Route 53 y Amazon CloudFront.

4. ¿Cómo dejamos de adivinar la capacidad que requerimos ? Una causa común de errores en cargas de trabajo críticas es la saturación de recursos cuando la demanda excede la capacidad planeada (este suele ser el objetivo de los ataques de denegación de servicio). En AWS puede monitorear la demanda y la utilización de la carga de trabajo. Además, puede automatizar el proceso de adición o eliminación de recursos a fin de mantener el nivel óptimo para satisfacer la demanda sin llegar a un aprovisionamiento excesivo o insuficiente. Esto no quiere decir que debamos despreocuparnos totalmente de la planeación, aún debemos pensar si con los limites de los recursos que tenemos asignados a nuestra cuenta por defecto, podemos soportar nuestra carga carga de trabajo. Ustedes podrán validar los limites de sus cuentas usando el servicio AWS Service Quotas y desde allí controlar las cuotas de los limites existentes. Si el escalamiento de su carga de trabajo puede llegar a ser atípico en cómo un incremento en el acceso a sus aplicaciones, por ejemplo de cero a millones en cuestion de minutos, valide siempre los limites de su cuenta y contacte algún especialista de AWS que pueda guiarlo en este proceso.

5. ¿Cómo automatizamos los cambios?. Los cambios en su infraestructura deben realizarse mediante la automatización. Para esto es recomendable que integre pruebas funcionales como parte de su implementación, con esto podrá verificar de manera automatizada si cumple o no los criterios de éxito. Puede utilizar las herramientas de CI/CD que mejor conozca o en su defecto hacer uso de Servicios como AWS CodePipeline, AWS CodeBuild y AWS CodeDeploy.

Excelencia Operativa

Generalmente cuando se opera infraestructura tradicional on-premises, la gente involucrada en un proceso operativo utiliza libros de ejecución (runbooks) donde la mayoría de los cambios se realizan por seres humanos siguiendo pasos que muchas veces se encontraban desactualizados en estos runbooks. También era fácil centrarse en las métricas tecnológicas en lugar de los resultados empresariales. Estábamos tan ocupados reaccionando a las situaciones que era difícil dedicar tiempo a extraer aprendizajes. Era difícil mantener la información actualizada ya que estábamos haciendo cambios en todo para combatir los incendios.

En la nube, se eliminan las restricciones de un entorno tradicional y se pueden utilizar los principios de diseño del pilar de la Excelencia Operativa para realizar todos los cambios por código con métricas de negocio con las que se puede medir el éxito. Al automatizar el cambio y utilizar el código, puede pasar a realizar cambios incrementales y reducir el riesgo. Como la infraestructura es ahora código, puede detectar cuando la documentación está desfasada e incluso generar documentación a partir de su código.

Mantener un nivel adecuado de excelencia operativa, atendiendo las recomendaciones del marco de buena arquitectura, le ayudará a tener un modelo de soporte estable en la nube de AWS, y evitar problemas en un momento crítico. Esto también ayudará a evitar dependencias de diferentes personas o interpretaciones de los procesos operativos de su organización, ya que cuando usted automatiza un proceso definido en un runbook, usted tendrá la libertad y agilidad de ejecutarlo en cualquier caso que sea necesario, estos procesos pueden ser un reinicio de una instancia EC2, una modificación a una regla de Security Group, o incluso el despliegue de una nueva función Lambda.

Eficiencia en el Rendimiento

La nube ha alterado fundamentalmente la forma en que podemos construir sistemas preparados para el rendimiento, no es suficiente solamente pensar en hacer todo lo más rápido posible posible, sino también satisfacer sus propios requisitos de negocio con pequeños cambios incrementales que, con el tiempo, pueden sumar grandes mejoras.
De este modo entonces, podríamos decir que la eficiencia en el rendimiento consistirá en asegurarnos de que los recursos que estamos utilizando sean los que se requieren para satisfacer tanto los requerimientos de negocio como los técnicos, y que además tengamos la capacidad de adaptarnos a los cambios en la demanda de nuestras aplicaciones o a nueva tecnología que pudiéramos aprovechar para mejorar.

Pensando en un entorno tradicional on-premises, cuando hablábamos sobre rendimiento necesitábamos considerar temas como:

El hecho de tener muchos servidores que hacían solo una cosa y la necesidad de tener personal para gestionarlos.
Estar limitados porque los despliegues de nuestros aplicativos fueran locales, era casi imposible tener un despliegue global para nuestras aplicaciones críticas.
Como se realizaban grandes inversiones en tecnología, había que pensar en utilizar esa adquisición tecnológica para todo, sino no era justificable la compra. Este punto es una de las razones por las que muchas organizaciones usaban bases de datos relacionales (RDBMS) para todo.

Se forzaba a las organizaciones a que pusieran el rendimiento de sus aplicaciones críticas en función de la poca opción tecnológica que pudieran utilizar, y se terminaba forzando a la tecnología para hacer lo que se necesitaba, sin alcanzar siempre los mejores resultados.

La nube ayuda a quitar esas ataduras tecnológicas, y ahora es posible implementar nuestras arquitecturas contemplando principios de diseño para evitar los anti patrones que se mencionaron anteriormente.

Democratizar las tecnologías avanzadas

Cuando trabaje una arquitectura para una carga de trabajo crítica, es fundamental facilitar al equipo relacionado con el proyecto lel acceso a tecnología avanzada. Esto implica también abstraer la mayor parte de las tareas complejas y delegarlas a AWS, piense en las ventajas de consumirla como servicio, y enfocar a su equipo de trabajo en atender las reglas de negocio que su proyecto necesita. Con esta estrategia será mucho menos costoso y más ágil aprovechar diferentes tecnologías para apalancar su solución, resultando en mejores métricas de rendimiento.
Imagine tratar de construir desde cero una solución de base de datos NoSQL para gestionar petabytes de información, con despliegue multi región y multi maestro, piense el tiempo que le tomaría a sus ingenieros llevar a cabo la construcción de un proyecto así, es mejor dedicar ese tiempo a su negocio y consumir esa infraestructura de base de datos como servicio en la nube.

Global en minutos

Utilizando el paradigma de infraestructura como código, usted puede generar plantillas para desplegar la infraestructura de su aplicación crítica, ya sea con CloudFormation, Terraform, Chef o Puppet. Esto permite generar implementaciones de sus recursos de arquitectura en diferentes regiones geográficas alrededor del mundo.
El despliegue en varias regiones ayuda a acercar su carga de trabajo a su audiencia global, mejorando los tiempos de respuesta, y reduciendo costos.
Al habilitar una infraestructura global usted gana resiliencia y a la vez reparte la carga que pudiera tener su arquitectura si estuviera desplegada en un solo punto, con ello se reparten los recursos y se mejora significativamente el rendimiento.

Use arquitecturas sin servidor

Como principio de diseño para el rendimiento de su arquitectura, es recomendable que no gestione y no mantenga servidores físicos por usted mismo. Esto le restará tracción a las tareas que de verdad importan para su negocio, y no necesariamente obtendrá el rendimiento que su aplicación requiere.
Una arquitectura serverless o sin servidor, no solo elimina la infraestructura que necesita gestionar, sino que hace que el escalado sea significativamente más fácil, porque solo necesita configurar ajustes como la concurrencia o el rendimiento, en lugar de CPU, memoria y almacenamiento.

Experimente más frecuentemente

A diferencia de las arquitecturas tradicionales on-premises, con la nube usted tiene recursos virtualmente ilimitados, y con ello puede llevar a cabo rápidamente comparaciones de diferentes configuraciones. Esto aporta muchísimo al momento de definir una arquitectura para una aplicación crítica. Usted tiene la posibilidad de elegir lo mejor para sus necesidades, y al experimentar rápido, también puede fallar rápido, evitando inconvenientes durante un evento que demande mucho rendimiento de su aplicación.
La creación de plantillas y el uso de la automatización le permiten probar rápidamente diferentes configuraciones en su carga de trabajo y aplicación. Puede poner en marcha recursos, o una copia completa de su entorno de producción, en horas o minutos, probar lo que necesite, obtener los resultados, analizarlos y ver si es un cambio que te gustaría llevar a cabo.
Esto puede ser tan simple como una instancia de tamaño diferente, o un tipo de almacenamiento, hasta probar servicios totalmente diferentes. por ejemplo ejecutar su código en AWS Lambda en lugar de en una instancia en Amazon EC2.

Considere la herramienta correcta para el trabajo correcto

La simpatía mecánica consiste en utilizar la herramienta adecuada para el trabajo adecuado, en lugar de conformarse con lo que todo el mundo ha utilizado antes. Utilice el enfoque tecnológico que mejor se alinee con sus objetivos de negocio y no al revés.
Esto aporta bastante al rendimiento de un sistema, porque muchas veces elegimos mal la herramienta para lo que nuestro negocio necesita, por ejemplo, al analizar los patrones de acceso a los datos podemos seleccionar mejor el motor o el tipo de base de datos que requerimos, no siempre una base de datos relacional será la que ofrezca mejor rendimiento a nuestra aplicación.
Con AWS usted tiene acceso a una variada gama de servicios, con características y funcionalidades para satisfacer una serie de casos de uso diferentes en sus cargas de trabajo y aplicaciones. El uso de la herramienta adecuada para el trabajo dará como resultado una mejora significativa del rendimiento, y a menudo a un costo menor.

Consideraciones de Observabilidad

El término observabilidad tiene su origen en el campo de la teoría de control, donde básicamente significa que se puede inferir el estado interno de los componentes de un sistema mediante el conocimiento de las señales/salidas externas que está produciendo. La diferencia entre la monitorización y la observabilidad es que el monitoreo le dice si un sistema funciona o no, mientras que la observabilidad le dice por qué el sistema no funciona.

Cuando diseñamos una solución crítica, la observabilidad es importante, tanto para las fases de desarrollo y pruebas, como para la fase productiva. En AWS creemos que se debe ofrecer a los desarrolladores y operadores la posibilidad de obtener una visión detallada de cuestiones como los errores, los fallos y los problemas relacionados con los estados internos. Esto es posible mediante la correlación de señales externas como logs, métricas y los rastros de los servicios de su solución, con una potente herramienta de capacidades analíticas y de visualización.
Así mismo, en AWS vamos un poco más allá al intentar identificar posibles problemas de la aplicación mediante algoritmos de machine learning sobre los datos que generan las aplicaciones.

AWS X-Ray le permite recopilar información de su aplicación crítica a través del agente de X-Ray, y puede hacer uso de potentes herramientas como X-Ray Analytics para analizar, filtrar y comparar conjuntos de trazas, para identificar problemas a partir de los datos. Esto permite identificar fácilmente la causa raíz de los problemas, los fallos, las fuentes de latencia, etc.

Las aplicaciones modernas, como las que se ejecutan en arquitecturas de micro servicios, generan grandes volúmenes de datos en forma de métricas, logs y eventos. Amazon CloudWatch le permite recopilar, acceder y correlacionar estos datos en una única plataforma desde todos sus recursos, aplicaciones y servicios de AWS o incluso on-premises, ayudándole a romper los silos de datos para que pueda obtener fácilmente visibilidad de todo el sistema y resolver rápidamente los problemas. Esto es bastante conveniente en un evento crítico, ya que no queremos perder tiempo buscando datos en diferentes herramientas de visualización y monitoreo, y mejor aún, tener que correlacionar manualmente los datos de esas distintas herramientas.
Para optimizar el desempeño y la utilización de recursos, necesita una vista operativa unificada, datos granulares en tiempo real y una referencia histórica. CloudWatch proporciona paneles automáticos, datos con granularidad de 1 segundo y hasta 15 meses de almacenamiento y retención de métricas.

Al usar CloudWatch para sus cargas críticas, tiene la posibilidad de integrarlo de manera nativa con otros servicios de AWS. Un ejemplo de esa integración se da cuando queremos validar el estado de salud de nuestras distribuciones de CloudFront, y de esta forma controlar la eficiencia en la entrega de contenido de nuestra aplicación. Puede revisar el blog sobre el envío de registros estándar de CloudFront a CloudWatch Logs para su análisis, y obtener más detalle.

Pruebas

Cuando usted tiene una carga de trabajo crítica, es clave contar con la suficiente cantidad y calidad de las pruebas en sus sistemas, de tal forma que contemos con la mayor cobertura de casos posibles y anticiparnos así a cualquier eventualidad.
En el caso de arquitecturas simples, con pocas capas o pocos servicios en AWS esto puede ser una tarea muy simple, pero imagine un escenario más complejo con docenas, o incluso cientos de diferentes servicios, dependencias que pueden fallar o comportarse de manera impredecible.
El reto aquí es tratar de hacer que esos servicios se comporten de manera predecible en condiciones impredecibles.

Las pruebas se vuelven una actividad obligatoria, y no siempre se ajustan a las condiciones de complejidad de una carga de trabajo crítica en producción, generalmente se suele probar en un entorno aislado bajo condiciones conocidas, pero ¿qué pasa cuando existen fallas aleatorias o con errores en redes complejas como internet? ¿qué pasa con lo desconocido? y ¿cómo probar algo que no se conoce?

Tomemos como ejemplo la siguiente imagen, con una comunicación muy simple entre un Cliente y un Servidor.

Figura 1. Comunicacin en un sistema distribuido

En este caso hay muchos pasos en un intercambio de mensajes como este, por ejemplo:

El CLIENTE pone el MENSAJE en la RED.
La RED entrega el MENSAJE al SERVIDOR.
El SERVIDOR valida el MENSAJE.
El SERVIDOR actualiza su estado
El SERVIDOR pone la RESPUESTA en la RED.
La RED entrega la RESPUESTA al CLIENTE.
El CLIENTE valida la RESPUESTA.
El CLIENTE actualiza su estado

Imagine la cantidad de errores que pudiera haber en este sencillo sistema distribuido, y esto considerando únicamente un solo mensaje. Ahora piense en una aplicación crítica en donde esperamos miles o millones de peticiones.

Ingeniería del Caos

De acuerdo a la definición de Principles of Chaos: «La ingeniería del caos es la disciplina que consiste en experimentar en un sistema distribuido con el fin de crear confianza en la capacidad del sistema para soportar condiciones turbulentas en producción».

Este es un enfoque de pruebas que debemos aplicar a nuestras aplicaciones críticas, ya que además de ayudarnos a mejorar la resiliencia de nuestras aplicaciones, también lograremos encontrar mejoras en su rendimiento, descubrir errores ocultos, exponer los puntos ciegos de supervisión a través de mecanismos de observabilidad y alarmas, mejorar el tiempo de recuperación, mejorar las habilidades operativas, preparar al personal ante cualquier eventualidad.

La ingeniería del caos nos permite romper sistemas en un ambiente controlado, a través de experimentos planeados con la finalidad de construyamos confianza en nuestra aplicación crítica, así como en las herramientas o servicios que utilizaremos para mantener el control en situaciones turbulentas.
Para lograr eso usted debe seguir un proceso bien definido, basado en el método científico que lo llevará desde la comprensión del estado actual del sistema, hasta la formulación de una hipótesis, realizar un experimento (utilizando mecanismos de inyección de fallos), verificar los resultados, y por último aprender a partir de estos experimentos, con el fin de mejorar el sistema. De aquí se pueden desprender cambios en las aplicaciones para afinar su resistencia a fallos, su rendimiento, el modelo de supervisión del sistema, las alarmas, y en general todo lo que ayude a contener cualquier eventualidad.

Figura 2. Fases de la Ingeniería del Caos

AWS Fault Injection Simulator es nuestro servicio de ingeniería del caos totalmente administrado. Es un servicio fácil de iniciar que le permite reproducir fallos del mundo real, ya sean simples, como detener una instancia, o más complejos, como estrangular las API de su sistema. Fault Injection Simulator adopta plenamente la idea de las salvaguardas, que es una forma de monitorear el radio de explosión del experimento y detenerlo automáticamente si se disparan las alarmas.

Usted puede empezar a usar el servicio muy fácilmente, esto es algo en lo que hemos puesto mucho esfuerzo ya que nuestros clientes nos han dicho repetidamente que era difícil empezar un entorno de pruebas basado en Ingeniería del Caos.
Se pueden ejecutar experimentos en secuencia o en paralelo. Las secuencias se utilizan para probar el impacto de la degradación escalonada, como la secuencia de acciones para aumentar progresivamente la latencia, y los experimentos paralelos son para probar el impacto de múltiples problemas concurrentes, que es a menudo como ocurren las interrupciones del mundo real.

Fault Injection Simulator es el servicio que le permitirá realizar la prueba de fallas de su sistema en AWS, y esto no se trata de una simulación, ya que cuando lo ejecuté, Fault Injection Simulator estará inyectando fallas reales en los servicios, es decir, se terminará una instancia de Amazon EC2, o se usará completamente su memoria, las APIs de sus servicios estarán realmente estrangulándose. No se estará “fingiendo” la manipulación de las métricas, as que deberá tener mucha precaución cuando utilice el servicio.

Pruebas de Intrusión

Desde la perspectiva de seguridad, también debemos tomar en cuenta la ejecución de pruebas que nos permitan disminuir cualquier riesgo de ataque, y tener visibilidad de los posibles huecos de seguridad en todo nuestro sistema.
Una Prueba de Intrusión le permitirá estar preparado ante ataques de seguridad y contar con mecanismos que le permitan atender cualquier riesgo en la vulnerabilidad de sus sistemas en la nube de AWS.

Los clientes de AWS pueden realizar evaluaciones de seguridad o pruebas de intrusión en su infraestructura de AWS sin aprobación previa de 8 servicios:

Instancias de Amazon EC2, NAT Gateways y balanceadores de carga elásticos
Amazon RDS
Amazon CloudFront
Amazon Aurora
Amazon API Gateways
AWS Lambda y funciones de Lambda Edge
Recursos de Amazon Lightsail
Entornos de Amazon Elastic Beanstalk

AWS permite que sus clientes realicen pruebas sobre los servicios antes descritos, siempre y cuando no se realicen las siguientes actividades:

DNS Zone Walking a través de las zonas alojadas de Amazon Route 53
Denegación de servicio (DoS), denegación de servicio distribuida (DDoS), DoS simulada, DDoS simulada (Sujetos a la política de pruebas de simulación DDoS)
Saturación de puertos
Saturación de protocolos
Saturación de solicitudes (de inicio de sesión o de API)

Los clientes que deseen realizar una prueba de estrés de red deben revisar nuestra Política de pruebas de estrés.

Existen diferentes tipos de pruebas de intrusión que usted puede ejecutar sobre su aplicación:

Pruebas de caja negra: En este caso los pentesters no tienen conocimiento del detalle de la infraestructura que se va a probar, así que con ello se logra una simulación más cercana a lo que sería un ataque real.

Pruebas de caja blanca: Aquí el personal que realiza las pruebas tiene conocimiento detallado de la infraestructura y de la aplicación que se va a probar, así que se pueden generar casos de prueba más específicos para “atacar” cualquier vulnerabilidad potencial de acuerdo a la arquitectura utilizada.

Pruebas de caja gris: En este tipo de pruebas se tiene un conocimiento parcial de la arquitectura a evaluar, y por lo mismo, es generada por un equipo de pentesters externos, es decir, que no estuvieron involucrados en el desarrollo del sistema a evaluar.

Al realizar sus prueba de intrusión, usted estará mucho más preparado para atender un evento crítico con su infraestructura, ya que podrá realizar las adecuaciones necesarias para atender cualquier vulnerabilidad detectada durante la fase de pruebas. Es recomendable realizar estas pruebas sobre la versión final de la aplicación que estará saliendo a producción, y sobre todo, es recomendable considerar un tiempo prudente para atender cualquier cambio que se detecte durante las pruebas.

Soporte y Escalación

Ciertamente una aplicación crítica debe estar siempre acompañada por un nivel de soporte adecuado para los servicios de AWS que intervienen en su arquitectura. Sería un riesgo muy alto desplegar en producción una aplicación de esta índole sin el soporte adecuado, o peor aún, sin ningún tipo de soporte por parte de AWS.

AWS Support ofrece una serie de planes que proporcionan acceso a herramientas y conocimientos que contribuyen al éxito y la salud operativa de sus soluciones de AWS. Su infraestructura crítica en la nube debe contar con un nivel de seguridad total y estar lista para cubrir cualquier necesidad de su negocio, la idea es que usted centre la atención en lo que su negocio va a atender en un evento crítico, y que delegue a AWS atender incidencias de su infraestructura. En esas situaciones usted no tiene tiempo para preocuparse por la infraestructura en la nube, y necesita administrar su negocio y encontrar estrategias que le permitan innovar sus eventos y aplicaciones críticas.

Particularmente en una aplicación crítica, es importante evaluar el nivel de soporte más alto para disminuir cualquier problemática durante un evento productivo. AWS Enterprise Support proporciona a los clientes un servicio similar al de un conserje, donde el objetivo fundamental es ayudarlo a lograr sus resultados y alcanzar éxito en la nube.
Con AWS Enterprise Support se busca tener una asociación proactiva con los clientes, en donde su valor proviene de la combinación de herramientas para monitorear y automatizar el estado de su entorno de AWS, con el apoyo de personal como los técnicos administradores de cuentas (TAM). Este equipo puede obtener rápidamente respuestas a cualquier pregunta que usted tenga y mantener su entorno optimizado tanto en términos de costos como de rendimiento, así como la orientación y planificación estratégicas para avalar que su sistema está diseñado de acuerdo con las prácticas recomendadas y funciona al máximo rendimiento para sus eventos empresariales más importantes.
Nuestros clientes nos dicen que parte del gran valor que obtienen de AWS Enterprise Support es la capacidad de centrarse simplemente en su negocio principal sabiendo que AWS Support ayudó a crear un entorno saludable, está supervisando ese entorno de cerca y es capaz de ayudar en un momento dado.

Figura 3. Niveles de soporte de AWS para cada tipo de criticidad

Gestión de Eventos de Infraestructura

De una forma complementaria a los servicios de soporte de AWS, también hay servicios como la Gestión de Eventos de Infraestructura (IEM) incluida en ES, en la que los expertos de AWS trabajan con usted con mucha antelación a los eventos críticos para asegurarse de que su entorno está preparado para manejarlos. El IEM incluye orientación sobre la arquitectura y el escalado, así como apoyo operativo en tiempo real durante el evento.

El equipo de AWS ofrece a sus clientes a través de un IEM los siguientes beneficios cuando se utiliza en un evento crítico:

Una comprensión común de los objetivos y casos de uso del evento a través de la planificación y preparación previa al mismo
Recomendaciones de recursos y orientación de implementación basadas en las necesidades de capacidad previstas
Atención dedicada de su equipo de AWS Support durante su evento
La capacidad de reducir inmediatamente los recursos a los niveles operativos normales después del evento

Cuando usted sepa que requiere desplegar una carga de trabajo crítica en AWS, es importante que busque inmediatamente al equipo de AWS para comenzar un proceso de Gestión de Eventos de Infraestructura, y de esta manera llegar junto con usted, con la preparación suficiente para apoyarlo durante su evento crítico. El tiempo que recomienda AWS para prepararnos es de al menos 6 semanas previas al evento.

Conclusión

Hemos entendido hasta el momento que para desplegar cargas criticas de trabajo sobre AWS necesitamos de una buena arquitectura basada en seguridad, observabilidad, fiabilidad , excelencia operativa , pruebas, rendimiento correcto y soporte, estos principios son los mismos que seguimos los arquitectos de soluciones de Amazon Web Services y cada uno de nuestros socios de negocios para ejecutar cargas criticas de trabajo, por otro lado nuestros clientes comprenden que pueden llevar sus cargas de trabajo criticas a AWS, y también comprenden que sus arquitecturas y cargas de trabajo no son estáticas, estas pueden cambiar en el tiempo bien sea por que hay un cambio de arquitectura empresarial , un cambio a nivel de negocio o por que pueden usar la herramienta correcta para el trabajo correcto y esto haciendo uso de los servicios con los que cuentan en AWS o siguiendo el ritmo de innovación que se tiene día a día, a la final siempre hay una mejora continua. Por otro lado nuestros clientes saben que pueden contar con la experiencia de nuestros Arquitectos de soluciones, servicios profesionales nuestro soporte empresarial y de todo el conocimiento de nuestros socios de negocios quienes junto con sus soluciones enriquecen la oferta para brindar un mejor servicio a nuestros clientes.

Sobre los autores

Eduardo Patiño Balaguera es Arquitecto de Soluciones Senior en Amazon Web Services para Sector Público. Eduardo ha ayudado múltiples empresas de sector público y privado en la adopción tecnológica de nube en los últimos 10 años y ha llevado acabo de manera satisfactoria proyectos que marcan impacto social a nivel de ciudadanos y estudiantes alrededor de América Latina.

Christian Castro es Arquitecto de Soluciones Senior para Gobierno Federal de México en Sector Público. Christian es un profesional de TI y diseñador de soluciones de nube orientadas al cliente, interesado en la innovación y la tecnología para brindar servicios que resuelvan necesidades de negocio de los clientes. Christian es responsable de establecer y mantener arquitecturas de soluciones en AWS para clientes del Gobierno Federal Mexicano, además forma parte de la comunidad técnica de contenedores (TFC) dentro de AWS.

Blog de Amazon Web Services (AWS)