Estudio de caso: Por qué utilizo la infraestructura de la nube de AWS para mis productos

Como plataforma para ejecutar un producto de software complejo y exigente, AWS ofrece flexibilidad al utilizar los recursos cuando sea necesario, a la escala necesaria. Es bajo demanda e instantáneo, lo que permite un control total sobre el entorno de ejecución. Al proponer una solución de arquitectura de nube de este tipo a un cliente, la infraestructura aprovisionada y su precio dependen en gran medida de los requisitos que deben establecerse por adelantado.

Este artículo presentará una de esas arquitecturas de infraestructura en la nube de AWS, propuesta e implementada para LEVELS, una red social con una función de pago facial integrada que encuentra y aplica todos los beneficios que los usuarios pueden obtener por los programas de tarjetas en los que se encuentran, las cosas que poseen o los lugares. viven en.

Requisitos

El cliente tenía dos requisitos principales que la solución propuesta debía cumplir:

1. Seguridad
2. Escalabilidad

El requisito de seguridad consistía en proteger los datos de los usuarios del acceso no autorizado desde el exterior, pero también desde el interior. El requisito de escalabilidad tenía que ver con la capacidad de la infraestructura para respaldar el crecimiento del producto, adaptándose automáticamente al aumento del tráfico y los picos ocasionales, así como la conmutación por error y la recuperación automáticas en caso de fallas de los servidores, minimizando el tiempo de inactividad potencial.

Descripción general de los conceptos de seguridad de AWS

Uno de los principales beneficios de configurar su propia infraestructura en la nube de AWS es el aislamiento total de la red y el control total sobre su nube. Esa es la razón principal por la que elegiría la ruta Infraestructura como servicio (IaaS), en lugar de ejecutar entornos algo más simples de Plataforma como servicio (PaaS), que ofrecen valores predeterminados de seguridad sólidos pero carecen del control completo y detallado que obtiene. configurar su propia nube con AWS.

Aunque LEVELS era un producto joven cuando se acercaron a Toptal para los servicios de consultoría de AWS, estaban dispuestos a comprometerse con AWS y sabían que querían seguridad de última generación con su infraestructura, ya que están muy preocupados por los datos y la privacidad de los usuarios. Además de eso, planean admitir el procesamiento de tarjetas de crédito en el futuro, por lo que sabían que tendrían que garantizar el cumplimiento de PCI-DSS en algún momento.

Nube privada virtual (VPC)

La seguridad en AWS comienza con la creación de su propia Amazon Virtual Private Cloud (VPC), una red virtual dedicada que aloja sus recursos de AWS y está lógicamente aislada de otras redes virtuales en la nube de AWS. La VPC obtiene su propio rango de direcciones IP, subredes totalmente configurables, tablas de enrutamiento, listas de control de acceso a la red y grupos de seguridad (de hecho, un firewall).

Con LEVELS, comenzamos aislando nuestro entorno de producción de los entornos de desarrollo, prueba y control de calidad. La primera idea era ejecutar cada uno de ellos como su propia VPC completamente aislada, cada uno ejecutando todos los servicios según lo requerido por la aplicación. Después de considerarlo un poco, resultó que podíamos compartir algunos recursos entre los tres entornos que no son de producción, lo que redujo el costo hasta cierto punto.

Por lo tanto, nos decidimos por el entorno de producción como una VPC, con los entornos de desarrollo, prueba y control de calidad como otra VPC.

Aislamiento de acceso a nivel de VPC

La configuración de dos VPC aísla el entorno de producción de los tres entornos restantes a nivel de red, lo que garantiza que la configuración incorrecta accidental de la aplicación no pueda cruzar ese límite. Incluso si la configuración del entorno que no es de producción apunta erróneamente a los recursos del entorno de producción, como la base de datos o las colas de mensajes, no hay forma de acceder a ellos.

Dado que los entornos de desarrollo, prueba y control de calidad comparten la misma VPC, es posible el acceso transfronterizo en caso de una configuración incorrecta, pero, dado que esos entornos usan datos de prueba, no existe un problema de seguridad real con la falta de aislamiento allí.

Modelo de seguridad de la tienda de activos

Los activos se almacenan en el almacenamiento de objetos de Amazon Simple Storage Service (S3) . La infraestructura de almacenamiento de S3 es completamente independiente de las VPC y su modelo de seguridad es diferente. El almacenamiento se organiza en cubos S3 separados para cada entorno y/o clases de activos, protegiendo cada cubo con los derechos de acceso apropiados.

Con LEVELS, se identificaron varias clases de activos: cargas de usuarios, contenido producido por LEVELS (videos promocionales y contenido similar), aplicaciones web y activos de interfaz de usuario (código JS, íconos, fuentes), configuración de aplicaciones e infraestructura y paquetes de implementaciones del lado del servidor.

Cada uno de estos obtiene un depósito S3 separado.

Gestión de secretos de aplicaciones

Con AWS, hay un almacén de parámetros de AWS Systems Manager cifrado o AWS Secrets Manager , que son servicios administrados de clave-valor diseñados para mantener seguros los secretos (puede obtener más información en Linux Academy y 1Strategy).

AWS administra las claves de cifrado subyacentes y maneja el cifrado/descifrado. Los propios secretos pueden tener políticas de permisos de lectura y escritura aplicadas en función de los prefijos clave, tanto para la infraestructura como para los usuarios (servidores y desarrolladores, respectivamente).

Acceso SSH del servidor

El acceso SSH a los servidores en un entorno totalmente automatizado e inmutable no debería ser necesario en absoluto. Los registros se pueden extraer y enviar a servicios de registro dedicados, el monitoreo también se descarga a un servicio de monitoreo dedicado. Aún así, puede haber una necesidad de acceso SSH ocasional para la inspección y depuración de la configuración.

Para limitar la superficie de ataque de los servidores, el puerto SSH no queda expuesto a la red pública. Se accede a los servidores a través de un host de bastión, una máquina dedicada que permite el acceso SSH externo, además protegido al incluir en la lista blanca solo el rango de direcciones IP permitidas en el firewall. El acceso se controla mediante la implementación de las claves SSH públicas de los usuarios en las casillas correspondientes (los inicios de sesión con contraseña están deshabilitados). Tal configuración ofrece una puerta bastante resistente para que los atacantes maliciosos la atraviesen.

Acceso a la base de datos

Los mismos principios descritos anteriormente se aplican a los servidores de bases de datos. También puede haber una necesidad ocasional de conectar y manipular los datos directamente en la base de datos, aunque esto definitivamente no es una práctica recomendada, y dicho acceso debe protegerse de la misma manera que se protege el acceso SSH a los servidores.

Se puede usar un enfoque similar, utilizando la misma infraestructura de host bastión con túneles SSH. Se necesita un doble túnel SSH, uno al host bastión y, a través de ese, otro al servidor que tiene acceso a la base de datos (el host bastión no tiene acceso al servidor de la base de datos). A través de ese segundo túnel, ahora está disponible una conexión desde la máquina cliente del usuario al servidor de la base de datos.

Descripción general de los conceptos de escalabilidad de AWS

Cuando hablamos únicamente de servidores, la escalabilidad se logra fácilmente con plataformas más simples que AWS. El principal inconveniente es que es posible que los servicios externos de la plataforma deban cubrir ciertos requisitos, lo que significa que los datos viajan a través de la red pública y rompen los límites de seguridad. Siguiendo con AWS, todos los datos se mantienen privados, mientras que la escalabilidad debe diseñarse para lograr una infraestructura escalable, resistente y tolerante a fallas.

Con AWS, el mejor enfoque para la escalabilidad es aprovechar los servicios administrados de AWS con monitoreo y automatización probados en batalla en miles de clientes que utilizan la plataforma. Agregue copias de seguridad de datos y mecanismos de recuperación a la mezcla, y eliminará muchas preocupaciones simplemente confiando en la plataforma misma.

Tener todo eso descargado permite un equipo de operaciones más pequeño, lo que compensa un poco el costo más alto de los servicios administrados por la plataforma. El equipo de LEVELS estuvo feliz de elegir ese camino siempre que fue posible.

Nube informática elástica de Amazon (EC2)

Confiar en un entorno probado que ejecuta instancias EC2 sigue siendo un enfoque bastante razonable, en comparación con la sobrecarga adicional y la complejidad de ejecutar contenedores o los conceptos arquitectónicos aún muy jóvenes y que cambian rápidamente de la informática sin servidor.

El aprovisionamiento de instancias EC2 debe estar completamente automatizado. La automatización se logra a través de AMI personalizadas para diferentes clases de servidores y Auto Scaling Groups que se encargan de ejecutar flotas de servidores dinámicos al mantener la cantidad adecuada de instancias de servidores en ejecución en la flota de acuerdo con el tráfico actual.

Además, la función de escalado automático permite establecer el límite inferior y superior en la cantidad de instancias EC2 que se ejecutarán. El límite inferior ayuda en la tolerancia a fallas, eliminando potencialmente el tiempo de inactividad en caso de fallas en las instancias. El límite superior mantiene los costos bajo control, lo que permite cierto riesgo de tiempo de inactividad en caso de condiciones extremas inesperadas. El escalado automático luego escala dinámicamente el número de instancias dentro de esos límites.

Servicio de base de datos relacional de Amazon (RDS)

El equipo ya ha estado ejecutando Amazon RDS para MySQL , pero aún no se había desarrollado la estrategia adecuada de copia de seguridad, tolerancia a fallas y seguridad. En la primera iteración, la instancia de la base de datos se actualizó a un clúster de dos instancias en cada VPC, configurado como maestro y réplica de lectura, que admite la conmutación por error automática.

En la siguiente iteración, con la disponibilidad del motor MySQL versión 5.7, la infraestructura se actualizó al servicio Amazon Aurora MySQL . Aunque está completamente administrada, Aurora no es una solución escalable automáticamente. Ofrece escalado de almacenamiento automático, evitando el problema de la planificación de la capacidad. Pero un arquitecto de soluciones aún debe elegir el tamaño de la instancia informática.

El tiempo de inactividad debido a la escala no se puede evitar, pero se puede reducir al mínimo con la ayuda de la capacidad de reparación automática. Gracias a las mejores capacidades de replicación, Aurora ofrece una funcionalidad de conmutación por error sin inconvenientes. El escalado se ejecuta creando una réplica de lectura con la potencia informática deseada y luego ejecutando la conmutación por error a esa instancia. Todas las demás réplicas de lectura también se extraen del clúster, se redimensionan y se vuelven a colocar en el clúster. Requiere algunos malabares manuales, pero es más que factible.

La nueva oferta de Aurora Serverless también permite cierto nivel de escalado automático de los recursos informáticos, una característica que definitivamente vale la pena considerar en el futuro.

Servicios de AWS administrados

Aparte de esos dos componentes, el resto del sistema se beneficia de los mecanismos de escalado automático de los servicios de AWS completamente administrados. Se trata de Elastic Load Balancing (ELB), Amazon Simple Queue Service (SQS), almacenamiento de objetos de Amazon S3, funciones de AWS Lambda y Amazon Simple Notification Service (SNS), donde no se necesita un esfuerzo de escalado particular por parte del arquitecto.

Infraestructura mutable frente a inmutable

Reconocemos dos enfoques para manejar la infraestructura de servidores: una infraestructura mutable donde los servidores se instalan y se actualizan y modifican continuamente en el lugar; y una infraestructura inmutable en la que los servidores nunca se modifican después de aprovisionarse, y cualquier modificación de configuración o actualización del servidor se maneja mediante el aprovisionamiento de nuevos servidores a partir de una imagen común o un script de instalación, reemplazando los antiguos.

Con LEVELS, la opción es ejecutar una infraestructura inmutable sin actualizaciones en el lugar, cambios de configuración o acciones de administración. La única excepción son las implementaciones de aplicaciones, que ocurren en el lugar.

Puede encontrar más información sobre la infraestructura mutable frente a la inmutable en el blog de HashiCorp.

Descripción general de la arquitectura

Técnicamente, LEVELS es una aplicación móvil y una aplicación web con el backend REST API y algunos servicios en segundo plano, una aplicación bastante típica hoy en día. Al respecto, se propuso y configuró la siguiente infraestructura:

Aislamiento de red virtual - Amazon VPC

El diagrama visualiza una estructura de un entorno en su VPC. Otros entornos siguen la misma estructura (que comparten el balanceador de carga de aplicaciones (ALB) y el clúster de Amazon Aurora entre los entornos que no son de producción en su VPC, pero la configuración de red es exactamente la misma).

La VPC está configurada en cuatro zonas de disponibilidad dentro de una región de AWS para la tolerancia a fallas. Las Subredes y Grupos de Seguridad con Listas de Control de Acceso a la Red permiten satisfacer los requisitos de seguridad y control de acceso.

Extender la infraestructura en varias regiones de AWS para una mayor tolerancia a fallas habría sido demasiado complejo e innecesario en una etapa temprana del negocio y su producto, pero es una opción en el futuro.

Informática

LEVELS ejecuta una API REST tradicional con algunos trabajadores en segundo plano para la lógica de la aplicación que ocurre en segundo plano. Ambos se ejecutan como flotas dinámicas de instancias EC2 simples, completamente automatizadas a través de Auto Scaling Groups. El servicio administrado de Amazon SQS se utiliza para la distribución de tareas en segundo plano (trabajos), lo que evita la necesidad de ejecutar, mantener y escalar su propio servidor MQ.

También hay algunas tareas de servicios públicos que no comparten la lógica empresarial con el resto de la aplicación, como el procesamiento de imágenes. Estos tipos de tareas se ejecutan extremadamente bien en AWS Lambda , ya que las Lambdas son indefinidamente escalables horizontalmente y ofrecen un procesamiento paralelo inigualable en comparación con los trabajadores del servidor.

Equilibrio de carga, escalado automático y tolerancia a fallas

El balanceo de carga se puede lograr manualmente a través de Nginx o HAProxy, pero elegir Amazon Elastic Load Balancing (ELB) agrega el beneficio de tener la infraestructura de balanceo de carga intrínsecamente escalable automáticamente, altamente disponible y tolerante a fallas.

Se utiliza el sabor de Balanceador de carga de aplicaciones (ALB) del ELB, haciendo uso del enrutamiento de capa HTTP disponible en el balanceador de carga. Las nuevas instancias agregadas a la flota se registran automáticamente en el ALB a través de los mecanismos de la plataforma de AWS. El ALB también supervisa la disponibilidad de las instancias en todo momento. Tiene el poder de anular el registro y terminar las instancias en mal estado, activando Auto Scaling para reemplazarlas por otras nuevas. A través de esta interacción entre los dos, se logra la reparación automática de la flota EC2.

Almacén de datos de la aplicación

El almacén de datos de la aplicación es un clúster de Amazon Aurora MySQL , que consta de una instancia maestra y varias instancias de réplica de lectura. En el caso de que falle la instancia maestra, una de las réplicas de lectura se promociona automáticamente a una nueva instancia maestra. Configurado como tal, satisface el requisito de tolerancia a fallos solicitado.

Las réplicas de lectura, como su nombre lo indica, también se pueden usar para distribuir la carga del clúster de la base de datos para las operaciones de lectura de datos.

El almacenamiento de la base de datos se escala automáticamente en incrementos de 10 GB con Aurora, y AWS también administra completamente las copias de seguridad, lo que ofrece una restauración en un momento dado de forma predeterminada. Todo eso reduce la carga de administración de la base de datos a prácticamente nada, excepto por la ampliación de la potencia informática de la base de datos cuando surge la necesidad: un servicio por el que vale la pena pagar para ejecutarlo sin preocupaciones.

Almacenamiento y servicio de activos

LEVELS acepta el contenido subido por los usuarios que necesita ser almacenado. El almacenamiento de objetos de Amazon S3 es, como era de esperar, el servicio que se encargará de esa tarea. También hay activos de la aplicación (elementos de la interfaz de usuario: imágenes, íconos, fuentes) que deben estar disponibles para la aplicación del cliente, para que también se almacenen en el S3. Ofreciendo copias de seguridad automatizadas de los datos cargados a través de su replicación de almacenamiento interno, S3 proporciona durabilidad de datos de forma predeterminada.

Las imágenes que suben los usuarios son de varios tamaños y pesos, a menudo innecesariamente grandes para servir directamente y con sobrepeso, lo que supone una carga para las conexiones móviles. Producir varias variaciones en diferentes tamaños permitirá ofrecer contenido más optimizado para cada caso de uso. AWS Lambda se aprovecha para esa tarea, así como para hacer una copia de las imágenes originales cargadas en un depósito de respaldo separado, por si acaso.

Por último, una aplicación web que se ejecuta en un navegador también es un conjunto de activos estáticos: la infraestructura de compilación de integración continua compila el código JavaScript y también almacena cada compilación en el S3.

Una vez que todos estos activos se almacenan de forma segura en S3, se pueden servir directamente, ya que S3 proporciona una interfaz HTTP pública, o a través de Amazon CloudFront CDN. CloudFront hace que los activos estén distribuidos geográficamente, lo que reduce la latencia para los usuarios finales y también habilita la compatibilidad con HTTPS para servir activos estáticos.

Aprovisionamiento y Gestión de Infraestructura

El aprovisionamiento de la infraestructura de AWS es una combinación de redes, los recursos y servicios administrados de AWS y los recursos informáticos básicos de EC2. Los servicios administrados de AWS están, bueno, administrados. No hay mucho que hacer con ellos, excepto el aprovisionamiento y la aplicación de la seguridad adecuada, mientras que con los recursos informáticos de EC2, debemos encargarnos de la configuración y la automatización por nuestra cuenta.

Estampación

La consola de AWS basada en la web hace que la administración de la infraestructura de AWS "similar a los ladrillos de Lego" sea todo menos trivial y, como cualquier trabajo manual, bastante propenso a errores. Es por eso que es muy deseable utilizar una herramienta dedicada para automatizar ese trabajo.

Una de esas herramientas es AWS CloudFormation , desarrollada y mantenida por AWS. Otro es Terraform de HashiCorp, una opción un poco más flexible que ofrece múltiples proveedores de plataformas, pero interesante aquí principalmente debido a la filosofía de enfoque de infraestructura inmutable de Terraform. Alineado con la forma en que se ejecuta la infraestructura LEVELS, Terraform, junto con Packer para proporcionar las imágenes AMI base, resultó ser una excelente opción.

Documentación de Infraestructura

Un beneficio adicional con una herramienta de automatización es que no requiere documentación detallada de la infraestructura, que tarde o temprano queda obsoleta. El paradigma de "Infraestructura como código" (IaC) de la herramienta de aprovisionamiento se dobla como documentación, con la ventaja de estar siempre actualizado con la infraestructura real. Tener una visión general de alto nivel, menos probable que se modifique y relativamente fácil de mantener con los cambios eventuales, documentado al costado es suficiente.

Pensamientos finales

La infraestructura de la nube de AWS propuesta es una solución escalable capaz de adaptarse al crecimiento futuro del producto en su mayoría de forma automática. Después de casi dos años, logra mantener bajos los costos de operación, apoyándose en la automatización de la nube sin tener un equipo de operaciones de sistemas dedicado las 24 horas del día, los 7 días de la semana.

Con respecto a la seguridad, AWS Cloud guarda todos los datos y todos los recursos dentro de una red privada dentro de la misma nube. Nunca se requieren datos confidenciales para viajar a través de la red pública. El acceso externo se otorga con permisos granulares finos a los sistemas de soporte confiables (CI/CD, monitoreo externo o alertas), limitando el alcance del acceso solo a los recursos necesarios para su función en todo el sistema.

Con la arquitectura y la configuración correctas, dicho sistema es flexible, resistente, seguro y está listo para responder a todos los requisitos futuros relacionados con la escalabilidad para el crecimiento del producto o la implementación de seguridad avanzada como el cumplimiento de PCI-DSS.

No es necesariamente más barato que las ofertas de productos como Heroku o plataformas similares, que funcionan bien siempre que se ajuste a los patrones de uso comunes cubiertos por sus ofertas. Al elegir AWS, obtiene más control sobre su infraestructura, un nivel adicional de flexibilidad con la gama de servicios de AWS ofrecidos y una configuración personalizada con la capacidad de ajuste fino de toda la infraestructura.

Lecturas adicionales en el blog de ingeniería de Toptal:

• Haga su tarea: 7 consejos para el examen de arquitecto de soluciones certificado por AWS
• Terraform vs. CloudFormation: la guía definitiva
• Registro de SSH y administración de sesiones mediante AWS SSM
• Trabajar con compatibilidad con TypeScript y Jest: un tutorial de AWS SAM