Hoje, o serviço Bitrix24 não possui centenas de gigabits de tráfego, nem uma enorme frota de servidores (embora, é claro, existam alguns já existentes). Mas para muitos clientes é a principal ferramenta de trabalho na empresa, é uma verdadeira aplicação crítica para os negócios. Portanto, não há como cair. E se o travamento aconteceu, mas o serviço “se recuperou” tão rapidamente que ninguém percebeu nada? E como é possível implementar failover sem perder a qualidade do trabalho e a quantidade de clientes? Alexander Demidov, diretor de serviços em nuvem do Bitrix24, falou em nosso blog sobre como o sistema de reservas evoluiu ao longo dos 7 anos de existência do produto.
“Lançamos o Bitrix24 como SaaS há 7 anos. A principal dificuldade era provavelmente a seguinte: antes de ser lançado publicamente como SaaS, este produto existia simplesmente no formato de uma solução in a box. Os clientes compraram de nós, hospedaram em seus servidores, criaram um portal corporativo - uma solução geral para comunicação de funcionários, armazenamento de arquivos, gerenciamento de tarefas, CRM, só isso. E em 2012 decidimos que queríamos lançá-lo como SaaS, administrando-o nós mesmos, garantindo tolerância a falhas e confiabilidade. Ganhamos experiência ao longo do caminho, porque até então simplesmente não a tínhamos - éramos apenas fabricantes de software, não prestadores de serviços.
Ao lançar o serviço, entendemos que o mais importante é garantir tolerância a falhas, confiabilidade e disponibilidade constante do serviço, pois se você tem um site simples e comum, uma loja, por exemplo, e ele cai em você e fica ali por uma hora, só você sofre, perde pedidos, perde clientes, mas para o próprio cliente isso não é muito crítico para ele. Ele ficou chateado, claro, mas foi e comprou em outro site. E se esta é uma aplicação na qual está vinculado todo o trabalho dentro da empresa, comunicações, decisões, então o mais importante é ganhar a confiança dos usuários, ou seja, não decepcioná-los e não cair. Porque todo trabalho pode parar se algo dentro de você não funcionar.
Bitrix.24 como SaaS
Montamos o primeiro protótipo um ano antes do lançamento público, em 2011. Montamos em cerca de uma semana, olhamos, giramos - estava até funcionando. Ou seja, você poderia entrar no formulário, inserir o nome do portal ali, um novo portal seria aberto e uma base de usuários seria criada. Analisámos, avaliámos o produto em princípio, desmantelámo-lo e continuámos a refiná-lo durante um ano inteiro. Porque tínhamos uma grande tarefa: não queríamos criar duas bases de código diferentes, não queríamos oferecer suporte a um pacote de produto separado, soluções de nuvem separadas - queríamos fazer tudo dentro de um código.
Uma aplicação web típica naquela época era um servidor no qual algum código PHP era executado, um banco de dados mysql, arquivos eram carregados, documentos e imagens eram colocados na pasta de upload - bem, tudo funciona. Infelizmente, é impossível lançar um serviço web criticamente estável usando isso. Lá, o cache distribuído não é compatível e a replicação do banco de dados não é suportada.
Formulamos os requisitos: esta é a capacidade de estar localizado em locais diferentes, suportar replicação e, idealmente, estar localizado em diferentes data centers distribuídos geograficamente. Separe a lógica do produto e, de fato, o armazenamento de dados. Ser capaz de dimensionar dinamicamente de acordo com a carga e tolerar totalmente a estática. Dessas considerações surgiram, de fato, os requisitos do produto, que aprimoramos ao longo do ano. Nesse período, na plataforma, que acabou sendo unificada - para soluções in a box, para nosso próprio serviço - fizemos suporte para o que precisávamos. Suporte para replicação mysql no nível do próprio produto: ou seja, o desenvolvedor que escreve o código não pensa em como suas solicitações serão distribuídas, ele usa nossa API, e sabemos como distribuir corretamente as solicitações de escrita e leitura entre mestres e escravos.
Oferecemos suporte no nível do produto para vários armazenamentos de objetos em nuvem: google storage, amazon s3, além de suporte para open stack swift. Portanto, isso foi conveniente tanto para nós como serviço quanto para os desenvolvedores que trabalham com uma solução empacotada: se eles apenas usam nossa API para trabalhar, eles não pensam onde o arquivo será salvo, localmente no sistema de arquivos ou no armazenamento de arquivos de objeto.
Como resultado, decidimos imediatamente que faríamos reservas no nível de todo o data center. Em 2012, lançamos inteiramente no Amazon AWS porque já tínhamos experiência com essa plataforma – nosso próprio site estava hospedado lá. Fomos atraídos pelo facto de em cada região a Amazon ter várias zonas de disponibilidade - na verdade, (na sua terminologia) vários data centers que são mais ou menos independentes uns dos outros e que nos permitem reservar ao nível de um data center inteiro: se falhar repentinamente, os bancos de dados serão replicados mestre-mestre, será feito backup dos servidores de aplicativos da web e os dados estáticos serão movidos para o armazenamento de objetos s3. A carga é balanceada - naquela época pelo Amazon Elb, mas um pouco depois chegamos aos nossos próprios balanceadores de carga, porque precisávamos de uma lógica mais complexa.
O que eles queriam é o que conseguiram...
Todas as coisas básicas que queríamos garantir – tolerância a falhas dos próprios servidores, aplicações web, bancos de dados – tudo funcionou bem. O cenário mais simples: se um de nossos aplicativos da web falhar, tudo será simples - eles serão desativados no balanceamento.
O balanceador (na época era o Elb da Amazon) marcou máquinas que estavam fora de serviço como insalubres e desligou a distribuição de carga nelas. O escalonamento automático da Amazon funcionou: quando a carga aumentou, novas máquinas foram adicionadas ao grupo de escalonamento automático, a carga foi distribuída para novas máquinas - estava tudo bem. Com nossos balanceadores, a lógica é aproximadamente a mesma: se algo acontecer com o servidor de aplicação, removemos as solicitações dele, descartamos essas máquinas, iniciamos novas e continuamos trabalhando. O esquema mudou um pouco ao longo dos anos, mas continua funcionando: é simples, direto e não há dificuldades com isso.
Trabalhamos em todo o mundo, os picos de carga dos clientes são completamente diferentes e, de forma amigável, deveríamos poder realizar determinados trabalhos de serviço em qualquer componente do nosso sistema a qualquer momento - despercebidos pelos clientes. Portanto, temos a oportunidade de desligar o banco de dados de operação, redistribuindo a carga para um segundo data center.
Como tudo funciona? — Transferimos o tráfego para um data center em funcionamento - se houver um acidente no data center, então completamente, se este for nosso trabalho planejado com um banco de dados, então transferimos parte do tráfego que atende esses clientes para um segundo data center, suspendendo isto replicação. Se novas máquinas forem necessárias para aplicações web porque a carga no segundo data center aumentou, elas serão iniciadas automaticamente. Terminamos o trabalho, a replicação é restaurada e devolvemos toda a carga. Se precisarmos espelhar algum trabalho no segundo DC, por exemplo, instalar atualizações do sistema ou alterar configurações no segundo banco de dados, então, em geral, repetimos a mesma coisa, só que na outra direção. E se for um acidente, então fazemos tudo de forma trivial: usamos o mecanismo de manipuladores de eventos no sistema de monitoramento. Se várias verificações forem acionadas e o status for crítico, então executamos este manipulador, um manipulador que pode executar esta ou aquela lógica. Para cada banco de dados, especificamos qual servidor é o failover e para onde o tráfego precisa ser comutado se estiver indisponível. Historicamente, usamos nagios ou alguns de seus forks de uma forma ou de outra. Em princípio, existem mecanismos semelhantes em quase todos os sistemas de monitorização; ainda não utilizamos nada mais complexo, mas talvez algum dia o utilizemos. Agora o monitoramento é acionado por indisponibilidade e tem a capacidade de mudar alguma coisa.
Reservamos tudo?
Temos muitos clientes dos EUA, muitos clientes da Europa, muitos clientes que estão mais próximos do Oriente - Japão, Singapura e assim por diante. É claro que uma grande parte dos clientes está na Rússia. Ou seja, o trabalho não está em uma região. Os usuários desejam uma resposta rápida, existem requisitos para cumprir diversas leis locais e, dentro de cada região, reservamos dois data centers, além de alguns serviços adicionais, que, novamente, são convenientes para serem colocados em uma região - para clientes que estão em esta região está funcionando. Manipuladores REST, servidores de autorização, são menos críticos para a operação do cliente como um todo, você pode alterná-los com um pequeno atraso aceitável, mas não quer reinventar a roda sobre como monitorá-los e o que fazer com eles. Portanto, estamos tentando aproveitar ao máximo as soluções existentes, em vez de desenvolver algum tipo de competência em produtos adicionais. E em algum lugar usamos trivialmente a comutação no nível do DNS e determinamos a vivacidade do serviço pelo mesmo DNS. A Amazon tem um serviço Route 53, mas não é apenas um DNS no qual você pode fazer entradas e pronto – é muito mais flexível e conveniente. Através dele você pode construir serviços geo-distribuídos com geolocalizações, ao utilizá-lo para determinar de onde veio o cliente e fornecer a ele determinados registros - com sua ajuda você pode construir arquiteturas de failover. As mesmas verificações de integridade são configuradas no próprio Route 53, você define os endpoints que são monitorados, define métricas, define quais protocolos para determinar a “vivacidade” do serviço - tcp, http, https; defina a frequência das verificações que determinam se o serviço está ativo ou não. E no próprio DNS você especifica o que será primário, o que será secundário, para onde mudar se a verificação de integridade for acionada dentro da rota 53. Tudo isso pode ser feito com algumas outras ferramentas, mas por que é conveniente - nós configuramos levantamos uma vez e depois não pensamos em como fazemos as verificações, como trocamos: tudo funciona sozinho.
O primeiro "mas": como e com o que reservar a própria rota 53? Quem sabe, e se algo acontecer com ele? Felizmente, nunca pisamos neste ancinho, mas, novamente, terei uma história adiante explicando por que pensamos que ainda precisávamos fazer uma reserva. Aqui preparamos canudos para nós mesmos com antecedência. Várias vezes ao dia fazemos um descarregamento completo de todas as zonas que temos na rota 53. A API da Amazon permite enviá-los facilmente em JSON, e temos vários servidores de backup onde convertemos, carregamos em forma de configurações e temos, grosso modo, uma configuração de backup. Se algo acontecer, podemos implantá-lo manualmente rapidamente sem perder os dados de configuração de DNS.
Segundo "mas": O que nesta foto ainda não foi reservado? O próprio balanceador! Nossa distribuição de clientes por região é muito simples. Temos os domínios bitrix24.ru, bitrix24.com, .de - agora são 13 diferentes, que operam em diversas zonas. Chegamos ao seguinte: cada região tem seus próprios balanceadores. Isso torna mais conveniente a distribuição entre regiões, dependendo de onde está o pico de carga na rede. Se isso for uma falha no nível de um único balanceador, ele será simplesmente retirado de serviço e removido do DNS. Se houver algum problema com um grupo de balanceadores, então eles são copiados em outros sites, e a troca entre eles é feita pela mesma rota53, pois devido ao TTL curto, a troca ocorre em no máximo 2, 3, 5 minutos .
Terceiro "mas": O que ainda não está reservado? S3, correto. Quando colocamos os arquivos que armazenamos para os usuários no s3, acreditamos sinceramente que era uma armadura e não havia necessidade de reservar nada ali. Mas a história mostra que as coisas acontecem de forma diferente. Em geral, a Amazon descreve o S3 como um serviço fundamental, porque a própria Amazon usa o S3 para armazenar imagens de máquinas, configurações, imagens AMI, snapshots... E se o s3 travar, como aconteceu uma vez durante esses 7 anos, desde que usamos bitrix24, ele segue como um fã. Há um monte de coisas que surgem – incapacidade de iniciar máquinas virtuais, falha de API e assim por diante.
E o S3 pode cair – isso aconteceu uma vez. Portanto, chegamos ao seguinte esquema: há alguns anos não havia instalações sérias de armazenamento de objetos públicos na Rússia, e consideramos a opção de fazer algo por conta própria... Felizmente, não começamos a fazer isso, porque iríamos investigamos o conhecimento que não temos e provavelmente estragaríamos. Agora, Mail.ru tem armazenamento compatível com s3, Yandex e vários outros provedores. Finalmente chegamos à ideia de que queríamos ter, em primeiro lugar, backup e, em segundo lugar, a capacidade de trabalhar com cópias locais. Especificamente para a região russa, usamos o serviço Mail.ru Hotbox, que é compatível com API com s3. Não precisamos de grandes modificações no código dentro da aplicação e fizemos o seguinte mecanismo: no s3 existem gatilhos que acionam a criação/exclusão de objetos, a Amazon tem um serviço chamado Lambda - este é um lançamento de código sem servidor que será executado apenas quando determinados gatilhos forem acionados.
Fizemos isso de maneira muito simples: se nosso gatilho disparar, executamos o código que copiará o objeto para o armazenamento do Mail.ru. Para iniciar totalmente o trabalho com cópias locais de dados, também precisamos de sincronização reversa para que os clientes que estão no segmento russo possam trabalhar com armazenamento mais próximo deles. O Mail está prestes a concluir os gatilhos em seu armazenamento - será possível realizar a sincronização reversa no nível da infraestrutura, mas por enquanto estamos fazendo isso no nível do nosso próprio código. Se percebermos que um cliente postou um arquivo, então, no nível do código, colocamos o evento em uma fila, processamos e fazemos a replicação reversa. Por que é ruim: se fizermos algum tipo de trabalho com nossos objetos fora do nosso produto, ou seja, por algum meio externo, não levaremos isso em consideração. Portanto, esperamos até o final, quando os gatilhos aparecem no nível do armazenamento, para que não importa de onde executemos o código, o objeto que chegou até nós seja copiado na outra direção.
No nível do código, cadastramos os dois storages para cada cliente: um é considerado o principal, o outro é considerado o backup. Se estiver tudo bem, trabalhamos com o armazenamento que está mais próximo de nós: ou seja, nossos clientes que estão na Amazon trabalham com S3, e aqueles que trabalham na Rússia trabalham com Hotbox. Se o sinalizador for acionado, o failover deverá ser conectado e mudaremos os clientes para outro armazenamento. Podemos marcar esta caixa independentemente por região e alterná-las entre si. Ainda não usamos isso na prática, mas fornecemos esse mecanismo e achamos que algum dia precisaremos dessa mesma opção e será útil. Isso já aconteceu uma vez.
Ah, e a Amazon fugiu...
Este mês de abril marca o aniversário do início do bloqueio do Telegram na Rússia. O fornecedor mais afetado é a Amazon. E, infelizmente, as empresas russas que trabalhavam para o mundo inteiro sofreram mais.
Se a empresa for global e a Rússia for um segmento muito pequeno para ela, 3-5% - bem, de uma forma ou de outra, você pode sacrificá-los.
Se esta for uma empresa puramente russa - tenho certeza de que precisa estar localizada localmente - bem, será simplesmente conveniente, confortável para os próprios usuários e haverá menos riscos.
E se esta for uma empresa que opera globalmente e tem um número aproximadamente igual de clientes na Rússia e em algum lugar do mundo? A conectividade dos segmentos é importante e eles devem funcionar entre si de uma forma ou de outra.
No final de março de 2018, Roskomnadzor enviou uma carta às maiores operadoras informando que planejavam bloquear vários milhões de IPs da Amazon para bloquear... o mensageiro Zello. Graças a esses mesmos fornecedores - eles vazaram a carta para todos com sucesso e houve um entendimento de que a conexão com a Amazon poderia desmoronar. Era sexta-feira, corremos em pânico para nossos colegas do server.ru, dizendo: “Amigos, precisamos de vários servidores que estarão localizados não na Rússia, nem na Amazon, mas, por exemplo, em algum lugar de Amsterdã”, para para poder, pelo menos de alguma forma, instalar nossa própria VPN e proxy lá para alguns endpoints que não podemos influenciar de forma alguma, por exemplo, endpoints do mesmo s3 - não podemos tentar criar um novo serviço e obter um IP diferente, nós, você ainda precisa chegar lá. Em apenas alguns dias, configuramos esses servidores, colocamos-nos em funcionamento e, em geral, nos preparamos para o momento do início do bloqueio. É curioso que a RKN, olhando para a agitação e o pânico, tenha dito: “Não, não vamos bloquear nada agora”. (Mas isso foi exatamente até o momento em que o Telegram começou a ser bloqueado.) Tendo configurado os recursos de bypass e percebendo que o bloqueio não havia sido introduzido, nós, entretanto, não começamos a resolver todo o assunto. Sim, apenas por precaução.
E em 2019 ainda vivemos em condições de bloqueio. Eu olhei ontem à noite: cerca de um milhão de IPs continuam bloqueados. É verdade que a Amazon foi quase totalmente desbloqueada, no seu auge atingiu 20 milhões de endereços... Em geral, a realidade é que pode não haver coerência, boa coerência. De repente. Pode não existir por razões técnicas – incêndios, escavadeiras, tudo isso. Ou, como vimos, não inteiramente técnico. Portanto, alguém grande e grande, com seus próprios ASs, provavelmente pode gerenciar isso de outras maneiras - conexão direta e outras coisas já estão no nível l2. Mas em uma versão simples, como a nossa ou ainda menor, você pode, por precaução, ter redundância no nível de servidores criados em outro lugar, configurados antecipadamente vpn, proxy, com a capacidade de mudar rapidamente a configuração para eles nesses segmentos que são essenciais para sua conectividade. Isso foi útil para nós mais de uma vez, quando o bloqueio da Amazon começou: na pior das hipóteses, permitimos apenas o tráfego S3 através deles, mas aos poucos tudo isso foi resolvido.
Como reservar... um fornecedor completo?
No momento não temos um cenário caso toda a Amazônia caia. Temos um cenário semelhante para a Rússia. Na Rússia, fomos hospedados por um provedor, do qual optamos por ter vários sites. E há um ano enfrentámos um problema: mesmo sendo dois data centers, pode haver problemas já ao nível da configuração da rede do fornecedor que ainda afetarão ambos os data centers. E podemos acabar indisponíveis em ambos os sites. Claro que foi isso que aconteceu. Acabamos reconsiderando a arquitetura interna. Não mudou muito, mas para a Rússia temos agora dois sites, que não são do mesmo fornecedor, mas de dois sites diferentes. Se um falhar, podemos mudar para o outro.
Hipoteticamente, para a Amazon estamos considerando a possibilidade de reserva em nível de outro provedor; talvez o Google, talvez outra pessoa... Mas até agora observamos na prática que, embora a Amazon tenha acidentes no nível de uma zona de disponibilidade, acidentes no nível de uma região inteira são bastante raros. Portanto, teoricamente temos a ideia de que poderíamos fazer uma reserva “Amazônia não é Amazônia”, mas na prática ainda não é o caso.
Algumas palavras sobre automação
A automação é sempre necessária? Aqui é apropriado recordar o efeito Dunning-Kruger. No eixo “x” está o conhecimento e a experiência que adquirimos, e no eixo “y” está a confiança em nossas ações. A princípio não sabemos nada e não temos certeza. Aí conhecemos um pouco e ficamos megaconfiantes - esse é o chamado “pico da estupidez”, bem ilustrado pela imagem “demência e coragem”. Então aprendemos um pouco e estamos prontos para a batalha. Depois cometemos alguns erros megagraves e nos encontramos num vale de desespero, quando parecemos saber alguma coisa, mas na verdade não sabemos muito. Então, à medida que ganhamos experiência, ficamos mais confiantes.
Nossa lógica sobre várias mudanças automáticas para certos acidentes é muito bem descrita por este gráfico. Começamos - não sabíamos fazer nada, quase todo o trabalho era feito à mão. Aí percebemos que poderíamos anexar automação a tudo e, tipo, dormir em paz. E de repente pisamos em um mega-rake: um falso positivo é acionado e alternamos o tráfego quando, no bom sentido, não deveríamos ter feito isso. Conseqüentemente, a replicação falha ou qualquer outra coisa – este é o verdadeiro vale do desespero. E então chegamos à compreensão de que devemos abordar tudo com sabedoria. Ou seja, faz sentido contar com a automação, prevendo a possibilidade de falsos alarmes. Mas! se as consequências podem ser devastadoras, então é melhor deixar isso para o plantonista, para os engenheiros de plantão, que se certificarão e monitorarão se realmente há um acidente, e realizarão as ações necessárias manualmente...
Conclusão
Ao longo de 7 anos, passamos do fato de que quando alguma coisa caía, havia pânico-pânico, à compreensão de que os problemas não existem, existem apenas tarefas, elas devem - e podem - ser resolvidas. Quando você estiver construindo um serviço, olhe de cima, avalie todos os riscos que podem acontecer. Se você os vir de imediato, providencie antecipadamente a redundância e a possibilidade de construir uma infraestrutura tolerante a falhas, pois qualquer ponto que possa falhar e levar à inoperabilidade do serviço certamente o fará. E mesmo que lhe pareça que alguns elementos da infraestrutura definitivamente não irão falhar - como o mesmo s3, tenha em mente que eles podem. E pelo menos em teoria, tenha uma ideia do que você fará com eles se algo acontecer. Tenha um plano de gerenciamento de riscos. Quando você estiver pensando em fazer tudo de forma automática ou manual, avalie os riscos: o que acontecerá se a automação começar a mudar tudo - isso não levará a uma situação ainda pior em comparação a um acidente? Talvez em algum lugar seja necessário usar um compromisso razoável entre o uso da automação e a reação do engenheiro de plantão, que avaliará o quadro real e entenderá se algo precisa ser trocado na hora ou “sim, mas não agora”.
Um compromisso razoável entre perfeccionismo e esforço real, tempo e dinheiro que você pode gastar no esquema que eventualmente terá.
Este texto é uma versão atualizada e ampliada do relatório de Alexander Demidov na conferência .
Fonte: habr.com