A jornada da Elastic para desenvolver o Elastic Cloud Serverless

Ao longo dos anos, as expectativas dos clientes mudaram drasticamente. Os usuários não querem mais se preocupar com as complexidades do gerenciamento de infraestrutura, como dimensionamento, monitoramento e redimensionamento. Em vez disso, buscam uma experiência integrada, na qual possam se concentrar exclusivamente em cargas de trabalho. Essa demanda crescente nos impulsionou a desenvolver uma solução que reduz a sobrecarga operacional, oferece uma experiência SaaS sem atritos e introduz um modelo de precificação por uso. Ao eliminar a necessidade de os clientes provisionarem e manterem recursos manualmente, criamos uma plataforma que redimensiona de forma dinâmica com base na demanda, otimizando a eficiência.

O Elastic Cloud Serverless está se expandindo rapidamente para atender à demanda dos clientes, tendo atingido disponibilidade geral (DG) na AWS em dezembro de 2024, no GCP em abril de 2025 e no Azure em junho de 2025. Desde então, expandimos para quatro regiões na AWS, três regiões no GCP e uma região no Azure, com regiões adicionais planejadas em todos os três provedores de serviços de nuvem (CSPs).

O Elastic Cloud Hosted (ECH) foi inicialmente desenvolvido como um sistema com estado, utilizando armazenamento local baseado em NVMe ou discos gerenciados para assegurar a durabilidade dos dados. À medida que o Elastic Cloud se expandiu globalmente, identificamos uma oportunidade de aperfeiçoar nossa arquitetura para melhor apoiar a eficiência operacional e o crescimento no longo prazo. Nossa abordagem hospedada para gerenciar o estado persistente em ambientes distribuídos mostrou-se eficaz, mas introduziu uma complexidade operacional adicional em relação a substituições de nodes, manutenção, garantia de redundância em zonas de disponibilidade e redimensionamento de cargas de trabalho com uso intensivo de computação, como indexação e busca.

Decidimos modernizar a arquitetura do nosso sistema adotando uma abordagem sem estado. A mudança chave foi descarregar o armazenamento persistente dos nós de computação para os armazenamentos de objetos nativos da nuvem. Isso trouxe múltiplos benefícios: redução da infraestrutura necessária para indexação, habilitação da separação entre busca e índice, eliminação da necessidade de replicação e aprimoramento da durabilidade dos dados ao aproveitar os mecanismos de redundância integrados dos CSPs.

Uma das principais mudanças em nossa arquitetura foi usar o armazenamento de objetos nativo da nuvem como o principal repositório de dados. O ECH foi projetado para armazenar dados em SSDs NVMe locais ou em discos SSD gerenciados. No entanto, à medida que os volumes de dados aumentavam, também aumentavam os desafios de redimensionamento do armazenamento de forma eficiente. Em seguida, introduzimos instantâneos pesquisáveis no ECH, o que nos permitiu pesquisar dados diretamente de armazenamentos de objetos, reduzindo significativamente os custos de armazenamento, mas precisávamos ir além. 

Um dos principais desafios foi determinar se os armazenamentos de objetos poderiam lidar com cargas de trabalho de alta ingestão enquanto mantinham o nível de desempenho que os usuários do Elasticsearch esperam. Por meio de testes e implementações rigorosas, validamos que o armazenamento de objetos pode atender às demandas de indexação em larga escala. A mudança para o armazenamento de objetos eliminou a necessidade de replicação de indexação, reduziu os requisitos de infraestrutura e proporcionou maior durabilidade ao replicar dados entre zonas de disponibilidade, garantindo alta disponibilidade e resiliência.

O diagrama abaixo ilustra a nova arquitetura “sem estado” em comparação com a arquitetura “ECH” existente:

O ECH usa um orquestrador de contêineres desenvolvido internamente que também alimenta o Elastic Cloud Enterprise (ECE). Como o desenvolvimento do ECE começou antes mesmo do Kubernetes (K8s) existir, tínhamos a opção de estender o ECE para dar suporte à infraestrutura sem servidor ou usar o K8s para essa infraestrutura. Com a rápida adoção do K8s em todo o setor e o crescente ecossistema em torno dele, decidimos adotar serviços gerenciados do Kubernetes em todos os CSPs no Elastic Cloud Serverless, onde isso se alinha aos nossos objetivos operacionais e de redimensionamento.

Ao adotar o Kubernetes, reduzimos a complexidade operacional, padronizamos as APIs para melhorar a escalabilidade e posicionamos o Elastic Cloud para inovação a longo prazo. O Kubernetes nos permitiu focar em recursos de maior valor em vez de reinventar a orquestração de contêineres.

Durante a transição para o Kubernetes, enfrentamos a decisão de gerenciar os clusters do Kubernetes nós mesmos ou usar os serviços gerenciados do Kubernetes fornecidos por CSPs. As implementações do Kubernetes variam muito entre os CSPs, mas para acelerar nossos cronogramas de implantação e reduzir a sobrecarga operacional, optamos por serviços do Kubernetes gerenciados pelo CSP na AWS, no GCP e no Azure. Essa abordagem nos permitiu focar na construção de aplicativos e na adoção das melhores práticas do setor, em vez de lidar com as complexidades do gerenciamento de clusters do Kubernetes. 

Nossos principais requisitos incluíam a capacidade de provisionar e gerenciar clusters do Kubernetes de forma consistente em vários CSPs; uma API independente de nuvem para gerenciar computação, armazenamento e bancos de dados; e operações simplificadas que eram econômicas. Além disso, ao escolher o Kubernetes gerenciado pelo CSP, pudemos contribuir com upstream para projetos de código aberto como o Crossplane, aprimorando o ecossistema geral do Kubernetes e, ao mesmo tempo, nos beneficiando dos recursos em evolução.

Operar o Kubernetes em escala, com dezenas de milhares de pods por cluster do Kubernetes, exige uma solução de rede independente de nuvem, que ofereça alto desempenho com latência mínima e suporte a políticas de segurança avançadas. Selecionamos o Cilium, uma solução moderna baseada em eBPF, para atender a esses requisitos. Inicialmente, nosso objetivo era implementar uma solução Cilium uniforme e autogerenciada em todos os CSPs. No entanto, diferenças nas implementações em nuvem nos levaram a adotar uma abordagem híbrida, utilizando soluções Cilium nativas de CSPs, quando disponíveis, e mantendo uma implantação autogerenciada na AWS. Essa flexibilidade garantiu que pudéssemos atender às nossas necessidades de desempenho e segurança sem complexidade desnecessária.

Para o tráfego de entrada, optamos por adaptar e continuar usando nosso proxy existente e comprovado do ECH. A avaliação não era apenas se poderíamos substituir o proxy por uma solução pronta para uso, mas se deveríamos.

Embora um proxy reverso padrão ofereça funcionalidade básica, ele não teria os recursos diferenciados que o proxy ECH já gerencia. Precisaríamos desenvolver extensões para filtros de tráfego de entrada, suporte para AWS PrivateLink e Google Cloud Private Service Connect, e terminação TLS em conformidade com FIPS. O proxy existente também já passou por todas as auditorias de conformidade relevantes e testes de penetração.

Iniciar com uma nova solução teria exigido um esforço significativo sem oferecer valor adicional ao cliente. Adaptar nosso proxy para Kubernetes envolveu principalmente atualizar como distribuímos a conscientização sobre os endpoints de serviço, mantendo intacta a funcionalidade núcleo e bem testada. Essa abordagem oferece diversas vantagens:

• Garante que o comportamento visível ao cliente permaneça consistente entre o ECH e o Kubernetes.

• As equipes podem trabalhar de forma mais eficiente com uma base de código familiar e bem compreendida, especialmente ao implementar novos recursos que exigem scripts ou extensões em uma solução pronta para uso.

• Podemos desenvolver tanto nossas plataformas ECH quanto Kubernetes com uma única base de código; assim, melhorias em um ambiente se traduzem em melhorias no outro.

• As equipes de suporte podem aproveitar o conhecimento existente, reduzindo a curva de aprendizado para a nova plataforma.

Após escolher o Kubernetes para o Elastic Cloud Serverless, selecionamos o Crossplane como ferramenta de gerenciamento de infraestrutura. O Crossplane é um projeto de código aberto que estende a API do Kubernetes para permitir o provisionamento e o gerenciamento de infraestrutura e serviços em nuvem usando ferramentas e práticas nativas do Kubernetes. Ele permite que os usuários provisionem, gerenciem e orquestrem recursos de nuvem em vários CSPs a partir de um cluster Kubernetes. Isso é possível por meio do uso de Definições de Recursos Personalizadas (CRDs) para definir recursos e controladores de nuvem e reconciliar o estado desejado especificado nos manifestos do Kubernetes com o estado real dos recursos de nuvem em vários CSPs. Ao utilizar os mecanismos declarativos de configuração e controle do Kubernetes, ele fornece uma maneira consistente e escalável de gerenciar a infraestrutura como código.

O Crossplane possibilita o gerenciamento e a provisão de infraestrutura utilizando as mesmas ferramentas e métodos usados para a implantação de serviços. Isso envolve aproveitar recursos do Kubernetes, uma arquitetura GitOps consistente e ferramentas de observabilidade unificadas. Além disso, desenvolvedores podem criar um ambiente de desenvolvimento completo baseado em Kubernetes, incluindo a infraestrutura periférica, que reflita os ambientes de produção. Isso é alcançado simplesmente criando um recurso do Kubernetes, já que ambos os ambientes são gerados a partir do mesmo código subjacente.

Uma suposição comum é que a capacidade da nuvem é infinita, mas, na realidade, os CSPs impõem restrições que podem levar a erros de "capacidade insuficiente". Se um tipo de instância estiver indisponível, precisamos tentar novamente ou alternar continuamente para um tipo de instância alternativo.

Para mitigar isso no Elastic Cloud Serverless, implementamos pools de capacidade baseados em prioridade, permitindo que as cargas de trabalho migrem para usar novos/outros pools de capacidade quando necessário. Além disso, investimos em planejamento proativo de capacidade, reservando recursos de computação antes de picos de demanda. Esses mecanismos garantem alta disponibilidade e, ao mesmo tempo, otimizam a utilização de recursos.

As atualizações de cluster do Kubernetes são demoradas. Para agilizar esse processo, utilizamos um processo de ponta a ponta totalmente automatizado, exigindo intervenção manual apenas para problemas que não podem ser resolvidos automaticamente. Após a conclusão dos testes internos e a aprovação de uma nova versão do Kubernetes, configuramos a versão centralizada. Um sistema automatizado inicia a atualização do plano de controle para cada cluster, com simultaneidade controlada e uma ordem específica. Depois, controladores Kubernetes personalizados realizam implantações azuis e verdes para atualizar os pools de nós. Apesar de os pods dos clientes migrarem para diferentes nós do K8s durante esse processo, a disponibilidade e o desempenho do projeto permanecem inalterados.

Usamos uma arquitetura baseada em células, que nos permite fornecer serviços escaláveis e resilientes. Cada cluster Kubernetes, juntamente com a infraestrutura periférica, é implantado em uma conta CSP separada para permitir o redimensionamento adequado sem ser afetado pelos limites do CSP e para fornecer segurança e isolamento máximos. Cargas de trabalho individuais, cada uma em uma célula, gerenciam aspectos específicos do sistema. Essas células operam de forma independente, permitindo redimensionamento e gerenciamento isolados. Esse design modular minimiza o alcance de falhas e facilita o redimensionamento direcionado, evitando impactos em todo o sistema. Para minimizar ainda mais o impacto potencial de problemas, empregamos implantações canárias tanto para nossos aplicativos quanto para a infraestrutura subjacente.

Para proporcionar uma experiência realmente sem servidor, precisávamos de um mecanismo inteligente de redimensionamento automático que ajustasse dinamicamente os recursos conforme as exigências da carga de trabalho. Nossa jornada começou com o redimensionamento horizontal básico, mas logo percebemos que serviços diferentes tinham necessidades de redimensionamento exclusivas. Alguns necessitavam de recursos computacionais adicionais, enquanto outros demandavam uma maior alocação de memória.

Aprimoramos nossa abordagem ao criar controladores personalizados de redimensionamento automático que analisam métricas específicas de carga de trabalho em tempo real, permitindo um redimensionamento dinâmico que é tanto responsivo quanto eficiente em termos de recursos. Como resultado, podemos redimensionar perfeitamente as operações de indexação e de busca no Elasticsearch sem superprovisão. Essa estratégia permite o uso de redimensionamento automático multidimensional de pods, permitindo que as cargas de trabalho sejam redimensionadas horizontal e verticalmente com base na CPU, memória e métricas personalizadas geradas pela carga de trabalho.

Para nossas cargas de trabalho do Elasticsearch, usamos uma API específica para serverless do Elasticsearch que retorna certas métricas chave sobre o cluster. Veja como funciona: os recomendadores sugerem os recursos de computação necessários (réplicas, memória e CPU) e armazenamento para um determinado nível. Essas recomendações são então convertidas por mapeadores em configurações concretas de computação e armazenamento aplicáveis a contêineres. Para evitar flutuações rápidas de redimensionamento, os estabilizadores filtram essas recomendações. Os limitadores então entram em ação, impondo tanto restrições mínimas quanto máximas de recursos. A saída do limitador é utilizada para ajustar a implantação do Kubernetes após considerar algumas políticas de restrição opcionais.

Um princípio fundamental da computação serverless é alinhar os custos com o uso real. Queríamos um modelo de preços que fosse simples, flexível e transparente. Depois de avaliar várias abordagens, projetamos um modelo que equilibra diferentes cargas de trabalho em nossas soluções núcleo:

• Observability e Security: cobrados com base nos dados ingeridos e retidos, com preços escalonados

• Elasticsearch (Search): preços baseados em unidades de computação virtuais, incluindo ingestão, busca, machine learning e retenção de dados

Essa abordagem oferece aos clientes preços de pagamento conforme o uso, proporcionando maior flexibilidade e previsibilidade de custos. 

Para implementar esse modelo de precificação (que passou por muitas iterações durante a fase de desenvolvimento), sabíamos que precisávamos de uma arquitetura com escalabilidade e flexibilidade. Por fim, construímos um pipeline que suporta um modelo de propriedade distribuída, com diferentes equipes responsáveis por diferentes componentes do processo de ponta a ponta. Abaixo, descrevemos os dois principais segmentos desse pipeline: coleta de uso medido por meio do pipeline de uso, e cálculos de cobrança por meio do pipeline de cobrança.

Componentes voltados para o usuário, como Elasticsearch e Kibana, enviam dados de uso medidos para o serviço de api de utilização, executado em cada cluster de carga de trabalho. Esse serviço realiza um enriquecimento nos dados e os coloca em uma fila. O serviço de envio de utilização, então, extrai esses dados da fila e os encaminha para o armazenamento de objetos. Essa arquitetura desacoplada é necessária para tornar o pipeline resiliente ao enviar dados entre regiões e CSPs, pois priorizamos a entrega em vez da latência. Assim que os dados chegam ao armazenamento de objetos, eles ficam disponíveis para outros processos em modo somente leitura para transformações ou agregações adicionais (por exemplo, para faturamento ou análise).

Construir uma plataforma de infraestrutura que ofereça funcionalidades semelhantes em vários CSPs é um desafio complexo. Equilibrar confiabilidade, escalabilidade e eficiência de custo requer iteração contínua e concessões. As implementações do Kubernetes variam significativamente entre os provedores de serviços em nuvem, e garantir uma experiência consistente entre eles requer testes e personalização extensivos.

Além disso, adotar uma arquitetura serverless não é apenas uma transformação técnica, mas também uma mudança cultural. É necessário passar da solução de problemas reativa para a otimização proativa do sistema e priorizar a automação para minimizar a carga operacional. Ao longo de nossa jornada, aprendemos que construir uma plataforma serverless bem-sucedida envolve tanto decisões arquitetônicas quanto fomentar uma mentalidade que abrace a inovação e o aprimoramento contínuos.

O sucesso no mundo serverless depende de oferecer uma experiência excepcional ao cliente, otimizar proativamente as operações e equilibrar continuamente confiabilidade, escalabilidade e eficiência de custos. Olhando para o futuro, nosso foco continua em desenvolver novos recursos para nossos clientes no Elastic Cloud Serverless, tornando o serverless o melhor lugar para executar o Elasticsearch para todos.

O futuro da busca, segurança e observabilidade está aqui sem comprometer a velocidade, a escala ou o custo. Experimente o Elastic Cloud Serverless e o Search AI Lake para desbloquear novas oportunidades com seus dados. Saiba mais sobre as possibilidades do serverless ou comece sua avaliação gratuita agora mesmo.

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.

Nesta postagem do blog, podemos ter usado ou feito referência a ferramentas de IA generativa de terceiros, que são de propriedade e operadas por seus respectivos proprietários. A Elastic não tem nenhum controle sobre as ferramentas de terceiros e não temos nenhuma responsabilidade ou obrigação por seu conteúdo, operação ou uso, nem por qualquer perda ou dano que possa surgir do uso de tais ferramentas. Tenha cuidado ao usar ferramentas de IA com informações pessoais, sensíveis ou confidenciais. Os dados que você enviar poderão ser usados para treinamento de IA ou outros fins. Não há garantia de que as informações fornecidas serão mantidas seguras ou confidenciais. Você deve se familiarizar com as práticas de privacidade e os termos de uso de qualquer ferramenta de IA generativa antes de usá-la. 

Elastic, Elasticsearch e marcas associadas são marcas comerciais, logotipos ou marcas registradas da Elasticsearch N.V. nos Estados Unidos e em outros países. Todos os outros nomes de empresas e produtos são marcas comerciais, logotipos ou marcas registradas de seus respectivos proprietários.