O objetivo do teste de carga deve ser identificar a carga que o seu cluster atual pode suportar e como você precisa alterar e adaptar a configuração do cluster à medida que atinge vários marcos de carga. O resultado deve ser um plano de como adaptar o cluster para lidar com o crescimento e a carga dos usuários antes que você precise dessas informações. Isso permite que você se dê ao luxo de planejar com antecedência, mantendo o desempenho dos seus aplicativos e bancos de dados com os SLAs desejados, sem quedas no serviço à medida que a carga cresce além da capacidade da sua configuração atual.
Entenda que essa não é uma informação que alguém vai lhe fornecer sem realizar um número significativo de testes. Há muitas variáveis a serem consideradas, como padrões de acesso, estruturas de dados, código de aplicativo, rede, hardware etc. Isso se aplica não apenas em um data center auto-hospedado, mas também em ambientes hospedados na nuvem. Não há substituto para a realização desse teste de carga preventivo para seu caso de uso específico.
Observação: Se estiver hospedando seu cluster do Couchbase em um ambiente de nuvem (AWS, Azure, Google Cloud, etc.), você simplificará o processo de criação de várias configurações de cluster do Couchbase aproveitando o Couchbase Kubernetes Autonomous Operator. Essa ferramenta permite que você faça alterações na configuração do cluster no arquivo yaml do Kubernetes e, em seguida, as alterações no cluster são implantadas automaticamente. Isso elimina uma grande quantidade de trabalho administrativo do sistema, instalando e configurando o Couchbase em nós, adicionando e removendo nós de um cluster, realizando rebalanceamentos e assim por diante.
Especifique seus SLAs
Antes de executar qualquer teste de desempenho, você precisa ter seus SLAs (Service Level Agreement) articulados. "O mais rápido possível" não é um SLA. Você precisa ter um SLA especificado para que o desempenho do teste se torne uma situação de aprovação ou reprovação. Ou o seu cluster está tendo um desempenho igual ou superior ao que você determinou que ele precisa ter, ou não está. Se você não tiver determinado qual é esse tempo de resposta, nunca conseguirá determinar em que carga o desempenho entrou na faixa inaceitável e precisa ser dimensionado para voltar a ter o desempenho no nível necessário.
Então, como você determina qual deve ser o seu SLA? Comece com seu processo mais complexo que precisa ser concluído em um período limitado. Geralmente, trata-se de uma interação com o usuário que não deve esperar mais de X segundos para ser concluída. Ocasionalmente, será um processo de microsserviço que precisa ser o mais em tempo real possível. Em resumo, deve ser um processo que tenha um ponto inicial e final definido e uma janela de tempo específica na qual ele precisa ser concluído.
Depois de ter seu processo, você precisa identificar o número de interações com o banco de dados que são realizadas durante esse processo, juntamente com a natureza de cada uma dessas interações. Uma vez identificadas, você precisará remover as interações com o banco de dados para obter alguns tempos de processo de linha de base. É nesse ponto que os objetos de simulação precisam entrar em ação. Use objetos simulados para substituir as interações com o banco de dados, retornando imediatamente um conjunto realista de resultados de interação com o banco de dados sem a interação real com o banco de dados. Ao colocar o processo sob carga sem as interações com o banco de dados, você pode determinar quanto tempo o processo interativo sem banco de dados remove do tempo total permitido para o processo completo. O tempo restante é a janela na qual todas as interações com o banco de dados precisam ser executadas.
Observação: Depois de saber quanto tempo está disponível para as interações com o banco de dados, é preciso dar um passo atrás e determinar se a lógica comercial está permitindo tempo suficiente para as interações com o banco de dados. Se a lógica de negócios estiver consumindo todo o tempo permitido para atender aos SLAs, então seus SLAs podem não ser realistas e precisam ser revisados. Se a sua lógica de negócios não permitir tempo suficiente para as interações com o banco de dados, será necessário aumentar os SLAs, simplificar a lógica de negócios ou reduzir o número de interações com o banco de dados a serem realizadas.
Uma vez que você tenha o número de interações com o banco de dados e o tempo em que elas precisam ser realizadas, é simples fazer alguns cálculos para determinar o tempo em que cada interação com o banco de dados deve retornar resultados. A partir daí, você deve determinar qual é a combinação das interações com o banco de dados. Todas elas são de acesso K/V? São todas consultas N1QL? Uma combinação de ambos? Quanto às suas consultas N1QL, são todas simples ou há algumas consultas complexas misturadas? É a partir da análise da combinação de interações que você pode criar uma combinação escalonada de SLA de banco de dados, em que seus acessos K/V têm um SLA, suas consultas N1QL simples têm outro e suas consultas complexas têm um terceiro. Entenda que esses serão os SLAs de destino médio para suas interações com o banco de dados. Nem toda interação atenderá a um SLA específico, mas a média deve atender ou exceder a média.
Depois de definir os SLAs de destino, você precisa determinar o nível de degradação de desempenho aceitável. À medida que a carga aumenta em seu cluster, há um ponto em que o desempenho do aplicativo e do banco de dados começa a se degradar. Você precisa determinar o quanto dessa degradação é aceitável. Esse número fornece a linha na areia além da qual você não pode permitir que o desempenho se degrade ainda mais. Esse será o ponto de ruptura da carga que seu cluster pode suportar. Ele será usado como um ponto de referência de carga para determinar quando o cluster precisará ser reconfigurado para lidar com mais carga a fim de evitar mais degradação. Lembre-se de que o objetivo desse teste é produzir um roteiro para a configuração do cluster, de modo que você saiba quanta carga cada configuração de cluster pode suportar e determinar os marcadores de milha que sinalizarão que é hora de reconfigurar o cluster para lidar com aumentos de carga.
Localize onde a configuração atual é interrompida
Agora que você tem seu SLA de meta para o processo completo, tem um tempo médio de desempenho conhecido para a interação não relacionada ao banco de dados e calculou quais devem ser as interações com o banco de dados, é necessário determinar se a configuração atual do cluster do Couchbase pode atender a esses SLAs.
Em primeiro lugar, com uma ferramenta genérica de geração de carga, como pillowfight ou n1qlback, seu cluster atende aos SLAs de tempo de resposta necessários ou você precisa aumentar seus SLAs para fornecer uma janela de processamento maior? Supondo que seus SLAs sejam teoricamente alcançáveis, a próxima pergunta é se seu aplicativo atual e a configuração do cluster do Couchbase podem atender aos SLAs. Depois de verificar se os SLAs desejados podem ser atingidos pelo seu processo de negócios de pilha completa, pelo aplicativo e pelo cluster de banco de dados, agora é hora de aumentar a carga para ver como tudo é dimensionado.
Depois de confirmar que os SLAs podem ser alcançados com a configuração atual, você pode aumentar imediatamente a carga para a carga de usuário/processo desejada e ver o desempenho, mas isso pode não ser uma boa ideia. Se você aumentar significativamente a carga de repente e descobrir que não está mais cumprindo os SLAs, não terá obtido nenhuma informação útil. Talvez você saiba que seu cluster precisará ser dimensionado antes que esse nível de carga seja atingido, mas não sabe quando deverá ser dimensionado. Em resumo, você ainda não tem informações acionáveis.
O que você deseja fazer é aumentar gradualmente a carga enquanto observa o tempo de resposta para determinar quando o desempenho da configuração atual se degrada além dos SLAs desejados, anotando quando esse limite é ultrapassado. Você também deseja continuar aumentando a carga até que o desempenho se degrade até o ponto em que os segundos SLAs degradados sejam ultrapassados. Isso também precisa ser anotado para que você tenha os dois pontos de referência de carga, marcando quando você precisa escalonar o cluster e qual carga você precisa ter concluído o escalonamento do cluster antes de alcançá-la.
Teste com várias configurações de crescimento
Depois de identificar a carga que degrada o desempenho do seu cluster em um grau inaceitável, a próxima pergunta que você precisa responder é qual serviço do Couchbase não consegue lidar com a carga. É o acesso K/V que está sofrendo? Consultas N1QL? O serviço de índice tem uma grande fila de atualizações pendentes que parece não estar conseguindo acompanhar? Algum dos nós está mostrando uma carga de CPU próxima a 100%? Essas são algumas pistas a serem observadas para determinar como dimensionar seu cluster do Couchbase.
Depois de adicionar um ou dois nós ao serviço específico que você determinou ser o que está sofrendo com a carga, repita o processo de aumento de carga até encontrar novamente a carga que degrada o desempenho. A adição do nó fez alguma diferença? Se não, então você pode ter identificado o serviço errado para escalonar. Se fez diferença, e seu cluster pode lidar com uma carga maior, então você tem mais alguns marcadores de ponto de milha para dimensionamento.
Novamente, você repete a mesma análise de antes para determinar qual serviço deve ser dimensionado desta vez. Talvez seja o mesmo de antes, talvez seja um serviço diferente. O segredo é garantir que, toda vez que você adicionar nós ao cluster para lidar com uma carga maior, tenha certeza de que os está adicionando ao serviço que precisa ser dimensionado.
Observação: Se o serviço que está sendo dimensionado for o serviço de índice, lembre-se de que adicionar um nó e executar um rebalanceamento não faz todas as alterações de configuração necessárias. Para mover os índices de um nó para outro durante um rebalanceamento, o nó em que os índices estão antes do rebalanceamento precisa ser marcado para exclusão. Caso contrário, os índices não serão movidos. Se você quiser apenas adicionar mais um ou dois nós a um cluster em execução usando o Kubernetes, talvez seja necessário mover manualmente os índices individuais dos nós existentes para o novo nó para distribuir a carga.
Operações de teste sob carga
Saber qual carga degrada o desempenho da sua configuração de cluster não é informação suficiente para planejar o início do dimensionamento. Você também precisa saber qual é o melhor momento para alterar a configuração do cluster. O dimensionamento do cluster do Couchbase não é apenas uma questão de adicionar um nó e ligá-lo. O cluster exigirá que um rebalanceamento seja executado antes que o novo nó comece a receber qualquer carga como parte do cluster. Como o rebalanceamento afetará seus SLAs? Que carga você pode continuar a executar simultaneamente com um rebalanceamento e continuar a cumprir seus SLAs?
A única maneira de responder a essas perguntas é adotar a mesma abordagem, começando com uma carga muito leve e aumentando gradualmente a carga simultaneamente à execução de um rebalanceamento de adição de nós. Depois de identificar uma carga aceitável para a execução de um rebalanceamento, você pode analisar seus padrões de uso para identificar um dia e uma hora em que seja preferível executar qualquer rebalanceamento que altere a configuração.
Identificar várias configurações de metas de crescimento
Depois de obter as várias métricas de capacidade de carga, com e sem processos operacionais, você poderá criar um plano para antecipar e adaptar-se ao crescimento. Seu plano deve incluir gatilhos para identificar quando escalonar o cluster, como escaloná-lo e quando programar o escalonamento.
O plano de crescimento resultante deve especificar alguma métrica que atuará como um acionador para cada evento de aumento de escala e o que deve ser feito como parte do aumento de escala (por exemplo, adicionar 1 nó K/V, 2 nós de consulta). Quando esses acionadores de milepost forem atingidos em seu ambiente de produção, programe as alterações apropriadas em seu cluster, implementando-as na janela apropriada mais próxima (tempo de baixa carga). Se a carga do cluster for sazonal, esses aumentos e reduções de escala podem e devem ser planejados com bastante antecedência.
Se as mudanças na carga não forem sazonais, mas resultarem de crescimento orgânico, seu mapa de postos de controle deve incluir marcadores adicionais em torno da marca 80% do próximo posto de controle de mudança de cluster. Esses marcadores 80% devem ser considerados como marcos de milha "prepare-se", alertando a sua equipe de que a carga no seu cluster está crescendo e que você precisa planejar o dimensionamento do cluster em breve, tomando as providências preparatórias necessárias.
