Optimización de Costos en AWS

En la actualidad, uno de los desafíos que enfrentamos al trabajar con sistemas informáticos de gran escala y demanda es el manejo de los costos asociados a la infraestructura, principalmente cuando la demanda de los sistemas fluctúa en el tiempo. En la gestión de infraestructura tradicional se suele intentar predecir la demanda a futuro y adquirir el hardware necesario sobreestimando sus capacidades en busca de poder soportar picos de carga, ya que la adquisición de hardware suele ser un proceso tedioso que requiere meses y no es posible escalar rápidamente para soportar dichos picos. Esto provoca que por largos periodos de tiempo se disponga de hardware innecesario y en casos excepcionales el mismo no soporte la demanda, y no exista forma de remediarlo como se puede ver en la figura 1.

Teniendo en cuenta lo anterior, es esencial evaluar cuatro factores principales: el costo de adquirir la infraestructura, el costo de su mantenimiento, el tiempo donde se desaprovecha la capacidad de cómputo disponible y, por último, los costos asociados con el almacenamiento y el funcionamiento continuo de la infraestructura, que incluyen el consumo de energía, como la alimentación y refrigeración de los equipos y el alquiler de espacios adecuados, entre otros.

Fig. 1 - Comparación de hardware tradicional vs cloud tradicional y desatendido

Una estrategia para evitar enfrentar directamente estos factores de costo y desperdiciar cómputo en momentos de baja demanda es optar por la infraestructura en la nube, una opción popular en la actualidad. Hay diversos proveedores, como AWS, que ofrecen una amplia variedad de servicios, permitiéndonos desentendernos de la adquisición de hardware, su mantenimiento y los costos relacionados. Esto deja como único origen de costos la tarifa del proveedor en la nube, que tiende a fluctuar según la demanda de nuestros sistemas (pay as you use).

La problemática actual radica en seleccionar los servicios en la nube más adecuados para las necesidades de los sistemas, sin perder de vista los costos asociados y sin malgastar dinero en capacidad de cómputo adquirido. Por lo tanto, en este trabajo, evaluaremos una estrategia de migración de sistemas nativos de la nube con una arquitectura clásica a una arquitectura moderna centrada en la reducción de costos.

Contexto

El proyecto tenía dos objetivos principales: reducir los costos asociados a la infraestructura en la nube y, al mismo tiempo, adoptar un conjunto de servicios sin intervención que permitiera que un equipo de DevOps más reducido brindara soporte sin comprometer la alta disponibilidad.

Para lograr estos dos objetivos, planificamos el proyecto en cuatro etapas:

1. Análisis de la Infraestructura/Arquitectura Actual: En esta fase llevamos a cabo el análisis de la infraestructura y la arquitectura existente. Identificamos los componentes clave y sus interdependencias para entender mejor cómo estaban estructurados y cómo podríamos optimizarlos.

2. Selección de Servicios Modernos de AWS para Facilitar el Mantenimiento y Optimizar Costos: En esta etapa nos enfocamos en elegir servicios modernos de AWS que no solo simplifican el mantenimiento, sino que también contribuirían a la optimización de costos. Buscamos soluciones que se alinearan con los requisitos del proyecto y permitieran una gestión eficiente con un equipo más pequeño.

3. Migración del Sistema: La migración fue una fase crítica donde implementamos los cambios planificados. Transferimos datos, configuraciones y funcionalidades a la nueva infraestructura, asegurándonos de minimizar cualquier impacto en la disponibilidad del sistema.

4. Monitoreo de Costos Antes, Durante y Después de la Migración: Con posterioridad a la migración, implementamos un sistema de monitoreo exhaustivo para evaluar los costos en todas las etapas. Este monitoreo incluyó un análisis previo a la migración, durante el proceso y después de completarla. Nos permitió asegurar que los costos se mantuvieran dentro de los límites previstos y ajustar estrategias si era necesario.

Estas cuatro etapas fueron diseñadas para abordar de manera integral los objetivos del proyecto, asegurando una transición fluida hacia una infraestructura más eficiente y rentable.

Análisis de la infraestructura/arquitectura actual

Los sistemas estaban alojados en AWS, adoptando una arquitectura de microservicios basada en contenedores Docker. Estos microservicios estaban desplegados en clusters Swarm en instancias EC2 de AWS, con balanceadores de carga clásicos en el frente (como se ilustra en la Fig. 2).

Fig. 2 - Ejemplificación de arquitectura previa a la migración

Al realizar el análisis identificamos varios aspectos significativos. En primer lugar, confirmamos que la elección de microservicios dockerizados para las necesidades generales del proyecto era apropiada ya que se varios servicios que componen la solución realizan tareas que perduran por largos periodos de tiempo y otros donde no se admiten tiempo de uptime algunos. Sin embargo, señalamos la oportunidad de migrar algunos componentes hacia servicios que no mantuvieran los contenedores activos constantemente, sino que generaran costos únicamente durante su utilización.

Por otro lado, observamos que Docker Swarm no era la solución más eficiente a medida que la complejidad del sistema aumentaba. Con el crecimiento en número y tamaño de los clusters, el mantenimiento requerido aumentaba exponencialmente, lo que planteaba desafíos operativos significativos.

Además, identificamos que la carga del sistema variaba en el tiempo, y la práctica de escalar los servidores de manera preventiva generaba gastos excesivos, como se puede ver en la figura 1. Este diseño mostraba ser lento al escalar los clusters, lo que resultaba en asignaciones de recursos innecesarias durante períodos de inactividad del sistema.

En resumen, el análisis reveló dos problemas principales:

1. Necesidad de Equipos Humanos Voluminosos para el Mantenimiento de la Infraestructura Actual: La complejidad del sistema requería equipos extensos para el mantenimiento, lo que se traducía en costos operativos significativos.

2. Gastos en la Asignación de Recursos Inactivos: La sobre-escala preventiva generaba gastos excesivos, ya que los recursos estaban asignados incluso cuando no se estaban utilizando.

Selección de servicios de AWS modernos que faciliten el mantenimiento y optimicen los costos

Tras realizar el análisis de la infraestructura y arquitectura existente, nuestro objetivo fue identificar servicios de AWS que permitieran mantener una arquitectura de microservicios dockerizados, simplificando el mantenimiento y optimizando los costos.

En la exploración de soluciones en la nube para la implementación de contenedores Docker y la evasión del mantenimiento directo de servidores, consideramos detenidamente dos opciones fundamentales: AWS Lambda y AWS Fargate. Aunque AWS Lambda resultó adecuado para ciertos casos de uso, encontramos limitaciones en su aplicabilidad debido a que no cubre toda nuestra carga de trabajo. Como mencionamos anteriormente, hay servicios que ejecutan procesos de larga duración, excediendo los tiempos máximos de ejecución permitidos por AWS Lambda, teniendo en cuenta esto, y buscando que toda la solución esté unificada en un mismo set de servicios, no se encontró viable su uso. Contrariamente, la elección de AWS Fargate se destacó por su capacidad para alojar microservicios Docker sin la obligación de mantener un uptime constante. Esto nos proporcionó la flexibilidad necesaria para ajustar dinámicamente la asignación de recursos según la demanda específica del servicio. La elección de AWS Fargate se justifica en su capacidad para ofrecer un equilibrio óptimo entre eficiencia operativa y adaptabilidad, proporcionando una solución integral que se alinea con nuestros requisitos particulares.

Además, consideramos orquestadores de Docker para gestionar sistemas complejos con un equipo reducido. Dos alternativas populares fueron analizadas:

EKS (Elastic Kubernetes Service):

Ventajas:

• Estándar de la Industria: EKS sigue el estándar de la industria al basarse en Kubernetes, que es ampliamente adoptado y respaldado por una comunidad robusta. Esto facilita la interoperabilidad y la adopción por parte de equipos que ya están familiarizados con Kubernetes.
• Ecosistema Kubernetes: Al utilizar EKS, se obtiene acceso al rico ecosistema de herramientas y recursos de Kubernetes. Esto incluye características avanzadas como despliegues automáticos, actualizaciones sin tiempo de inactividad y autoscaling, que son fundamentales para entornos de producción dinámicos.

Desventajas:

• Curva de Aprendizaje Pronunciada: EKS, al basarse en Kubernetes, tiende a tener una curva de aprendizaje más empinada en comparación con ECS. La implementación y gestión de clusters Kubernetes pueden resultar complejas, especialmente para equipos menos familiarizados con esta tecnología.
• Mayor Complejidad de Configuración: La configuración inicial de EKS puede ser más compleja, ya que requiere la configuración de nodos, roles de IAM y otros elementos para establecer y mantener el cluster Kubernetes.
• Costos Asociados: EKS tiende a tener costos más altos que ECS debido a la complejidad adicional y a la necesidad de mantener un cluster de Kubernetes. Esto puede ser una consideración importante en proyectos con presupuestos ajustados.
• Tiempo de Implementación: La adopción de EKS generalmente lleva más tiempo en comparación con ECS. La configuración y puesta en marcha del cluster Kubernetes pueden ser procesos más prolongados, lo que puede afectar la agilidad en el despliegue de nuevas aplicaciones o servicios.

ECS (Elastic Container Service):

Ventajas:

• Fácil Aprendizaje: ECS es conocido por tener una curva de aprendizaje más suave en comparación con EKS. Su interfaz y configuración son más intuitivas, lo que facilita la adopción para equipos con menos experiencia en orquestación de contenedores.
• Integración Nativa con AWS: Al ser nativo de AWS, ECS se integra sin problemas con otros servicios de la plataforma, como IAM (Identity and Access Management), CloudWatch y CloudFormation. Esta integración facilita la gestión y monitoreo dentro del ecosistema AWS.
• Soporte de Herramientas AWS: ECS cuenta con un sólido respaldo de herramientas de gestión de infraestructura de AWS, incluyendo Terraform, SDK y CDK, lo que simplifica la automatización y el despliegue de recursos.
• Escalabilidad Sencilla: ECS proporciona herramientas eficientes para escalar servicios, lo que facilita la gestión de la demanda cambiante y permite ajustar la capacidad de manera rápida y efectiva sin tiempo de inactividad.

Desventajas:

• Aunque es un servicio moderno, no es tan conocido en toda la industria.
• Menos Flexible para Escenarios No Estándar: ECS, al ser una solución específica de AWS, puede ser menos flexible en comparación con EKS cuando se trata de escenarios no estándar o requisitos específicos que no se alinean perfectamente con el enfoque de ECS. EKS, basado en Kubernetes, tiene una mayor flexibilidad y es más adaptable a casos de uso no convencionales o que requieren configuraciones altamente personalizadas.

Considerando el contexto específico de nuestro proyecto, optamos por ECS debido a varias razones estratégicas y prácticas. En primer lugar, ECS ofrecía una curva de aprendizaje más suave, lo que resultaba fundamental para nuestros equipos, especialmente aquellos menos familiarizados con las complejidades de Kubernetes. La integración nativa con el ecosistema AWS, junto con el soporte de herramientas como Terraform, SDK y CDK, simplificó significativamente la implementación y el mantenimiento de nuestra arquitectura de microservicios. Además, la naturaleza más simple y específica de ECS se alineaba con la estructura de nuestra carga de trabajo, proporcionando una solución eficiente y directa para nuestros requisitos actuales. Aunque EKS ofrece ventajas notables, ECS se destacó como la opción más pragmática y eficaz para nuestros objetivos inmediatos, asegurando una transición fluida y eficiente hacia un entorno de contenedores optimizado en la nube.

Durante la selección de servicios, nos enfrentamos a desafíos específicos que guiaron nuestras decisiones estratégicas. La necesidad de migrar servicios más antiguos que no cumplían con las buenas prácticas organizativas representó un obstáculo inicial. Para abordar esto, colaboramos estrechamente con los equipos de desarrollo, implementando cambios programados que garantizaron una transición suave y no disruptiva, permitiendo que dichos servicios continuaran operando en la infraestructura existente.

Además, durante este proceso, se hizo evidente la importancia de migrar nuestros repositorios y pipelines a la solución de AWS Developer Tools. La eficiencia en términos de rendimiento y costos se convirtió en un factor clave, y centralizar estos componentes en la plataforma de AWS permitió una gestión más integrada y optimizada.

Esta combinación de desafíos y soluciones tácticas fortaleció la elección de ECS sobre EKS en nuestra estrategia de migración. ECS, alineado con nuestras necesidades actuales y facilitando la transición de servicios heredados, emergió como la opción más coherente y eficiente en nuestro viaje hacia una arquitectura de contenedores en la nube optimizada.

A continuación se puede ver un diagrama ejemplificador de la nueva definición de infraestructura.

Fig. 3 - Nuevo diseño de infraestructura

Migración del sistema

Con el contexto comprendido y el nuevo conjunto de tecnologías y herramientas seleccionadas, se dio inicio a la planificación y ejecución de la migración. Para llevar a cabo este proceso, se optó por una estrategia gradual que comenzó migrando repositorios y pipelines, seguido por la migración e integración de entornos inferiores con los nuevos pipelines. Posteriormente, se procedió a probar y deprecar la infraestructura de esos entornos, avanzando progresivamente hasta llegar al entorno productivo.

Esta estrategia gradual, aunque efectiva, tuvo la desventaja de mantener el sistema duplicado en partes a lo largo de todo el proceso, generando costos adicionales. Esto se materializó en la existencia de un cluster de desarrollo en la infraestructura previa y un nuevo cluster donde el equipo de DevOps trabajaba. Este enfoque conservador se adoptó para evitar afectar a los equipos de desarrollo y, lo más crucial, para preservar la disponibilidad del entorno productivo.

El proceso completo de migración llevó un tiempo considerable, marcado por la creación de cuatro entornos (DEV/QA/PRE/PROD), cada uno compuesto por un número significativo de servicios. Se dedicó atención especial a probar y validar minuciosamente cada entorno antes de proceder a la siguiente fase. Finalmente, el cambio se completó con la reasignación de los DNS hacia el nuevo entorno.

Este enfoque meticuloso y paso a paso aseguró la estabilidad del sistema durante la transición, minimizando las interrupciones y mitigando los riesgos asociados.

Monitoreo de costos, antes, durante y después de la migración

Para garantizar una gestión financiera efectiva y evaluar el impacto económico de la migración, implementamos un exhaustivo proceso de monitoreo de costos en cada etapa del proyecto. Este enfoque proactivo nos permitió obtener una visión completa de los gastos asociados a la infraestructura, brindando insights cruciales que informaron nuestras decisiones estratégicas.

Antes de la Migración: Antes de iniciar la migración realizamos un análisis detallado de los costos existentes. Identificamos patrones de gastos, áreas de optimización y posibles ahorros. Esta fase preparatoria nos proporcionó una línea base crucial para evaluar cualquier cambio en los costos durante y después de la migración.

Durante la Migración: Durante la ejecución del proyecto implementamos un monitoreo en tiempo real de los costos. Seguimos de cerca la evolución de los gastos a medida que se desplegaban nuevos servicios y se realizaban ajustes en la infraestructura. Esta vigilancia continua nos permitió abordar de inmediato cualquier desviación presupuestaria y ajustar estrategias según fuera necesario para garantizar la eficiencia económica.

Después de la Migración: Una vez completada la migración, el monitoreo de costos no finalizó. Continuamos evaluando el rendimiento financiero en el nuevo entorno, comparándolo con la línea base establecida antes de la migración. Analizamos tendencias a largo plazo, identificamos áreas de oportunidad para optimización continua y garantizamos que los costos siguieran alineados con los objetivos empresariales.

Este enfoque integral de monitoreo de costos contribuyó significativamente a la transparencia financiera del proyecto, asegurando que los beneficios esperados en términos de eficiencia y ahorro se materializaron a lo largo del tiempo.

Evolución de costos

Para el seguimiento de costos nos centramos en 7 servicios que representaban un 80% de los costos totales: EC2 Elastic Load Balancing Elastic Container Service (Fargate) CloudWatch Virtual Private Cloud Backup Simple Storage Service

Algo para aclarar es que en la cuenta de AWS donde se realizaron las tareas de migración se encuentran otros sistemas externos al proyecto, los cuales serán ignorados en este análisis de costos.

Tab. 1 - Evolución de costos por servicio

Tab. 2 - Evolución de costos totales por etapa

Análisis de la evolución de costos

Observando los datos presentados en la Tabla 2, es evidente que al concluir la migración los costos totales se redujeron notablemente, en un 39% (aproximadamente 4500U$D al mes), validando así la efectividad de los supuestos y decisiones iniciales adoptadas durante el proyecto. Esto confirma que la optimización de costos y recursos se alineó exitosamente con los objetivos establecidos.

Además, es importante destacar que, aunque nuestra estrategia se mantuvo conservadora, no generó costos adicionales significativos que pudieran impactar negativamente en el proyecto. Se observa una tendencia gradual a la baja en los costos asociados con EC2, mientras que los costos relacionados con Fargate experimentaron un aumento, aunque en una escala considerablemente menor que EC2. Esto resalta la capacidad de Fargate para ajustar las asignaciones de cómputo de manera más eficiente, adaptándose así a la carga de trabajo de manera optimizada.

Si te interesó el proyecto, y necesitás realizar algo similar para tu empresa o institución, contactanos haciendo click acá. El café corre por nuestra cuenta ;).