Netflix EVCache: memcached replicado entre regiões

01 · CONTEXTO

O que é o EVCache

O EVCache é um cache distribuído em memória baseado em memcached. O nome é uma sigla: Ephemeral, porque o dado guardado dura pouco, conforme o TTL; Volatile, porque o dado pode desaparecer a qualquer momento, por exemplo por remoção; e Cache, um armazenamento chave-valor em memória.

Segundo o anúncio do cliente EVCache, as vantagens de um cache distribuído são resposta mais rápida do que buscar na fonte ou no banco, menos carga e menos servidores, porque o cache atende a maior parte dos pedidos, e maior vazão dos serviços que ele protege.

O artigo da InfoQ descreve a escala da implantação da Netflix: quatro regiões e 200 clusters Memcached, cada um dedicado a uma aplicação ou a um grupo de aplicações. A infraestrutura soma 22.000 instâncias de servidor e lida com 30 milhões de eventos de replicação globalmente e 400 milhões de operações por segundo no total. Os dados chegam a cerca de 2 trilhões de itens e 14,3 petabytes.

02 · DENTRO DE UMA REGIÃO

Um cluster por zona de disponibilidade

No modelo descrito no anúncio do cliente, um EVCache App é um agrupamento lógico de instâncias memcached, e o cliente EVCache gerencia as operações entre a aplicação Java e esse App. Os dados são particionados entre os nós por hash consistente, o algoritmo Ketama. Quando há várias zonas, cada cluster fica numa zona de disponibilidade, e o cliente obtém no Eureka a lista de servidores para montar os clusters pela zona de cada um.

1. O cliente EVCache obtém no Eureka a lista de servidores e monta um cluster por zona de disponibilidade.

2. Nas leituras, o cliente consulta sempre a zona local, o que melhora a latência.

3. Nas escritas, o cliente grava em todas as zonas. Com o dado replicado, a disponibilidade aumenta.

4. Se um dado se perde no cluster local por falha de instância ou remoção, ele pode ser buscado no outro cluster, e em geral isso é bem mais rápido do que buscar na fonte.

5. Se o cluster local perde instâncias, ele pode ser posto em modo write only e a leitura vai toda para a outra zona.

As leituras de um cliente vão sempre para a zona local, e as escritas vão para as zonas. Ler localmente melhora a latência e escrever em todas aumenta a disponibilidade. Quando a leitura precisa ir a outra zona, o anúncio diz que a latência sobe, mas a confiabilidade é maior. No caso de perda de instâncias, direcionar a leitura à outra zona evita impacto na latência e na taxa de acerto.

03 · POR QUE REPLICAR ENTRE REGIÕES

Evitar recomputar quando a região muda

Segundo o artigo da InfoQ, numa troca de região (failover) ter os dados do cache já disponíveis na região de destino garante serviço sem interrupção e com latência mínima. O motivo de custo é específico do caso da Netflix: recomputar um dado depois de um cache miss pode consumir muita CPU, e construir recomendações personalizadas exige recursos computacionais significativos, com algoritmos de aprendizado de máquina como peça central. Replicar entre regiões reduz esse recálculo.

O artigo afirma que o EVCache foi projetado para resistir a falhas em vários níveis (instância, zona de disponibilidade e região). O cliente é ciente da topologia: conhece a localização física e lógica dos servidores.

04 · O SERVIÇO DE REPLICAÇÃO

Do cliente ao cache da outra região

O artigo descreve a replicação como um fluxo em etapas. A origem é a escrita: a aplicação usa o cliente EVCache para enviar mutações, como set, add, delete e touch, aos servidores locais.

1. A aplicação envia a mutação ao cliente EVCache, que a aplica nos servidores locais.

2. O EVCache também envia ao Kafka um evento assíncrono só com metadados: chave, TTL e timestamp de criação, sem o valor.

3. O reader lê as mensagens do Kafka e faz uma leitura no EVCache local. Ele pode filtrar mensagens indesejadas, como as de TTL muito curto.

4. O reader faz uma chamada entre regiões ao writer da região de destino, levando metadados e o valor.

5. O writer grava o par chave-valor no EVCache de destino. Se essa região passar a atender o tráfego, o dado já está disponível para leitura.

6. Se alguma etapa falha, a mutação que falhou é capturada e enviada a uma fila SQS, para ser tentada de novo mais tarde.

Um único cluster Kafka atende a replicação de mais de 200 clusters EVCache. Cada cluster EVCache é representado por um tópico, particionado conforme o volume de eventos. No serviço reader existem grupos de consumidores distintos, e cada grupo tem como alvo uma região diferente.

1. Um único cluster Kafka concentra a replicação. Cada cluster EVCache é um tópico, dividido em partições conforme o volume de eventos.

2. Os readers se organizam em grupos de consumidores. Cada grupo é um conjunto de nós, e cada nó lê várias partições, o que permite processar em paralelo.

3. Cada grupo de consumidores tem como alvo uma região diferente, e assim o dado é replicado para várias regiões.

Antes de cruzar a região, o reader converte a chave, os metadados e o valor para JSON, e o envio ao writer é feito por REST.

Falhas em qualquer etapa não perdem a mutação: ela vai para uma fila SQS, e o serviço de replicação monitora a fila e reprocessa o que falhou pelo mesmo fluxo. Segundo o artigo, esse mecanismo de nova tentativa garante que todas as mutações sejam eventualmente processadas.

05 · CLIENTE OU SERVIDOR

Quem inicia a replicação

A Netflix escolheu a replicação iniciada pelo cliente, principalmente porque o cliente EVCache é ciente da topologia. Ele conhece a localização dos nós memcached, sabe quais estão disponíveis, entende como os dados se distribuem entre eles e pode decidir com base na latência de rede.

06 · EFICIÊNCIA E LIMITES

Menos bytes e menos intermediários

O primeiro ajuste foi agrupar mensagens em lotes e comprimir o lote antes do envio do reader ao writer. O artigo relata uma redução de 35% no uso de banda de rede.

O segundo ajuste foi retirar os Network Load Balancers (NLBs) que gerenciavam a comunicação entre reader e writer, porque esse arranjo gerava custo adicional de transferência de rede. Em vez deles, usa-se o Eureka DNS: o reader obtém os endereços IP dos writers e faz o roteamento por conta própria. O artigo relata queda de 50% no custo de transferência, com latências previsíveis. O uso diário de NLB, em torno de 45 GB/s somando as regiões, caiu para menos de 100 MB/s, e os NLBs ainda ficam na arquitetura como alternativa de reserva.

1. No desenho inicial, um NLB gerenciava a comunicação entre reader e writer, e esse arranjo gerava custo adicional de transferência de rede.

2. Depois, o reader passou a obter os endereços dos writers por Eureka DNS e a fazer o roteamento por conta própria.

3. Os NLBs seguem na arquitetura apenas como alternativa de reserva.