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.
- 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).
- O serviço Orchestrator acciona o Atlantis para executar o Terraform Plan no tópico.
- O plantão recebe uma notificação automática por correio eletrónico sobre o PR.
- O serviço do Orchestrator sonda o estado do BP para verificar a aprovação do plantão.
- Uma vez aprovado e num estado fundível, o Atlantis Apply é acionado contra o PR.
- 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.
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
Please enter a valid email address.
Obrigado por subscrever!
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.
Na Figura 2, ainda envolto num fluxo de trabalho Cadence, o aprovisionamento de tópicos é reduzido a um processo de duas etapas:
- 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.
- 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
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.