Por que e como as equipes estão substituindo o cache de banco de dados externo

A equipe da comunidade de código aberto da China fez sua primeira transmissão ao vivo, contando a história por trás da comunidade de código aberto da China em nome do compartilhamento."

Embora os caches externos sejam ótimos para reduzir a latência, eles geralmente causam mais problemas do que benefícios. Veja como resolver esse problema.

Traduzido de Por que e como as equipes estão substituindo caches de bancos de dados externos, de Felipe Cardeneti Mendes.

As equipes geralmente consideram o cache externo quando um banco de dados existente não consegue atender ao acordo de nível de serviço (SLA) exigido. Esta é uma decisão decididamente orientada para o desempenho. Colocar cache externo na frente do banco de dados geralmente é feito para compensar a latência abaixo do ideal causada por vários fatores (por exemplo, componentes internos ineficientes do banco de dados, uso de driver, escolhas de infraestrutura, picos de tráfego, etc.).

O cache parece ser uma solução rápida e fácil, pois a implantação pode ser implementada sem grandes complicações e sem incorrer em custos significativos de expansão do banco de dados , redesenho do esquema do banco de dados ou até mesmo conversões tecnológicas mais profundas. No entanto, o cache externo não é tão simples como se costuma dizer. Eles podem ser um dos componentes mais problemáticos da arquitetura de aplicativos distribuídos.

Em alguns casos, isso é um mal necessário, como quando você precisa de acesso frequente a dados transformados resultantes de cálculos longos e caros, e você tentou de todas as outras maneiras reduzir a latência. Mas, em muitos casos, o ganho de desempenho simplesmente não vale a pena. Você resolve um problema, mas cria outros.

Aqui estão os riscos frequentemente negligenciados associados ao cache externo e as maneiras pelas quais três equipes obtiveram ganhos de desempenho e economia de custos substituindo seu banco de dados principal e cache externo por uma única solução. Spoiler: Eles usam o ScyllaDB, um banco de dados de alto desempenho que melhora a latência de cauda longa aproveitando um cache interno especializado.

Por que não armazenar em cache?

No ScyllaDB, trabalhamos com inúmeras equipes que enfrentam custos, complicações e limitações das tentativas tradicionais de melhoria de desempenho de bancos de dados. Aqui estão as principais dificuldades que vemos as equipes encontrarem ao colocar cache externo em seus bancos de dados.

O cache externo aumenta a latência

Uma cache separada significa mais um salto no caminho. Quando o cache envolve o banco de dados, o primeiro acesso ocorre na camada de cache. Caso os dados não estejam no cache, a solicitação será enviada ao banco de dados. Isso adiciona latência ao caminho já lento para dados não armazenados em cache. Pode-se afirmar que quando todo o conjunto de dados cabe no cache, a latência adicional não entra em ação. No entanto, a menos que seu conjunto de dados seja relativamente pequeno, armazenar tudo na memória aumenta significativamente o custo, tornando-o proibitivamente caro para a maioria das organizações.

O cache externo tem um custo adicional

Cache significa DRAM caro, o que significa que o custo por gigabyte é maior do que os discos de estado sólido. (Para obter mais detalhes sobre isso, consulte a palestra de Danny Kopping do Grafana no P99 CONF .) Em vez de provisionar uma infraestrutura completamente separada para armazenamento em cache, geralmente é melhor usar a memória do banco de dados existente ou até mesmo aumentá-la para acomodar o cache interno. Quando dimensionados corretamente, os caches de banco de dados modernos podem ser tão eficientes quanto as soluções tradicionais de cache na memória. Os bancos de dados geralmente fazem um bom trabalho ao otimizar o acesso de E/S ao armazenamento flash quando o tamanho do conjunto de trabalho é muito grande para caber na memória, tornando um banco de dados separado (sem cache externo) a opção preferida e mais barata.

O cache externo reduz a disponibilidade

Nenhuma solução de cache de alta disponibilidade pode rivalizar com o próprio banco de dados. Os bancos de dados distribuídos modernos têm múltiplas réplicas; eles também reconhecem a topologia e a velocidade e podem suportar diversas falhas sem perder dados.

Por exemplo, um padrão de replicação comum são três réplicas locais, o que muitas vezes permite que as leituras sejam balanceadas entre essas réplicas para utilizar efetivamente o mecanismo de cache interno do banco de dados. Considere um cluster de nove nós com um fator de replicação de três: Essencialmente, cada nó conterá aproximadamente um terço do tamanho total do conjunto de dados. Como as solicitações são balanceadas entre diferentes réplicas, isso oferece mais espaço para armazenar os dados em cache, o que pode eliminar a necessidade de armazenamento em cache externo. Por outro lado, se o cache externo invalidar uma entrada logo antes de um grande número de solicitações não solicitadas, a disponibilidade poderá ser afetada por um período de tempo porque o banco de dados não possui esses dados em seu cache interno (mais sobre isso abaixo).

Os caches geralmente não possuem propriedades de alta disponibilidade e podem facilmente falhar ou invalidar registros com base em suas heurísticas. As falhas parciais são mais comuns e ainda piores em termos de consistência. Quando o cache falha inevitavelmente, o banco de dados será atingido por uma enxurrada de consultas não mitigadas e poderá quebrar seu SLA. Além disso, mesmo que o próprio cache tenha alguns recursos de alta disponibilidade, ele não pode coordenar o tratamento de tais falhas com o banco de dados persistente à sua frente. Resumindo : confie no banco de dados, em vez de fazer com que seu SLA de latência dependa do cache.

Complexidade da aplicação – sua aplicação precisa lidar com mais situações

O cache externo introduz complexidade operacional e de aplicativos. Depois de ter um cache externo, é sua responsabilidade mantê-lo atualizado com o banco de dados. Independentemente da sua estratégia de cache (por exemplo, write-through, bypass de cache, etc.), haverá casos extremos em que seu cache poderá ficar fora de sincronia com o banco de dados, e você deverá levar em conta essas situações durante o desenvolvimento do aplicativo. As configurações do seu cliente (como políticas de failover, nova tentativa e tempo limite) precisam corresponder às propriedades do cache e do banco de dados para funcionar quando o cache estiver indisponível ou esfriar. Normalmente, esses cenários são difíceis de testar e implementar.

Cache externo corrompe cache do banco de dados

Os bancos de dados modernos possuem caches incorporados e estratégias complexas para gerenciá-los. Quando você coloca um cache na frente do banco de dados, a maioria das solicitações de leitura atingirá apenas o cache externo e o banco de dados não manterá esses objetos em sua memória. Como resultado, o cache do banco de dados torna-se inválido. Quando a solicitação finalmente chegar ao banco de dados, seu cache estará frio e a resposta virá principalmente do disco. Como resultado, a viagem de ida e volta do cache ao banco de dados e de volta ao aplicativo pode aumentar a latência.

O cache externo pode aumentar os riscos de segurança

O cache externo adiciona uma superfície de ataque totalmente nova à sua infraestrutura. A criptografia, o isolamento e os controles de acesso aos dados colocados no cache podem diferir daqueles da própria camada do banco de dados.

O cache externo ignora o conhecimento e os recursos do banco de dados

O banco de dados é complexo e criado para cargas de trabalho de E/S especializadas no sistema. Muitas consultas acessam os mesmos dados e uma certa quantidade do tamanho do conjunto de trabalho pode ser armazenada em cache na memória para economizar acesso ao disco. Um bom banco de dados deve ter uma lógica complexa para decidir quais objetos, índices e acessos devem ser armazenados em cache. O banco de dados também deve ter uma política de despejo para determinar quando novos dados devem substituir objetos de cache existentes (mais antigos).

O cache resistente à varredura é um exemplo. Ao verificar grandes conjuntos de dados, como varreduras de grande intervalo ou de tabela completa, um grande número de objetos é lido do disco. O banco de dados pode perceber que se trata de uma varredura (em vez de uma consulta normal) e optar por manter seus objetos fora do cache interno. No entanto, o cache externo (que segue a política de leitura) trata o conjunto de resultados como qualquer outro conjunto de resultados e tenta armazenar os resultados em cache. O banco de dados sincroniza automaticamente o conteúdo armazenado em cache com o disco com base nas taxas de solicitação recebidas, para que os usuários e desenvolvedores não precisem fazer nada para garantir o desempenho e a consistência nas pesquisas de dados gravados recentemente. Então, se por algum motivo seu banco de dados não estiver respondendo rápido o suficiente, isso significa:

Erro de configuração de cache.
Não há RAM suficiente para cache.
O tamanho do conjunto de trabalho e o padrão de solicitação não são adequados para armazenamento em cache.
A implementação do cache do banco de dados é ruim.

Melhor opção: deixar o banco de dados cuidar disso

Como cumprir seu SLA sem o risco de cache externo de banco de dados? Muitas equipes descobrem que, ao migrar para um banco de dados mais rápido (como o ScyllaDB) e usar um cache interno dedicado , conseguem cumprir seus SLAs de latência com menos complicações e custos menores. É claro que os resultados variam de acordo com as características da carga de trabalho e os requisitos técnicos. Mas para saber o que é possível, considere o que essas equipes podem alcançar.

SecurityScorecard alcança redução de latência de 90% com economia anual de US$ 1 milhão

O SecurityScorecard visa tornar o mundo um lugar mais seguro, mudando a forma como milhares de organizações entendem, mitigam e se comunicam sobre segurança cibernética. Sua plataforma de classificações é uma medida objetiva, baseada em dados e quantificável da segurança cibernética geral e da exposição ao risco cibernético de uma organização.

A arquitetura de dados anterior da equipe serviu bem por um tempo, mas não conseguiu acompanhar seu crescimento. A API da plataforma consulta um dos três armazenamentos de dados: Redis (para pesquisas mais rápidas de 12 milhões de scorecards), Aurora (para armazenar 4 bilhões de estatísticas de medição entre nós) ou o sistema de arquivos distribuído Hadoop Presto cluster (para consultas SQL complexas em resultados históricos). ).

À medida que os dados e as solicitações aumentam, surgem desafios. Aurora e Presto experimentam picos de latência em alta taxa de transferência. A maior instância possível do Redis ainda não era suficiente e eles não queriam usar a complexidade do Redis Cluster.

Para reduzir a latência na nova escala necessária para o rápido crescimento dos negócios, a equipe recorreu ao ScyllaDB Cloud e desenvolveu uma nova API de pontuação para rotear solicitações menos sensíveis à latência para armazenamento Presto e S3. Aqui está uma visualização dessa arquitetura, e é bastante simples:

Este movimento resultou em:

Latência 90% menor para a maioria dos endpoints de serviço
Redução de 80% em incidentes de produção relacionados ao desempenho do Presto/Aurora
US$ 1 milhão em economia anual de custos de infraestrutura
A velocidade de processamento do pipeline de dados aumentou 30%
Melhore drasticamente a experiência do cliente

IMVU reduz custo do Redis em 100 vezes

IMVU é uma comunidade social popular que permite que pessoas de todo o mundo interajam usando avatares 3D em desktops, tablets e dispositivos móveis. Para atender aos requisitos de escala crescente, a IMVU decidiu que precisava de uma solução de desempenho superior à de sua arquitetura de banco de dados anterior (MySQL e Memcached na frente do Redis). A equipe procurou algo que fosse mais fácil de configurar, mais fácil de escalar e (se fosse bem-sucedido) mais fácil de escalar.

“O Redis era ótimo para capacidades de prototipagem, mas depois que o implementamos, a despesa ficou difícil de justificar”, disse Ken Rudy, engenheiro de software sênior da IMVU. "O ScyllaDB é otimizado para manter os dados necessários na memória e todo o resto no disco. O ScyllaDB nos permite manter a mesma capacidade de resposta em centenas de vezes a escala que o Redis pode suportar."

A Comcast usa US$ 2,5 milhões em economia anual para reduzir a latência de cauda longa em 95%

A Comcast é uma empresa global de mídia e tecnologia com três negócios principais: Comcast Cable, um dos maiores provedores de vídeo, Internet de alta velocidade e chamadas telefônicas para clientes residenciais nos Estados Unidos; O serviço Xfinity da Comcast atende 15 milhões de residências, com mais de 2 bilhões de chamadas de API (leitura/gravação) e mais de 200 milhões de novos objetos todos os dias. Em sete anos, o programa expandiu-se do suporte de 30.000 dispositivos para mais de 31 milhões de dispositivos.

A latência de cauda longa de Cassandra revelou-se inaceitável na escala de rápido crescimento da empresa. Para ocultar dos usuários os problemas de latência do Cassandra, a equipe colocou 60 servidores de cache na frente de seu banco de dados. Manter essa camada de cache consistente com o banco de dados cria muitas dores de cabeça para os administradores. Como o cache e a infraestrutura relacionada devem ser replicados entre data centers, a Comcast precisa manter o cache ativo. Eles implementaram um aquecedor de cache que verificava o volume de gravação e depois copiava os dados entre data centers.

A Comcast rapidamente recorreu ao ScyllaDB depois de lutar com a sobrecarga dessa abordagem. O ScyllaDB foi projetado para minimizar picos de latência por meio de seu mecanismo de cache interno, permitindo que a Comcast elimine camadas de cache externas, fornecendo uma estrutura simples onde os serviços de dados se conectam diretamente aos armazenamentos de dados. A Comcast conseguiu substituir 962 nós Cassandra por apenas 78 nós ScyllaDB. Eles melhoraram a disponibilidade e o desempenho gerais e eliminaram completamente 60 servidores de cache. Resultados: P99, P999 e P9999 reduziram a latência em 95% e conseguiram lidar com o dobro de solicitações, a um custo operacional de 60%. Em última análise, isso economizou US$ 2,5 milhões por ano em custos de infraestrutura e despesas gerais com pessoal.

Conclusão

Embora os caches externos sejam ótimos companheiros para reduzir a latência (como servir conteúdo estático e dados personalizados que não exigem nenhum nível de persistência), eles geralmente criam mais problemas do que benefícios quando colocados na frente do banco de dados.

As principais compensações incluem aumento de custo, maior complexidade de aplicativos, viagens de ida e volta adicionais ao banco de dados e superfícies de segurança adicionais. Ao repensar as estratégias de cache existentes e mudar para um banco de dados moderno que oferece baixa latência previsível em escala, as equipes podem simplificar sua infraestrutura e minimizar custos. Ao mesmo tempo, eles ainda podem cumprir seus SLAs sem o incômodo e a complexidade extras do cache externo.

Este artigo foi publicado pela primeira vez em Yunyunzhongsheng ( https://yylives.cc/ ), todos são bem-vindos para visitar.