Well-Architected: transformando una arquitectura tradicional, a una optimizada para cómputo en la nube

Por Javier Huerta, Well-Architected Solutions Architect de AWS

Introducción

Como hemos visto en artículos anteriores, el Well-Architected Framework, o el Marco de Mejores Prácticas, nos ayuda a crear diseños arquitectónicos operacionalmente excelentes, seguros, confiables, eficientes en desempeño y optimizados en costos a través del uso de prácticas prescriptivas, consistentes y confiables, las cuales pueden usarse para implementar diseños escalables a través de su ciclo de vida.

Nuestro Well-Architected Framework consiste en un documento principal, lentes para dominios específicos, laboratorios, y la herramienta AWS Well-Architected Tool, la cual provee un mecanismo para evaluar regularmente nuestras cargas de trabajo, identificar problemas de alto impacto, y llevar un registro de las mejoras realizadas.

Sin embargo, puede resultar complejo el entender las mejoras que aplican sobre una carga de trabajo al momento de llevarla a la nube.

En este artículo, veremos un ejemplo práctico, en el cual tomaremos una carga hipotética migrada directamente de un Centro de Datos, y paso a paso la convertiremos en Well-Architected.

Gestión y Gobernanza en AWS

En ambientes on-premises, o en Centros de Datos, las organizaciones tenían que elegir entre mantener el control sobre su infraestructura y servicios de manera integral, o el innovar de manera más rápida. Esto, porque no existía la forma de tener visibilidad completa al interior de los componentes (tanto de servicios como de equipamiento), al no contar con interfaces de programación para aplicaciones (APIs).

Con los servicios de AWS, es posible habilitar, aprovisionar, administrar y dar de baja arquitecturas y ambientes completos, de trabajo, de manera prácticamente inmediata, lo cual permite tener un alto grado de control e innovación.

Este control, y agilidad se ofrece a través de los servicios de AWS de Management and Governance (Administración y Gobernanza), y proveen los siguientes beneficios:

Escala: Los servicios de AWS permiten la administración de recursos de cómputo dinámico, para lograr arquitecturas y aplicaciones a escala masiva.
Simplicidad: al ofrecer una interfaz única de administración para servicios, infraestructura, monitoreo, alertas e infraestructura como código, AWS reduce la complejidad en la administración de las cargas de trabajo
Optimización de Costos: los clientes pueden entender la utilización de sus recursos, e identificar formas de reducir costos.

El uso de los servicios de Administración y Gobernanza está sujeto a nuestro Marco de Mejores Prácticas, o Well-Architected Framework, de forma tal que en todo momento conoceremos la forma correcta de implementar los mismos.

Y es así como, a través de estas Mejores Prácticas, podemos mostrar la manera en la cual en Amazon Web Services somos capaces de transformar sus cargas de trabajo, aprovechando los beneficios del Cómputo en la Nube. Sin embargo, es necesario enfatizar que la arquitectura mostrada a continuación no está diseñada para ser implementada en ambientes productivos, sino para ejemplificar algunas de las aplicaciones y beneficios de las Mejores Prácticas y del Cómputo en la nube, de manera enunciativa, más no limitativa.

La arquitectura original

Para efectos de este ejercicio, usaremos una arquitectura simple en dos capas, la cual podemos considerar que fue una migración tipo lift and shift desde un Centro de Datos tradicional. En este diseño, tenemos un Servidor Web, una base de datos relacional (MySQL), y un Gateway hacia Internet. Podemos ver, de manera inmediata, que esta arquitectura, aunque funcional, no cumple con requisitos básicos de escalabilidad, desempeño, seguridad, o visibilidad.

Primero, comenzaremos por añadir componentes básicos, los cuales nos permitan controlar la arquitectura – a través de la visibilidad de la actividad de nuestra infraestructura.

Añadiendo visibilidad

Usaremos los siguientes servicios para observar, y por lo tanto, ser capaces de monitorear nuestra arquitectura.

Para comenzar, añadiremos identificadores (tags) a nuestros servicios. A través de éstos, podemos agrupar la infraestructura con la que contamos en grupos lógicos, con los cuales la identificaremos como una carga de trabajo única.

Posteriormente, utilizando los identificadores, usaremos AWS Systems Manager para instalar agentes en nuestros equipos. AWS Systems Manager nos permite entender el estado operacional de nuestros recursos, y tomar acciones en consecuencia – para este ejemplo, instalaremos el agente de monitoreo de Amazon CloudWatch Logs.

Amazon CloudWatch Logs nos permite tomar los archivos de registro (logs) de nuestras aplicaciones (como, en nuestro ejemplo, el Servidor Web y la Base de Datos) para enviarlas a nuestro servicio de monitoreo Amazon CloudWatch, mediante el cual podemos ver, en tableros de control, el estado operativo de nustra arquitectura.

De la misma manera, Amazon CloudWatch nos permite ver los archivos de registro de nuestras instancias Amazon EC2, las cuales ejecutan el software de los servidores antes mencionados.

El uso de tableros nos permite tener una mejor visibilidad, como hemos visto. Sin embargo, es bastante práctico ser alertado cuando excedemos algún límite operacional (como por ejemplo, el espacio disponible en disco duro). Para resolver este problema, podemos configurar Amazon CloudWatch Alarms, los cuales nos alertarán cuando sobrepasemos cualquier umbral operacional que definamos.

Por último, utilizaremos AWS CloudTrail, un servicio de trazabilidad, el cual nos informará cuando se hayan realizado cambios en nuestra infraestructura.

Implementando Alta Disponibilidad

La visibilidad nos permitirá entender el uso, y comportamiento, de nuestra infraestructura ante distintos tipos de cargas. Sin embargo, seguimos operando en una sola zona de disponibilidad. Dependiendo de nuestros requerimientos, es posible que esta configuración sea suficiente para funcionar adecuadamente; para aquellos casos en los que se requiera un nivel mayor de disponibilidad, podemos realizar estas actividades.

Para comenzar, usaremos múltiples zonas de disponibilidad, y configuraremos subredes (tanto públicas como privadas) en ellas. Esto, recordemos, implica la ejecución de nuestras instancias en distintas localidades dentro de una Región de AWS, diseñadas para estar aisladas en caso de fallos de otras Zonas de Disponibilidad, con conectividad a baja latencia en otras Zonas de Disponibilidad dentro de la misma región.

Nuestras instancias Web necesitarán ser balanceadas para poder operar en estas zonas, por lo que utilizaremos Balanceadores Elásticos de Carga (Elastic Load Balancers) en subredes públicas dentro de nuestras múltiples zonas de disponibilidad. Esto, además de permitirnos crecer horizontalmente nuestras instancias, nos permitirá incrementar nuestra seguridad, al ejecutar los servidores Web en subredes privadas.

Añadiendo Servicios Administrados

El añadir Servicios Administrados de AWS incrementa la confiabilidad, y facilita el uso de nuestros servicios, pues AWS realiza las labores cotidianas de administración de los servicios, permitiéndonos enfocarnos en la operación de nuestras aplicaciones. Para este ejemplo, utilizaremos 3 servicios: AWS Backup, Amazon Elastic File System y Amazon RDS (Relational Database Service).

AWS Backup le permite centralizar y automatizar sus procesos de protección de datos a través de múltiples servicios de AWS. AWS Backup ofrece un servicio efectivo, completamente administrado, y basado en políticas de uso, el cual simplifica la protección de datos a escala.

En un inicio, utilizamos volúmenes de datos dentro de nuestros servidores Web. Para lograr incluso mayor confiabilidad, usaremos Amazon Elastic File System (EFS), el cual es un servicio que provee un servicio de almacenamiento de datos elástico, que nos permite compartir datos sin aprovisionar, o administrar nuestro almacenamiento. Puede ser usado con servicios de AWS de nube on en ambientes on-premises, y puede crecer y compactarse de manera automática.

Hemos dejado relativamente intacta nuestra base de datos. Es posible mejorar su desempeño, facilitar su administración, e implementar un ambiente de alta disponibilidad usando Amazon RDS (Relational Database Service). Amazon RDS nos ap¡yuda a administrar una base de datos en la nube; provee capacidad redimensionable, y el ajtomatizar tareas como aprovisionamiento de hardware, configuración de la base de datos, parcheo y respaldos. En este ejemplo, añadimos una base de datos de réplica (Amazon RDS Standby), para contar con una base de datos altamente disponible.

Mejorando nuestra postura de seguridad

La seguridad es nuestra mayor prioridad. Nuestra carga on-premises será habilitada con múltiples componentes, para mejorar su postura, y afrontar las amenazas más comunes.

En primera instancia, bloquearemos el tráfico indeseado hacia nuestra Nube Privada Virtual (Virtual Private Cloud) utilizando Listas de Control de Acceso (Network Access Control Lists). Procederemos a bloquear puertos indeseados con Grupos de Seguridad (Security Groups), que son Firewalls tipo Stateful, los cuales protegen nuestra arquitectura al nivel de interfaz de red. Por último, bloquearemos los accesos a nivel Sistema Operativo utilizando los Firewalls propios de éstos. Cada nivel de bloqueo nos permitirá tener protección a distintos niveles de acceso, por lo que es altamente recomendable habilitarlos.

Ahora, nos aseguraremos de evitar que existan modificaciones a la línea base de nuestra configuración. AWS Config es un servicio que nos permite evaluar las configuraciones de nuestros recursos, monitoreándolos continuamente. Podemos revisar cambios en las configuraciones, y determinar nuestro nivel de cumplimiento comparándolo contra nuestra gobernanza corporativa.

Un servicio de detección de intrusiones altamente recomendado es Amazon GuardDuty. Amazon GuardDuty monitorea continuamente actividad maliciosa y prohibida, para proteger nuetras cuentas, cargas y datos. Este servicio utiliza servicios de Aprendizaje Automatizado (Machine Learning), detección de anomalías, y detección integrada de amenazas, permitiéndonos identificar y priorizar amenazas potenciales.

Finalmente, aprovechando el uso de nuestro Elastic Load Balancer, habilitaremos AWS Web Application Firewall y AWS Shield. AWS WAF es un Firewall que protege nuestras aplicaciones web o nuestras APIs contra ataques comunes vía web, y bots que pueden afectar nuesta disponibilidad, seguridad, o consumir recursos excesivos. AWS Shield es un servicio de protección contra ataques de negación de servicio distribuidos (DDoS) que protege aplicaciones al interior de AWS, en modo de protección continuo, con mitigaciones automáticas.

Arquitecturas escalables y replicables

Un diferenciador fundamental del cómputo en la nube es la escalabilidad (capacidad de adaptarse a una mayor demanda conforme pasa el tiempo) y la elasticidad (capacidad de adaptarse rápidamente a cambios repentinos en la demanda). Para poder cumplir con este requerimiento, utilizaremos Auto Scaling Groups en nuestros equipos Amazon EC2. Nuestros grupos de autoescalado permiten el crecimiento de nuestra infraestructura de manera proactiva o reactiva, y también facilita el uso de pruebas de salud en nuestras instancias, escalando y recuperando instancias dañadas fácilmente.

El siguiente componente a añadir será la automatización de nuestro despliegue, lo cual nos traerá múltiples beneficios:

Generar ambientes de prueba, y evaluar nuestras estrategias de recuperación de desastres.
Generar ambientes de aseguramiento de la calidad, o cualquier otra etapa de despliegue.
Multiplicar nuestros ambientes de producción en múltiples Regiones de AWS, y operar a nivel global.

Todo esto de manera automatizada, y sin intervención humana que pudiera cometer errores, e invariablemente, usar más tiempo.

AWS CloudFormation nos proporciona una forma sencilla de crear recursos. Basado en Infrastructure as a Code, o Infraestructura como Código, nos permite generar plantillas (de texto) con indicaciones para crear los servicios y recursos que necesitamos, en conjunto con sus dependencias, y lanzarlos como un stack (pila de componentes).

AWS OpsWorks nos provee con instancias administradas de Chef y Puppet, con lo que podemos automatizar la configuración de componentes a través de instancias de Amazon EC2, o de nuestros componentes en ambiente on-premises.

Es posible utilizar AWS CloudFormation, AWS OpsWorks, o una combinación de ambas tecnologías al momento de desplegar nuestra infraestructura.

Ahora tenemos una arquitectura administrada, resiliente, segura, escalable, y altamente disponible. Si comparamos con nuestro diseño inicial:

Podemos afirmar que nuestro último diseño contesta afirmativamente la pregunta “¿Tu arquitectura es la correcta para desplegarse en la nube?”

Conclusión

El hecho de que un ambiente tipo Cloud tenga múltiples beneficios para el despliegue de arquitecturas conlleva también un cuestionamiento básico: ¿De qué manera podemos hacer uso de los servicios de valor agregado que proporciona AWS, para poder obtener el máximo beneficio de las nuevas funcionalidades?

En este sentido, es necesario recordar que en Amazon Web Services, nuestra principal preocupación es el objetivo final de nuestros clientes. A través de nuestro Working Backwards (o “trabajo a la inversa”) primero determinamos su objetivo de negocio, y partimos de esa premisa para construir la mejor arquitectura posible. Esto es un acercamiento que evita el uso de tecnología por el simple hecho de su existencia, y se concentra íntegramente en satisfacer, de manera frugal, optimizada y segura, los requerimientos principales de nuestros clientes.

El ejemplo que presentamos es un ejemplo de cómo nuestros servicios de Management and Governance (Administración y Gobernanza) pueden apoyar sus objetivos de negocio, a través de funcionalidad disponible actualmente en nuestra Nube.

Esperamos que este artículo haya sido de su interés, y que, como siempre, siga construyendo con AWS.

Recursos:

Sobre el autor

Javier Huerta es Arquitecto de Soluciones Sr. especializado en Mejores Prácticas (Well-Architected) para Latinoamérica. Ha sido Arquitecto de Soluciones, Service Delivery Manager, Gerente de Cumplimiento Normativo, y Director de Innovación Tecnológica a lo largo de 25 años de carrera profesional. Es también miembro de la Comunidad Técnica de Campo (TFC) de Media y Entretenimiento. Actualmente, se encuentra construyendo el que (ha prometido) será su último par de bocinas.

Sobre los revisores

Roberto García es Arquitecto de Soluciones Sr. para Partners, especializado en ISVs

Hans Hahn es Arquitecto de Soluciones Sr. para Partners, especializado en SAP.

Omner Barajas es Arquitecto de Soluciones y Especialista en Seguridad en AWS México.

Blog de Amazon Web Services (AWS)