Blog de Amazon Web Services (AWS)
Ânima Educação y AWS
João Talles Dantas Batista – Ânima Educação
Wesley Rodrigues – AWS
ÂNIMA EDUCAÇÃO
Ânima Educação comenzó sus actividades en 2003, con la adquisición de Una, y hoy, menos de 20 años después, es una de las mayores organizaciones educativas del país. Sus números impresionan: son cerca de 115 mil alumnos, más de 3800 colaboradores y casi 3 mil profesores.
La presencia de Ânima se expandió para los estados de São Paulo, Minas Gerais, Goiás, Santa Catarina, Paraná, Bahía y Sergipe. Son parte del grupo actualmente las instituciones Una, UniSociesc, São Judas, UniBH, AGES, HSM, HSMu, EBRADI, Le Cordon Bleu y SingularityU Brasil.
LOS PROBLEMAS DE ESCALABILIDAD
Conforme el grupo fue creciendo, TI fue incorporando nuevos sistemas, websites y tecnologías. Hacer la integración de todos estos activos fue un desafío enorme.
Un punto en común entre las instituciones que pasarán a formar parte de Ânima fue el uso de la plataforma WordPress como portal de comunicación web. El mayor problema de tener varias instancias de WordPress en ejecución al mismo tiempo, oriundos de diferentes fuentes y preparados de maneras distintas, es que se vuelve muy difícil administrar las versiones de los plugins, del PHP, de los webservers y hasta igual del propio WordPress. Y plugins desactualizados en WordPress son los vectores de ataque más comunes de la plataforma. Fueron 17 fallas en 2018 y 11 en 2019, según el CVE (https://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337), y la gran mayoría puede ser resuelta con simples actualizaciones.
Para proveer el poder computacional, eran utilizados servidores físicos. La escalabilidad dependía directamente de la disponibilidad de nuevos servidores y de personas para hacer el trabajo ─ bastante repetitivo ─ de proveer máquinas y agregar la capacidad a los sites corriendo WordPress.
Las instituciones del grupo tienen una característica de estacionalidad presente en la mayoría de los grupos de educación: la cantidad de acceso supera en muchas veces lo que es esperado para un período normal en épocas de pruebas, entrega de trabajos, exámenes de ingreso a la universidad, etc. En estos momentos, principalmente en el período de captación (en el inicio del año lectivo), había un trabajo manual pesadísimo, e igual así sucedían indisponibilidades en estos sites.
El ideal sería tener una forma de poner disponibles nuevos sitios de WordPress y administrar los sites actuales de un modo estandarizado. Además de eso, los sites necesitarían escalar horizontalmente para aguantar la demanda variable, y ser eficientes en la utilización de recursos, generando costos de acuerdo con el uso.
MIGRANDO PARA AWS
Migrar para AWS trajo mucha facilidad para administrar los sites. Fueron básicamente 3 grandes mejorías:
Bancos de Datos movidos para el RDS
Amazon Relational Database Service (Amazon RDS) facilita la configuración, la operación y la escalabilidad de bancos de datos relacionales en la nube. El servicio ofrece capacidad económica y redimensionamiento y automatiza tareas demoradas de administración, como provisionamiento de hardware, configuración de bancos de datos, aplicación de parches y respaldos. De esa forma, usted se puede concentrar en el desempeño rápido, en la alta disponibilidad, en la seguridad y en la conformidad que las aplicaciones necesitan. Dejamos de preocuparnos con la administración de MySQL y tenemos más tiempo para pensar en mejorías.
Procesamiento en Instancias EC2 con AutoScaling
AWS Auto Scaling monitorea las aplicaciones y ajusta automáticamente la capacidad para mantener un desempeño constante y previsible por el menor costo posible. Con AWS Auto Scaling, es fácil configurar la escalabilidad de aplicativos para varios recursos en diversos servicios en cuestión de minutos. Cuando la demanda cae, AWS Auto Scaling remueve automáticamente toda la capacidad excesiva de recursos, evitando gastos innecesarios. El uso de AWS Auto Scaling es gratuito y permite optimizar los costos de ambientes en AWS. Con él, ahora dejamos que la aplicación escale cuando fuera necesario, y vuelva al tamaño mínimo cuando no hay tráfico.
Separación de los archivos estáticos del site
Normalmente, un website necesita tratar datos de los usuarios haciendo procesamientos en el servidor HTTP con ayuda de un lenguaje dinámico, como PHP, Ruby o Python. Pero existen muchos recursos que no necesitan ser interpretados, como imágenes, CSS y JavaScript. Estos son conocidos como archivos estáticos, y pueden ser accedidos a través de un simple servidor o servicio de HTTP. Administrar servidores HTTP es una tarea difícil y que involucra varios cuidados de seguridad.
AWS ofrece una solución basada en CloudFront y S3 para servir los archivos estáticos de forma económica, segura y con baja latencia. El S3 es un servicio de almacenamiento de objetos que puede ser configurado para servir contenido estático vía HTTPS. El CloudFront convierte los archivos estáticos de su site disponibles a partir de centros de datos alredor del mundo, denominados puntos de presencia. Cuando un visitante solicita un archivo en su site, CloudFront redirecciona automáticamente la solicitud para una copia del archivo en el punto de presencia más próximo. Eso resulta en tiempos de descarga más rápidos se el visitante ha solicitado el contenido en un data center localizado más lejos.
Visión general de la solución
Para cada uno de los sites en WordPress, creamos un AutoScaling Group que cuenta con su propio balanceador de carga. Así, las aplicaciones pueden escalar de forma independiente, pueden tener su soporte delegados para tiempos diferentes y podemos saber exactamente cuanto gastamos con cada site. Estamos usando una instancia de RDS con varias bases de datos creadas, cada una con su propio usuario, con privilegios limitados por las políticas de MySQL. Ya estamos estudiando la separación de este banco en varios bancos separados.
RESULTADOS
Después de migrar para AWS con esta arquitectura, conseguimos mejorar diversos aspectos: Proveer ambientes fácilmente: Actualizaciones o nuevos sites pueden ser provistos em minutos, no más en horas o días. Además de eso, copias pueden ser generadas fácilmente y utilizadas como ambiente de pruebas o desarrollo.
Ambiente más protegido: La infraestructura global de AWS ofrece protección nativa a los end points que responden para CloudFront. Por estándar, CloudFront utiliza HTTPS, protegiendo los datos en tránsito, y posee mitigación automática contra los ataques más comunes de DDoS gratuitamente. Hay soporte para URLs asignadas y otros recursos varios de seguridad.
Escalabilidad y Economía: Con AutoScaling y con los archivos estáticos en S3 con CloudFront, el ambiente se volvió menos volátil y paso a escalar de acuerdo con la demanda. Ânima paso a pagar solo lo que es utilizado, sabiendo vía Cost Explorer exactamente cuanto fue el gasto en cada momento. Eso está permitiendo una gestión mucho más apurada de los costos de cada portal.
PRÓXIMOS PASOS
La migración para a AWS no es un movimiento del tipo todo o nada. Hacer estos cambios ya trajo resultados, más todavía hay mejorías que están en el backlog para los próximos meses.
Aurora Serverless: Migrar para Aurora Serverless va a extender las ventajas de escalabilidad para el nivel de banco de datos, así como y es hecho en el nivel de aplicación. Con Aurora Serverless, es posible crear un endpoint de banco de datos sin especificar el tamaño de la clase de instancia de banco de datos. Usted define las capacidades mínima y máxima. El endpoint del banco de datos se conecta a un grupo de proxy que direcciona la carga de trabajo para un grupo de recursos que son dimensionados automáticamente. Debido al grupo de proxy, las conexiones son continuas. Aurora Serverless escala los recursos automáticamente con base en las especificaciones de las capacidades mínima y máxima. Aplicaciones clientes del banco de datos no necesitan ser alterados para usar el grupo de proxy. Aurora Serverless administra las conexiones automáticamente. La mayor ventaja es que es posible escalar hasta cero procesamiento, y pagar solamente por el almacenamiento. Eso va a permitir que los sites de Ânima puedan ser más económicos, dejando de pagar por instancias de banco de datos cuando no hay demanda. La mayor ventaja en aplicar este cambio es conseguir aislar totalmente las aplicaciones web.
Docker y ECS: Docker es una herramienta muy utilizada para empaquetar una aplicación y sus dependencias en un único contenedor, capaz de ejecutar en diversos ambientes de la misma forma. Amazon Elastic Container Service (Amazon ECS) es un servicio de orquestación de contenedores totalmente administrado. Con ECS usted puede optar por ejecutar sus clusters usando AWS Fargate, que es computación sin servidor para contenedores. Fargate elimina las necesidades de proveer y administrar servidores, permite que usted especifique y pague por los recursos por aplicación, además de aumentar la seguridad al concebir aplicativos aislados. Como ECS ha sido un pilar fundamental para los principales servicios de Amazon, él se puede integrar de forma nativa con servicios de monitoreo, almacenamiento, seguridad, machine learning, entre otros, proporcionando una experiencia familiar para implantar y escalar sus contenedores. Migrando para Docker, lograremos mejorar el proceso de despliegue y disminuir la complejidad (trayendo el concepto de serverless con Fargate).
CONSIDERACIONES FINALES
Notamos que no se trata de un cambio. Es una jornada, y a cada nuevo servicio lanzado, una nueva mejoría puede ser implementada. Estamos evolucionando a nuestro ritmo, y ya conseguimos recoger algunos frutos: tardábamos meses para agregar capacidad, hoy hacemos en minutos, con pocos clics. No tenemos más el trabajo manual pesado para preparar el ambiente. Durante todo el año logramos atender muy bien las demandas, sin indisponibilidad. La experiencia de nuestros alumnos ha sido muy buena, y ese es el mayor indicio que estamos en el rumbo cierto.
REFERENCIAS
- https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf
- https://docs.thinkwithwp.com/AmazonCloudFront/latest/DeveloperGuide/infrastructuresecurity.html
- https://thinkwithwp.com/pt/ecs/
- https://docs.thinkwithwp.com/pt_br/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html
Sobre os Autores
João Talles Dantas Batista es un arquitecto de software senior en Ânima Educação, donde desarrolla aplicaciones escalables y resilientes, trabaja con métodos ágiles como SCRUM, y comparte sus conocimientos en tecnología y educación, obtenidos durante los últimos 10 años. Trabajó como profesor, desarrollador, consultor y traductor, entre otras atribuciones.
Wesley Rodrigues es un arquitecto de soluciones senior en AWS con foco en clientes de organizaciones sin fines lucrativos (NPO). Sea ayudando a mejorar el desempeño de sites orientados a donantes, mejorando prácticas de datos por medio de bancos de datos administrados y análisis, promoviendo investigaciones por medio de machine learning y mejorando el monitoreo remoto con Internet de las Cosas (IoT), su foco es ayudar a convertir al mundo en un lugar mejor para que vivan las personas.