Como o Let’s Encrypt Construiu um Data Warehouse

Quando os scripts que geravam os dados de letsencrypt.org/stats quebraram mais uma vez, a equipe decidiu aposentar o pipeline em vez de consertar. O Let’s Encrypt emite de seis a dez milhões de certificados por dia, e o volume de logs cresce junto com essa emissão.

Por que os logs brutos deixaram de responder

Responder perguntas simples, como quantos certificados usam o perfil shortlived, exigia encontrar, parsear e extrair trechos relevantes de linhas de log. Consultar o banco por trás da API de emissão também não servia, porque ele é construído para transações e não para análise.

A equipe ainda usou um produto SaaS de busca em logs, mas a conta crescia bem mais rápido do que o desejado. A busca funcionava, porém as cargas analíticas de que precisavam ficavam fora do alcance da ferramenta.

Isso levou à busca de uma solução auto-hospedada, com armazenamento eficiente para dados estruturados além dos logs. A escolha foi o ClickHouse, pela combinação de armazenamento barato e agregação rápida sobre grandes volumes, além de ser open source.

O hardware e a folga de capacidade

O primeiro passo foi comprar hardware novo: três servidores PowerEdge R7715, cada um com processador AMD EPYC 9355P de 32 núcleos a 3,55GHz, 384 GB de RAM e 32 discos NVMe de 3,2TB. No total, isso dá aproximadamente 100TB de armazenamento bruto.

Com dados estruturados e 100 dias de logs já no banco, o uso estava em cerca de 14% da capacidade total. Os logs são a maior parte do consumo e também a base de tudo, já que cada tabela derivada sai deles.

Materialized views respondendo em milissegundos

O alvo principal são os registros de emissão: uma materialized view extrai esses registros dos logs para uma tabela própria, e outras views pré-agregam a partir dela. Uma delas conta a emissão por dia por perfil, então perguntas sobre os últimos 180 dias voltam em milissegundos.

A página pública de estatísticas foi reconstruída por esse caminho. Os scripts antigos levavam horas por dia para ler e processar dezenas de arquivos comprimidos e falhavam várias vezes por ano, enquanto o ClickHouse calcula as mesmas estatísticas em menos de 10 segundos.

Parte disso vem das funções nativas, que fazem agregações complexas sem sair do banco. No trecho compartilhado, uniq(arrayJoin(...)) conta domínios ativos em milhões de linhas, e a função uniq usa aproximações para continuar rápida em escala.

Backfill, importação S3 e ReplacingMergeTree

O maior obstáculo foi o backfill. O collector do OpenTelemetry lida bem com ingestão ao vivo, mas não com logs históricos: nenhuma configuração de throttling deu conta do volume, e uma parte grande dos arquivos era descartada em silêncio.

A saída foi usar o método nativo de importação via S3, com um gateway compatível com S3 na frente dos logs antigos. Ainda assim, foi preciso ajustar as regras de parsing para que os logs de backfill e os de streaming ficassem idênticos.

Duas lições ficaram: não passe importações históricas em massa por um collector de streaming e alinhe as regras de parsing antes de começar. Para as tabelas que passariam por backfill, a escolha foi o engine ReplacingMergeTree, que substitui linhas antigas quando o dado é reingerido.

Na minha experiência, essa decisão economiza retrabalho quando a agregação sai errada. Nas tabelas sem esse engine, a alternativa foi OPTIMIZE TABLE... DEDUPLICATE BY, caro, mas executado uma única vez.

Conclusão

O horizonte inclui a redução de 90 para 45 dias na validade dos certificados e a chegada de certificados pós-quânticos. Com cerca de 14% do armazenamento em uso, sobra espaço para extrair e pré-agregar mais dados.

Fonte: https://letsencrypt.org/2026/09/17/clickhouse.html
Publicado originalmente em Let’s Encrypt