Bancos de dados de autoatendimento

Tradicionalmente, os repositórios de dados têm sido gerenciados por equipes especializadas e exigem muito trabalho para serem configurados e administrados. Essa abordagem pode funcionar para arquiteturas monolíticas. No entanto, para microsserviços com maior taxa de mudança e com o objetivo de que cada um tenha seu próprio repositório de dados, esse modelo não é escalável.  Isso pode tornar a criação de microsserviços dispendiosa e fazer com que as equipes fiquem dependentes de uma equipe centralizada.

O VCC (Vonage Contact Center) para esse problema foi migrar para um modelo de autoatendimento que utilizasse automação, permitindo que as equipes realizassem muitas dessas tarefas por conta própria. No entanto, o autoatendimento em si é um conceito bastante abstrato; portanto, nossa primeira tarefa foi definir o que um repositório de dados de autoatendimento realmente significava para nós.

O que é um datastore de autoatendimento

Um datastore é “um repositório para armazenar e gerenciar coleções de dados de forma persistente”. Para nós, isso abrange:

• Banco de dados relacional, por exemplo, MySQL

• Banco de dados NoSQL, por exemplo, o DynamoDB

• Caches, como, por exemplo, o Redis

• Outros armazenamentos semelhantes ao Elasticsearch

Nesse contexto, o autoatendimento significa que uma equipe pode:

• Criar e gerenciar seu repositório de dados

• Fazer alterações no esquema

• Efetuar alterações nos dados com segurança

• Oferecer suporte ao banco de dados deles, incluindo acesso para depuração e suporte à produção

Essas coisas, por si só, são bastante fáceis de fazer. No entanto, para evitar criar mais problemas do que aqueles que resolvemos, também precisamos levar em consideração:

• Ferramentas que incorporam as melhores práticas por meio de testes automatizados e padrões de qualidade

• Registro de audit de todos os acessos e alterações para garantir a conformidade

• Barreiras e fachadas da multilocação (nem sempre é econômico ter um cluster de banco de dados para cada microsserviço)

• Complexidade da replicação “hot-hot”, quando necessário

• Facilidade de uso, robustez e ocultação da complexidade interna

Benefícios

Ambas as principais partes interessadas dos repositórios de dados (as equipes que operam os repositórios e as equipes de desenvolvimento que os utilizam) se beneficiam do autoatendimento, mas de maneiras diferentes. Dependendo da estrutura da sua organização, essas equipes podem até ser a mesma! Os dois gráficos a seguir mostram o cenário de adotar o autoatendimento e continuar a aprimorá-lo em comparação com não fazer nada, ao longo de um período de 18 meses.

Esses gráficos mostram nossa experiência sobre como as tarefas de rotina (BAU), como realizar migrações de esquema, fazer alterações nos dados etc., afetaram as equipes à medida que a demanda por bancos de dados aumentou ao longo do tempo.

Impact from BAU tasks increases over time

Se a sua organização estiver aumentando o número de microsserviços e/ou equipes, chegará um momento em que o volume de tarefas de rotina (BAU) sobrecarregará sua(s) equipe(s) de gerenciamento de bancos de dados. Você pode resolver isso contratando mais pessoas, mas é provável que isso não seja suficiente para acompanhar a demanda. A adoção de uma estratégia de autoatendimento reduzirá o volume de tarefas de manutenção de rotina (BAU), eliminando tarefas como a migração de esquemas, ao mesmo tempo em que permite que a equipe de armazenamento de dados se concentre em tarefas de maior valor.

Time to make a datastore change increases over time

As equipes de desenvolvimento também se beneficiarão do autoatendimento, já que as alterações nos datastores serão mais rápidas e menos onerosas à medida que você adicionar mais recursos de autoatendimento. Se as equipes de funcionalidades dependerem de uma equipe de armazenamento de dados para fazer essas alterações por elas, essa equipe pode se tornar um gargalo e aumentar o custo das alterações. Esse custo se reflete principalmente no tempo decorrido. Se a equipe de armazenamento de dados começar a ficar sobrecarregada, as equipes de funcionalidades talvez tenham que começar a acompanhar as alterações que solicitaram para garantir que elas sejam realizadas.

O que já fizemos

Agora que você já entende o que é um datastore de autoatendimento e por que precisamos deles, provavelmente está curioso para saber o que estamos fazendo para migrar para um modelo de autoatendimento.

As equipes que trabalham no VCC adotaram o autoatendimento para AWS Aurora MySQL, o que nos permite criar automaticamente novos esquemas para os serviços e fazer alterações nos esquemas como parte do pipeline de CI. Ele também se encarrega de fornecer credenciais de banco de dados e a configuração de acesso aos microsserviços.

O processo de execução das migrações (conforme mostrado no diagrama abaixo) envolve uma função Lambda que coordena a criação de contêineres Docker para realizar as migrações. A comunicação entre o sistema de CI e o sistema de migração de esquema é feita por meio de mensagens. O processo também criará um banco de dados caso o esquema ainda não exista.

O fluxo de trabalho do processo de migração consiste no seguinte: o Jenkins solicita que uma nova versão de um esquema seja implantada (1) enviando a migração para o bucket de scripts de migração e, em seguida, (2) publicando-a em um tópico do SNS. Essa solicitação é captada por (3) uma fila do SQS, que está inscrita no tópico, e (4) aciona a função Lambda de migração do esquema.

A função Lambda de migração de esquema (5) inicia uma tarefa do ECS cujo (6) contêiner busca a migração do bucket de scripts de migração e, em seguida, (7) executa o Flyway usando o script de migração no cluster Aurora de destino. Após a conclusão da migração (8), o contêiner publica uma mensagem no SNS que é (9) captada por uma fila SQS de CI/CD, a qual (10) atualiza o status da tarefa do Jenkins para indicar que ela foi concluída.

Para apoiar isso, também elaboramos diretrizes sobre as melhores práticas específicas para nossa arquitetura (por exemplo, considerações sobre a replicação “hot-hot” entre vários clusters e melhores práticas para migrações, para que as equipes possam evitar erros comuns).

Próximos passos

Em seguida, pretendemos adicionar mais recursos de autoatendimento, como permitir alterações de dados de forma autônoma, disponibilizar mais métricas e ferramentas para análises detalhadas de consultas. Queremos possibilitar um acesso seguro e sem obstáculos aos dados, com integração à nossa trilha de auditoria. Também precisamos verificar se o trabalho que já realizamos trouxe os benefícios esperados.

Por fim, estamos analisando se outras áreas da Vonage podem aproveitar o trabalho que realizamos. Isso é especialmente relevante, já que estamos desenvolvendo a Plataforma de Comunicações da Vonage e a arquitetura comum das plataformas internas que a sustentam.