Servidor cloud para Redis na Europa: configuração EU de baixa latência
Redis e o armazenamento de dados em memória que fica na frente do seu banco de dados, absorvendo o tráfego de leitura e reduzindo os tempos de resposta de milissegundos para microssegundos. Para aplicações que atendem usuários europeus, executar o Redis em um servidor cloud da UE não e apenas uma escolha de desempenho - também mantém os dados de sessão, tokens de usuário e informações pessoais em cache sob a jurisdição da UE conforme o RGPD.
Por que a residência de dados na UE importa para Redis
O Redis normalmente armazena tokens de sessão, preferências do usuário e respostas de API em cache - tudo isso pode constituir dados pessoais sob o RGPD. A hospedagem em um servidor EU operado por uma empresa europeia garante que esses dados nunca transitem pela jurisdição dos EUA.
A latência também e critica para um cache. Uma instância do Redis em Praga ou Frankfurt adiciona 0,1-0,5 ms de tempo de ida e volta ao servidor de aplicações no mesmo data center. A mesma instância em uma região dos EUA adiciona 80-100 ms.
Especificações mínimas para Redis
O Redis e completamente em memória, portanto, a RAM e o recurso principal:
- Pequeno (cache de sessão, ate 10 GB de dados) - 2 vCPU, 16 GB RAM, 50 GB NVMe SSD
- Médio (cache de páginas/objetos, 10-50 GB) - 4 vCPU, 64 GB RAM, 100 GB NVMe SSD
- Grande (armazenamento de dados principal ou pub/sub) - 8 vCPU, 128 GB RAM, 200 GB NVMe SSD
Configuração recomendada da DCXV
Os servidores cloud da DCXV oferecem configurações de alta memória com armazenamento NVMe:
- 4 vCPU, 64 GB RAM, 100 GB NVMe - cache de produção para uma aplicação SaaS
- 8 vCPU, 128 GB RAM, 200 GB NVMe - armazenamento de sessões de alto desempenho
Contate sales@dcxv.com para uma recomendação de configuração.
Comandos de configuração rápida
# Instalar Redis 7 no Ubuntu 22.04
sudo apt update && sudo apt install -y redis-server
sudo systemctl start redis-server && sudo systemctl enable redis-server
redis-cli ping
# Configuracoes chave do redis.conf para 64 GB RAM
bind 127.0.0.1 10.0.0.5
maxmemory 51gb
maxmemory-policy allkeys-lru
appendonly yes
appendfsync everysec
Que modo de persistência escolher
Esta é a única decisão do Redis que é realmente sua, e é uma troca de durabilidade por débito, não uma configuração com uma resposta certa:
| Modo | Sobrevive a uma falha | Custo de escrita | Quando escolher |
|---|---|---|---|
| Sem persistência | Nada | Nenhum | Uma cache pura que consegue reconstruir da base |
| Snapshots RDB | Tudo até ao último snapshot | Um pico de fork em cada gravação | O arranque a quente importa, perder minutos não |
| AOF, everysec | Tudo menos o último segundo | 10-15% | Sessões, carrinhos, tudo cuja perda se note |
| AOF, always | Cada escrita | 50% ou mais | Quase nunca - use uma base de dados |
| RDB mais AOF | Tudo menos o último segundo, e arranca rápido | 10-15% | Um armazenamento primário, não uma cache |
O que a tabela não pode dizer por você: uma reescrita de AOF faz fork do processo, e o fork precisa de memória. É essa a verdadeira razão para deixar 20-25% da RAM livre em vez de a enchar de dados.
Desempenho esperado
Em uma instância de 4 vCPU / 64 GB RAM com Redis 7:
- Throughput GET (sem pipelining) - 150.000-200.000 ops/s
- Throughput SET - 120.000-160.000 ops/s
- Latência P99 (GET) - menos de 0,5 ms
Estas são expectativas para hardware desta classe, não medições do nosso próprio laboratório. Use-as como ponto de partida para o dimensionamento e meça a sua própria carga: os números reais dependem dos seus dados, das suas consultas e do seu tuning muito mais do que do fornecedor.
Conclusão
Redis em um servidor cloud da UE oferece desempenho de cache sub-milissegundo enquanto mantém os dados de sessão sob a jurisdição da UE.
