Aproximación súper básica sobre cómo conseguir la máxima eficiencia de los costes en la nube gracias a la agilidad de los entornos cloud.

Tus primeros días trabajando con entornos cloud pueden ser algo confusos porque no estás acostumbrado a su diferente paradigma, y algunas de tus primeras preguntas pueden tener respuestas sencillas. Buscando consejos, muchas empresas nos preguntan cómo ser rentables cuando comienzan en la nube.

Aunque este post puede resultar algo básico, pensamos que puede ayudar a aquellos que tengan algunas dudas tempranas, así como a ayudar a algunas empresas a ahorrar algo de dinero cuando comienzan en la nube. En “los básicos de la eficiencia de los costes en la nube” conocerás cómo economizar tus costes en la nube en los entornos de testing y preproducción sobre Amazon Web Services utilizando comandos simples de AWS CLI.

Normalmente, la mayor parte de los costes sobre la infraestructura recaen en la capacidad computacional de los servidores. En AWS, cuando hablamos de capacidad de computación hablamos de instancias EC2, donde el coste depende únicamente de las horas reales que utilizas cada instancia. Además, una instancia más grande en términos de capacidad computacional es más cara, lógicamente. Es bastante común utilizar servidores de testing y preproducción sólo durante horas laborales, ya que no tiene ningún sentido tener esta clase de entornos funcionando durante las 24 horas del día. Por esta razón es interesante, en cuanto a la eficiencia de los costes en la nube, aprovecharse de lo sencillo que es iniciar y parar instancias en la nube de AWS. Por ejemplo, puedes detener todas las instancias durante la noche y reiniciarlas por la mañana. Hay dos aproximaciones diferentes:

Eficiencia de los costes en la nube: instancias de largo recorrido

Para instancias de largo recorrido, podemos utilizar un simple script en bash cuya ejecución puede programarse en un cronjob. Este cron usaría comandos AWS CLI para detener instancias específicas. Imagina que todas tus instancias dentro de una cuenta AWS están etiquetadas con el tag “Environment”, con valores distintos dependiendo del entorno del que dependen: producción, preproducción y testing. El script simplemente comprobará qué IDs de las instancias tienen un tag específico (“Environment = Preproduction” por ejemplo), y una vez que tenga sus IDs, utilizaremos la API de AWS para mandar una señal de stop a estas instancias EC2. El script podría parecerse a lo siguiente:

instances_ids=$(aws ec2 describe-instances --filter Name=tag:Environment,Values=preproduction --query 'Reservations[*].Instances[*].InstanceId' --output text)
aws ec2 stop-instances --instance-ids $instances_ids

En el comando previo estamos filtrando por etiqueta de entorno, y una vez que tengamos toda la información de las distintas instancias, usaremos JMESPath para obtener únicamente el ID de instancia. Una vez que lo tengamos, enviaremos un comando stop-instance a todas estas instancias.

Para comenzarlas, tenemos otro script que ejecuta el comando start-instances:

instances_ids=$(aws ec2 describe-instances --filter Name=tag:Environment,Values=preproduction --query 'Reservations[*].Instances[*].InstanceId' --output text)
aws ec2 start-instances --instance-ids $instances_ids

Eficiencia de los costes en la nube: grupos de Autoscaling

Para las instancias que se encuentran dentro de un ASG (AutoScaling Group), la aproximación será diferente debido al hecho de que, si apagas una instancia dentro de un ASG, el ASG la reemplazará con una nueva.

La configuración de ASGs tiene tres valores distintos que corresponden al número de instancias que se encuentran dentro de un ASG:

Imagínate que tienes un grupo autoscaling con 4 instancias (mínimo=4, deseado=4, máximo=8). En este caso, en vez de detener instancias, lo que podrías hacer es reducir el número de instancias a cero (mínimo y deseado = 0) por la noche, y restablecer los valores normales por la mañana (aumentando el mínimo y deseado = 4).

Para poder ejecutar estas acciones, vamos a utilizar de nuevo algunos comandos AWS CLI disponibles. En este caso utilizaremos lo que se conoce como “ASG scheduled actions”. Estas acciones programadas están basadas en expresiones cron universales, en las que tenemos que utilizar el huso horario UTC. Crearemos dos acciones programadas, la primera ejecutada por la tarde:

aws autoscaling put-scheduled-update-group-action --scheduled-action-name 'scale-down-night' --auto-scaling-group-name ASG-NAME --region eu-west-1 --recurrence '0 18 * * *' --min-size 0 --desired-capacity 0

El comando anterior, ejecutado únicamente una vez, creará una acción programada denominada “scale-down-night” que AWS ejecutará recurrentemente cada día a las 18:00 UTC (observa que la regla se dispara a las 19:00 en España porque se encontraba en UTC +1 en aquel momento), y disminuirá el número de instancias del ASG a 0.  Y este próximos se ejecutaría por la mañana:

aws autoscaling put-scheduled-update-group-action --scheduled-action-name 'scale-up-morning' --auto-scaling-group-name ASG-NAME --region eu-west-1 --recurrence '0 7 * * *' --min-size 4 --desired-capacity 4

Ten en cuenta que una vez que has aumentado el número de instancias que se encuentran dentro del ASG, las políticas de autoscaling decidirán de nuevo el número real de instancias necesarias (valor deseado) dependiendo de la carga del ASG (utilización de la CPU, por ejemplo). Las políticas de escalado basadas en alarmas de CloudWatch definen cómo los ASG escalan hacia fuera o hacia adentro.

Conclusión

Éstos son comandos AWS CLI muy simples para iniciar/parar instancias de forma sencilla, para ahorrar costes en los entornos test/dev en AWS, y por supuesto normalmente existen más elementos de los que preocuparse en un entorno completo de preproducción. En CAPSiDE ofrecemos a nuestros clientes nuestras potentes herramientas propias para poder automatizar el inicio/detención de los distintos entornos (incluyendo instancias de largo recorrido, grupos autoscaling, RDSs…).

De todas formas, puedes crear potentes scripts con una lógica e inteligencia más complejas utilizando tu lenguaje de programación favorito. AWS ofrece distintos SDKs para prácticamente todos los lenguajes de programación: Python, Ruby, Java, PHP, .Net, Go, C++, Node.js… Por cierto, si tu lenguaje favorito es Perl, ten en cuenta el CTO de CAPSiDE, José Luis Martínez (aka Pplu) ha creado el SDK de Perl para AWS (denominado PAWS). Puedes encontrar más información en el CPAN y el código propiamente dicho en Github – SDK de Perl.

TAGS: amazon web services, AutoScaling Group, aws, AWS CLI, bash, Cloud Cost Efficiency, Cloud Efficiency, JMESpath, test/dev environments

speech-bubble-13-icon Created with Sketch.
Comentarios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*