In estate tradizionalmente diminuiscono sia l'attività degli acquirenti sia l'intensità dei cambiamenti nell'infrastruttura dei progetti web, come ci dice il Capitano Ovvio. Semplicemente perché anche gli informatici, a volte, vanno in vacanza. E anche i CTO. È particolarmente difficile per chi rimane in servizio, ma non è questo il punto: probabilmente è proprio per questo che l'estate è il miglior periodo per riflettere con calma sul sistema di backup esistente e pianificare il suo miglioramento. E in questo vi sarà utile l'esperienza di Egor Andreev di , di cui ha parlato alla conferenza .
Nella costruzione di siti di backup, ci sono diverse trappole in cui è possibile cadere. Ed è assolutamente da evitare cadere in esse. A farci del male in tutto questo, come in molte altre cose, è il perfezionismo e… la pigrizia. Cerchiamo di fare tutto alla perfezione, ma non è necessario farlo in modo perfetto! È importante fare solo alcune cose, ma farle bene, portarle a termine, affinché funzionino correttamente.
Il failover non è una cosa divertente giusto per il gusto di farlo; è qualcosa che deve fare una sola cosa: ridurre i tempi di inattività, affinché il servizio e l'azienda perdano meno denaro. In tutti i metodi di riserva, propongo di pensare nel seguente contesto: dove sono i soldi?
La prima trappola: quando costruiamo grandi sistemi affidabili e ci occupiamo di riserva, riduciamo il numero di guasti. Questo è un terribile fraintendimento. Quando ci occupiamo di riserva, è probabile che il numero di guasti aumenti. E se facciamo tutto correttamente, ridurremo il tempo di inattività complessivo. Ci saranno più guasti, ma si verificheranno con costi ridotti. Cos'è la riserva? È un complicazione del sistema. Qualsiasi complicazione è negativa: abbiamo più viti, più ingranaggi, insomma, più elementi — e quindi una maggiore probabilità di guasto. E si guasteranno davvero. E si guasteranno più spesso. Un semplice esempio: supponiamo di avere un sito web, con PHP e MySQL. E deve essere urgentemente messo in riserva.
Dunque (c) Prendiamo un secondo sito, costruiamo un sistema identico... La complessità raddoppia: abbiamo due entità. Inoltre, sovrapponiamo una certa logica di trasferimento dei dati da un sito all'altro, ovvero la replicazione dei dati, la copia della statica e così via. Ecco, la logica di replicazione è solitamente molto complessa, quindi la complessità complessiva del sistema può essere non 2, bensì 3, 5, 10 volte maggiore.
La seconda trappola: quando costruiamo sistemi veramente complessi e di grandi dimensioni, immaginiamo cosa vogliamo ottenere alla fine. Ecco la magia: vogliamo un sistema super affidabile, che funzioni senza alcun downtime, che commuti in mezzo secondo (o meglio, istantaneamente), e iniziamo a realizzare i nostri sogni. Ma qui c'è un punto da considerare: più breve è il tempo di commutazione desiderato, più complessa diventa la logica del sistema. Più complessa deve essere questa logica, più spesso il sistema si guasterà. E si può finire in una situazione molto scomoda: ci sforziamo al massimo di ridurre il tempo di inattività, ma in realtà rendiamo tutto più complicato, e quando qualcosa va storto, il tempo di inattività alla fine sarà maggiore. Spesso ti ritrovi a pensare: ecco… sarebbe stato meglio non avere riserve. Sarebbe stato meglio avere un solo sistema funzionante con un tempo di inattività comprensibile.
Come possiamo affrontare questo problema? Dobbiamo smettere di mentire a noi stessi, smettere di illuderci che stiamo costruendo un razzo spaziale, e capire realisticamente quanto tempo il progetto può rimanere in sospeso. E in base a questo tempo massimo, sceglieremo quali metodi utilizzare per aumentare l'affidabilità del nostro sistema.
È tempo per "storie da..."... dalla vita, naturalmente.
Esempio numero uno
Immagina un sito di presentazione per la fabbrica di tubi n. 1 della città di N. Con scritto in caratteri enormi — FABBRICA DI TUBI N. 1. Poco sotto — il motto: "I nostri tubi sono i tubi più rotondi di N". E in fondo il numero di telefono del direttore generale e il suo nome. Comprendiamo che è necessario prenotare — è una cosa molto importante! Iniziamo a capire di cosa si compone. Staticità in HTML — due immagini, dove il direttore, in effetti, è al tavolo nella sauna con il suo partner discutendo di un'ulteriore trattativa. Iniziamo a pensare al tempo di inattività. Ci viene in mente: ci si deve stare per cinque minuti, non di più. E qui sorge la domanda: quante vendite ci sono state da questo nostro sito? Quante? Cosa vuol dire "zero"? In effetti significa: perché tutte e quattro le trattative dello scorso anno il direttore le ha fatte allo stesso tavolo, con le stesse persone, con cui siede al tavolo nella sauna. E capiamo che anche se il sito rimane inattivo per un giorno, non succederà nulla di terribile.
In base alle informazioni fornite, c'è un giorno per sollevare questa questione. Iniziamo a pensare allo schema di riserva. E scegliamo il piano di riserva ideale per questo esempio: non utilizziamo la riserva. Questa cosa può essere impostata da qualsiasi amministratore in mezz'ora, comprese le pause. Installare un server web, caricare i file — tutto qui. Funzionerà. Non è necessario tenere d'occhio nulla, non è richiesta un'attenzione particolare. Dunque, la conclusione del primo esempio è piuttosto ovvia: i servizi che non richiedono riserva — non vanno riservati.
Esempio numero due
Blog dell'azienda: persone appositamente addestrate scrivono notizie, ad esempio, abbiamo partecipato a una certa fiera, ecco un altro nuovo prodotto e così via. Supponiamo che si tratti di un PHP standard con WordPress, un piccolo database e un po' di statico. Naturalmente, ci viene in mente di non rimanere inattivi — "non più di cinque minuti!", tutte queste cose. Ma riflettiamo oltre. Cosa fa questo blog? Le persone arrivano da Yandex, da Google per alcune ricerche, per il traffico organico. Ottimo. E le vendite sono in qualche modo collegate? Rivelazione: non proprio. Il traffico pubblicitario va al sito principale, che si trova su un'altra macchina. Iniziamo a pensare a uno schema di backup per il blog. In modo ideale, dovrebbe essere avviato in poche ore, e sarebbe utile prepararsi a questo. Sarebbe ragionevole prendere un'altra macchina in un altro data center, installarvi l'ambiente, quindi web server, PHP, WordPress, MySQL, e lasciarlo inattivo. Nel momento in cui capiamo che tutto è andato in pezzi, dobbiamo fare due cose: ripristinare un dump mysql di 50 MB, che impiegherà un minuto, e ripristinare un certo numero di immagini dal backup. Anche questo non richiede molto. In questo modo, in mezz'ora, tutto questo viene ripristinato. Niente repliche, né, Dio non voglia, failover automatico. Conclusione: ciò che possiamo ripristinare rapidamente dal backup non ha bisogno di essere riservato.
Esempio numero tre, un po' più complesso
Negozio online. PHP con un cuore aperto leggermente modificato, MySQL con una solida base. Abbondanza di statiche (dopotutto, in un negozio online ci sono belle immagini in alta definizione e tutto il resto), Redis per le sessioni ed Elasticsearch per la ricerca. Iniziamo a riflettere sui tempi di inattività. Qui è chiaro che un giorno il negozio online non può rimanere inattivo senza conseguenze. Più a lungo rimane fermo, più denaro perdiamo. È tempo di agire. Ma quanto? Suppongo che se rimaniamo inattivi per un'ora, nessuno impazzirà. Sì, perderemo qualcosa, ma se iniziamo a lavorare duro, le cose si faranno solo più complicate. Definiamo lo schema di inattività tollerabile in un'ora.
Come si può riservare tutto questo? La macchina è necessaria in ogni caso: un'ora è davvero poco. Mysql: qui è necessaria la replica, una replica in tempo reale, perché in un'ora 100 GB in dump probabilmente non riusciranno a entrare. Statica, immagini: anche qui 500 GB potrebbero non arrivare in un'ora. Quindi, è meglio copiare subito le immagini. Redis: qui diventa interessante. Le sessioni sono memorizzate in Redis — non possiamo semplicemente eliminarlo. Perché non sarebbe affatto bene: tutti gli utenti si troveranno disconnessi, i carrelli svuotati, e così via. Le persone dovranno reinserire il proprio login e password, e molti potrebbero abbandonare l'acquisto. Anche in questo caso, la conversione diminuirà. D'altra parte, Redis è attualmente in uso, e probabilmente non sarà necessario avere esattamente gli ultimi utenti loggati. Un buon compromesso sarebbe prendersi Redis e ripristinarlo da un backup, di ieri, oppure, se lo create ogni ora, da un'ora fa. Fortunatamente, il ripristino da un backup richiede solo la copia di un file. E la storia più interessante riguarda Elasticsearch. Chi ha mai impostato la replica di MySQL? Chi ha mai impostato la replica di Elasticsearch? E a chi ha funzionato normalmente dopo? A cosa mi riferisco: vediamo nella nostra azienda una certa entità. Sembra utile — ma è complessa.
È complicato nel senso che i nostri colleghi ingegneri non hanno esperienza con essa. O hanno avuto esperienze negative. Oppure capiamo che questa è una tecnologia piuttosto nuova con le sue complessità e imperfezioni. Pensiamo... accidenti, anche elastic è grande, ci vuole tempo per ripristinarlo da un backup, cosa facciamo? Comprendiamo che elastic in questo caso è usato per la ricerca. E come vende il nostro negozio online? Ci rivolgiamo ai marketer, chiediamo da dove arrivano le persone. Loro rispondono: "Il 90% proviene direttamente da Yandex.Market nella scheda del prodotto". E comprano o non comprano. Di conseguenza, la ricerca è necessaria per il 10% degli utenti. Mantenere la replica di elastic, soprattutto tra diversi data center in diverse zone, comporta davvero molte complessità. Qual è l'uscita? Prendiamo elastic su una piattaforma riservata e non facciamo nulla con esso. Se la questione si protrae, potremmo attivarlo in un secondo momento, ma non è certo. Dunque, la conclusione è più o meno la stessa: i servizi che non influiscono sulle finanze, di nuovo, non li riserviamo. Per mantenere la configurazione più semplice.
Esempio numero quattro, ancora più complicato
Integratore: vendite di fiori, chiamate taxi, vendita di beni, insomma, qualsiasi cosa. È un'operazione seria, che funziona 24/7 per un alto numero di utenti. Con un stack interessante, in cui ci sono basi interessanti, soluzioni, alta richiesta, e soprattutto, non dovrebbe restare inattivo per più di 5 minuti. Non solo perché le persone non comprerebbero, ma anche perché vedrebbero che questo non funziona, si arrabbierebbero e potrebbero non tornare mai più.
Ok. Cinque minuti. Cosa facciamo a questo punto? In questo caso, costruiremo in modo serio, con ogni risorsa, un vero e proprio ambiente di backup, con replicazione di tutto e di più, e forse cercheremo anche di automatizzare al massimo il passaggio a questo ambiente. Inoltre, non dobbiamo dimenticare di fare una cosa importante: infatti, scrivere una procedura di commutazione. La procedura, anche se abbiamo automatizzato tutto, può essere molto semplice. Tipo "lanciare un certo script ansible", "selezionare una certa opzione in route 53", e così via — ma deve essere un elenco preciso di azioni.
E sembra tutto chiaro. Passare alla replica è un compito banale, oppure si attiverà automaticamente. Riscrivere il nome di dominio nel DNS rientra nella stessa categoria. Il problema è che quando un progetto del genere fallisce, scatta la panico e persino gli admin più esperti e navigati possono esserne colpiti. Senza istruzioni chiare come "apri il terminale, vai qui, l'indirizzo del nostro server è ancora questo", mantenere il tempo di 5 minuti per la rianimazione diventa difficile. Inoltre, quando utilizziamo questo regolamento, è facile registrare eventuali cambiamenti nell'infrastruttura, ad esempio, e modificare il regolamento di conseguenza.
Ma se il sistema di riserva è molto complesso e in un certo momento abbiamo commesso un errore, possiamo compromettere anche il nostro ambiente di riserva e, in aggiunta, trasformare i dati in zucche in entrambi gli ambienti — sarebbe davvero triste.
Esempio numero cinque, hardcore completo
Un servizio internazionale con centinaia di milioni di utenti in tutto il mondo. Tutti i fusi orari che esistono, highload al massimo, non ci si può permettere di fermarsi. Un minuto e sarà brutto. Cosa fare? Prenotare, ancora una volta, completamente. Abbiamo fatto tutto ciò di cui abbiamo parlato nell'esempio precedente, e anche un po' di più. Un mondo ideale, e la nostra infrastruttura è secondo i principi dell'IaaC DevOps. Cioè, tutto in git, e basta premere un pulsante.
Cosa manca? Una cosa: l'esercizio. Senza di esso non si può. Sembra che tutto sia perfetto, abbiamo tutto sotto controllo. Premi il pulsante e tutto accade. Anche se fosse così — e sappiamo che così non è — il nostro sistema interagisce con altri sistemi. Ad esempio, ci sono DNS da route 53, archiviazione s3, integrazione con alcune API. Non riusciremo a prevedere tutto in questo esperimento teorico. E finché non attiviamo realmente l'interruttore, non sapremo se funzionerà o meno.
Su questo, probabilmente, è tutto. Non siate pigri e non esagerate. Che il uptime sia con voi!
Fonte: habr.com
