O ElastiCache é um cache em memória gerenciado (Redis ou Memcached). Ele guarda na RAM o que é caro de buscar, pra a aplicação ler em microssegundos em vez de bater no banco toda hora.
Acelerar aplicações e aliviar o banco de dados: guardar resultados de consultas pesadas, sessões de usuário, rankings, contadores. É o truque nº 1 pra deixar um site rápido sob carga.
Cada um deles roda de verdade no terminal do CLImb, com a mesma saída e as mesmas mensagens de erro que a AWS devolve.
aws elasticache describe-cache-clustersUSO
aws elasticache describe-cache-clusters
aws elasticache create-cache-clusterUSO
aws elasticache create-cache-cluster --cache-cluster-id cache-loja --engine redis --cache-node-type cache.t3.micro --num-cache-nodes 1
aws elasticache create-cache-subnet-groupUSO
aws elasticache create-cache-subnet-group --cache-subnet-group-name cache-privado \ --cache-subnet-group-description "Sub-redes privadas" --subnet-ids subnet-aaa1 subnet-bbb2
aws elasticache describe-cache-subnet-groupsUSO
aws elasticache describe-cache-subnet-groups
aws elasticache create-replication-groupUSO
aws elasticache create-replication-group --replication-group-id cache-loja-ha \ --replication-group-description "Redis com failover" --num-cache-clusters 2
aws elasticache describe-replication-groupsUSO
aws elasticache describe-replication-groups
aws elasticache create-snapshotUSO
aws elasticache create-snapshot --snapshot-name backup-cache \ --replication-group-id cache-loja-ha
aws elasticache describe-snapshotsUSO
aws elasticache describe-snapshots
aws elasticache describe-eventsUSO
aws elasticache describe-events --duration 1440
aws elasticache delete-cache-clusterUSO
aws elasticache delete-cache-cluster --cache-cluster-id cache-loja
Cada atividade é um pedido de trabalho, do jeito que ele chega no dia a dia — você resolve digitando os comandos, não escolhendo alternativa.
O ElastiCache guarda em memória o que é caro de buscar — a app lê do cache em microssegundos em vez de bater no banco toda hora. Liste os clusters de cache.
Crie o cache cache-loja com engine redis, tipo cache.t3.micro, 1 nó.
Cache não fica solto na internet — ele vive em sub-redes da sua VPC. Crie o subnet group cache-privado com duas sub-redes (subnet-aaa1 e subnet-bbb2). <small>(duas zonas diferentes: cache numa zona só cai junto com ela)</small>
Antes de subir qualquer coisa, liste os subnet groups — é assim que se descobre se alguém deixou uma sub-rede pública no meio.
O cache de um nó só que você subiu é exatamente o que não se coloca em produção: se ele cair, todo o tráfego vai pro banco de uma vez. Crie o replication group cache-loja-ha com 2 nós — primário e réplica, com failover automático.
Achar que tem réplica e não ter é pior do que não ter. Confirme o estado do grupo e do failover automático.
Cache é memória: reiniciar sem backup significa subir vazio, e aí todo o tráfego bate no banco até reaquecer. Faça um snapshot chamado backup-cache-loja do grupo cache-loja-ha.
A pergunta que ninguém faz antes do acidente. Liste os snapshots e veja quando foram feitos.
O sistema ficou lento às 3 da manhã e ninguém mexeu em nada. Veja os eventos do serviço na janela das últimas 24 horas — failover, nó substituído e manutenção aparecem aqui. <small>(cuidado: a duração conta em MINUTOS, e sem a flag o padrão são só 60 — a madrugada ficaria de fora)</small>
Apague o cluster cache-loja.
Ler explica. Digitar fixa. No CLImb você roda os comandos de verdade num terminal AWS simulado — o estado persiste entre eles, como na nuvem real.
As 3 primeiras atividades desta trilha são abertas; o resto faz parte do plano Pro.
Começar — 3 atividades grátis