movendo 15 tb de dados de um estado para outro

Hoje nós vamos falar um pouco a respeito de como fizemos uma migração de data center na Zenvia, do Rio Grande do Sul para São Paulo. Vamos mostrar um pouco a respeito de como é que as coisas foram feitas, não necessariamente do PostgreSQL, porque a parte do PostgreSQL foi super fácil. Mas eu tenho certeza que pode ser de interesse pra muitos. Tudo o que nós precisamos orquestrar pra que aquela transferência de dados com o PostgreSQL pudesse acontecer.

Acredito que a grande maioria que está aqui já tenha trabalhado com PostgreSQL ou trabalhou com PostgreSQL. Mas quantos aqui precisaram fazer uma migração de dados ou de data center? E quantos precisam fazer? Ou planejam fazer? Hoje nós vamos ter um pouco dessa ideia do que foi feito lá na Zenvia, pra que a gente pudesse alcançar isso.

Meu nome é Rodrigo, eu sou analista de infraestrutura Sênior na Zenvia. Trabalho na Zenvia a quase dois anos. Trabalho com desenvolvimento e infraestrutura a praticamente 20 anos. E a Zenvia é uma empresa que tem o propósito de empoderar empresas a criarem experiências únicas de comunicação com clientes, por meio de uma plataforma unificada de comunicação de ponta a ponta. Então, nesse propósito e com seus canais de comunicação, a Zenvia tem esse propósito.

E um dos canais de comunicação que a Zenvia utiliza é o SMS. Que aliás é o que a Zenvia começou fazendo há 18 anos atrás. Eu e parte da equipe que está aqui hoje trabalhamos especificamente na área de SRE com o SMS.

Agora talvez se pergunte: você fez uma transferência de 15 terabytes de dados com PostgreSQL. Como? A resposta simples e direta: replicações. Só isso.

Nós montamos uma replicação em Porto Alegre, colocamos uma réplica física em São Paulo, ficamos com dois servidores ainda no Rio Grande do Sul fazendo o papel de segundo secundário para que pudesse utilizar depois. Depois de transportado pra São Paulo esse hardware, destruímos essa replicação e refizemos ela em São Paulo.

Da parte do PostgreSQL foi basicamente isso.

E talvez você pergunte: mas por que uma replicação física? Tivemos excelentes palestras de replicação lógica. Mas por que ainda assim utilizar a física? PostgreSQL 9.6. Essa base é bem antiga, são bases grandes e são muito estáveis. E como elas são as principais bases da empresa, para nós funcionar muito bem. Embora que, depois da migração de data center, nós já iniciamos, inclusive a Timbira tem nos ajudado, já iniciamos o processo de migração desse banco para o PostgreSQL 14.

Como é que estava essa arquitetura dos sistemas em Porto Alegre? E como é que ela deveria ficar em São Paulo?

Bom, primeiramente, em Porto Alegre, nós tínhamos um data center com duas zonas separadas. Elas ficavam no mesmo prédio, mas eram duas zonas. Nós sempre procuramos deixar dois servidores em cada zona, porque nós temos duas bases de dados principais, por isso temos um hardware físico para cada base. Então nós deixávamos os primários de uma zona, e os secundários em outra. E as aplicações ficavam também espalhadas em ambas as zonas, com o BGBouncer na frente. Sempre que precisa de escrita vai para um lado, sempre precisava de leitura vai para o outro. Tanto um servidor quanto o outro processam uma base de 1 bilhão de transações por dia, cada um deles.

E como é que isso deveria ficar em São Paulo?

Basicamente, a mesma coisa que nós tínhamos em Porto Alegre, só que em vez de utilizar duas zonas, são dois data centers separados. Esses data centers ficam mais ou menos a 5 km de distância um do outro, ligados por um link de 10 gigabits. Mas a nossa ideia era justamente essa, fazer com que ele ficasse exatamente igual a como era em Porto Alegre, só que em dois lugares distintos. Da mesma forma nós deixamos os PGBouncers em ambos data centers e mesmo que as aplicações de um data center precisem fazer a leitura, eles vão até o outro pra fazer a leitura usando, de fato, os secundários que nós vamos chamar aqui de SP02, pra usar como servidores de leitura.

A primeira fase, então, desse transporte não só dos dados, como também da infraestrutura, começou com o planejamento.

O plano era deixar, basicamente, como estava em Porto Alegre. O PostgreSQL primário em uma zona, secundária em outra. Primeira coisa que fizemos, claro, começamos a instalar as aplicações, PGBouncer, roteamentos, tudo em São Paulo, mais ou menos igual a como estava em Porto Alegre. Aqui a gente deixou ele simplificado. Mas, só que nessa parte de aplicações, principalmente, nós temos um pouco mais de 900 máquinas virtuais, dos dois lados. Então, tudo isso começou a ser replicado agora em São Paulo tanto em SP01 quanto SP02.

Em Porto Alegre, a primeira coisa que nós fizemos foi adicionar uma replicação física de dados usando outros dois servidores físicos que tínhamos. Esses dois são físicos, esses dois também. Quatro hardwares iguais. Colocamos mais dois secundários e fizemos uma replicação física aqui também, para ficarmos com dois. Aguardamos essa replicação ficar estável. Nós fizemos alguns testes para ter certeza que esse hardware, que era um pouquinho mais antigo, iria aguentar as leituras. E depois de que estava isso tudo estável, nós começamos a fazer a movimentação dos servidores e dos dados para São Paulo.

Primeira coisa que fizemos foi pegar aqueles secundários que estavam em Porto Alegre e transportar eles pro primeiro data center de São Paulo. Nós colocamos no avião, levamos pra lá, instalamos e tal. Configuramos de novo a replicação de Porto Alegre com São Paulo, assim como tinha já com aquele hardware antigo, que agora estava servindo como leitura em Porto Alegre. Nós também configuramos aquele segundo secundário, também em São Paulo, para replicar dos dois lados.

Durante esse tempo, os servidores antigos serviam como os secundários read-only. Nós levamos mais ou menos 36 horas pra replicar as duas bases de Porto Alegre pra São Paulo. Já que tínhamos um link de 1 gigabit entre Porto Alegre e São Paulo. Foi o suficiente para que nós pudéssemos trabalhar mas ainda tivemos essa demora, mas como não era algo que precisava ficar disponível na hora, foi tranquilo para nós fazemos essa transferência de dados em 36 horas.

Uma vez que a replicação estava estável, nós montamos uma terceira replicação entre SP01 e SP02. Lá em SP02 utilizando máquinas virtuais, que iriam servir como se fossem as máquinas de leitura. Assim como essas eram de leitura aqui em Porto Alegre, esses secundários temporários iam servir como leitura.

Ô Avila, mas Máquina virtual? Base grande? A gente sabe que não ia ter o mesmo desempenho, mas ele ia servir para aquele tempo'. e era só para o tempo de pegarmos essas máquinas e transportarmos para lá. Então elas tinham uma tarefa específica, um tempo de vida ali pra que eles iam fazer o trabalho deles. Nós sabemos que ele não é a solução ideal, mas ela ia servir para o propósito que nós tínhamos.

Replicações feitas, dados estáveis, tudo replicado, bonitinho, hora de começar a alterar as rotas. Como é que essa alteração de rotas foi feita?

Os clientes, durante esse tempo todo, continuavam entrando por Porto Alegre. Só que nós já tínhamos um sistema autônomo específico, com IPs específicos pra deixar em São Paulo. E aí nós começamos a fazer os clientes parar de entrar por Porto Alegre e começar a entrar por São Paulo. E aí nós temos várias aplicações que nossos clientes usam. Nós procuramos organizar isso de forma que nós fazíamos, a cada dois dias, mais ou menos, a virada de um dos sistemas, por DNS mesmo.

Começávamos a avisar os clientes, avisaríamos a mudança de IP, alguns clientes precisavam ser ajudados pois tinham problemas com firewall, agora vai mudar o IP e tal, tem que ajudar o cliente com firewall. Mas nós começamos a fazer isso gradualmente. Começamos a fazer com que eles parassem de entrar por Porto Alegre e entrassem pelos datacenters novos SP01 e SP02, que já estão balanceados.

Mas note um detalhe. Nós não começamos a usar as aplicações em São Paulo. Nós utilizávamos São Paulo apenas como uma rota de entrada. Assim que eles entravam em São Paulo, os clientes já iam pelo link de 1 gigabit utilizar as aplicações em Porto Alegre. Por que isso? Porque as nossas aplicações executam muitas queries que ficavam lentas demais no link de 1 gigabit. Então, se a gente tentasse fazer esses PGBouncers lerem os dados daqui de Porto Alegre pra lá, algumas queries acabavam ficando pesadas demais. E como os nossos sistemas são, em grande maioria, aplicações transacionais, e tem muitas ações que precisam ser feitas de forma síncrona, a latência e o tempo de resposta são um problema pra nós. Nós somos muito sensíveis a esse problema. Então, mesmo que nós tivéssemos, entre Porto Alegre e São Paulo, um uma latência de 25, 35 milissegundos, para uma parte de nossas aplicações isso já era um problema. Então nós decidimos deixar as bases e as aplicações em Porto Alegre, vamos fazer apenas os clientes entrarem por São Paulo. Isso se mostrou uma decisão acertada, porque isso facilitou na hora que a gente foi, de fato, fazer a troca de data center. Porque daí não foi necessário nos preocuparmos com os clientes, além do Downtime que, em algum momento, precisou acontecer.

Então não foi necessário a gente avisar clientes que eles iam mudar de IP ou ajudar eles durante essa fase, que seria uma fase crítica. A gente só se preocupou mesmo com o que tinha que ser feito ali da troca das aplicações e da troca das bases, apenas isso.

Essa fase foi planejada para ser feita em só uma janela de manutenção, durante um final de semana, no final de setembro de 2021. E nós precisávamos dessa janela de manutenção porque é nesse momento que a troca do primário ia ser feita. Nós íamos fazer a troca do primário, que estava em Porto Alegre agora para São Paulo. Nós conseguimos executar todas as tarefas que foram necessárias, dentro da janela programada de 3 horas. Mas nessa janela programada de 3 horas, menos de 60 minutos de Downtime nós tivemos. Menos de 60 minutos.

Nossos clientes foram avisados com bastante antecedência, programamos essa janela para um período de menor tráfego e assim nós conseguimos então fazer tudo o que precisava ser feito. Primeiramente, bloqueando o acesso dos clientes, aguardando o término das transações. No caso das mensagens de SMS, os clientes que já tinham enviado mensagens, essas mensagens tinham que ser enviados para as operadoras. Tínhamos que esperar voltar o status de entrega, tínhamos que ter certeza de que esses dados estavam íntegros, então a gente precisou esperar alguns instantes pra baixar essa poeira. Então, nós trancamos o acesso dos clientes que já estavam vindo por São Paulo, interrompemos a replicação entre Porto Alegre e São Paulo e promovemos os servidores de São Paulo pra primário. Depois disso fizemos a conferência da replicação entre eles e as VMs que estavam em SP02 para ver se os dados estavam certos. Os dados estavam estáveis, tudo bonitinho, replicação funcionando.

Beleza, os PGBouncers de São Paulo já estavam configurados. Eles já sabiam qual deveria ser o primário, qual deveria ser o secundário, mas mesmo assim fizemos, novamente uma verificação se eles estavam configurados corretamente. E fizemos a configuração das aplicações. Algumas delas precisavam ser reiniciadas pra que eles pudessem enxergar as bases de dados novas. Uma vez de que as aplicações já estavam funcionando direitinho, fizemos a troca de rota nos balanceadores pra que agora as conexões que chegassem não fossem mais para Porto Alegre e começassem, então, a utilizar as aplicações, aquele monte de máquina virtual e as bases de dados que agora estavam separadas em São Paulo, em dois datas centrais diferentes.

Entre o bloqueio e a liberação de tráfego, todos os passos que nós mostramos aqui foram feitos de forma simultânea. Aqui estava toda reunida, alguns faziam uma parte, outros faziam outra. Nós conseguimos fazer elas de forma simultânea. Como a Zenvia não tem uma sede, a gente trabalha no sistema Anywhere, funcionários trabalham de qualquer lugar do Brasil, de qualquer lugar do mundo, todo esse procedimento foi feito de forma remota, com participação de colegas de suporte a cliente, infraestrutura de data center, pessoal de engenharia e também o pessoal de SRE. Todos juntos.

A migração em si foi concluída aqui. Liberamos o acesso aos clientes, os clientes começaram a mandar de novo suas mensagens. Olhamos lá se os clientes mais importantes estavam de fato conectados, se as mensagens estavam trafegando. A migração estava concluída, por assim dizer. Mas, ainda tínhamos duas coisas a nos preocupar.

Primeira delas era de fato trazer aqueles servidores que ainda ficaram em Porto Alegre.

Nós tínhamos ainda servidores físicos que ficaram lá. Transportamos essas máquinas que estavam em Porto Alegre, trouxemos elas para ficar em SP02, ressincronizamos SP02, porque obviamente já alguns dados estavam defasados, fizemos a ressincronização e fizemos a substituição. Como eram máquinas somente para leitura, conseguimos fazer pelo PGBouncer a troca do servidor de leitura de forma transparente. Essa parte foi mais tranquila. Colocamos eles como secundários e removemos os secundários virtuais. Desta forma, estávamos então configurados, prontos e da mesma forma como estávamos em Porto Alegre.

Mas a segunda coisa que nós precisamos preocupar era: como é que essa infraestrutura toda ia se comportar dois meses depois na Black Friday de 2021? Porque a Black Friday, pra nós, é um dos momentos com um maior tráfego. É um tráfego muito grande, principalmente de SMS. Então nós temos uma preocupação. Hoje nós ficamos nove meses nos preparando, preparando automação, vendo como é que ia fazer, planejando... será que isso realmente ia dar certo? Será que ele ia ter o mesmo desempenho pro mais cuidadoso que a gente tivesse sido? Será que teria o mesmo desempenho estando em lugares diferentes?

Felizmente sim. A Black Friday de novembro de 2021, ia ser o nosso termômetro do sucesso ou do fracasso da operação. E o resultado foi que, comparado com o nosso histórico anterior, o nosso tráfego, naquela Black Friday de 2021 foi três vezes maior. E essa, de fato, foi uma prova de fogo pra essa nova arquitetura. Podemos dizer que nenhum incidente foi registrado, não só na sexta feira da Black Friday, como também durante toda aquela semana. Não registramos nenhum incidente. E nós podemos dizer que, não só durante aquela Black Friday, como durante todo o período de migração, nós tivemos vários aprendizados, experiências novas, conhecemos tecnologias novas. A equipe toda conseguiu aprender muito, principalmente com o pessoal da Timbira que nos ajudou. Nós aprendemos muito com bases de dados PostgreSQL. Só que também nós vimos coisas que nós não tínhamos visto ainda. Talvez para algum seja comum, mas nós não tínhamos visto ainda. Como, por exemplo, uma máquina que tem 96 núcleos, 512 GB de RAM, ficar com o load desse tamanho, mas mesmo assim respondendo, PostgreSQL funcionando, tudo ok. Tudo funcionando como deveria funcionar. Como diria o Chicó, eu não sei porque isso aconteceu, só sei que foi assim.