Dentro de las tareas que desempeñamos en STR, está la optimización de costes de las plataformas de nuestros clientes. Hoy te vamos a mostrar un ejemplo de uno de nuestros clientes utilizando datos ficticios por la privacidad del mismo.

La empresa actualmente tiene una plataforma dimensionada para afrontar su mayor pico conocido de actividad. Esto, entre otras cosas, le genera unos costes muy elevados, ya que, en la mayor parte del tiempo la actividad en la plataforma es bastante baja en comparación con los picos de tráfico que debe gestionar.

Nos centramos en las instancias que contienen la parte frontend de la aplicación,  ya que es donde se localiza la mayor parte del coste donde tienen desplegadas 20 instancias de tipo m5.2xlarge en la región de Irlanda. Teniendo en cuenta que el coste de las instancias en esta región es de 0,428 $/hora y suponiendo que un mes tiene 30 días, el coste de las instancias es de 6163,20$.

Después de analizar junto con el cliente el comportamiento y requisitos de su aplicativo y revisar la actividad de la plataforma, llegamos al siguiente planteamiento en los tramos de actividad que la aplicación debía gestionar:

• Tramos con diferentes tráficos de forma recurrente entre semana:
  • Primer tramo de actividad de 9:00 a 11:00.
  • Segundo tramo de actividad de 11:00 a 18:00.
  • Tercer tramo de actividad de 18:00 a 21:00.
  • Cuarto tramo de 21:00 a 9:00.
• Los fines de semana la actividad es similar al cuarto tramo que sucede entre semana.

Teniendo en cuenta la información, planteamos a la empresa empezar a utilizar el servicio de Autoscaling para la parte frontend de su aplicación. De esta forma le permitirá reducir considerablemente los costes, ya que solo tendrá desplegadas las instancias que necesite en cada momento. En este caso concreto nos vamos a centrar en los Autoscaling de tipo EC2.

En este caso de ejemplo, damos por sentado que se conoce el funcionamiento y las configuraciones para poner en marcha un grupo de autoscaling con EC2 y nos vamos a centrar en la planificación y configuraciones enfocadas a la reducción/aumento de instancias de forma planificada o de forma dinámica.

Por tanto, con toda la información recopilada, el planteamiento es el siguiente:

• La plataforma para funcionar en los momentos de menor tráfico necesita de 5 instancias. Estos momentos son los fines de semana y el tramo de 21:00 a 9:00.
• En el tramo de 9:00 a 11:00 son necesarias 20 instancias para el correcto funcionamiento del aplicativo.
• En el tramo de 11:00 a 18:00 son necesarias 13 instancias.
• En el tramo de 18:00 a 21:00 son necesarias 9 instancias.

Si suponemos que un mes tiene 30 días de los cuales 22 son laborables y 8 corresponden a fines de semana, el planteamiento queda de la siguiente forma:

Teniendo en cuenta que inicialmente estaba pagando 6163,20$ y ha pasado a pagar 2463,57$, hemos conseguido un ahorro del 60% aproximadamente. A las programaciones anteriormente indicadas, se puede añadir políticas de autoscaling dinámicas basadas en métricas para ajustar las cargas con un grano más fino en base al uso real de la plataforma.

Este es un punto de partida enfocado a un supuesto caso de donde se puede ir trabajando en mejorar y reducir los costes utilizando diferentes servicios de los que dispone AWS, o incluso haciendo uso de Saving Plans, instancias reservadas o en algunos casos instancias de tipo spot.

Si necesitas que gestionemos tu plataforma y analicemos las posibilidades de reducir los costes de los mismos, escríbenos.