¿Cómo hacer un plan de capacidad?
Hace tiempo que no escribo una entrada y me apetecía mucho escribir sobre algo. Recientemente, hemos tenido que hacer un plan de capacidad y creo que es algo relativamente sencillo pero se suele complicar por falta de entendimiento.
En cada sitio la forma en la que se realiza puede variar, pero vamos a intentar dar una forma de hacer un plan de capacidad sin hacer cosas como “estrangular” producción. Que si se quiere hacer por algún motivo concreto, vale. Pero, no por tener que enfrentarte a un plan de capacidad.
Antes de comenzar, comentar que este es un ejercicio ficticio, cualquier parecido con la realidad es pura casualidad :)
Contexto
Lo primero que tenemos que saber es, que no es necesario hacer un cálculo preciso. Basta con hacer una estimación que nos permita estar entorno al orden de magnitud que hemos obtenido.
También es importante conocer nuestro caso concreto, principalmente si estamos ante un calculo de capacidad para un servidor o una base de datos. En cada caso, buscamos obtener peticiones por segundo (RPS en adelante) para servidores o consultar por segundo (QPS en adelante).
Pero no es lo único a tener en cuenta. Debemos conocer la funcionalidad, las características de nuestro activo, es decir, si es un monolito o no, etc.
Todo esto lo vamos a ver mejor con un ejemplo, pero antes vamos a dar una fórmula.
La fórmula
Lo primero es establecer qué parámetros necesitamos:
1. Usuarios activos diarios (DAU en adelante). También pueden ser estimados a partir de los usuarios mensuales o totales.
2. Promedio de accesos por DAU.
3. Cuando tenemos un pico de carga, cuántas veces éste supera al promedio.
4. Número de peticiones que, para la funcionalidad indicada, nuestro activo debe soportar.
RPS = ((DAU x promedio x pico) / 86.400 segundos/día) * número de peticiones.
Es conveniente trabajar con números redondos y en notación científica para facilitar los cálculos, por ejemplo, 86.400 segundos son, aproximadamente, 100.000 segundos, o 10⁵.
Antes, tenemos que obtener los números. Aquí, hay dos posibilidades:
1. Que estemos ya en producción, en cuyo caso los números no necesitan ser estimados en muchos casos.
2. Que no estemos en producción y necesitemos realizar una estimación.
Ejemplo
Vamos a ver todo esto con un ejemplo. Vamos a suponer que trabajamos en un banco de 5 millones de clientes y, para complicarlo aún más, nuestro activo es un monolito por el que pasan diferentes funcionalidades.
Vamos a realizar los cálculos para 3 funcionalidades distintas que ocurren en nuestro activo, es decir, para cargar la posición global, para las transferencias y, por último, para las operaciones por Bizum.
Por tanto, supongamos que de los 5 millones de clientes tenemos aproximadamente 3 millones de usuarios mensuales. De los cuales, vamos a suponer que el 50% entran a diario, es decir, 1.5 millones de clientes que acceden cada día o DAU.
Cada usuario accede a la posición global 3 veces, el 25% de los DAU realiza una transferencia al día y, finalmente, el 50% de los DAU realizan 3 operaciones con Bizum.
También, cuando tenemos un pico, éste supera en tres veces al promedio. Es decir, x3.
Finalmente, cargar la posición global suponen 5 peticiones a nuestro monolito, las transferencias suponen 3 peticiones y, finalmente, las operaciones con Bizum suponen 3 peticiones también.
Posición global
En este caso, un acceso a nuestro banco siempre va a suponer cargar la posición global. No existe la posibilidad de tener un porcentaje de usuarios como en el resto de ejemplos. Por tanto:
RPS = (1.5 · 10⁶ x 3 x 3 / 10⁵) x 5 = 675
Transferencias
En este caso, tenemos que el 25% de los usuarios realiza una transferencia al día:
RPS = (1.5 · 10⁶ x 0.25 x 3 / 10⁵) x 3 = 35
En este caso, hemos redondeado al alza para obtener los 35. En realidad, son 33 y pico.
Bizum
En este caso, el 50% de los DAU realizan 3 operaciones al día, por tanto, el promedio es 0.5 x 3 = 1.5.
RPS = (1.5 · 10⁶ x 1.5 x 3 / 10⁵) x 3 = 200
Volvemos a redondear para obtener 200 peticiones por segundo.
Resultados
Tenemos, por tanto, 900 RPS aproximadamente. Pero, el ejercicio no ha terminado aquí. Necesitamos conocer cuánta carga aguanta nuestras instancias para saber cuántas necesitamos.
Existen, de nuevo, dos posibilidades. La primera, no estamos en producción y necesitamos realizar una prueba de carga para saber cuánto aguanta nuestro activo. La segunda, estamos en producción y podemos obtener datos a partir de la monitorización y estimar.
Es importante saber que si obtenemos en una prueba de carga, suponiendo que la hacemos con la misma configuración e infraestructura que producción, que no siempre es así, que nuestro activo aguanta 250 RPS, en producción es probable que no soportemos esa carga. En cualquier caso, esto no será un problema por lo que se comentará en las conclusiones finales.
Por ejemplo, si en el horario donde se recibe más carga, tenemos que un activo tiene 150 RPS con el 40% de uso de CPU y con el 30% de uso de memoria. Sabemos que nuestro activo usa más CPU que memoria por la operativa implementada y, además, que el estrangulamiento llegará, probablemente, antes por CPU que por memoria. Por tanto, podemos estimar que nuestro activo soportará unas 300 RPS.
Y con esto, tenemos nuestro plan de capacidad. Ahora, unas consideraciones finales.
Consideraciones finales
Como hemos visto, hemos obtenido que nuestras instancias soportan 300 RPS y que necesitamos soportar unas 900 RPS. Pues bien, lo primero, es que nuestro calculo siempre tendrá más o menos incertidumbre, por lo que es conveniente considerar que necesitaremos 4 instancias, aunque con 3 lleguemos a ese límite de unas 900 RPS aproximadamente.
Además, debemos considerar que un plan de capacidad sólo tiene en cuenta la carga, pero no es lo único que tenemos que tener en cuenta. También, es importante tener en cuenta que necesitaremos alta disponibilidad y, ante un despliegue, se puede hacer rollout dejando siempre una instancia fuera y, en ese caso, deberíamos tener suficiente con el resto para, en el peor de los casos, poder hacer un despliegue con garantías.
También, necesitamos contar con que una de las instancias puede sufrir un problema catastrófico quedando en fuera de juego.
Y, finalmente, mencionar que hay otros aspectos que quedan fuera del plan de capacidad que deben ser tenidos en cuenta. Por ejemplo, una gestión de riesgos debe considerar tener dos zonas, regiones y/o datacenters para contar con una replica de respaldo. En ese caso, el número de instancias será mayor, ya que habrá, al menos, una réplica.
Si alguna vez tenemos que enfrentarnos a un plan de capacidad, ya conocemos una forma de hacerlo. Aunque, seguro que no es la única.
Referencias
Muchas, pero creo que la más interesante, fácil, sencilla y en la que me he basado principalmente es en este vídeo de ByteByteGo, al que recomiendo la subscripción ya que los vídeos son muy interesantes.
