Saltar para o conteúdo

Blogue


Abordagem API-First para a criação de tópicos Kafka

5 de dezembro de 2023

|
Varun Chakravarthy

Varun Chakravarthy

Basar Onat

Basar Onat

Semente Zeng

Semente Zeng

Luke Christopherson

Luke Christopherson

DoorDash's Engineering teams revamped Kafka Topic creation by replacing a Terraform/Atlantis based approach with an in-house API, Infra Service. This has reduced real-time pipeline onboarding time by 95% and saved countless developer hours.

DoorDash's Real-Time Streaming Platform, or RTSP, team is under the Data Platform organization and manages over 2,500 Kafka Topics across five clusters. Kafka is the pub-sub layer of the Iguazu pipeline, which provides real-time event delivery at DoorDash. Almost six billion messages are processed each day at an average rate of four million messages per minute, which sometimes peaks at double that rate. 

The RTSP team constantly looks for ways to speed up Iguazu onboarding. The slowest step in that process was provisioning Kafka Topics, which involved on-call engineer approval and was prone to failure, further increasing the on-call load. To improve this, RTSP partnered with DoorDash's storage and cloud teams to automate Kafka resources creation by integrating with an internal infrastructure resource creation service.

Terminologia-chave

Aqui estão as definições e as ligações para documentação adicional sobre as ferramentas que utilizámos. Abordamos a forma como estas ferramentas são utilizadas e os seus prós e contras no artigo principal. 

  • Terraform: Plataforma de infraestrutura como código (IaC). Utiliza a linguagem de configuração (HCL) exclusiva da HashiCorp para configurar recursos de infraestrutura. Para aprovisionar a infraestrutura, crie um plano de execução, designado por plano Terraform, e, em seguida, execute o plano através do Terraform Apply.
  • Atlantis: Uma ferramenta de automação do Terraform. Executa o Terraform Plan and Apply. Mescla solicitações pull do Terraform em execuções bem-sucedidas.
  • Pulumi: Semelhante ao Terraform, esta é também uma plataforma IaC, mas sem HCL. Em vez disso, o Pulumi aproveita as linguagens de programação existentes para gerir a infraestrutura.
  • Prometheus: Uma base de dados de monitorização e de séries temporais. Concebida para monitorizar métricas de aplicações e infra-estruturas. Expõe a linguagem de consulta PromQL para escrever alertas sobre métricas.
  • Chronosphere: Plataforma de observabilidade nativa da nuvem. Construída sobre a Prometheus. 
  • Cadence Workflow: Motor de fluxo de trabalho tolerante a falhas e com estado, capaz de executar gráficos acíclicos direccionados (DAGs).

Compreender a arquitetura herdada

As shown in Figure 1 below, DoorDash's legacy approach to Topic creation involved several steps within a Cadence workflow.

  1. O serviço Orchestrator desencadeia uma chamada de API para o repositório do GitHub para os tópicos do Kafka, criando um pedido de extração, ou PR, para um novo tópico e uma entrada correspondente na lista de controlo de acesso (ACL).
  2. O serviço Orchestrator acciona o Atlantis para executar o Terraform Plan no tópico. 
  3. O plantão recebe uma notificação automática por correio eletrónico sobre o PR. 
  4. O serviço do Orchestrator sonda o estado do BP para verificar a aprovação do plantão. 
  5. Uma vez aprovado e num estado fundível, o Atlantis Apply é acionado contra o PR. 
  6. Os serviços do Orchestrator monitorizam a fusão bem sucedida do BP. Em caso de falha, o BP é eliminado e o processo recomeça a partir do Passo 1.
Figura 1: Arquitetura herdada para a criação de tópicos Kafka

Infelizmente, o fluxo de trabalho de criação de tópicos falha frequentemente por uma de várias razões:

  • Conflitos de mesclagem do GitHub na criação de PR quando vários PRs são cortados do mesmo commit
  • Derivação do estado do Terraform em relação ao estado do Kafka
  • Por vezes, o Atlantis atingia o tempo limite em clusters com centenas de tópicos e era concluído num período de tempo não determinístico 
  • Desvio do estado do Atlantis em relação ao estado do Terraform. O Terraform é aplicado mas o Atlantis não fundiu o PR
  • Uma vez que a revisão e a aprovação dos BP são demoradas, os funcionários de serviço por vezes não recebiam a notificação por correio eletrónico, o que causava interrupções. Nota: O volume de novos PRs criados por tópicos pode exceder 20 por hora durante o lançamento de produtos.

Além disso, é difícil auditar programaticamente os clusters Kafka e efetuar operações de aumento de escala, como a adição de partições ou a migração para clusters dedicados, sem intervenção manual. 

Desenvolvimento de uma nova arquitetura

Inicialmente, considerámos uma série de abordagens potenciais, incluindo:

  • Criação de um estado durável na memória para acompanhar o progresso refinado e para sincronizar entre fluxos de trabalho. O estado seria recuperado do disco na reinicialização do Orchestrator.
  • Utilizar a base de dados de processamento de transacções em linha (OLTP) para manter o estado acima referido.
  • Escrever um fornecedor Terraform personalizado
  • Aumentar as tentativas de fluxo de trabalho. 

Todas as quatro soluções teriam sido soluções de fita adesiva incapazes de resolver completamente os problemas subjacentes: Sincronização de estado no Terraform como hospedado no Git, Atlantis, fluxo de trabalho Cadence e Kafka. Embora os dois primeiros pudessem ter resolvido alguns dos problemas mencionados, eles correriam o risco de complicar ainda mais o gerenciamento de estado ao introduzir novos estados para manter a sincronização. Como fonte autorizada da verdade, o Kafka deve ser consistente com qualquer solução que escolhermos. 

Capturar uma pequena vitória: Um caso de utilização para os superutilizadores do Kafka

While exploring these solutions, we identified that merge conflicts were only occurring in the ACL files for Iguazu users. Each consumer and publisher in the Iguazu pipeline has a separate Kafka user account. Upon each Topic creation, an Iguazu user's ACL file was updated with an ACL entry for that topic. Eventually, the ACL files grew to have hundreds of permissions, significantly slowing Atlantis applications.

Our "eureka" moment was when we realized that this was a perfect use-case for super-user accounts. Permissions-related pitfalls meant that we usually shied away from setting up super users. But if each Iguazu user - REST proxy or upstream and downstream Flink jobs needed access to every single topic in a cluster, it would be ideal to give these users full read or read-write access as needed, eliminating the ACL file and its related issues. Additionally, the existing workflow could be further improved, as we will outline shortly.

Mantenha-se informado com as actualizações semanais

Subscreva o nosso blogue de Engenharia para receber actualizações regulares sobre todos os projectos mais interessantes em que a nossa equipa está a trabalhar

Em busca da grande vitória: Criação simplificada de recursos Kafka 

Infra Service is an internal platform that provides an API to perform CRUD operations on infrastructure components. It is built and maintained by the Infrastructure organization at DoorDash. It replaces the traditional approach of using infrastructure-as-code and GitOps to provision infrastructure. Infra Service replicates the important features provided by Git and GitHub, including version control and change reviews. It's also plugin-driven, allowing teams to add support for resources that they would like to manage programmatically. Most of the work required to implement an Infra Service plugin involves writing an underlying Pulumi program.

O Infra Service utiliza o Pulumi para lidar com o aprovisionamento da infraestrutura sob o capô. O Pulumi é uma ferramenta de infraestrutura como código semelhante ao Terraform, mas, ao contrário do Terraform, permite a utilização de linguagens de programação gerais para definir a infraestrutura. Ele tem suporte robusto para testes e um extenso catálogo de provedores. O Infra Service trata da invocação programática do Pulumi quando é solicitada uma alteração e da propagação de quaisquer resultados resultantes da execução do Pulumi para o utilizador final.

To create Kafka and database resources, we've developed a component within Infra Service called Storage Self-Serve Platform. This is shown below in Figure 2.

Figura 2: Nova arquitetura simplificada para a criação de tópicos Kafka

Na Figura 2, ainda envolto num fluxo de trabalho Cadence, o aprovisionamento de tópicos é reduzido a um processo de duas etapas:

  1. Orchestrator service Minions fires a gRPC request to the Infra Service gateway to provision the Kafka Topic. Minions receive a synchronous response on whether the topic create request is persisted. At this point, the topic creation might not have been completed. From Minions' perspective, everything behind the Infra Service Gateway is a black box that handles dedupe, validation, and retries.
  2. Because a Topic is considered created when it shows up with non-zero disk usage,  Minions continuously polls the Prometheus metrics platform Chronosphere for that state. All Topics, even those without any messages, include some metadata that is backed up to disk. We use Chronosphere for two reasons: First, it independently corroborates the state of the Infra Service black box and, second, DoorDash runs Chronosphere at at four nines (99.99%) availability. This means that Chronosphere outages essentially don't exist. If Kafka doesn't report topic metrics for a few minutes, it is improbable that this will continue any longer -- unless there are bigger issues with Kafka. When the metrics eventually show up in Chronosphere, they will be pulled by Minions. 

Saborear a vitória

This new architecture allows provisioning roughly 100 new topics every week without manual intervention. With this API-based topic workflow, we reduced Iguazu onboarding time by 95%. Previously, customers were guaranteed onboarding within two business days, or about 48 hours. Now onboarding completes within an hour of request submission and often within 15 minutes. And there's a bonus: Manual on-call intervention has been reduced about four hours per week.

Cada tópico criado utilizando a nova arquitetura inclui metadados ricos sobre a propriedade, as expectativas de débito e o tamanho da mensagem, o que facilitará a aplicação de barreiras de fiabilidade no futuro.

Em última análise, ao integrar a plataforma de autosserviço de armazenamento padrão no Infra Service, temos acesso a controlos de administração, incluindo a substituição de configurações de tópicos, a recuperação de palavras-passe de utilizadores e o acesso fácil do programador ao estado do cluster Kafka. 

Explorar um futuro de armazenamento self-service

Figura 3: Aqui CRDB é a base de dados Cockroach e DBMesh é um serviço de gateway de dados que interage com todas as tecnologias de armazenamento suportadas em nome dos utilizadores.

Com base no sucesso do Infra Service e da Plataforma de Auto-Serviço de Armazenamento, planeamos acrescentar as seguintes funcionalidades para melhorar as nossas guardas e a experiência do cliente. A Figura 3 ilustra a arquitetura de alto nível da futura conceção. 

  • Lógica de validação centralizada, que será mantida pela equipa de armazenamento. Essa lógica de validação pode ser continuamente ajustada para atender às necessidades comerciais.
  • Valores predefinidos inteligentes. A contagem de partições e o fator de replicação podem ser calculados com base no pedido do cliente. Isto simplifica a entrada do utilizador para aprovisionar um tópico.
  • Capture solicitações duplicadas no início do processo de provisionamento por meio da lógica de desduplicação específica do Kafka. Devolver erros de API aos utilizadores.

Agradecimentos

Esta vitória da engenharia foi um esforço de equipa de várias equipas: Plataforma de transmissão em tempo real, armazenamento e nuvem. Agradecimentos especiais a todos os engenheiros que ajudaram a concretizar este objetivo: Roger Zeng, Luke Christopherson, Venkata Sivanaga Saisuvarna Krishna Manikeswaram Chaitanya, Basar Hamdi Onat, Chen Yang, Seed Zeng, Donovan Bai, Kane Du, Lin Du, Thai Pham, Allen Wang, Zachary Shaw e Varun Narayanan Chakravarthy.

About the Authors

  • Varun Chakravarthy

    Varun is a software engineer in the Data Platform Organization. Currently in the Data Infrastructure team and previously in Real-Time Streaming Platform team, he likes learning about and building scalable distributed systems. Outside work, he enjoys watching sports, hiking and traveling.

  • Basar Onat

    Basar is a software engineer on Real-Time Streaming Platform team in Data Platform Organization, with a focus on distributed data processing, distributed systems & architecture. Outside of his professional pursuits, Basar enjoys visiting cinemas, frequenting local coffee shops, and attending concerts.

  • Semente Zeng

    Seed is a software engineer on Storage team in Core Infra Organization. His focus on is on databases and large distributed systems. During his spare time, he hosts a podcast interviewing founders & VCs in tech.

  • Luke Christopherson

    Luke is a software engineer on the Cloud team, which is part of the Core Infrastructure organization. He's primarily focused on building and improving interfaces between engineers and cloud providers. During his spare time, Luke enjoys recording music and playing Pickleball.

Empregos relacionados

Job ID: 2915998
Localização
Sao Paulo, Brazil
Departamento
Engenharia
Localização
Sunnyvale, CA
Departamento
Engenharia
Localização
Pune, Índia
Departamento
Engenharia
Localização
São Paulo, Brasil
Departamento
Engenharia
Job ID: 2739485
Localização
San Francisco, CA; Tempe, AZ
Departamento
Engenharia