No verão, tanto a atividade de compras quanto a intensidade das mudanças na infraestrutura dos projetos web tradicionalmente diminuem, conta o Capitão Óbvio. Simplesmente porque até os especialistas em TI às vezes saem de férias. E CTO também. É ainda mais difícil para quem permanece no cargo, mas a questão agora não é essa: talvez por isso o verão seja o melhor período para pensar lentamente no esquema de reservas existente e traçar um plano para melhorá-lo. E a experiência de Yegor Andreev de , sobre o qual ele falou na conferência .
Existem várias armadilhas nas quais você pode cair ao criar sites de backup. E é absolutamente impossível ser pego por eles. E o que nos arruína nisso tudo, como em muitas outras coisas, é o perfeccionismo e... a preguiça. Estamos tentando fazer tudo, tudo, tudo perfeitamente, mas não precisamos fazer perfeitamente! Você só precisa fazer certas coisas, mas fazê-las corretamente, concluí-las para que funcionem corretamente.
O failover não é algum tipo de coisa divertida e divertida “que assim seja”; isso é algo que deveria fazer exatamente uma coisa - reduzir o tempo de inatividade para que o serviço, a empresa, perca menos dinheiro. E em todos os métodos de reserva sugiro pensar no seguinte contexto: onde está o dinheiro?
Primeira armadilha: quando construímos sistemas grandes e confiáveis e adotamos redundância, reduzimos o número de acidentes. Este é um equívoco terrível. Quando nos envolvemos em redundância, é provável que aumentemos o número de acidentes. E se fizermos tudo certo, coletivamente reduziremos o tempo de inatividade. Haverá mais acidentes, mas ocorrerão a custos mais baixos. O que é uma reserva? - esta é uma complicação do sistema. Qualquer complicação é ruim: temos mais engrenagens, mais engrenagens, enfim, mais elementos – e, portanto, maior chance de quebra. E eles realmente vão quebrar. E eles vão quebrar com mais frequência. Um exemplo simples: digamos que temos um site com PHP e MySQL. E precisa ser reservado com urgência.
Shtosh (c) Pegamos o segundo site, construímos um sistema idêntico... A complexidade torna-se duas vezes maior - temos duas entidades. Também implementamos uma certa lógica para transferir dados de um site para outro - ou seja, replicação de dados, cópia de dados estáticos e assim por diante. Assim, a lógica de replicação costuma ser muito complexa e, portanto, a complexidade total do sistema pode não ser 2, mas 3, 5, 10 vezes maior.
Segunda armadilha: quando construímos sistemas complexos realmente grandes, fantasiamos sobre o que queremos obter no final. Voila: queremos um sistema superconfiável que funcione sem nenhum tempo de inatividade, mude em meio segundo (ou melhor ainda, instantaneamente) e comecemos a realizar sonhos. Mas também há uma nuance aqui: quanto menor o tempo de comutação desejado, mais complexa se torna a lógica do sistema. Quanto mais complexa tivermos de tornar esta lógica, mais frequentemente o sistema irá falhar. E você pode acabar em uma situação muito desagradável: estamos tentando com todas as nossas forças diminuir o tempo de inatividade, mas na verdade estamos complicando tudo, e quando algo dá errado, o tempo de inatividade vai acabar sendo mais longo. Aqui muitas vezes você se pega pensando: bom... seria melhor não fazer reserva. Seria melhor se funcionasse sozinho e com um tempo de inatividade compreensível.
Como você pode lutar contra isso? Precisamos parar de mentir para nós mesmos, parar de nos gabar de que vamos construir uma nave espacial aqui agora, mas compreender adequadamente quanto tempo o projeto pode durar. E para esse tempo máximo, escolheremos quais métodos realmente usaremos para aumentar a confiabilidade do nosso sistema.
É hora de “histórias de w”... da vida, claro.
Exemplo número um
Imagine um site de cartão de visita da Pipe Rolling Plant No. 1 na cidade de N. Está escrito em letras enormes - PIPE ROLLING PLANT No. Logo abaixo está o slogan: “Nossos canos são os canos mais redondos de N.” E abaixo está o número de telefone do CEO e seu nome. Entendemos que você precisa fazer uma reserva - isso é muito importante! Vamos começar a descobrir em que consiste. Estática HTML - isto é, algumas fotos em que o gerente geral, de fato, está discutindo algum tipo de próximo negócio à mesa do balneário com seu parceiro. Começamos a pensar no tempo de inatividade. Vem à mente: você precisa ficar deitado ali por cinco minutos, não mais. E aí surge a pergunta: quantas vendas foram feitas nesse nosso site em geral? Quanto, quanto? O que significa “zero”? E isso significa: porque o general fez as quatro transações do ano passado na mesma mesa, com as mesmas pessoas com quem vai ao balneário e se senta à mesa. E entendemos que mesmo que o site fique parado por um dia, nada de terrível acontecerá.
Com base nas informações introdutórias, há um dia para contar essa história. Vamos começar a pensar em um esquema de redundância. E escolhemos o esquema de redundância ideal para este exemplo: não usamos redundância. Essa coisa toda pode ser levantada por qualquer administrador em meia hora com pausas para fumar. Instale um servidor web, adicione arquivos - é isso. Vai funcionar. Você não precisa ficar de olho em nada, não precisa prestar atenção especial em nada. Ou seja, a conclusão do exemplo número um é bastante óbvia: os serviços que não precisam de ser reservados não precisam de ser reservados.
Exemplo número dois
Blog da empresa: lá pessoas especialmente treinadas escrevem notícias, participamos de tal e tal exposição, mas lançamos outro novo produto e assim por diante. Digamos que este seja PHP padrão com WordPress, um banco de dados pequeno e um pouco de estática. Claro, mais uma vez me vem à mente que você não deve, em nenhuma circunstância, deitar-se - “não mais que cinco minutos!” Isso é tudo. Mas vamos pensar mais. O que este blog faz? As pessoas chegam lá do Yandex, do Google com base em algumas consultas, organicamente. Ótimo. As vendas têm algo a ver com isso? Epifania: na verdade não. O tráfego publicitário vai para o site principal, que fica em uma máquina diferente. Vamos começar a pensar em um esquema de reserva. No bom sentido, ele precisa ser aumentado em algumas horas, e seria bom se preparar para isso. Seria razoável pegar uma máquina de outro data center, colocar nela o ambiente, ou seja, um servidor web, PHP, WordPress, MySQL, e deixar lá. No momento em que entendemos que tudo está quebrado, precisamos fazer duas coisas - lançar o dump do mysql 50 metros, ele voará até lá em um minuto, e lançar um certo número de fotos do backup lá. Isso também não existe por Deus sabe por quanto tempo. Assim, em meia hora tudo sobe. Sem replicação, ou Deus me perdoe, failover automático. Conclusão: o que podemos implementar rapidamente a partir de um backup não precisa de backup.
Exemplo número três, mais complicado
Loja online. PHP de coração aberto é um pouco ajustado, mysql com base sólida. Muita estática (afinal, a loja online tem lindas imagens HD e tudo mais), Redis para sessão e Elasticsearch para busca. Começamos a pensar no tempo de inatividade. E aqui, é claro, é óbvio que uma loja online não pode ficar parada por um dia sem dor. Afinal, quanto mais tempo permanecer, mais dinheiro perderemos. Vale a pena acelerar. Quanto? Acho que se ficarmos deitados por uma hora, ninguém vai enlouquecer. Sim, perderemos alguma coisa, mas se começarmos a trabalhar duro, só vai piorar. Definimos um esquema de tempo de inatividade permitido por hora.
Como tudo isso pode ser reservado? De qualquer forma, você precisa de um carro: uma hora é muito pouco. Mysql: aqui já precisamos de replicação, replicação ao vivo, porque em uma hora provavelmente não serão adicionados 100 GB ao dump. Estática, imagens: novamente, em uma hora, 500 GB podem não ter tempo para serem adicionados. Portanto, é melhor copiar as fotos imediatamente. Redis: é aqui que as coisas ficam interessantes. No Redis, as sessões são armazenadas – não podemos simplesmente pegá-las e enterrá-las. Porque isso não será muito bom: todos os usuários serão desconectados, suas cestas serão esvaziadas e assim por diante. As pessoas serão forçadas a inserir novamente seu nome de usuário e senha, e muitas pessoas poderão desistir e não concluir a compra. Novamente, as conversões cairão. Por outro lado, o Redis está diretamente atualizado, e os últimos usuários logados provavelmente também não serão necessários. E um bom compromisso é pegar o Redis e restaurá-lo a partir de um backup de ontem ou, se você fizer isso a cada hora, de uma hora atrás. Felizmente, restaurá-lo a partir de um backup significa copiar um arquivo. E a história mais interessante é a do Elasticsearch. Quem já pegou a replicação do MySQL? Quem já pegou a replicação do Elasticsearch? E para quem funcionou normalmente depois? O que quero dizer é que vemos uma determinada entidade em nosso sistema. Parece ser útil – mas é complexo.
Complexo no sentido de que nossos colegas engenheiros não têm experiência em trabalhar com isso. Ou há uma experiência negativa. Ou entendemos que esta ainda é uma tecnologia relativamente nova, com nuances ou crueza. Achamos... Caramba, o elástico também está íntegro, também demora muito para restaurá-lo de um backup, o que devo fazer? Entendemos que o elástico no nosso caso é usado para pesquisa. Como nossa loja online vende? Procuramos os profissionais de marketing e perguntamos de onde vêm as pessoas. Eles respondem: “90% do Yandex Market vem diretamente para o cartão do produto”. E ou eles compram ou não. Portanto, a pesquisa é necessária para 10% dos usuários. E manter a replicação elástica, especialmente entre data centers diferentes em zonas diferentes, realmente tem muitas nuances. Qual saída? Pegamos elástico de um site reservado e não fazemos nada com ele. Se o assunto se arrastar, provavelmente iremos abordá-lo algum dia, mas isso não é certo. Na verdade, a conclusão é a mesma, mais ou menos: nós, novamente, não reservamos serviços que não afetem o dinheiro. Para manter o diagrama mais simples.
Exemplo número quatro, ainda mais difícil
Integrador: vender flores, chamar táxi, vender mercadorias, em geral, qualquer coisa. Uma coisa séria que funciona 24 horas por dia, 7 dias por semana, para um grande número de usuários. Com uma pilha completa e interessante, onde existem bases, soluções interessantes, carga alta e, o mais importante, dói ficar deitado por mais de 5 minutos. Não só e não tanto porque as pessoas não vão comprar, mas porque as pessoas vão ver que isso não funciona, vão ficar chateadas e podem nem voltar.
OK. Cinco minutos. O que vamos fazer sobre isso? Nesse caso, nós, como adultos, usamos todo o dinheiro para construir um verdadeiro site de backup, com replicação de tudo, e quem sabe até automatizar ao máximo a mudança para esse site. E além disso, você precisa se lembrar de fazer uma coisa importante: na verdade, escrever os regulamentos de troca. Os regulamentos, mesmo que você tenha tudo automatizado, podem ser muito simples. Da série “executar tal e tal script ansible”, “clique em tal e tal caixa de seleção na rota 53” e assim por diante - mas deve ser algum tipo de lista exata de ações.
E tudo parece claro. Alternar a replicação é uma tarefa trivial, ou ela mudará sozinha. Reescrever um nome de domínio no DNS é da mesma série. O problema é que quando tal projeto falha, o pânico começa, e até mesmo os administradores barbudos mais fortes podem ser suscetíveis a isso. Sem instruções claras “abra o terminal, venha aqui, o endereço do nosso servidor ainda é assim”, é difícil cumprir o prazo de 5 minutos previsto para a reanimação. Bem, além disso, quando utilizamos estes regulamentos, é fácil registar algumas alterações na infra-estrutura, por exemplo, e alterar os regulamentos em conformidade.
Bem, se o sistema de reservas for muito complexo e em algum momento cometemos um erro, então podemos destruir nosso site de backup e, além disso, transformar os dados em abóboras em ambos os sites - isso será completamente triste.
Exemplo número cinco, hardcore completo
Um serviço internacional com centenas de milhões de usuários em todo o mundo. Todos os fusos horários que existem, carga alta em velocidade máxima, você não consegue deitar de jeito nenhum. Um minuto - e será triste. O que fazer? Reserve, novamente, de acordo com o programa completo. Fizemos tudo o que falei no exemplo anterior e um pouco mais. Um mundo ideal, e nossa infraestrutura está de acordo com todos os conceitos do IaaC devops. Ou seja, está tudo no git, basta apertar o botão.
O que está faltando? Um são exercícios. É impossível sem eles. Parece que tudo está perfeito conosco, geralmente temos tudo sob controle. Apertamos o botão, tudo acontece. Mesmo que seja assim - e entendemos que não é assim - nosso sistema interage com alguns outros sistemas. Por exemplo, este é o DNS da rota 53, armazenamento s3, integração com alguma API. Não seremos capazes de prever tudo nesta experiência especulativa. E até que realmente puxemos o interruptor, não saberemos se funcionará ou não.
Provavelmente é tudo. Não seja preguiçoso nem exagere. E que o tempo de atividade esteja com você!
Fonte: habr.com