- A Stripe manteve 99,999% de uptime em 2023, mesmo processando um volume total de pagamentos de US$ 1 trilhão
- A equipe de infraestrutura de banco de dados da Stripe fornece uma camada fundamental da API na forma de um banco de dados como serviço (DBaaS) chamado DocDB
- O DocDB é uma versão estendida do MongoDB Community, composta por vários serviços construídos internamente pela Stripe
- Processa mais de 5 milhões de consultas por segundo e armazena dados financeiros críticos em escala de petabytes, distribuídos por mais de 2.000 shards de banco de dados e mais de 5.000 coleções
- A escolha do MongoDB Community se deveu à flexibilidade do modelo de documentos e à capacidade de processar dados em tempo real em grande escala
- Em 2011, o MongoDB Atlas ainda não existia, então a empresa construiu clusters autogerenciados de instâncias do MongoDB executando na nuvem
- O núcleo do DocDB é a Data Movement Platform
- Originalmente, ela foi criada como uma solução de escalabilidade horizontal para superar os limites de escalabilidade vertical do MongoDB, mas acabou sendo customizada para diversos usos
- Como consolidar shards de banco de dados subutilizados para melhorar uso e eficiência, fazer upgrades de versões principais do mecanismo de banco de dados para aumentar a confiabilidade e migrar grandes clientes de multitenancy para single-tenancy
- A Data Movement Platform permite a transição de um pequeno número de shards grandes para um grande número de shards menores
- Também oferece migrações transparentes para os clientes e zero downtime, possibilitando um DBaaS altamente elástico
- O DocDB pode dividir shards de banco de dados em momentos de pico de tráfego e, quando o tráfego cai, consolidar milhares de bancos por meio de bin packing
Como a infraestrutura de banco de dados foi construída
- No lançamento da Stripe, em 2011, a empresa escolheu o MongoDB como banco de dados online por oferecer maior produtividade para desenvolvedores do que bancos relacionais padrão
- A empresa queria operar, sobre o MongoDB, uma infraestrutura robusta de banco de dados que priorizasse a confiabilidade da API, mas não encontrou um DBaaS pronto que atendesse aos requisitos
- Atender aos mais altos níveis de disponibilidade, durabilidade e desempenho
- Expor o mínimo possível de funcionalidades do banco de dados para evitar problemas causados por consultas não otimizadas de aplicações cliente
- Suportar escalabilidade horizontal por meio de sharding
- Oferecer suporte de primeira linha a multitenancy com cotas obrigatórias
- Fornecer segurança forte por meio da aplicação de políticas de autorização
- A solução foi construir o DocDB usando o MongoDB como mecanismo de armazenamento subjacente — um DBaaS verdadeiramente elástico e escalável, com migração de dados online como elemento central
- As aplicações de produto da Stripe acessam os dados do banco por meio de uma frota interna de servidores proxy de banco de dados, desenvolvidos em Go para impor confiabilidade, escalabilidade, controles de permissão e controle de acesso
- Nessa arquitetura, foi tomada a decisão central de usar sharding como mecanismo de escalabilidade horizontal
- Milhares de shards de banco de dados, cada um armazenando pequenos chunks de dados acumulados, hoje formam a base de todos os produtos da Stripe
- Quando uma aplicação envia uma consulta ao servidor proxy de banco de dados, ele analisa a consulta, a encaminha para um ou mais shards e depois combina os resultados antes de devolvê-los à aplicação
- Os servidores proxy dependem do serviço de metadados de chunks para mapear chunks para shards de banco de dados, o que permite localizar facilmente os shards relevantes para uma consulta
- Eventos de mudança gerados por escritas no banco são enviados para um sistema de software de streaming e, por fim, armazenados em object storage por meio de um pipeline de captura de dados de mudança (CDC)
- A equipe da Stripe provisiona, no nível das aplicações de produto, contêineres lógicos de dados chamados bancos de dados lógicos, usando um control plane interno para banco de dados de documentos, contendo uma ou mais coleções do DocDB compostas por documentos com propósitos relacionados
- Os dados dessas coleções do DocDB são distribuídos entre vários bancos de dados físicos, cada um armazenando pequenos chunks das coleções
- Os bancos de dados físicos do DocDB residem em shards implantados como replica sets, compostos por um nó primário e vários nós secundários, com replicação e failover automático
Como a Data Movement Platform foi projetada
- Para construir um produto DBaaS horizontalmente escalável e altamente elástico, capaz de aumentar e reduzir conforme a demanda das aplicações de produto, era necessário poder migrar dados entre shards de banco de dados com zero downtime e de forma transparente para os clientes
- Trata-se de um problema complexo de sistemas distribuídos, ainda mais complicado pelos requisitos específicos de dados financeiros críticos
- Consistência e integridade dos dados: era preciso garantir que os dados migrados permanecessem consistentes e íntegros tanto no shard de origem quanto no shard de destino
- Disponibilidade: longos períodos de indisponibilidade durante a migração de dados eram inaceitáveis, já que milhões de empresas dependem da Stripe para receber pagamentos de clientes 24 horas por dia
- O objetivo era manter as etapas críticas do processo de migração abaixo do tempo de um failover planejado do primário do banco de dados, que normalmente leva alguns segundos, e dentro do orçamento de retries das aplicações de produto
- Granularidade e adaptabilidade: na escala da Stripe, deveria ser possível migrar qualquer quantidade de chunks de dados, de qualquer quantidade de origens para shards de destino
- Não deveria haver limite para o número de migrações de chunks em andamento na frota, nem para o número de migrações das quais um shard específico pudesse participar em um dado momento
- Além disso, como uma parcela significativa dos shards contém dados em escala de terabytes, também era necessário migrar chunks de diferentes tamanhos com alto throughput
- Sem impacto de desempenho no shard de origem: ao migrar chunks de banco de dados entre shards, a meta era preservar desempenho e throughput do shard de origem para não afetar negativamente o desempenho e a capacidade disponível para consultas dos usuários
- Para atender a esses requisitos, a Stripe construiu uma plataforma de movimentação de dados que aciona serviços desenvolvidos especificamente para gerenciar migrações de dados online entre shards de banco de dados
- O componente Coordinator da plataforma é responsável por orquestrar as várias etapas da migração online e chama os serviços relevantes para executar cada etapa descrita abaixo
Etapa 1: registro da migração de chunk
- Primeiro, registra-se no serviço de metadados de chunks a intenção de migrar um chunk de banco de dados de um shard de origem para qualquer shard de destino
- Em seguida, índices são construídos no shard de destino para o chunk em migração
Etapa 2: importação em massa de dados
- Depois, os dados são carregados em um ou mais shards de banco de dados usando um snapshot do chunk no shard de origem no instante T
- O serviço responsável pela importação em massa aceita vários filtros de dados e importa apenas os chunks que atendem aos critérios de filtragem
- Embora inicialmente parecesse simples, a equipe encontrou limites de throughput ao fazer carga em massa de dados nos shards do DocDB
- Eles tentaram agrupar escritas em lotes e ajustar parâmetros do mecanismo do DocDB para uma ingestão em massa ideal, mas sem grande sucesso
- O avanço veio ao explorar o fato de que o DocDB usa a estrutura de dados B-tree para ordenar os dados, buscando então otimizar a ordem de inserção
- Ao ordenar os dados segundo o atributo de índice mais comum da coleção e inseri-los nessa ordem, aumentaram significativamente a localidade de escrita e elevaram o throughput de escrita em 10 vezes
Etapa 3: replicação assíncrona
- Após importar os dados para o shard de destino, a Stripe inicia a replicação de escritas do shard de origem para o shard de destino a partir do instante T para o chunk em migração
- O sistema de replicação assíncrona lê, no sistema de CDC, as mudanças causadas por escritas no shard de origem e executa as escritas no shard de destino
- O operation log, ou oplog, é uma coleção especial de cada shard do DocDB que mantém o registro de todas as operações que alteram dados naquele banco
- O oplog de todos os shards do DocDB é enviado para o Kafka, a plataforma de streaming de eventos, e depois armazenado em serviços de object storage em nuvem como o Amazon S3
- Com eventos do oplog vindos do Kafka e do Amazon S3, a equipe construiu um serviço que replica mudanças de um ou mais shards de origem do DocDB para um ou mais shards de destino
- Ao depender dos eventos de oplog do sistema de CDC, em vez de consumir throughput de leitura disponível para consultas de usuários no shard de origem, o serviço evita reduzir a velocidade dessas consultas e também não fica limitado pelo tamanho do oplog no shard de origem
- O serviço foi projetado para ser resiliente mesmo quando o shard de destino não está disponível e para permitir iniciar, pausar e retomar a sincronização a partir de checkpoints a qualquer momento
- O serviço de replicação também oferece a capacidade de obter o replication lag
- As mudanças dos chunks em migração são replicadas bidirecionalmente, do shard de origem para o shard de destino e vice-versa, e o serviço de replicação marca as escritas que publica para evitar replicação assíncrona cíclica
- Essa foi uma escolha de projeto intencional para dar flexibilidade de retornar o tráfego ao shard de origem caso surjam problemas ao direcioná-lo para o shard de destino
Etapa 4: verificação de correção
- Depois que a replicação entre o shard de origem e o shard de destino está sincronizada, a equipe compara snapshots de um ponto no tempo para verificar de forma abrangente a integridade e a exatidão dos dados
- Essa foi uma decisão de projeto deliberada para não impactar o throughput dos shards
Etapa 5: comutação de tráfego
- Quando os dados do chunk já foram importados da origem para o shard de destino e as mudanças estão sendo ativamente replicadas, a comutação de tráfego é orquestrada pelo Coordinator
- Para redirecionar os caminhos de leitura e escrita do chunk em migração, primeiro é preciso pausar brevemente o tráfego para o shard de origem, atualizar o roteamento no serviço de metadados de chunks e fazer com que os servidores proxy redirecionem leituras e escritas para o shard de destino
- O protocolo de comutação de tráfego se baseia na ideia de version gating
- Em estado estável, cada servidor proxy adiciona um número de version token às requisições para os shards do DocDB
- A Stripe adicionou patches customizados ao MongoDB para que os shards pudessem verificar se o número de version token recebido do proxy é mais novo do que o número que conhecem e processar apenas requisições que atendam a esse critério
- Para atualizar o roteamento do chunk, o Coordinator executa os seguintes passos:
- Primeiro, incrementa o número de version token do shard de origem do DocDB. Esse número é armazenado em um documento de uma coleção especial do DocDB e, nesse ponto, todas as leituras e escritas para o chunk no shard de origem passam a ser rejeitadas
- Em seguida, espera até que o serviço de replicação replique as escritas pendentes do shard de origem
- Por fim, atualiza no serviço de metadados de chunks o roteamento do chunk para apontar para o shard de destino e para o número de version token
- Quando isso termina, os servidores proxy obtêm no serviço de metadados de chunks o roteamento atualizado do chunk e o número de version token mais recente
- Usando esse roteamento atualizado, os servidores proxy passam a encaminhar leituras e escritas do chunk para o shard de destino
- Todo o protocolo de comutação de tráfego leva menos de 2 segundos para ser executado, e todas as leituras e escritas que falharem ao serem enviadas ao shard de origem terão sucesso após retry
Etapa 6: cancelamento do registro da migração de chunk
- Por fim, o serviço de metadados de chunks marca a migração como concluída e os dados do chunk são apagados do shard de origem, encerrando o processo de migração
Como a plataforma de movimentação de dados é usada
- A capacidade de migrar chunks de dados online entre shards do DocDB ajuda a Stripe a escalar horizontalmente sua infraestrutura de banco de dados no ritmo do crescimento da empresa
- Engenheiros da equipe de infraestrutura de banco de dados conseguem dividir shards do DocDB com um clique, com base em tamanho e throughput, criando folga de armazenamento e capacidade para as equipes de produto
- Em 2023, a Stripe usou a plataforma de movimentação de dados para melhorar a utilização da infraestrutura de banco de dados
- Especificamente, migrou 1,5 petabyte de dados de forma transparente para as aplicações de produto para fazer bin packing de milhares de bancos de dados subutilizados, reduzindo o total de shards subjacentes do DocDB para cerca de três quartos do número anterior
- Também usou a plataforma para atualizar a frota de infraestrutura de banco de dados, fazendo forklift dos dados para versões mais recentes do MongoDB em uma única etapa, sem passar por versões principais e secundárias intermediárias
- A equipe de infraestrutura de banco de dados da Stripe está focada em construir uma base robusta e confiável que escale junto com o crescimento da economia da internet
- Atualmente, a equipe está prototipando um sistema de gerenciamento de calor que equilibra proativamente dados entre shards com base em tamanho e throughput, além de investir em autoscaling de shards para responder dinamicamente a mudanças nos padrões de tráfego
Ainda não há comentários.