# PERF03-BP05 Implementar padrões de acesso a dados que utilizem cache
Implemente padrões de acesso que possam se beneficiar do armazenamento em cache de dados para recuperação rápida de dados acessados com frequência.
**Antipadrões comuns:**
+ Você armazena em cache dados que mudam com frequência.
+ Você depende dos dados em cache como se estivessem armazenados de forma durável e sempre disponíveis.
+ Você não leva em conta a consistência dos seus dados em cache.
+ Você não monitora a eficiência da sua implementação de cache.
**Benefícios de estabelecer esta prática recomendada:** armazenar dados em um cache pode melhorar a latência de leitura, throughput de leitura, a experiência do usuário e a eficiência geral, além de reduzir custos.
**Nível de risco exposto se esta prática recomendada não for estabelecida**: médio
## Orientação para implementação
Um cache é um componente de software ou hardware destinado a armazenar dados para que futuras solicitações dos mesmos dados possam ser atendidas com maior rapidez e eficiência. Os dados armazenados em um cache podem ser reconstruídos se perdidos, repetindo um cálculo anterior ou obtendo-os de outro armazenamento de dados.
O armazenamento de dados em cache pode ser uma das estratégias mais eficazes para melhorar o desempenho geral da aplicação e reduzir a carga sobre as fontes de dados primárias subjacentes. Os dados podem ser armazenados em cache em vários níveis na aplicação, tais como dentro da aplicação fazendo chamadas remotas, conhecidas como *armazenamento em cache do lado do cliente,*ou usando um serviço secundário rápido para armazenar os dados, conhecido como *armazenamento em cache remoto*.
**Armazenamento em cache do lado do cliente**
Com o armazenamento em cache do lado do cliente, cada cliente (uma aplicação ou serviço que consulta o datastore de back-end) pode armazenar os resultados de suas consultas exclusivas localmente por um período especificado. Isso pode reduzir o número de solicitações na rede para um datastore verificando primeiro o cache do cliente local. Se os resultados não estiverem presentes, a aplicação poderá então consultar o datastore e armazenar esses resultados localmente. Esse padrão permite que cada cliente armazene dados no local mais próximo (o próprio cliente), resultando na menor latência possível. Os clientes também podem continuar a atender algumas consultas quando o datastore de back-end não está disponível, aumentando a disponibilidade geral do sistema.
Uma desvantagem dessa abordagem é que, quando vários clientes estão envolvidos, eles podem armazenar os mesmos dados em cache localmente. Isso resulta no uso de armazenamento duplicado e na inconsistência de dados entre esses clientes. Um cliente pode armazenar em cache os resultados de uma consulta e, um minuto depois, outro cliente pode executar a mesma consulta e obter um resultado diferente.
**Armazenamento em cache remoto**
Para resolver o problema de dados duplicados entre clientes, um serviço externo rápido, ou *cache remoto,*pode ser usado para armazenar os dados consultados. Em vez de verificar um datastore local, cada cliente verificará o cache remoto antes de consultar o datastore de back-end. Essa estratégia permite respostas mais consistentes entre clientes, melhor eficiência nos dados armazenados e um volume maior de dados em cache, pois o espaço de armazenamento é dimensionado independentemente dos clientes.
A desvantagem de um cache remoto é que o sistema geral pode ter uma latência maior, pois é necessário um salto de rede adicional para verificar o cache remoto. O cache do lado do cliente pode ser usado junto com o armazenamento em cache remoto para o armazenamento em vários níveis para melhorar a latência.
### Etapas da implementação
1. Identifique bancos de dados, APIs e serviços de rede que poderiam se beneficiar do armazenamento em cache. Serviços que têm workloads de leitura pesadas, uma alta taxa de leitura e gravação ou que são caros para escalar são candidatos ao armazenamento em cache.
+ [Armazenamento em cache de banco de dados](https://aws.amazon.com/caching/database-caching/)
+ [Ativação do armazenamento em cache da API para melhorar a capacidade de resposta](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html)
1. Identifique o tipo apropriado de estratégia de armazenamento em cache que melhor se adapte ao seu padrão de acesso.
+ [Estratégias de armazenamento em cache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Strategies.html)
+ [Soluções de armazenamento em cache da AWS](https://aws.amazon.com/caching/aws-caching/)
1. Siga [Práticas recomendadas de armazenamento em cache](https://aws.amazon.com/caching/best-practices/) para seu armazenamento de dados.
1. Configure uma estratégia de invalidação de cache, como um time-to-live (TTL), para todos os dados que equilibre a atualização dos dados e reduza a pressão sobre o datastore de back-end.
1. Ative recursos como novas tentativas automáticas de conexão, recuo exponencial, tempos limite do lado do cliente e pool de conexões no cliente, se disponíveis, pois eles podem melhorar o desempenho e a confiabilidade.
+ [Práticas recomendadas: clientes Redis e Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/)
1. Monitore a taxa de acertos de cache com uma meta de 80% ou mais. Valores mais baixos podem indicar tamanho insuficiente do cache ou um padrão de acesso que não se beneficia do armazenamento em cache.
+ [Quais métricas devo monitorar?](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html)
+ [Práticas recomendadas para monitorar workloads do Redis no Amazon ElastiCache](https://www.youtube.com/watch?v=c-hTMLN35BY)
+ [Monitoramento das práticas recomendadas com Amazon ElastiCache (Redis OSS) usando o Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
1. Implemente [replicação de dados](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) para descarregar as leituras em várias instâncias e melhorar o desempenho e a disponibilidade da leitura de dados.
## Recursos
**Documentos relacionados:**
+ [Uso do Amazon ElastiCache Well-Architected Lens](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WellArchitechtedLens.html)
+ [Monitoramento das práticas recomendadas com Amazon ElastiCache (Redis OSS) usando o Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [Quais métricas devo monitorar?](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html)
+ [Whitepaper: Performance at Scale with Amazon ElastiCache (Desempenho em escala com Amazon ElastiCache)](https://docs.aws.amazon.com/whitepapers/latest/scale-performance-elasticache/scale-performance-elasticache.html)
+ [Desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
**Vídeos relacionados:**
+ [Amazon ElastiCache Learning Path (Roteiro de aprendizado do Amazon ElastiCache)](https://pages.awscloud.com/GLB-WBNR-AWS-OTT-2021_LP_0003-DAT_AmazonElastiCache.html)
+ [Design for success with Amazon ElastiCache best practices (Projete para o sucesso com as práticas recomendadas do Amazon ElastiCache)](https://youtu.be/_4SkEy6r-C4)
**Exemplos relacionados:**
+ [Como aumentar o desempenho do banco de dados MySQL com Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/getting-started/hands-on/boosting-mysql-database-performance-with-amazon-elasticache-for-redis/)