No verán, tanto a actividade de compras como a intensidade dos cambios na infraestrutura dos proxectos web tradicionalmente diminúen, dinos o capitán Obvious. Simplemente porque ata os especialistas en TI ás veces van de vacacións. E CTO tamén. Tanto máis é difícil para os que seguen no cargo, pero non é ese o punto agora: quizais por iso o verán sexa o mellor período para pensar pouco a pouco no esquema de reservas existente e elaborar un plan para melloralo. E a experiencia de Yegor Andreev de , do que falou na conferencia .
Hai varias trampas nas que podes caer ao crear sitios de copia de seguridade. E é absolutamente imposible quedar atrapado neles. E o que nos estraga en todo isto, como en moitas outras cousas, é o perfeccionismo e... a preguiza. Estamos tentando facelo todo, todo, todo perfectamente, pero non necesitamos facelo perfectamente! Só tes que facer certas cousas, pero facelas correctamente, complétaas para que funcionen correctamente.
Failover non é un tipo de cousa divertida e divertida "que así sexa"; isto é algo que debería facer exactamente unha cousa: reducir o tempo de inactividade para que o servizo, a empresa, perda menos diñeiro. E en todos os métodos de reserva, suxiro pensar no seguinte contexto: onde está o diñeiro?
Primeira trampa: cando construímos sistemas grandes e fiables e participamos na redundancia, reducimos o número de accidentes. Este é un equívoco terrible. Cando participamos en despedimentos, é probable que aumentemos o número de accidentes. E se facemos todo ben, entón colectivamente reduciremos o tempo de inactividade. Haberá máis accidentes, pero produciranse a menor custo. Que é unha reserva? - Esta é unha complicación do sistema. Calquera complicación é mala: temos máis engrenaxes, máis engrenaxes, nunha palabra, máis elementos e, polo tanto, unha maior probabilidade de avaría. E realmente romperán. E romperán con máis frecuencia. Un exemplo sinxelo: digamos que temos un sitio web con PHP e MySQL. E é urxente reservalo.
Shtosh (c) Tomamos o segundo sitio, construímos un sistema idéntico... A complexidade faise o dobre: temos dúas entidades. Tamén implementamos unha certa lóxica para transferir datos dun sitio a outro, é dicir, a replicación de datos, a copia de datos estáticos, etc. Entón, a lóxica de replicación adoita ser moi complexa e, polo tanto, a complexidade total do sistema pode ser non 2, senón 3, 5, 10 veces maior.
Segunda trampa: cando construímos sistemas complexos realmente grandes, fantaseamos co que queremos conseguir ao final. Voila: queremos conseguir un sistema súper fiable que funcione sen ningún tempo de inactividade, cambie en medio segundo (ou mellor aínda, ao instante) e comecemos a facer realidade os soños. Pero tamén hai un matiz aquí: canto máis curto sexa o tempo de conmutación desexado, máis complexa se fai a lóxica do sistema. Canto máis complexo teñamos que facer esta lóxica, máis a miúdo se romperá o sistema. E podes acabar nunha situación moi desagradable: estamos intentando con todas as nosas forzas reducir o tempo de inactividade, pero de feito facémolo todo máis complicado e, cando algo vai mal, o tempo de inactividade acabará sendo máis longo. Aquí tes moitas veces a pensar: bueno... mellor non facer reserva. Sería mellor que funcionase só e cun tempo de inactividade comprensible.
Como podes loitar contra isto? Necesitamos deixar de mentirnos a nós mesmos, deixar de halagarnos de que imos construír unha nave espacial aquí agora, pero comprender adecuadamente canto tempo pode durar o proxecto. E durante este tempo máximo, escolleremos que métodos utilizaremos realmente para aumentar a fiabilidade do noso sistema.
Chegou o momento das “historias de w”... da vida, claro.
Exemplo número un
Imaxina un sitio web de tarxetas de visita para a planta de laminación de tubos número 1 da cidade de N. Di en letras enormes: PLANTA DE LAMINACIÓN DE TUBERÍAS número 1. Xusto debaixo está o slogan: "Os nosos tubos son os tubos máis redondos de N". E debaixo está o número de teléfono do CEO e o seu nome. Entendemos que cómpre facer unha reserva - isto é moi importante! Comecemos a descubrir en que consiste. Html-statics - é dicir, un par de imaxes onde o director xeral, de feito, está a discutir algún tipo de próximo acordo na mesa da casa de baños co seu compañeiro. Comezamos a pensar no tempo de inactividade. Vénme á mente: hai que estar alí deitado cinco minutos, sen máis. E entón xorde a pregunta: cantas vendas houbo deste sitio noso en xeral? Canto-canto? Que significa "cero"? E iso quere dicir: porque o xeneral fixo as catro transaccións o ano pasado na mesma mesa, coas mesmas persoas coas que van ao baño e sentan á mesa. E entendemos que aínda que o sitio permaneza un día, non pasará nada terrible.
A partir da información introdutoria, hai un día para plantexar esta historia. Comecemos a pensar nun esquema de redundancia. E escollemos o esquema de redundancia máis ideal para este exemplo: non usamos a redundancia. Todo isto pode ser levantado por calquera administrador en media hora con pausas de fume. Instala un servidor web, engade ficheiros, iso é todo. Funcionará. Non é preciso estar atento a nada, non é preciso prestarlle especial atención a nada. É dicir, a conclusión do exemplo número un é bastante obvia: os servizos que non precisan ser reservados non precisan ser reservados.
Exemplo número dous
Blog da empresa: xente especialmente formada escribe noticias alí, participamos en tal ou cal exposición, pero estreamos outro produto novo, etc. Digamos que isto é PHP estándar con WordPress, unha pequena base de datos e un pouco de estática. Por suposto, volve á mente que non debes deitar en ningún caso: "non máis de cinco minutos!" Iso é todo. Pero pensemos máis. Que fai este blog? A xente vén alí de Yandex, de Google en base a algunhas consultas, de xeito orgánico. Genial. Teñen algo que ver as vendas? Epifanía: non realmente. O tráfico de publicidade vai ao sitio principal, que está nunha máquina diferente. Comecemos a pensar nun esquema de reserva. En boa forma, hai que levantalo nun par de horas, e sería bo prepararse para iso. Sería razoable coller unha máquina doutro centro de datos, rodar o ambiente nela, é dicir, un servidor web, PHP, WordPress, MySQL, e deixalo alí. No momento no que entendemos que todo está roto, debemos facer dúas cousas: lanzar o vertedoiro de mysql a 50 metros, voará alí nun minuto e lanzará alí un certo número de imaxes da copia de seguridade. Isto tampouco está aí porque Deus sabe canto tempo. Así, en media hora sobe todo. Sen replicación, ou Deus me perdoe, conmutación automática por falla automática. Conclusión: o que podemos lanzar rapidamente a partir dunha copia de seguranza non necesita facer unha copia de seguranza.
Exemplo número tres, máis complicado
Tenda en liña. PhP con corazón aberto está un pouco modificado, mysql cunha base sólida. Moita estática (despois de todo, a tenda en liña ten fermosas imaxes en HD e todas esas cousas), Redis para a sesión e Elasticsearch para a busca. Comezamos a pensar no tempo de inactividade. E aquí, por suposto, é obvio que unha tenda en liña non pode estar un día sen dor. Despois de todo, canto máis tempo estea sentado, máis cartos perdemos. Paga a pena acelerar. Canto? Creo que se nos deitamos unha hora, ninguén se volverá tolo. Si, algo perderemos, pero se empezamos a traballar duro, só empeorará. Definimos un esquema de tempo de inactividade permitido por hora.
Como se pode reservar todo isto? Necesitas un coche en calquera caso: unha hora de tempo é bastante pouca. Mysql: aquí xa necesitamos replicación, replicación en directo, porque nunha hora probablemente non se engaden 100 GB ao vertedoiro. Estática, imaxes: de novo, nunha hora 500 GB poden non ter tempo de engadirse. Polo tanto, é mellor copiar as imaxes inmediatamente. Redis: aquí é onde as cousas se poñen interesantes. En Redis, as sesións almacénanse; non podemos simplemente tomalas e enterralas. Porque isto non será moi bo: todos os usuarios pecharanse, baleiraranse as súas cestas, etc. As persoas veranse obrigadas a introducir de novo o seu nome de usuario e contrasinal, e moitas persoas poden separarse e non completar a compra. De novo, as conversións baixarán. Por outra banda, Redis está directamente actualizado, e probablemente tampouco sexan necesarios os últimos usuarios conectados. E un bo compromiso é tomar Redis e restauralo a partir dunha copia de seguridade de onte ou, se o fas cada hora, desde hai unha hora. Afortunadamente, restauralo desde unha copia de seguridade significa copiar un ficheiro. E a historia máis interesante é Elasticsearch. Quen colleu algunha vez a replicación de MySQL? Quen colleu algunha vez a replicación de Elasticsearch? E para quen funcionou normalmente despois? O que quero dicir é que vemos unha determinada entidade no noso sistema. Parece útil, pero é complexo.
Complexo no sentido de que os nosos compañeiros enxeñeiros non teñen experiencia traballando con el. Ou hai unha experiencia negativa. Ou entendemos que esta aínda é unha tecnoloxía bastante nova con matices ou crudeza. Pensamos... Caramba, o elástico tamén é saudable, tamén leva moito tempo restauralo desde unha copia de seguridade, que debo facer? Entendemos que o elástico no noso caso utilízase para a busca. Como vende a nosa tenda en liña? Imos aos comerciantes e preguntamos de onde vén a xente en xeral. Eles responden: "O 90% de Yandex Market chega directamente á tarxeta do produto". E ou o compran ou non. Polo tanto, a busca é necesaria para o 10% dos usuarios. E manter a replicación elástica, especialmente entre diferentes centros de datos en diferentes zonas, realmente ten moitos matices. Que saída? Collemos o elástico dun sitio reservado e non facemos nada con el. Se o caso se prolonga, poderemos plantexalo algún día, pero iso non é certo. En realidade, a conclusión é a mesma, máis ou menos: nós, de novo, non reservamos servizos que non afecten ao diñeiro. Para que o diagrama sexa máis sinxelo.
Exemplo número catro, aínda máis difícil
Integrador: vender flores, chamar a un taxi, vender mercadorías, en xeral, calquera cousa. Unha cousa seria que funciona 24/7 para un gran número de usuarios. Cunha pila interesante en toda regla, onde hai bases interesantes, solucións, carga elevada e, o máis importante, doe deitarse durante máis de 5 minutos. Non só e non tanto porque a xente non compre, senón porque a xente verá que isto non funciona, enfadarase e quizais non volva nada.
OK. Cinco minutos. Que imos facer con isto? Neste caso, nós, como os adultos, usamos todo o diñeiro para construír un sitio de copia de seguridade real, con replicación de todo, e quizais mesmo automatizamos o cambio a este sitio na medida do posible. E ademais disto, cómpre lembrar de facer unha cousa importante: en realidade, escribir as normas de cambio. A normativa, aínda que teñas todo automatizado, pode ser moi sinxela. Da serie "Executar tal ou cal script ansible", "faga clic en tal ou cal caixa de verificación na ruta 53" e así por diante, pero esta debe ser unha especie de lista exacta de accións.
E todo parece claro. Cambiar a replicación é unha tarefa trivial, ou cambiará por si mesmo. Reescribir un nome de dominio en DNS é da mesma serie. O problema é que cando un proxecto deste tipo falla, comeza o pánico e mesmo os administradores máis fortes e barbudos poden ser susceptibles a iso. Sen instrucións claras "abre o terminal, ven aquí, o enderezo do noso servidor segue sendo así", é difícil cumprir o límite de tempo de 5 minutos asignado para a reanimación. Pois ademais, cando usamos esta normativa, é fácil rexistrar algúns cambios na infraestrutura, por exemplo, e cambiar a normativa en consecuencia.
Ben, se o sistema de reserva é moi complexo e nalgún momento cometemos un erro, entón podemos destruír o noso sitio de copia de seguridade e, ademais, converter os datos nunha cabaza en ambos os sitios, isto será completamente triste.
Exemplo número cinco, hardcore completo
Un servizo internacional con centos de millóns de usuarios en todo o mundo. Todos os fusos horarios que hai, alta carga á máxima velocidade, non te podes deitar nada. Un minuto - e será triste. Que facer? Reserva, de novo, segundo o programa completo. Fixemos todo o que falei no exemplo anterior, e un pouco máis. Un mundo ideal, e a nosa infraestrutura está de acordo con todos os conceptos dos devops de IaaC. É dicir, todo está en git, e só tes que premer o botón.
Que falta? Un - exercicios. É imposible sen eles. Parece que todo é perfecto con nós, polo xeral temos todo controlado. Prememos o botón, todo pasa. Aínda que isto sexa así -e entendemos que non ocorre así- o noso sistema interactúa con algúns outros sistemas. Por exemplo, isto é dns da ruta 53, almacenamento s3, integración con algunha API. Non poderemos prever todo neste experimento especulativo. E ata que realmente tiremos do interruptor, non saberemos se funcionará ou non.
Iso probablemente sexa todo. Non sexas preguiceiro nin esaxeres. E que o tempo de actividade estea contigo!
Fonte: www.habr.com