Por que a Cloudflare coloca em cache na memória até itens impopulares
(blog.cloudflare.com)A Cloudflare publicou em seu blog sua experiência ao mudar a estratégia de cache e reduzir em até 25% a carga de escrita em SSDs. (em inglês) Ao contrário do senso comum, a Cloudflare alcançou esse objetivo adotando deliberadamente uma abordagem de colocar em cache na memória até itens com baixa frequência de acesso.
SSDs são meios de armazenamento vulneráveis a gravações. As células de memória flash usadas para armazenar dados em SSDs têm um número limitado de regravações, e apagar o que já foi gravado para escrever novamente não só leva relativamente muito tempo, como também acaba tornando até as operações de leitura mais lentas. Por isso, reduzir especialmente as operações de escrita é uma otimização importante em SSDs.
Como a Cloudflare usa muitos SSDs NVMe de alto desempenho em seus servidores, naturalmente ela se preocupou com esse ponto. A Cloudflare é uma empresa de CDN, e um CDN pode ser visto, em essência, como um grande cache de rede. O conteúdo armazenado nos SSDs dos servidores da Cloudflare também consiste, no fim das contas, em itens em cache, e as observações mostraram que muitos deles, depois de armazenados uma vez, nunca mais eram acessados (os chamados “one-hit wonders”). Portanto, o ideal seria não gravar esses itens no SSD. Ao testar uma forma de não gravar no SSD os itens acessados apenas uma vez, surgiu um resultado animador: a latência do SSD caiu quase 5%.
O problema era como aplicar essa ideia em escala real de serviço. Não colocar em cache no primeiro acesso e só passar a armazenar em cache a partir do segundo significa que o volume de acesso à origem dos dados dobra. Naturalmente, isso gera vários custos, o que inverteria a lógica da otimização. Por isso, a Cloudflare hierarquizou a gravação em cache em duas etapas. Primeiro, todos os itens são colocados em cache na memória, que funciona como um “cache de curto prazo”; depois, apenas os itens acessados várias vezes são “promovidos” e gravados no SSD, que funciona como “cache permanente”. Assim, itens com baixa frequência de acesso acabam sendo naturalmente expulsos do cache. No caso das leituras, não foi necessário tratamento especial, porque o sistema operacional já faz um bom cache do que é lido a partir do SSD.
Claro, a aplicação dessa ideia em um serviço real está sendo feita com cautela e de forma conservadora. Essa abordagem tende a consumir muita memória, o que pode competir com o cache já existente do sistema operacional, ou então, durante atualizações do processo do servidor com implantação sem interrupção, pode haver falta temporária de memória, prejudicando a qualidade do serviço. Por isso, a ideia está sendo introduzida gradualmente, sendo aplicada apenas em servidores recém-adicionados com memória suficiente.
Os resultados da adoção são positivos. Após aplicar a técnica ajustando a capacidade do cache, as gravações em SSD foram reduzidas de 20% até no máximo 25%, o que levou à redução da latência. No futuro, a Cloudflare pretende expandir essa técnica para mais servidores, melhorar o algoritmo de promoção para também introduzir “rebaixamento” e criar uma estrutura em camadas que considere não apenas SSDs, mas também HDDs.
Ao ver essa ideia, a primeira coisa que me veio à cabeça foi a técnica de coleta de lixo do Java. Afinal, a premissa básica da maioria das técnicas de garbage collection é justamente que [a maioria dos objetos é usada por pouquíssimo tempo], a chamada ‘weak generational hypothesis’. Talvez o princípio acima seja uma espécie de reaproveitamento adaptado dessa ideia.
3 comentários
Obrigado pelo ótimo texto.
Parece que o blog da Cloudflare sempre publica discretamente muitos artigos que valem a leitura.
Como é operado o blog técnico de uma boa empresa https://pt.news.hada.io/topic?id=1698
Acho que isso acontece porque, na Cloudflare, escrever no blog já se consolidou como parte da cultura interna.
Muito interessante, obrigado.
Uau.. até a tradução veio de uma vez haha. Obrigado por compartilhar um conteúdo tão bom.