El objetivo de las pruebas de carga debería ser identificar qué carga puede soportar su clúster actual y cómo necesita mutar y adaptar la configuración de su clúster a medida que alcanza diversos hitos de carga. El resultado debería ser un plan sobre cómo adaptar su clúster para gestionar el crecimiento y la carga de usuarios antes de que necesite esta información. Esto le permite el lujo de planificar con antelación, manteniendo sus aplicaciones y bases de datos funcionando con los SLA deseados, sin caídas en el servicio a medida que su carga crece más allá de la capacidad de su configuración actual.
Comprenda que no es una información que nadie le vaya a proporcionar sin realizar un número significativo de pruebas. Hay muchas variables a tener en cuenta, como los patrones de acceso, las estructuras de datos, el código de la aplicación, la red, el hardware, etc. Esto se aplica no sólo en un centro de datos autoalojado, sino también en entornos alojados en la nube. No hay nada mejor que realizar estas pruebas de carga preventivas para su caso de uso específico.
Nota: Si alojas tu clúster de Couchbase en un entorno en la nube (AWS, Azure, Google Cloud, etc.), agilizarás el proceso de creación de varias configuraciones de clúster de Couchbase aprovechando Couchbase Kubernetes Autonomous Operator. Esta herramienta te permite realizar cambios en la configuración del clúster en el archivo yaml de Kubernetes, y luego los cambios en el clúster se despliegan automáticamente. Elimina una gran cantidad de trabajo administrativo del sistema instalando y configurando Couchbase en nodos, añadiendo y eliminando nodos de un clúster, realizando reequilibrios, etc.
Especifique sus ANS
Antes de realizar cualquier prueba de rendimiento, debe tener articulados sus ANS (Acuerdos de Nivel de Servicio). "Lo más rápido posible" no es un SLA. Es necesario especificar el SLA para que el rendimiento de las pruebas se convierta en una situación de aprobado o suspenso. O bien el clúster tiene un rendimiento igual o superior a lo que se ha determinado que necesita, o bien no lo tiene. Si no ha determinado cuál es ese tiempo de respuesta, nunca será capaz de determinar a qué carga el rendimiento ha entrado en el rango inaceptable y necesita ser escalado para volver a rendir al nivel que necesita.
¿Cómo determinar cuál debe ser su SLA? Empiece por el proceso más complejo que deba completarse en un plazo limitado. A menudo se tratará de una interacción con el usuario que no quiere que espere más de X segundos para completarse. Ocasionalmente será un proceso de microservicio que necesita ser lo más en tiempo real posible. En resumen, tiene que ser algún proceso que tenga un punto de inicio y final definido, y una ventana de tiempo específica en la que debe completarse.
Una vez que tenga su proceso, tendrá que identificar el número de interacciones con la base de datos que se realizan durante este proceso, junto con la naturaleza de cada una de estas interacciones. Una vez identificadas, tendrás que eliminar las interacciones con la base de datos para obtener unos tiempos base del proceso. Aquí es donde entran en juego los objetos simulados. Utilice objetos simulados para sustituir las interacciones con la base de datos, devolviendo inmediatamente un conjunto realista de resultados de interacción con la base de datos sin la interacción real con la base de datos. Al poner su proceso bajo carga sin las interacciones con la base de datos, puede determinar cuánto tiempo el proceso interactivo sin base de datos elimina del tiempo total permitido para el proceso completo. El tiempo restante es la ventana dentro de la cual deben realizarse todas las interacciones con la base de datos.
Nota: Una vez que sepa cuánto tiempo hay disponible para las interacciones con la base de datos, debe dar un paso atrás y determinar si su lógica de negocio está dejando tiempo suficiente para las interacciones con la base de datos. Si la lógica de negocio está empleando todo el tiempo permitido para cumplir los SLA, es posible que sus SLA no sean realistas y deban revisarse. Si su lógica de negocio no deja tiempo suficiente para las interacciones con la base de datos, debe aumentar sus SLA, racionalizar su lógica de negocio o reducir el número de interacciones con la base de datos que deben realizarse.
Una vez que se tiene el número de interacciones con la base de datos y el tiempo en el que deben realizarse, es cuestión de hacer algunos cálculos para determinar el tiempo en el que cada interacción con la base de datos debe devolver resultados. A partir de aquí, hay que determinar la combinación de interacciones con la base de datos. ¿Son todas accesos K/V? ¿Son todas consultas N1QL? ¿Una mezcla de ambas? En cuanto a sus consultas N1QL, ¿son todas consultas simples, o hay algunas consultas complejas mezcladas? Es a partir de la mezcla de interacciones que puede crear una mezcla escalada de SLA de base de datos, donde sus accesos K/V tienen un SLA, sus consultas simples N1QL tienen otro, y sus consultas complejas tienen un tercero. Tenga en cuenta que estos serán los SLA objetivos medios para sus interacciones con la base de datos. No todas las interacciones cumplirán un SLA específico, pero la media debería cumplirlo o superarlo.
Una vez definidos los acuerdos de nivel de servicio, hay que determinar el nivel de degradación del rendimiento aceptable. A medida que aumenta la carga en el clúster, llega un punto en el que el rendimiento de la aplicación y de la base de datos empieza a degradarse. Es necesario determinar cuánto de esta degradación es aceptable. Este número te proporciona la línea en la arena más allá de la cual no puedes permitir que tu rendimiento se degrade más. Este será el punto de ruptura en la carga que tu cluster puede manejar. Esto se utilizará como un mojón de carga para determinar cuándo su clúster necesita ser reconfigurado para manejar más carga para evitar una mayor degradación. Recuerde que el objetivo de estas pruebas es producir una hoja de ruta para la configuración de su clúster, para que sepa cuánta carga puede manejar cada configuración de clúster, y determinar los hitos que señalarán que es hora de reconfigurar su clúster para manejar aumentos en la carga.
Encontrar el punto de ruptura de la configuración actual
Ahora que tienes tu SLA objetivo para el proceso completo, y tienes un tiempo medio de rendimiento conocido para las interacciones no relacionadas con la base de datos, y has calculado cuáles deberían ser tus interacciones con la base de datos, necesitas determinar si tu configuración actual del cluster de Couchbase puede cumplir estos SLAs.
En primer lugar, bajo una herramienta genérica de generación de carga como pillowfight o n1qlback, ¿cumple tu cluster los SLAs de tiempo de respuesta necesarios, o necesitas aumentar tus SLAs para proporcionar una ventana de procesamiento mayor? Asumiendo que tus SLAs son teóricamente alcanzables, la siguiente pregunta es si tu aplicación actual y la configuración del cluster de Couchbase pueden cumplir tus SLAs. Una vez que hayas verificado que los SLAs deseados son alcanzables por tu proceso de negocio full-stack, tanto la aplicación como el cluster de base de datos, ahora es el momento de aumentar la carga para ver cómo escala todo.
Una vez que haya confirmado que sus SLA son alcanzables con su configuración actual, podría aumentar inmediatamente la carga a su carga objetivo de usuario/proceso y ver cómo se comporta, pero eso podría no ser una buena idea. Si aumentas la carga de forma significativa y de repente descubres que ya no cumples tus SLA, no habrás obtenido ninguna información útil. Puede que sepa que su clúster necesitará escalar antes de que se alcance ese nivel de carga, pero no sabe cuándo debe escalar. En resumen, aún no dispone de información procesable.
Lo que quieres hacer es añadir carga gradualmente mientras observas el tiempo de respuesta para determinar cuándo el rendimiento de la configuración actual se degrada más allá de los SLA deseados, tomando nota de cuándo se cruza este umbral. También querrá seguir aumentando la carga hasta que el rendimiento se degrade hasta el punto en que se cruce el segundo SLA degradado. Esto también necesita ser anotado para que tenga los dos mojones de carga, marcando cuándo necesita escalar su cluster, y qué carga necesita haber completado su escalado de cluster antes de alcanzar.
Pruebas con múltiples configuraciones de crecimiento
Una vez que hayas identificado la carga que degrada el rendimiento de tu cluster hasta un grado inaceptable, la siguiente pregunta que tienes que responder es qué servicio de Couchbase no puede manejar la carga. ¿Es el acceso K/V el que está sufriendo? ¿Consultas N1QL? ¿Tiene el servicio de índices una gran cola de actualizaciones pendientes que no parece aguantar? ¿Alguno de los nodos muestra una carga de CPU cercana a 100%? Estas son algunas pistas a tener en cuenta para determinar cómo escalar tu cluster de Couchbase.
Una vez que hayas añadido uno o dos nodos al servicio concreto que hayas determinado que es el que sufre la carga, repite el proceso de escalado de carga hasta que vuelvas a encontrar la carga que degrada el rendimiento. ¿Ha cambiado algo al añadir el nodo? Si no es así, es posible que haya identificado el servicio equivocado para escalar. Si marcó la diferencia, y su clúster puede soportar una carga mayor, entonces tiene un par de hitos más para escalar.
Una vez más, repite el mismo análisis que antes para determinar qué servicio escalar esta vez. Tal vez sea el mismo que antes, tal vez sea un servicio diferente. La clave es asegurarse de que cada vez que añada nodos a su clúster para gestionar un aumento de la carga, esté seguro de que los está añadiendo al servicio que necesita ser escalado.
Nota: Si el servicio que se está escalando es el servicio de índices, recuerde que añadir un nodo y ejecutar un reequilibrio no realiza todos los cambios de configuración necesarios. Para mover índices de un nodo a otro durante un reequilibrio, el nodo en el que se encuentran los índices antes del reequilibrio debe marcarse para su eliminación. De lo contrario, los índices no se moverán. Si solo desea añadir uno o dos nodos más a un clúster en ejecución mediante Kubernetes, es posible que tenga que mover manualmente índices individuales de los nodos existentes al nuevo nodo para distribuir la carga.
Operaciones de prueba bajo carga
Saber qué carga degrada el rendimiento de su configuración de clúster no es información suficiente para planificar el inicio del escalado. También necesitas saber cuándo es mejor cambiar la configuración de tu cluster. Escalar tu cluster Couchbase no es sólo cuestión de añadir un nodo y encenderlo. El cluster requerirá que se ejecute un rebalanceo antes de que el nuevo nodo comience a tomar cualquier carga como parte del cluster. ¿Cómo afectará el reequilibrio a sus SLA? ¿Qué carga puede seguir ejecutando simultáneamente con un reequilibrio y seguir cumpliendo sus SLA?
La única forma de responder a estas preguntas es adoptar el mismo enfoque, comenzando con una carga muy ligera y aumentando gradualmente la carga simultáneamente con un reequilibrio de adición de nodos en ejecución. Una vez que haya identificado una carga aceptable mientras ejecuta un reequilibrio, puede observar sus patrones de uso para identificar un día y una hora en los que es preferible ejecutar cualquier reequilibrio que cambie la configuración.
Identificar múltiples configuraciones de objetivos de crecimiento
Una vez que disponga de las distintas métricas de capacidad de carga, tanto con procesos operativos como sin ellos, podrá elaborar su plan para anticiparse y adaptarse al crecimiento. Su plan debe incluir activadores de hitos para identificar cuándo escalar su clúster, cómo escalarlo y cuándo programar el escalado.
El plan de crecimiento resultante debería especificar alguna métrica que actuará como disparador para cada evento de escalado, y qué debería hacerse como parte del escalado (por ejemplo, añadir 1 nodo K/V, 2 nodos de consulta). Cuando se alcancen estos desencadenantes en su entorno de producción, programe los cambios apropiados en su clúster, implementándolos en la primera ventana apropiada (momento de baja carga). Si la carga de su clúster es estacional, estas subidas y bajadas de escala pueden y deben planificarse con mucha antelación.
Si los cambios en la carga no son estacionales, sino el resultado de un crecimiento orgánico, su mapa de hitos debería incluir marcadores adicionales alrededor de la marca 80% del siguiente hito de cambio de cluster. Estos marcadores 80% deben considerarse hitos de "prepárate", alertando a tu equipo de que la carga de tu cluster está creciendo y que necesitas planificar el escalado de tu cluster pronto, haciendo los preparativos necesarios.
