Ad oggi, il servizio «Bitrix24» non ha centinaia di gigabit di traffico né un enorme parco server (anche se, ovviamente, ce ne sono parecchi). Tuttavia, per molti clienti rappresenta uno strumento fondamentale per il lavoro in azienda, un'applicazione veramente business-critical. Quindi, cadere — è fuori discussione. E se la caduta si fosse comunque verificata, ma il servizio è «resuscitato» così rapidamente che nessuno se ne è accorto? E come riescono a implementare il failover senza perdere qualità del servizio e numero di clienti? Alexander Demidov, direttore della divisione dei servizi cloud di «Bitrix24», ci ha raccontato nel nostro blog come nel corso di 7 anni di esistenza del prodotto si sia evoluto il sistema di riservazione.
Abbiamo lanciato "Bitrix24" 7 anni fa in formato SaaS. La principale difficoltà, probabilmente, è stata la seguente: prima del lancio pubblico come SaaS, questo prodotto esisteva semplicemente come soluzione software confezionata. I clienti lo acquistavano da noi, lo installavano sui propri server, creavano un portale aziendale — una soluzione generale per la comunicazione fra i dipendenti, l'archiviazione di file, la gestione delle attività, CRM, e così via. Fino al 2012 abbiamo deciso di lanciarlo come SaaS, gestendolo autonomamente e garantendo resilienza e affidabilità. Abbiamo acquisito esperienza nel processo, poiché fino ad allora non ne avevamo — eravamo solo produttori di software, non fornitori di servizi.
Lanciando il servizio, sapevamo che l'aspetto principale era garantire resilienza, affidabilità e disponibilità costante del servizio, perché se hai un semplice sito web, un negozio ad esempio, e questo si blocca per un'ora, ne soffri solo tu, perdi ordini e clienti, ma per il tuo cliente non è così critico. Può sentirsi deluso, certo, ma andrà a comprare altrove. Ma se si tratta di un'applicazione su cui si basa tutto il lavoro interno dell'azienda, le comunicazioni, le decisioni, allora è fondamentale conquistare la fiducia degli utenti, cioè non tradirli e non farli cadere. Perché tutto il lavoro può fermarsi se qualcosa all'interno smette di funzionare.
Bitrix24 come SaaS
Il primo prototipo è stato realizzato un anno prima del lancio pubblico, nel 2011. È stato assemblato in circa una settimana, l'abbiamo esaminato, ruotato — e funzionava già. Si poteva accedere alla schermata, inserire il nome del portale, e veniva creato un nuovo portale con un database utenti avviato. L'abbiamo valutato e poi ci siamo fermati, continuando a lavorarci per un anno. Avevamo un compito importante: non volevamo creare due diverse basi di codice, non volevamo mantenere un prodotto confezionato separato dalle soluzioni cloud — volevamo unificarli in un unico codice.
Un'applicazione web tipica per quell'epoca era un singolo server su cui girava un codice PHP, con un database MySQL, file caricati, documenti e immagini memorizzati nella cartella upload — e funzionava. Purtroppo, non è possibile avviare un servizio web critico in modo sostenibile su questo tipo di struttura. Non supporta un cache distribuito e la replica del database non è prevista.
Abbiamo definito i requisiti: è fondamentale poter operare in diverse località, supportare la replicazione e, idealmente, trovarsi in data center geograficamente distribuiti. Separare la logica del prodotto dallo storage dei dati. Essere in grado di scalare dinamicamente in base al carico, esternalizzando completamente la parte statica. Da queste considerazioni sono emersi, appunto, i requisiti del prodotto che abbiamo sviluppato nel corso dell'anno. Durante questo periodo, abbiamo realizzato una piattaforma unica — per soluzioni on-premise, e per il nostro servizio interno — implementando il supporto per le funzionalità necessarie. Il supporto per la replicazione MySQL a livello di prodotto: il che significa che lo sviluppatore, scrivendo codice, non deve preoccuparsi di come verranno distribuite le sue query; usa la nostra API, e noi gestiamo correttamente la distribuzione delle query di scrittura e lettura tra master e slave.
Abbiamo implementato il supporto per diversi storage object cloud a livello di prodotto: Google Storage, Amazon S3, oltre al supporto per OpenStack Swift. Questo rendeva tutto più conveniente sia per noi come servizio che per gli sviluppatori che lavorano con la soluzione preconfezionata: se utilizzano semplicemente la nostra API per le operazioni, non devono preoccuparsi di dove verrà salvato il file, localmente nel file system o in uno storage object.
Alla fine, abbiamo deciso di prenotare a livello di intero data center. Nel 2012 ci siamo lanciati completamente su Amazon AWS, perché avevamo già esperienza con questa piattaforma: il nostro sito era già ospitato lì. Ci ha attratto il fatto che in ogni regione di Amazon ci sono diverse Availability Zone — fondamentalmente, (nella loro terminologia) più data center che sono più o meno indipendenti tra loro e ci permettono di prenotare a livello di un intero data center: se uno di essi si guasta, i database vengono replicati master-master, i server delle applicazioni web sono riservati e la staticità è spostata nello storage oggetti s3. Il carico è bilanciato — inizialmente con elb di Amazon, ma poco dopo abbiamo adottato i nostri bilanciatori, poiché avevamo bisogno di una logica più complessa.
Quello che volevamo, l'abbiamo ottenuto...
Tutte le cose di base che volevamo garantire — la resilienza dei server, delle applicazioni web e dei database — funzionavano bene. Lo scenario più semplice: se uno delle applicazioni web si guasta, è facile — vengono esclusi dal bilanciamento.
I server bilanciatori che hanno smesso di funzionare (all'epoca si trattava di ELB di Amazon) si segnano da soli come non sani, interrompendo il bilanciamento del carico su di essi. Ha funzionato l'auto-scalabilità di Amazon: quando il carico aumentava, venivano aggiunti nuovi server al gruppo di auto-scalabilità e il carico veniva distribuito sui nuovi server — tutto andava bene. Con i nostri bilanciatori, la logica è sostanzialmente la stessa: se succede qualcosa con il server delle applicazioni, rimuoviamo le richieste, eliminando quei server, avviamo dei nuovi e continuiamo a lavorare. Lo schema è cambiato un po' nel corso degli anni, ma continua a funzionare: è semplice, chiaro e non ci sono complessità a riguardo.
Operiamo in tutto il mondo, i picchi di carico dei clienti sono assolutamente diversi e, a dire il vero, dobbiamo avere la possibilità di eseguire lavori di manutenzione su qualsiasi componente del nostro sistema in qualsiasi momento – senza che i clienti se ne accorgano. Pertanto abbiamo la possibilità di disattivare il database, ridistribuendo il carico sul secondo centro dati.
Come funziona tutto questo? — Devia il traffico verso il data center funzionante: in caso di un guasto del data center, viene deviatato completamente; se si tratta delle nostre operazioni programmate su un singolo database, deviamo una parte del traffico servito a quei clienti verso il secondo data center, sospendendo la replica. Se sono necessarie nuove macchine per le applicazioni web a causa di un aumento del carico nel secondo data center, esse vengono avviate automaticamente. Terminati i lavori, la replica viene ripristinata e riportiamo tutto il carico indietro. Se dobbiamo eseguire lavori speculari nel secondo DC, ad esempio installare aggiornamenti di sistema o modificare impostazioni in un secondo database, ripetiamo fondamentalmente tutto allo stesso modo, solo in direzione opposta. E se si tratta di un guasto, seguiamo semplicemente un processo banale: utilizziamo nel sistema di monitoraggio il meccanismo degli event-handlers. Se vengono attivate diverse verifiche e lo stato passa a critico, si attiva il handler, che può eseguire la logica necessaria. Per ciascun database abbiamo definito quale server sia il failover, e dove deviare il traffico in caso di indisponibilità. Storicamente, usiamo in un modo o nell'altro Nagios o alcune sue varianti. In linea di principio, meccanismi simili sono presenti in quasi tutti i sistemi di monitoraggio; al momento non utilizziamo nulla di più complesso, ma potrebbe accadere in futuro. Ora il monitoraggio si attiva in caso di indisponibilità e ha la capacità di deviare il traffico.
Abbiamo riservato tutto?
Abbiamo molti clienti dagli Stati Uniti, molti clienti dall'Europa, e molti clienti più vicini all'Oriente — Giappone, Singapore e così via. Naturalmente, una grande parte dei clienti è in Russia. Questo significa che operiamo in più di una regione. Gli utenti desiderano risposte rapide e ci sono requisiti di conformità a diverse leggi locali; all'interno di ogni regione, riserviamo due data center, oltre ad alcuni servizi aggiuntivi che, di nuovo, è conveniente posizionare in una sola regione — per i clienti che operano in quella regione. I gestori REST e i server di autorizzazione sono meno critici per il funzionamento del cliente complessivo; per loro è possibile passare con un piccolo ritardo accettabile, ma non vogliamo reinventare la ruota su come monitorarli e cosa fare con loro. Pertanto, cerchiamo di sfruttare al massimo le soluzioni già esistenti, piuttosto che sviluppare competenze su prodotti aggiuntivi. Talvolta utilizziamo semplicemente il trasferimento a livello DNS, e la vivacità del servizio è determinata dallo stesso DNS. Amazon ha il servizio Route 53, ma non è solo un DNS in cui si possono inserire registrazioni e via; è molto più flessibile e conveniente. Con questo servizio si possono costruire servizi geo-distribuiti con geolocalizzazioni, determinando da dove proviene il cliente e fornendogli le registrazioni appropriate — con il suo aiuto si possono realizzare architetture di failover. Anche i health check vengono impostati direttamente in Route 53; si impostano gli endpoint da monitorare, le metriche da considerare, e i protocolli per determinare la "vivacità" del servizio — tcp, http, https; definire la frequenza dei controlli che determinano se il servizio è attivo o meno. E nel DNS si specifica quale sarà il primario, quale il secondario e dove dev'essere effettuato il passaggio se scatta un health check all'interno di Route 53. Tutto questo può essere realizzato con altri strumenti, ma la comodità è che una volta impostato, non dobbiamo più pensare a come vengono eseguiti i controlli o come avviene il passaggio: tutto funziona da solo.
Il primo "ma": e come e con cosa riservare il route 53? Non si sa mai, potrebbe succedere qualcosa! Fortunatamente non ci siamo mai imbattuti in questo problema, ma ancora, ho una storia da raccontare sul perché abbiamo pensato che fosse necessario riservare. Qui stiamo preparando il terreno in anticipo. Diverse volte al giorno, facciamo un'estrazione completa di tutte le zone che abbiamo registrato in route 53. L'API di Amazon permette di restituirle facilmente in formato JSON, e abbiamo attivato diversi server di riserva, dove le convertiamo, le eseguiamo come configurazioni e abbiamo, in parole povere, una configurazione di backup. In caso di necessità, possiamo facilmente ripristinarla manualmente, senza perdere i dati delle impostazioni DNS.
Il secondo "ma": che cosa non è ancora riservato in questa immagine? Solo il bilanciatore! Abbiamo organizzato la distribuzione dei clienti per regioni in modo molto semplice. Abbiamo domini come bitrix24.ru, bitrix24.com, .de — attualmente ne abbiamo circa 13 diversi, che operano in vari ambiti. Siamo giunti alla seguente conclusione: in ogni regione ci sono i nostri bilanciatori. Questo facilita la distribuzione in base a dove si trova il picco del carico di rete. Se si verifica un guasto a uno di questi bilanciatori, viene semplicemente disattivato e rimosso dal DNS. Se ci sono problemi con un gruppo di bilanciatori, questi vengono riservati su altre piattaforme, e il passaggio tra di loro avviene tramite Route53, poiché grazie a un TTL breve il passaggio avviene al massimo in 2, 3, 5 minuti.
Il terzo «ma»: che cos'altro non è riservato? S3, giusto. Quando carichiamo file che conserviamo per gli utenti su S3, credevamo sinceramente che fosse a prova di proiettile e che non ci fosse bisogno di riservare nulla lì. Ma la storia mostra che le cose non stanno così. Infatti, Amazon descrive S3 come un servizio fondamentale, perché lo stesso Amazon utilizza S3 per memorizzare immagini delle macchine, configurazioni, immagini AMI, snapshot... E se S3 va in panne, come è successo una volta in questi 7 anni in cui utilizziamo Bitrix24, porta con sé un sacco di problemi — l'impossibilità di avviare macchine virtuali, guasti nell'API e così via.
E se S3 dovesse crollare — è accaduto una volta. Per questo motivo, siamo giunti al seguente piano: diversi anni fa, in Russia non c'erano seri archivi pubblici per oggetti, ed abbiamo considerato di crearne uno nostro... Per fortuna, non abbiamo iniziato a farlo, perché ci saremmo addentrati in un'esperienza per la quale non eravamo pronti e, senza dubbio, avremmo commesso errori. Oggi ci sono archivi compatibili con S3 offre Mail.ru, Yandex e altri provider. Alla fine, abbiamo concluso che volevamo avere, innanzitutto, un sistema di riserva e, in secondo luogo, la possibilità di lavorare con copie locali. Per la regione specificamente russa, utilizziamo il servizio Mail.ru Hotbox, che è compatibile con S3 tramite API. Non abbiamo dovuto apportare modifiche significative al codice dell'applicazione, e abbiamo creato il seguente meccanismo: S3 ha dei trigger che si attivano alla creazione/cancellazione di oggetti. Amazon dispone di un servizio chiamato Lambda — è un sistema serverless per l'esecuzione di codice, che verrà eseguito proprio al verificarsi di determinati trigger.
Abbiamo semplificato il processo: quando scatta un trigger, eseguiamo il codice che copia l'oggetto nello storage di Mail.ru. Per avviare completamente il lavoro con le copie locali dei dati, abbiamo bisogno anche di una sincronizzazione inversa, in modo che i clienti nel segmento russo possano lavorare con uno storage a loro più vicino. Mail sta per completare i trigger nel proprio storage — sarà possibile già a livello di infrastruttura eseguire la sincronizzazione inversa, mentre al momento lo facciamo a livello del nostro codice. Se vediamo che un cliente ha caricato un file, allora noi, a livello di codice, mettiamo un evento in coda, lo elaboriamo e effettuano la replica inversa. Il problema è che se c'è un'operazione con i nostri oggetti al di fuori del nostro prodotto, cioè con strumenti esterni, non lo considereremo. Pertanto, stiamo aspettando che vengano implementati i trigger a livello di storage, in modo che indipendentemente da dove abbiamo eseguito il codice, l'oggetto che ci è arrivato venga copiato dall'altra parte.
A livello di codice, per ciascun cliente vengono configurati entrambi i storage: uno considerato principale e l'altro di backup. Se tutto va bene, lavoriamo con il storage più vicino a noi: i nostri clienti che sono su Amazon utilizzano S3, mentre quelli che operano in Russia usano Hotbox. Se scatta il flag, dobbiamo attivare il failover e spostare i clienti su un altro storage. Possiamo impostare questo flag in modo indipendente per le regioni e fare switch bidirezionali. Nella pratica non lo abbiamo ancora utilizzato, ma abbiamo previsto questo meccanismo e pensiamo che prima o poi avremo bisogno di questo switching. È già successo una volta.
Oh, ma il tuo Amazon è scappato...
Questo aprile segna l'anniversario dell'inizio del blocco di Telegram in Russia. Il fornitore più colpito da questa situazione è stato Amazon. E, sfortunatamente, le aziende russe che operavano a livello globale hanno subito maggiori danni.
Se un'azienda è globale e la Russia rappresenta solo una piccola frazione, dal 3 al 5%, beh, in un modo o nell'altro, si possono sacrificare.
Se si tratta di un'azienda esclusivamente russa, sono sicuro che sia necessario localizzarsi — semplicemente per il comfort degli utenti, sarà più comodo e ci saranno meno rischi.
E se è un'azienda che opera a livello globale, con clienti più o meno equamente distribuiti tra la Russia e il resto del mondo? La connettività tra i segmenti è importante, e devono lavorare insieme in un modo o nell'altro.
Alla fine di marzo 2018, il Roskomnadzor ha inviato una lettera ai maggiori operatori, informandoli che avevano intenzione di bloccare alcuni milioni di IP di Amazon per impedire… il messenger Zello. Grazie a questi stessi provider — hanno pubblicato la lettera a tutti, ed è emersa la comprensione che la connettività con Amazon potrebbe collassare. Era venerdì, e siamo corsi in panico dai colleghi di servers.ru, dicendo: «Amici, abbiamo bisogno di alcuni server che non siano in Russia, non su Amazon, ma, ad esempio, da qualche parte ad Amsterdam», per avere almeno la possibilità di mettere là i nostri server. vpn e un proxy per alcuni endpoint su cui non possiamo influire, ad esempio gli endpoint dello stesso S3 — non possiamo provare a lanciare un nuovo servizio e ottenere un altro IP, dobbiamo comunque raggiungerli. In pochi giorni abbiamo configurato e attivato questi server e, in generale, siamo stati pronti al momento dell'inizio delle restrizioni. È curioso che il RKN, osservando il trambusto e il panico sollevato, abbia detto: «No, adesso non bloccheremo nulla». (Ma è stato proprio fino a quel momento in cui hanno iniziato a bloccare Telegram.) Configurando le opzioni per aggirare e capendo che non era stata introdotta una restrizione, abbiamo comunque deciso di non smontare tutto questo. Così, per ogni evenienza.
Nel 2019 ci troviamo quindi a vivere in un contesto di blocchi. Ieri notte ho osservato che circa un milione di IP continuano a essere bloccati. Tuttavia, Amazon è stata quasi completamente sbloccata; in alcuni momenti abbiamo raggiunto fino a 20 milioni di indirizzi. In breve, la realtà è che la connettività — una buona connettività — può venire a mancare. All'improvviso. Può mancare per motivi tecnici — incendi, escavatori, cose del genere. Oppure, come abbiamo visto, per ragioni non del tutto tecniche. Pertanto, qualcuno di grande e importante, con propri AS, può probabilmente gestire la situazione in altri modi — direct connect e altri sistemi già a livello L2. Ma per le situazioni più semplici, come nel nostro caso o per altre aziende più piccole, è utile avere un piano di riserva a livello di server, attivati altrove, con VPN e proxy preconfigurati, in modo da poter rapidamente passare la configurazione su quei segmenti che sono critici per la connettività. Ci è stato utile in numerose occasioni quando sono iniziati i blocchi di Amazon, abbiamo utilizzato questi server per instradare il traffico S3 nei momenti peggiori, ma alla fine la situazione si è risolta.
E come si riserva... un intero provider?
Attualmente non abbiamo uno scenario in caso di totale guasto di Amazon. Abbiamo uno scenario simile per la Russia. In Russia ci siamo appoggiati a un fornitore che ci ha permesso di scegliere tra più sedi. Un anno fa ci siamo trovati di fronte a un problema: anche se si trattava di due data center, già a livello di configurazione della rete del fornitore possono sorgere problemi che interessano entrambi i data center. Di conseguenza, possiamo avere disservizi in entrambe le sedi. Infatti, così è stato. Alla fine abbiamo rivisto l'architettura interna. Non è cambiata molto, ma per la Russia ora abbiamo due sedi, non della stessa compagnia, ma di due fornitori diversi. Se uno di essi avesse un problema, possiamo passare all'altro.
Ipoteticamente, stiamo considerando di fare backup per Amazon a livello di un altro provider; che potrebbe essere Google, o qualcun altro... Ma finora abbiamo osservato nella pratica che se ci sono guasti in una availability zone di Amazon, i guasti a livello di intera regione sono fenomeni abbastanza rari. Pertanto, abbiamo un'idea teorica di ciò che potremmo fare come riserva "Amazon – non Amazon", ma nella pratica non siamo ancora a quel punto.
Due parole sull'automazione
Serve sempre l'automazione? Qui vale la pena ricordare l'effetto Dunning-Kruger. Sull'asse "x" troviamo le nostre conoscenze e l'esperienza accumulata, mentre sull'asse "y" c'è la fiducia nelle nostre azioni. All'inizio non sappiamo nulla e siamo del tutto insicuri. Poi iniziamo a sapere un po' di più e diventiamo super sicuri di noi: questo è il cosiddetto "picco di stupidità", ben illustrato dall'immagine "incompetenza e coraggio." Successivamente, impariamo un po' e ci sentiamo pronti a combattere. Poi inciampiamo in gravi problemi e ci troviamo nella valle della disperazione, quando sembra che sappiamo qualcosa, ma in realtà non sappiamo molto. Con l'aumentare dell'esperienza, diventiamo più sicuri.
La nostra logica sui vari switch automatici in caso di guasti è ben spiegata da questo grafico. Siamo partiti — eravamo alle prime armi, praticamente tutto il lavoro veniva svolto manualmente. Poi abbiamo capito che si poteva automatizzare tutto e, in qualche modo, dormire sonni tranquilli. E improvvisamente ci troviamo ad affrontare un mega errore: un falso positivo si attiva e commutiamo il traffico avanti e indietro, quando, a rigor di logica, non avremmo dovuto farlo. Di conseguenza, la replicazione si guasta o qualcosa del genere — questa è la vera valle della disperazione. E poi arriviamo a comprendere che è necessario avvicinarsi a tutto con saggezza. Vale a dire che ha senso affidarsi all'automazione, prevedendo la possibilità di falsi feedback. Ma! se le conseguenze possono essere distruttive, è meglio lasciare queste decisioni a un turno di guardia, a ingegneri di servizio, che verificheranno e si assicureranno che ci sia davvero una situazione di emergenza, e che le azioni necessarie vengano eseguite manualmente...
Conclusione
In sette anni, siamo passati da un'era di panico totale ogni volta che qualcosa andava storto a una comprensione che non ci sono problemi, solo compiti da affrontare e risolvere. Quando costruite un servizio, osservatelo dall'alto, valutate tutti i rischi potenziali che potrebbero verificarsi. Se li individuate subito, pianificate in anticipo le riserve e la possibilità di creare un'infrastruttura resiliente, perché ogni punto che può guastarsi e portare alla non operatività del servizio, lo farà. Anche se pensate che alcuni elementi dell'infrastruttura non si guasteranno mai, come ad esempio s3, tenete presente che potrebbero farlo. E anche solo in teoria, dovete avere un'idea di cosa farete con loro in caso di problemi. Sviluppate un piano di gestione dei rischi. Quando pensate di automatizzare tutto o fare manualmente, valutate i rischi: cosa succede se l'automazione inizia a commutare tutto? Non creerà una situazione anche peggiore rispetto a un guasto? Potrebbe essere necessario trovare un compromesso ragionevole tra l'uso dell'automazione e la reazione di un ingegnere di guardia che valuta la situazione reale e decide se è il caso di cambiare qualcosa subito o «sì, ma non ora».
Un compromesso ragionevole tra perfezionismo e le risorse reali, il tempo, il denaro che puoi spendere per lo schema che alla fine avrai.
Questo testo è una versione ampliata e arricchita della relazione di Alexander Demidov alla conferenza .
Fonte: habr.com
