Planejamento de capacidade para bancos de dados

Observação: este post é inspirado no post recente de Julia Evans sobre planejamento de capacidade.

RDBMS

Primeiro, vamos estabelecer algumas regras básicas. Sim... este post é voltado para aqueles de nós que usam MySQL com um único gravador de cada vez e 2 ou mais réplicas de leitura. Muito do que falarei aqui se aplica de maneira diferente, ou não, a armazenamentos de dados em cluster de vários gravadores, embora eles também venham com seu próprio conjunto de compromissos e ressalvas. Então... sua milhagem definitivamente vai variar.

No entanto, esta postagem do blog será aplicada independentemente de você usar hosts físicos auto-hospedados ou estar na AWS, onde você pode usar instâncias reservadas mágicas e provisionamento quase instantâneo. Estar na “nuvem” não o impedirá de conhecer as capacidades e os limites de sua infraestrutura e não o isentará dessa responsabilidade para com sua equipe e clientes.

Fragmentação

Eu já abordei grandes traços disso em um dos meus posts anteriores, concentrei-me principalmente nos benefícios do sharding funcional ou horizontal. Sim, isso é um pré-requisito absoluto, pois o que você usa para acessar a camada de banco de dados DECIDIRÁ quanta flexibilidade você terá para dimensionar.

Se você é uma empresa nova, pode não precisar de fragmentação funcional no primeiro dia, mas, se espera (e suspeito que sim) crescer, não se encaixote com um ORM de código aberto que não permitirá a divisão seus dados em uma base funcional. Pontos de bônus se você também não iniciar sua empresa com todos os seus dados relacionais em um único esquema.

Capacidade de dividir leituras e gravações

Isso é algo que você precisará ser capaz de fazer, mas não necessariamente impor como uma regra fixa. Haverá casos de uso em que uma gravação precisa ser lida logo depois e em que a tolerância para coisas como lag/consistência eventual é baixa. Tudo bem, mas nos mesmos aplicativos, você também terá cenários para leituras que podem tolerar um intervalo de tempo mais longo de consistência eventual. Quando essas leituras estão em alto volume, você realmente quer que esse volume vá para o seu único escritor se não for realmente necessário? Faça um favor a si mesmo e certifique-se de que em breve em seus dias de crescimento você possa controlar o uso de um IP de leitura ou gravação em seu código.

Agora, para o processo de pensamento do planejamento de capacidade real... Um cluster de banco de dados não está acompanhando, o que eu faço?

Determine o gargalo do sistema

• Você está com gargalo em gravações ou leituras?
• O problema está sendo exibido como CPU alta?
• Está exibindo como capacidade de IO?
• Está crescendo o atraso nas réplicas sem um culpado claro da consulta de leitura?
• É fechaduras?
• Como eu mesmo sei qual é?

Cada um deles pode ser um post por si só. O ponto que estou tentando mostrar é que você precisa estar familiarizado com o sistema e as métricas específicas do banco de dados para poder descobrir qual peça é o gargalo.

Você precisa de uma linha de base

Certifique-se sempre de ter as métricas básicas do sistema disponíveis para visualização por pelo menos algumas semanas atrás. Muitas ferramentas fornecem isso (Cacti, Munin, Graphite…etc). Depois de saber a qual métrica do sistema você está mais vinculado, você precisa estabelecer valores de linha de base e de pico. Caso contrário, determinar se o seu problema atual é um novo bug originado do aplicativo versus um crescimento real será muito mais propenso a erros do que você gostaria.

No entanto, as métricas básicas do servidor só podem ir tão longe – em algum momento você descobrirá que também precisa de métricas baseadas em contexto. O desempenho da consulta e o desempenho percebido do lado do aplicativo informarão o que o aplicativo vê como um tempo de resposta às consultas. Existem muitas ferramentas para fazer esse rastreamento pesado de contexto. Alguns são de código aberto como o Anemometer e ferramentas comerciais como o Vivid Cortex (nós usamos isso no SendGrid. Veja-nos falar sobre isso aqui.) Mesmo apenas rastrear essas métricas da perspectiva do aplicativo e jogá-las como métricas statsd será um bom primeiro passo. Mas, desde o início, você deve se acostumar com o fato de que o que seu aplicativo percebe é o que seus clientes percebem. E você deve encontrar uma maneira de saber primeiro.

Conheça os padrões de tráfego da sua empresa

Você é uma empresa suscetível a picos extremos em dias da semana específicos (por exemplo, marketing)? Você tem lançamentos regulares que triplicam ou quadruplicam seu tráfego como jogos? Esses tipos de perguntas determinarão quanto de espaço reservado você deve manter ou se você precisa investir em crescimento elástico.

Determinar a proporção de números brutos de tráfego em relação à capacidade em uso

Esta é simplesmente a resposta para “Se não fizermos otimizações de código, quantos e-mails/vendas/usuários online/qualquer coisa” podemos atender com as instâncias de banco de dados que temos agora?

Idealmente, este é um valor específico que torna a matemática para planejar o crescimento de um ano uma simples equação matemática. Mas a vida nunca é o ideal e esse valor varia dependendo da estação ou de fatores completamente externos, como a contratação de um novo cliente importante. Nas primeiras startups, esse número é um alvo em movimento mais rápido, mas deve se estabilizar à medida que a empresa transita dos primeiros dias para negócios mais estabelecidos, com padrões de crescimento de negócios mais previsíveis.

Eu realmente preciso comprar mais máquinas?

Você precisa encontrar uma maneira de determinar se isso é realmente capacidade - preciso dividir as gravações para suportar mais carga de gravação simultânea ou adicionar mais réplicas de leitura - vs. gargalo de desempenho baseado em código (essa nova consulta de uma implantação recente pode realmente ter seus resultados armazenados em cache em algo mais barato e não superar tanto o banco de dados).

Como você faz isso? Você precisa se familiarizar com suas dúvidas. O primeiro passo para isso é uma combinação de innotop, log lento e pt-query-digest do Percona Toolkit. Você pode automatizar isso enviando os logs do banco de dados para um local central e automatizando a parte do resumo.

Mas esse também não é o cenário completo, os logs lentos são intensivos em desempenho se você diminuir muito o limite. Se você puder viver com amostragem menos seletiva, precisará detectar todas as conversas entre o aplicativo e o armazenamento de dados. Na terra do código aberto, você pode ir tão básico quanto o tcpdump ou pode usar produtos hospedados como Datadog, New Relic ou VividCortex.

Faça uma ligação

O planejamento de capacidade pode ser 90% ciência e 10% arte, mas esses 10% não devem significar que não devemos nos esforçar para obter o máximo possível da imagem. Como engenheiros, às vezes podemos nos fixar nos 10% que faltam e não perceber que, se fizermos o trabalho, esses 90% podem nos dar uma ideia melhor da saúde de nossa pilha, um uso mais eficiente do nosso tempo otimizando o desempenho e a capacidade de planejamento aumenta cuidadosamente, o que acaba resultando em um retorno muito melhor do investimento para nossos produtos.