Como a RTL Alemanha triplicou a retenção com a camada frozen do Elastic Observability, sem tempo de inatividade durante a transição

A RTL Alemanha reformulou seu data lake centralizado, ampliando a retenção padrão de 30 para 90 dias, reduzindo o número de nós quase pela metade e concluindo a migração sem nenhuma perda de dados.

A RTL Alemanha mantém um data lake da Elastic que atende a toda a empresa e, ao longo de quase uma década, tornou-se a plataforma padrão para logging, dados de aplicações e análise de dados empresarial em todos os departamentos. O limite de 100 TB de armazenamento no local restringia a retenção padrão a cerca de 30 dias. Isso impedia as equipes de analisar como os KPIs evoluíam ao longo dos meses e obrigava a armazenar dados de conformidade em buckets separados do S3, fora do data lake pesquisável. Após passar da assinatura Platina para a Empresarial e reformular a arquitetura com snapshots pesquisáveis e a camada frozen, a retenção padrão triplicou para 90 dias, a capacidade combinada aumentou para 235 TB no mesmo escopo de licenciamento, o número de nós físicos de hipervisor caiu de 18 para 10 e toda a transição foi concluída sem tempo de inatividade nem perda de dados.

O data lake da Elastic da RTL Alemanha reúne quase uma década de logging, dados de aplicações e análise de dados empresarial de toda a empresa, abrangendo suas operações de transmissão e mídia. Em 2024, o data lake estava chegando ao limite. Cerca de 100 TB de armazenamento no local restringiam a retenção padrão a aproximadamente 30 dias. No entanto, vários departamentos precisavam de meses de histórico para acompanhar a evolução dos KPIs ao longo do tempo. Além disso, dados de conformidade sujeitos a uma expectativa interna de retenção de seis meses eram armazenados fora da plataforma pesquisável, em buckets separados do S3. Após passar da assinatura Platina para a Empresarial e reformular a arquitetura com snapshots pesquisáveis e a camada frozen, a RTL Alemanha triplicou a retenção padrão para 90 dias, aumentou a capacidade combinada para 235 TB no mesmo escopo de licenciamento, reduziu o número de nós físicos de hipervisor de 18 para 10 e concluiu toda a transição sem tempo de inatividade nem perda de dados.

O que o limite de 30 dias impedia não era apenas um histórico mais longo, mas toda uma categoria de análises: comparações entre trimestres, ciclos sazonais de um ano para outro e linhas de base longas o suficiente para tornar uma tendência confiável. Para as equipes de BI da RTL Alemanha, o data lake continha os dados operacionais, mas sua retenção terminava muito antes do ponto em que começavam as análises de negócios. Com 90 dias de histórico como padrão e um ano inteiro para alguns índices, essas análises agora podem ser realizadas no mesmo data lake que as equipes operacionais monitoram em tempo real, usando os mesmos dados e sem precisar exportá-los para outro lugar.

Esse resultado foi possível graças a duas transformações distintas na evolução da plataforma: a consolidação no Elastic em 2023, após uma fusão corporativa que incorporou uma segunda plataforma de logging, e a atualização da assinatura, que reformulou a arquitetura de armazenamento para triplicar a retenção sem aumentar o escopo de licenciamento.

O ambiente Elastic da RTL Alemanha começou, há quase uma década, como uma infraestrutura compartilhada e, gradualmente, foi adotado por diferentes equipes até se tornar o data lake de toda a empresa. Dois acontecimentos moldaram a plataforma como ela existe hoje.

O primeiro foi a consolidação após a fusão, em 2023. A empresa recém-incorporada utilizava uma plataforma de logging diferente. Como o ambiente Elastic da RTL Alemanha já era executado no local e ainda tinha capacidade disponível, manter duas plataformas em paralelo não fazia sentido nem do ponto de vista financeiro nem operacional. A migração da ferramenta de logging legada levou cerca de cinco meses. O maior desafio foi a comunicação, seguida pela recriação dos dashboards e dos fluxos de trabalho de notificações desenvolvidos pela equipe ao longo dos anos, além da reformulação dos pipelines de ingestão.

O segundo acontecimento foi o limite de armazenamento e a forma de superá-lo. Depois de conhecer os snapshots pesquisáveis e a camada frozen durante o Elastic{ON} Munich, a equipe identificou uma arquitetura que resolvia diretamente o problema de armazenamento: manter o mesmo escopo de licenciamento, mover os dados de longo prazo para o armazenamento frozen baseado no S3 e utilizar a capacidade liberada na camada hot para ampliar a retenção. Antes de seguir em frente, a equipe desenvolveu uma prova de conceito focada na única questão realmente importante: qual seria o desempenho das consultas aos dados mais antigos armazenados na camada frozen? O resultado foi suficientemente rápido para tornar a decisão de redesenhar todo o cluster, migrando de uma arquitetura hot-and-cold para hot-and-frozen, uma escolha natural.

Antes da reformulação, a retenção padrão da RTL Alemanha era limitada a cerca de 30 dias pelos 100 TB de armazenamento no local. O data lake estava em boas condições, mas três fatores operacionais pressionavam esse limite ao mesmo tempo.

As necessidades de análise de dados empresarial iam além de 30 dias. Alguns departamentos precisavam acompanhar a evolução dos KPIs ao longo do tempo. Trinta dias de histórico não eram suficientes para realizar esse tipo de análise no data lake. As equipes tinham os dados necessários para as operações, mas não a janela histórica necessária para a análise.

Os dados de conformidade ficavam fora do data lake. Os dados de firewall, sujeitos a uma exigência interna de retenção de seis meses, eram armazenados em buckets separados do S3, e não na plataforma pesquisável. Os dados eram preservados, mas acessá-los durante uma investigação exigia extraí-los do armazenamento de objetos e carregá-los em alguma plataforma pesquisável, um processo que a equipe descreveu como bastante trabalhoso em qualquer situação real.

O hardware estava envelhecendo. O cluster era executado em servidores com aproximadamente cinco ou seis anos de uso, equipados com SSDs convencionais em vez de NVMe. A equipe sabia que a renovação do hardware seria inevitável, independentemente de uma mudança na arquitetura.

Assim, o tempo da equipe era consumido mantendo a plataforma existente funcionando dentro desse limite, em vez de ampliar seus recursos para atender melhor às necessidades do restante da empresa.

A equipe migrou da assinatura Platina para a Empresarial para habilitar os snapshots pesquisáveis e a camada frozen. Em seguida, reformulou a arquitetura de armazenamento, substituindo o modelo hot-and-cold por uma arquitetura hot-and-frozen com suporte do S3.

O fluxo de dados de ponta a ponta permaneceu praticamente o mesmo. Os nós do Logstash fazem a ingestão dos dados provenientes das diversas fontes da organização e os gravam no Elastic. Os índices hot ficam armazenados em SSDs NVMe locais no novo cluster. Os índices mais antigos são movidos para a camada frozen, onde permanecem armazenados no S3 e são carregados para um cache local sob demanda quando uma consulta é executada. Durante a transição, a busca entre clusters permitiu integrar os clusters antigo e novo, possibilitando que os usuários acessassem dados históricos sem precisar alternar entre ambientes.

O impacto no desempenho mostrou-se administrável. A primeira consulta a um índice armazenado na camada frozen leva cerca de 30 segundos, enquanto os dados relevantes são carregados para o cache dos nós frozen. Depois disso, as consultas aos mesmos dados passam a ter desempenho equivalente ao da camada hot.

• Velocidade de consulta da camada hot para dados atuais: 35 TB de SSDs NVMe em servidores mais recentes, executados sobre KVM.
• Retenção de meses a anos com baixo custo: 200 TB de armazenamento na camada frozen com suporte do S3, disponibilizados por meio de snapshots pesquisáveis.
• Capacidade triplicada com o mesmo escopo de licenciamento: 235 TB de capacidade combinada (35 TB na camada hot e 200 TB na camada frozen), sem aumento nas unidades de recursos licenciadas.
• Cluster menor e mais rápido: redução da infraestrutura de hipervisores de 18 para 10 nós físicos, utilizando hardware mais recente e com maior número de núcleos por nó.
• Transição por carga de trabalho, sem reestruturar os pipelines: o Logstash continuou responsável pela ingestão; durante a migração, o destino de cada fonte de dados foi redirecionado individualmente.
• Acesso contínuo aos dados históricos durante a migração: a busca entre clusters permaneceu ativa durante todo o processo, permitindo que os usuários continuassem consultando os índices históricos no cluster legado enquanto os novos dados eram enviados ao novo cluster.
• Desempenho da camada hot para dados antigos após a primeira consulta: cerca de 30 segundos para carregar o cache da camada frozen na consulta inicial; as consultas seguintes são executadas com desempenho equivalente ao da camada hot.

Em vez de realizar uma migração completa de uma só vez, a equipe implantou o novo cluster em paralelo ao antigo e migrou as cargas de trabalho gradualmente, começando pelas maiores fontes de dados. Como a ingestão é feita pelo Logstash, migrar uma carga de trabalho geralmente significava apenas alterar, no nó do Logstash, o destino do cluster antigo para o novo. A busca entre clusters manteve os usuários trabalhando no novo ambiente, com acesso de leitura aos dados que ainda permaneciam no cluster antigo, garantindo que o histórico continuasse disponível durante toda a migração.

A equipe também aproveitou a oportunidade para migrar os pipelines de ingestão personalizados para as integrações mantidas pela Elastic sempre que possível, o que, segundo eles, representa a melhor estratégia para o futuro.

O suporte da Elastic prorrogou o período de coexistência entre os clusters quando houve atraso na entrega do hardware, algo que a equipe destacou como essencial para manter o cronograma.

A prova de conceito (PoC) levou aproximadamente duas semanas. A maior parte do cronograma de seis a oito semanas da PoC foi consumida pela aquisição e pelo provisionamento do hardware, e não pelos testes. A migração completa levou cerca de três meses e foi concluída sem tempo de inatividade nem perda de dados.

Para os departamentos que utilizam o data lake diariamente, a mudança foi praticamente imperceptível. Durante o período temporário de coexistência dos clusters, os usuários precisaram apenas atualizar seus favoritos para a nova URL e, após a conclusão da migração, voltar a utilizar o domínio padrão. A busca entre clusters manteve os dados históricos acessíveis a partir do novo cluster durante todo o processo, de modo que ninguém precisou aprender um novo fluxo de trabalho nem consultar dois sistemas diferentes para localizar dados antigos.

No aspecto de conformidade, os dados que antes ficavam armazenados em buckets separados do S3 agora fazem parte do data lake pesquisável. A retenção de seis meses dos dados de firewall deixou de ser um problema operacional. Se um departamento precisar consultar todo o período de retenção, basta realizar a consulta da mesma forma que faria para qualquer outro índice do data lake.

O projeto também trouxe alguns aprendizados práticos.

Utilizar integrações gerenciadas sempre que possível. A RTL Alemanha acumulava anos de pipelines de ingestão personalizados e aproveitou a migração para substituir muitos deles pelas integrações mantidas pela Elastic. Segundo a equipe, essa abordagem representa um caminho mais sustentável para o futuro, e não apenas para este projeto.

Encarar uma migração como uma modernização completa. Substituir o hardware antigo, modernizar a arquitetura e revisar as integrações ao mesmo tempo aumentou significativamente o valor do projeto em comparação com executar cada uma dessas iniciativas separadamente.

Avaliar o modelo de hospedagem de forma realista. Executar a solução no local fazia sentido para a RTL Alemanha devido aos recursos já existentes e às considerações comerciais. Para organizações menores, sem capacidade interna para implantar e administrar um cluster, a equipe recomenda considerar a oferta SaaS da Elastic para evitar a sobrecarga operacional.

O maior desafio é o volume, não a complexidade. Redirecionar a ingestão de um cluster para outro foi uma tarefa relativamente simples. O verdadeiro esforço esteve na enorme quantidade de pipelines e no volume de dados que precisaram passar por essa mudança.

Dois objetivos orientam os próximos passos. O primeiro é reduzir o tempo necessário para que novos integrantes encontrem a visualização de dados correta, conectando o Elastic AI Agent aos modelos internos de linguagem de grande porte (LLMs) da RTL Alemanha. Isso ajudará quem está chegando à equipe a navegar pela plataforma e localizar a visualização de dados adequada com mais rapidez, um dos aspectos historicamente mais desafiadores do processo de integração.

O segundo objetivo é incorporar ainda mais logs de aplicações ao data lake, sem precisar ampliar o escopo de licenciamento. Esse é um programa interno que incorporará ainda mais logs de aplicações de todos os sistemas ao data lake. A nova arquitetura foi projetada deliberadamente para sustentar esse crescimento. Com 200 TB de capacidade baseada em S3 e a possibilidade de expandir esse armazenamento com facilidade, a equipe tem espaço para absorver esse volume sem precisar rever o escopo de licenciamento.

Talvez sua organização não opere hoje um data lake com quase uma década de existência cobrindo toda uma empresa de transmissão e mídia, mas os mesmos princípios se aplicam, seja você começando com alguns terabytes de dados de logs ou expandindo para uma arquitetura hot-and-frozen de 235 TB: o escopo de licenciamento não precisa crescer junto com a janela de retenção.

A RTL Alemanha faz parte do RTL Group, a maior empresa de transmissão e mídia da Alemanha, com operações em televisão, streaming e produção de conteúdo.

Veja como a camada frozen do Elastic Observability amplia a retenção sem aumentar os custos ou comece agora mesmo com um teste gratuito.

• Elastic Observability
• Monitoramento de log
• Elasticsearch
• Logstash
• Integrações de dados
• Observability Labs
• Documentação da Elastic

Tópicos: Elastic Observability, Elasticsearch, Logstash, camada frozen, snapshots pesquisáveis, armazenamento em camadas, busca entre clusters, análise de logs, data lake, retenção de dados de conformidade, mídia e transmissão, mídia e entretenimento