Caching Strategies

Transcript

1.  Cache strategies Leonardo Rodrigues
2.  Table of contents ▪ Cache ▪ Tipos de armazenamento ▪ Terminologias ▪ Estrategias de cache ▪ Cache-aside ▪ Read-through ▪ Write-through ▪ Write-behind (Back) ▪ Write-around ▪ Possíveis problemas com cache ▪ Determinando a eficiência do cache ▪ Real world use cases
3.  Cache Cache é um espaço de armazenamento rápido e temporário de dados que são frequentemente acessados. A rapidez é dada devido o armazenamento ser feito em memória ao invés de discos. Podemos notar a diferença do tempo de latência quando olhamos para a hierarquia de memória na arquitetura moderna de computadores. Fonte: https://cs.brown.edu/courses/csci1310/2020/assign/labs/lab4.html?spm=a2c65.11461447.0.0.47497f65llHVDn
4.  Tipos de armazenamento Cache de aplicação pode ser armazenado de duas maneiras em memória e distribuído. Lembrando que sempre temos que olhar do ponto de vista da aplicação que irá trabalhar com o mecanismo de cache.
5.  Em memória Dizemos que o cache é em memória quando a aplicação compartilha uma parte da sua memória para armazenamento. Geralmente as Libraries e Frameworks disponíveis no mercado que fazem a gestão do cache são abstrações que implementam a estrutura de dados Map (HashMap, ConcurrentHasmap) Libraries • Spring Cache • Caffeine • Cache2k
6.  Distribuído Quando externalizamos esse armazenamento para um sistema terceiro, dizemos que este é um cache distribuído. Bancos de dados NoSQL chave-valor são os mais empregados em cenários de cache distribuído na indústria. O Redis sendo o principal deles, que também implementa a estrutura de dados Map por trás dos panos. Providers • Redis • Memcached • Hazelcast
7.  Prós e contras Fonte: https://leonardorodrigues.tech/masterizando-cache-em-aplicacoes-introducao/
8.  Terminologias Cache Hit Cache hit é quando a aplicação encontra o dado salvo no cache. Cache Miss Cache miss é quando a aplicação não encontra o dado salvo no cache. TTL (time-to-live) É o tempo em que o dado ficará salvo dentro do cache e não havendo atualização do dado ele será deletado espontaneamente pelo cache.
9.  Estratégias de cache – Cache-aside (Lazy) Cache-aside ou lazy é a estratégia mais utilizada por aplicações onde o cache e a base de dados são independentes, sendo a própria aplicação responsável por manter a consistência do dado. Benefícios • Código da aplicação flexível: Desenvolvedores pode otimizar o cache, determinando o que deve ser colocado em cache e por quanto tempo • Resiliência: Se a camada de cache cair as leituras são feitas direto na base. • Escalabilidade: É possível adicionar nós na camada de cache conforme a demanda • Separação do cache provider: Como o controle é feito via código ou libraries, os requerimentos do cache provider são mínimos facilitando a troca caso necessário. Limitações • Gerenciamento do cache: Fica a cargo do desenvolvedor tratar o update, invalidação, requisições concorrentes. Podendo adicionar uma complexidade extra. • Lazy loading: O dado sempre será atualizado/escrito no cache depois de um cache-miss. Caso exista atualizações frequente na base vai existir cache- misses frequentemente. • Database spike: Em uma eventual falha da camada de cache, pode-se ocorrer uma alta demanda de queries na base de dados.
10.  Estratégias de cache – Read through Diferente do cache-aside em que a aplicação gerencia o cache, na estratégia Read-through o cache fica responsável por buscar e atualizar o dado na base de dados. Desta maneira o cache se torna uma aplicação intermediaria entre a aplicação e a base de dados. A implementação da gestão do cache é feito por libraries instaladas direto no nó ou motor de cache, por exemplo: Redis Gears, CacheLib e DistCache Benefícios • Simplifica o código da aplicação: O motor de cache abstrai a gestão do dado do cache • Reduz a latência: Principalmente quando a base de dados é localizada em outra geolocalização • Recarregamento de dados: Temos a possibilidade de recarregar o cache automaticamente de em determinado período, reduzindo a necessidade de um cache miss e a atualização posterior do dado Limitações • Single point of failure: Se o motor de cache não possuir replicas e ao cair, o sistema fica inoperante • Inconsistência: Se o dado foi atualizado na base por vias externas e o cache ainda não expirou teremos inconsistência entre o cache e o banco de dados • Cache stampede: Se optarmos pelo recarregamento de dados automático, quando uma grande quantidade de dados expirar no cache muitas requisições vão ocorrer na base de dados, causando o cache stampede.
11.  Estratégias de cache – Write through Similar ao Read-through com a particularidade de somente escrita. Também é o cache responsável por fazer a gestão do dado. Quando um sistema precisa escrever um dado, primeiro é persistido na camada de cache e posteriormente no banco de dados, de maneira síncrona. A implementação da gestão do cache é feito por libraries instaladas direto no nó ou motor de cache, por exemplo: Redis Gears, CacheLib e DistCache Benefícios • Dado atualizado: O dado sempre será o mais atualizado nas duas fontes de dados, uma vez que o dado escrito no cache será imediatamente escrito na base de dados. • Redução de perca de dados: Em caso de crashes seja no cache ou banco de dados podemos escolher qualquer uma das duas fontes como verdade, pois, o dado sempre é o mais atualizado. Limitações • Necessita de estratégia de leitura: É necessário implementar uma estratégia de leitura caso queira fazer leitura. Como por exemplo Read-through. • Alta latência na escrita: Devido a escrita ocorrer sincronamente no cache e na base dados.
12.  Estratégias de cache – Write behind (Back) Similar ao Write-through com a particularidade da escrita ser feita de maneira assíncrona na base de dados. Também é o cache responsável por fazer a gestão do dado. A implementação da gestão do cache é feito por libraries instaladas direto no nó ou motor de cache, por exemplo: Redis Gears, CacheLib e DistCache Benefícios • Baixa latência na escrita: A latência é baixa devido o comportamento assíncrono entre o cache e o banco. Garantindo a alta performance na escrita. • Resiliência: Mesmo com downtime da base de dados o sistema que faz uso do cache ainda continua a escrever e funcionar sem problemas. Limitações • Consistência eventual: Como a escrita na base é feita de maneira assíncrona, não conseguimos garantir totalmente a consistência do dado entre o cache e a base. Podemos haver crashes. • Necessita de estratégia de leitura: É necessário implementar uma estratégia de leitura caso queira fazer leitura. Como por exemplo Read-through.
13.  Estratégias de cache – Write around Na estratégia write-around é a aplicação que gerencia o dado. Quando ocorre a escrita a aplicação da um by-pass no cache e escreve diretamente na base, desta forma o dado não é persistido no cache em operações de escrita. Quando uma operação de leitura é requisitada, caso exista um cache-miss o dado é buscado na base e persistido no cache. Benefícios • Espaço de cache otimizado: Os dados armazenados em cache são somente os requisitados, evitando assim o armazenamento de dados desnecessários. • Consistência na base: O dado escrito sempre será o mais atual e consistente na base. Limitações • Alta latência em operações de leitura: Operações de leitura enfrenta problemas de latência pois precisa buscar o dado na base e persistir no cache em casos de cache-miss
14.  Possíveis problemas com cache ▪ Avalanche: Acontece quando muitos dados que estão em cache expiram ao mesmo tempo ou a camada de cache caiu, logo, uma quantidade alta de requisições vão direto no banco de dados. Causando degradação na performance ou até mesmo derrubando o banco de dados. ▪ Stampede: Acontece quando muitas requisições disputam um dado específico que expirou no cache, logo, o tráfego é direcionado direto para a base de dados. ▪ Breakdown: Em estratégias de escrita pura (Write-though, Write-behind) ou leitura pura (Read-through) temos a possibilidade de o sistema todo ficar inoperante, caso não exista redundância dos nós no cache provider, devido single-point-of-failure. ▪ Consistência: É custoso e complexo a garantia da consistência do dado em situações de alto volume de dados, baixa redundância e concorrência. Podemos mitigar esses problemas utilizando técnicas como Staggered expiration, Consistent Hashing, Rate limit, Circuit breaker Fonte: https://blog.bytebytego.com/p/a-crash-course-in-caching-final-part
15.  Determinando a eficiência do cache Antes de determinar se o nosso cache está sendo eficiente ou não precisamos de dados a serem processados. Nesse caso, precisamos que métricas sejam coletadas na própria aplicação ou no motor de cache e para isso podemos utilizar ferramentas de métricas e monitoração já conhecidas no mercado, por exemplo, micrometer, prometheus, datadog e new relic. • Cache hit ratio: Para determinar se o cache está sendo efetivo podemos utilizar a fórmula que determina a taxa de cache hit. Quanto maior o resultado, maior a efetividade do cache. Um bom percentual fica em torno de 95- 99% de cache hit ratio. • Latência: Quanto menor a latência, melhor. Ou seja, devemos notar a queda no tempo de latência quando passamos a fazer leitura do dado em cache. É comum o tempo de latência cair de segundos para milissegundos.
16.  Real world use cases + overall benefits ▪ Facebook: https://blog.bytebytego.com/p/how-facebook-served-billions-of-requests ▪ Netflix: https://netflixtechblog.com/caching-for-a-global-netflix-7bcc457012f1
17.  Thanks
18.  Fontes https://cs.brown.edu/courses/csci1310/2020/assign/labs/lab4.html?spm=a2c65.11461447.0.0.47497f65l lHVDn https://www.enjoyalgorithms.com/blog/cache-aside-caching-strategy https://leonardorodrigues.tech/masterizando-cache-em-aplicacoes-introducao/ https://redis.io/learn/howtos/solutions/caching-architecture/common-caching/redis-gears https://cachelib.org/ https://pkg.go.dev/github.com/tochemey/distcache https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/gears-v1/python/recipes/write- behind/ https://blog.bytebytego.com/p/a-crash-course-in-caching-final-part https://aws.amazon.com/caching/best-practices/ https://www.prisma.io/dataguide/managing-databases/introduction-database-caching https://www.cloudflare.com/learning/cdn/what-is-a-cache-hit-ratio/ https://colin-scott.github.io/personal_website/research/interactive_latency.html