Apresentamos o Rump: sincronize duas bases de dados Redis em tempo real com dumps

É com grande entusiasmo que anunciamos o nosso primeiro projeto de código aberto: o Rump!

O Rump é uma pequena ferramenta focada em uma coisa simples: extrair dados em tempo real de um AWS ElastiCache do Redis cluster.

Nós enfrentamos este problema quando tentámos sincronizar os nossos containers Redis de teste com o nosso cluster de produção. Na Sticker Mule, usamos muito o Docker e o CoreOS, contando com um cluster ElastiCache para quando necessitamos do Redis em produção.

Ultimamente, queríamos tornar o nosso ambiente de teste o mais próximo possível do nosso ambiente de produção, e o Redis faz parte disso. Aqui está a jornada que levou ao Rump.

Não bloquear

Nós tínhamos um requisito simples: não bloquear a produção enquanto obtemos dados. O fato do Redis trabalhar num só fio é um aspeto importante a ser levado em conta.

Surpreendentemente descobrimos que o ElastiCache envia com alguns comandos desativados. Basicamente, todos os comandos que pode usar para transferir dados com segurança.

BGSAVE

A maneira padrão de forçar manualmente um backup de uma base de dados Redis é gerar um BGSAVE, e esperar que ele termine em segundo plano, uma operação sem bloqueio. Infelizmente, isto está desativado, a menos que use a implementação interna da AWS do recurso de snapshot.

SLAVEOF

Configurar réplicas é outra opção interessante que o Redis oferece, e teria sido a escolha perfeita para nós.

O plano era configurar temporariamente os containers Redis de teste como réplicas do nosso cluster de produção, obtendo dados ao vivo. Infelizmente, o SLAVEOF também está desativado, não há como adicionar réplicas a uma instância do ElastiCache.

Ferramentas existentes

Existem muitas ferramentas incríveis para o Redis que tentam simplificar a administração de servidores do Redis, dumping para JSON, etc.

O problema é que a maioria das ferramentas estáveis e mantidas, usam o comando KEYS para obter chaves e depois operar com elas. O comando KEYS tem uma complexidade O(N), bloqueando fortemente o Redis quando N é alto, até que todas as chaves sejam retornadas. Containers de sincronização são criados e destruídos frequentemente e nós temos um bom número de chaves, não queremos fazer um DoS no nosso próprio servidor.

Ficou claro que precisávamos de uma ferramenta simples para apenas fazer a sincronização. Começámos a testar com SCAN para obter as chaves, e DUMP/RESTORE ara obter/configurar os valores.

O SCAN é um comando O(1), seguro para executar num servidor de produção para obter todas as chaves, e por causa disto a sua implementação tem que ser diferente de KEYS. SCAN retorna um grupo de chaves atualmente presentes no DB, e um cursor para o próximo grupo.

O DUMP/RESTORE faz o trabalho de leitura/escrita de valores independente do tipo de chave.

Com isto em mente, vejamos o que o Rump pode fazer:

• Leitura progressiva e sem bloqueio de chaves via SCAN.

• Operações com valores independentes TYPE via DUMP/RESTORE.

• Operações SCAN e DUMP/RESTORE em pipeline.

• A leitura do servidor de origem e comunicação com o servidor de destino são simultâneas. O Rump não armazena todas as chaves antes de comunicar para o servidor de destino.

• Binary cross-platform, sem dependências.

• Mínimo footprint, filosofia UNIX, realiza uma única coisa com duas bandeiras.

Esperamos que a ferramenta seja útil para aqueles que estão a ter os mesmos problemas que nós, e muito, muito obrigado ao Redis por suportar um conjunto tão vasto de comandos!

P.S. Se isto é do seu interesse e está à procura de uma organização onde pessoas talentosas gostem de trabalhar, estamos a contratar.