{"id":83188,"date":"2020-05-29T07:43:02","date_gmt":"2020-05-29T05:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali"},"modified":"2020-05-29T07:43:02","modified_gmt":"2020-05-29T05:43:02","slug":"kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Come abbiamo affrontato un incremento improvviso della domanda x10 in remoto e quali conclusioni abbiamo tratto","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr! Negli ultimi mesi abbiamo vissuto una situazione molto interessante e vorrei condividere la nostra storia di scalabilit\u00e0 dell'infrastruttura. In questo periodo, SberMarket ha visto un aumento degli ordini di 4 volte e ha lanciato il servizio in 17 nuove citt\u00e0. L'esplosione della domanda per la consegna di prodotti ci ha richiesto di scalare l'infrastruttura. Leggi di pi\u00f9 sulle conclusioni pi\u00f9 interessanti e utili qui sotto.<\/p>\n

\"Come
\n<\/a><\/noindex>
\nMi chiamo Dima Bobylev, sono il direttore tecnico di SberMarket. Poich\u00e9 questo \u00e8 il primo post nel nostro blog, dir\u00f2 qualche parola su di me e sull'azienda. Lo scorso autunno ho partecipato a un concorso per giovani leader di Runet. Per il concorso ho scritto una breve storia<\/a><\/noindex> su come vediamo in SberMarket la cultura interna e l'approccio allo sviluppo del servizio. E anche se non sono riuscito a vincere il concorso, ho comunque formulato per me stesso i principi fondamentali dello sviluppo dell'ecosistema IT. <\/p>\n

Gestire un team richiede di comprendere e trovare un equilibrio tra le esigenze del business e le necessit\u00e0 di ogni singolo sviluppatore. Attualmente, SberMarket sta crescendo di 13 volte anno per anno, e questo influisce sul prodotto, richiedendo un costante aumento delle quantit\u00e0 e della velocit\u00e0 di sviluppo. Nonostante ci\u00f2, dedichiamo tempo sufficiente agli sviluppatori per un'analisi preliminare e per una scrittura del codice di qualit\u00e0. Un approccio strutturato aiuta non solo a creare un prodotto funzionante, ma anche a garantirne la scalabilit\u00e0 e l'evoluzione nel tempo. A seguito di questa crescita, SberMarket \u00e8 diventato gi\u00e0 un leader tra i servizi di consegna di prodotti: consegniamo quotidianamente circa 18.000 ordini, anche se all'inizio di febbraio erano circa 3.500.<\/p>\n

\"Come
\nUn giorno un cliente ha chiesto al corriere di SberMarket di consegnare i prodotti in modalit\u00e0 contactless, direttamente sul balcone.<\/i><\/p>\n

Ma passiamo ai dettagli. Negli ultimi mesi, abbiamo lavorato attivamente all'espansione dell'infrastruttura della nostra azienda. Questa necessit\u00e0 \u00e8 stata motivata da fattori esterni e interni. Contemporaneamente all'aumento della base clienti, il numero di negozi collegati \u00e8 cresciuto da 90 all'inizio dell'anno a pi\u00f9 di 200 a met\u00e0 maggio. Abbiamo, ovviamente, preso le dovute precauzioni, riservando l'infrastruttura principale e prevedendo la possibilit\u00e0 di scalabilit\u00e0 verticale e orizzontale per tutte le macchine virtuali ospitate nel cloud di Yandex. Tuttavia, la pratica ha dimostrato: \"Qualunque cosa possa andare storta andr\u00e0 storta.\" E oggi voglio condividere le situazioni pi\u00f9 interessanti che si sono verificate in queste settimane. Spero che la nostra esperienza sar\u00e0 utile per voi.<\/p>\n

Slave \u00e8 pronto per l'azione<\/h3>\n

\nGi\u00e0 prima dell'inizio della pandemia, abbiamo assistito a un aumento del numero di richieste sui nostri server backend. La tendenza a ordinare prodotti con consegna a domicilio ha iniziato a prendere piede e con l'introduzione delle prime misure di auto-isolamento legate al COVID-19, il carico \u00e8 aumentato drammaticamente nel corso della giornata. Si \u00e8 presentata la necessit\u00e0 di scaricare rapidamente i master server del database principale e trasferire parte delle richieste di lettura sui server replica (slave).<\/p>\n

Ci eravamo preparati in anticipo a questo passo e per questo tipo di manovra erano gi\u00e0 stati avviati 2 server slave. Su di essi lavoravano principalmente attivit\u00e0 batch per la generazione di feed informativi per lo scambio di dati con i partner. Questi processi creavano un carico aggiuntivo e sono stati giustamente esclusi 'dai conti' due mesi prima.\u00a0<\/p>\n

Poich\u00e9 la replica avveniva sul Slave, abbiamo aderito al concetto che le applicazioni potessero interagire con essi solo in modalit\u00e0 di sola lettura. Il Piano di Recupero da Disastri prevedeva che, in caso di catastrofe, potessimo semplicemente montare lo Slave al posto del Master e reindirizzare tutte le richieste di scrittura e lettura allo Slave. Tuttavia, volevamo anche utilizzare le repliche per le esigenze del dipartimento analisi, quindi i server non erano completamente impostati in modalit\u00e0 di sola lettura, e ogni host aveva il proprio insieme di utenti, alcuni dei quali disponevano di diritti di scrittura per salvare i risultati intermedi dei calcoli.<\/p>\n

Fino a un certo livello di carico, ci bastava il master sia per la scrittura che per la lettura nell'elaborazione delle richieste http. A met\u00e0 marzo, proprio quando Sbermarket ha deciso di passare completamente al lavoro remoto, abbiamo iniziato a registrare una crescita esponenziale degli RPS. Sempre pi\u00f9 clienti si isolavano o lavoravano da casa, il che ha influito sui nostri indicatori di carico.<\/p>\n

Le prestazioni del \"master\" non erano pi\u00f9 sufficienti, quindi abbiamo iniziato a spostare una parte delle query di lettura pi\u00f9 pesanti su una replica. Per reindirizzare in modo trasparente le query di scrittura al master e quelle di lettura allo slave, abbiamo utilizzato la gemma ruby \u00abOctopus<\/a><\/noindex>\u00bb. Abbiamo creato un utente speciale con il suffisso _readonly privo di diritti di scrittura. Tuttavia, a causa di un errore di configurazione su uno degli host, alcune query di scrittura sono andate su un server slave con un nome utente che aveva i diritti appropriati.<\/p>\n

Il problema non si \u00e8 manifestato subito, poich\u00e9 il carico aumentato ha incrementato il ritardo degli slave. L'incoerenza dei dati \u00e8 stata scoperta la mattina, quando dopo le importazioni notturne, gli slave non hanno \"raggiunto\" il master. Abbiamo attribuito questo alla forte pressione sul servizio stesso e agli import legati all'apertura di nuovi negozi. Ma fornire dati con un ritardo di ore era inaccettabile, quindi abbiamo trasferito i processi su un secondo slave analitico, poich\u00e9 disponeva diun<\/strong>risorse maggiori ed era privo di query di lettura (il che ha spiegato a noi stessi l'assenza di lag nella replica).<\/p>\n

Dopo aver analizzato le cause dell'\u00abespansione\u00bb del slave principale, anche l'analitico ha smesso di funzionare per la stessa ragione. Nonostante ci fossero due server aggiuntivi su cui prevedevamo di spostare il carico in caso di crash del master, un errore sfortunato ha portato a scoprire che al momento critico non ce n'era nemmeno uno.<\/p>\n

Poich\u00e9 non abbiamo creato solo un dump del database (il ripristino in quel momento richiedeva circa 5 ore), ma anche uno snapshot del server master, siamo riusciti a far partire la replica nell'arco di 2 ore. Tuttavia, dopo ci\u00f2, ci aspettava un lungo processo di applicazione del log di replicazione (poich\u00e9 il processo avviene in modalit\u00e0 monothread, ma questa \u00e8 un'altra storia).<\/p>\n

Risultato:<\/strong> Dopo un incidente del genere, \u00e8 diventato chiaro che dovevamo rinunciare alla pratica di limitare la scrittura per gli utenti e dichiarare l'intero server in sola lettura. Con questo approccio, non si pu\u00f2 dubitare che le repliche saranno disponibili nei momenti critici.<\/p><\/blockquote>\n

<\/p>\n

L'ottimizzazione anche di una sola query pesante pu\u00f2 \u00abriportare in vita\u00bb il database.<\/h3>\n

\nSebbene aggiorniamo costantemente il catalogo sul sito, le richieste che inviavamo ai server Slave presentavano un leggero ritardo rispetto al Master. Il tempo necessario per individuare e risolvere il problema dei Slave 'che si disconnettevano improvvisamente' superava il 'confine psicologico' (in quel lasso di tempo potevano verificarsi aggiornamenti dei prezzi, e i clienti avrebbero visto dati obsoleti), costringendoci a reindirizzare tutte le richieste al server principale del DB. Di conseguenza, il sito funzionava lentamente... ma almeno funzionava. E mentre il Slave si ripristinava, non ci restava altro da fare se non ottimizzare.\u00a0<\/p>\n

Mentre i server Slave si ripristinavano, i minuti si trascinavano lentamente, il Master rimaneva sovraccarico e abbiamo concentrato tutte le forze sull'ottimizzazione delle attivit\u00e0 attive secondo la 'Regola di Pareto': abbiamo selezionato le richieste TOP, che generavano la maggior parte del carico, e abbiamo iniziato a effettuare il tuning. Questo veniva fatto 'in corsa'.<\/p>\n

L'effetto interessante \u00e8 stato che un MySQL completamente carico rispondere anche a un miglioramento minimo dei processi. L'ottimizzazione di un paio di query, che generavano solo il 5% del carico totale, ha gi\u00e0 mostrato un notevole alleviamento della CPU. Di conseguenza, siamo riusciti a garantire una riserva di risorse accettabile per l'esecuzione di Master con il database e ottenere il tempo necessario per il ripristino delle repliche.\u00a0<\/p>\n

Risultato:<\/strong> Anche una piccola ottimizzazione consente di \"sopravvivere\" a un sovraccarico per diverse ore. Questo ci \u00e8 stato sufficiente per il tempo di ripristino dei server con repliche. Tra l'altro, discuteremo il lato tecnico dell'ottimizzazione delle query in uno dei prossimi post. Quindi, iscrivetevi al nostro blog se potrebbe esservi utile.<\/p><\/blockquote>\n

<\/p>\n

Organizzate il monitoraggio della disponibilit\u00e0 dei servizi partner.<\/h3>\n

\nGestiamo gli ordini dei clienti e, pertanto, i nostri servizi interagiscono costantemente con API esterne \u2014 queste includono gateway per l'invio di SMS, piattaforme di pagamento, sistemi di routing, geocodificatori, servizi fiscali e molte altre soluzioni. Quando il carico \u00e8 aumentato rapidamente, abbiamo iniziato a incontrare i limiti delle API dei nostri partner, di cui non ci eravamo mai preoccupati prima.<\/p>\n

Un'improvvisa violazione delle quote dei servizi partner pu\u00f2 causare downtime per il tuo. Molti API bloccano i clienti che superano i limiti, e in alcuni casi, un eccesso di richieste pu\u00f2 sovraccaricare l'infrastruttura del partner.\u00a0<\/p>\n

Ad esempio, durante l'aumento delle consegne, i servizi di supporto non riuscivano a gestire le attivit\u00e0 di distribuzione e determinazione dei percorsi. Di conseguenza, \u00e8 successo che gli ordini erano stati effettuati, ma il servizio che creava il percorso non funzionava. Va detto che i nostri logisti hanno fatto praticamente l'impossibile in queste condizioni e una chiara collaborazione del team ha contribuito a compensare i guasti temporanei dei servizi. Tuttavia, un volume cos\u00ec elevato di richieste non pu\u00f2 essere gestito manualmente in modo costante, e dopo un po' ci saremmo trovati di fronte a una inaccettabile discrepanza tra gli ordini e la loro esecuzione.\u00a0<\/p>\n

Sono state adottate diverse misure organizzative e un lavoro coordinato del team ha permesso di guadagnare tempo, mentre ci si metteva d'accordo su nuove condizioni e si attendeva la modernizzazione dei servizi da parte di alcuni partner. Esistono anche altri API che offrono una grande resilienza e tariffe competitive in caso di alto traffico. Ad esempio, inizialmente abbiamo utilizzato un noto API cartografico per determinare l'indirizzo del punto di consegna. Ma alla fine del mese abbiamo ricevuto una fattura di quasi 2 milioni di rubli. Dopo questo, abbiamo deciso di sostituirlo rapidamente. Non far\u00f2 pubblicit\u00e0, ma posso dire che le nostre spese si sono notevolmente ridotte.
\n\"Come<\/p>\n

Risultato: <\/strong>\u00c8 fondamentale monitorare le condizioni di lavoro di tutti i servizi partner e tenerle a mente. Anche se oggi sembrano avere 'un grande margine', non significa che domani non diventino un ostacolo alla crescita. E, naturalmente, \u00e8 meglio concordare in anticipo le condizioni finanziarie per le richieste crescenti al servizio.\u00a0<\/p><\/blockquote>\n

<\/p>\n

A volte si scopre che \"serve pi\u00f9 oro<\/a><\/noindex>\" (cit) non aiuta<\/h3>\n

\nCi siamo abituati ai \"colli di bottiglia\" nel database principale o nei server applicativi, ma durante la scalabilit\u00e0 possono emergere problemi dove meno ce li si aspetta. Per la ricerca testuale completa sul sito utilizziamo il motore Apache Solr. Con l'aumento del carico, abbiamo notato un calo dei tempi di risposta e il carico della CPU del server ha raggiunto il 100%. Cosa potrebbe essere pi\u00f9 semplice: diamo pi\u00f9 risorse al contenitore con Solr.<\/p>\n

Invece di un aumento previsto delle prestazioni, il server semplicemente \"\u00e8 morto\". Si caricava immediatamente al 100% e rispondeva ancora pi\u00f9 lentamente. Inizialmente avevamo 2 core e 2 GB di RAM. Abbiamo deciso di fare ci\u00f2 che di solito funziona: abbiamo dato al server 8 core e 32 GB. Tutto \u00e8 peggiorato notevolmente (come e perch\u00e9 lo racconteremo in un post separato).\u00a0<\/p>\n

In pochi giorni abbiamo compreso le sottigliezze di questo problema e abbiamo ottenuto prestazioni ottimali con 8 core e 32 GB di RAM. Questa configurazione permette ancora oggi di continuare a incrementare il carico, il che \u00e8 molto importante, perch\u00e9 la crescita non riguarda solo i clienti, ma anche il numero di negozi connessi: in 2 mesi il loro numero \u00e8 raddoppiato.\u00a0<\/p>\n

Risultato: <\/strong>I metodi tradizionali come \"aggiungere pi\u00f9 hardware\" non funzionano sempre. Pertanto, quando si scala qualsiasi servizio, \u00e8 importante comprendere come utilizza le risorse e testare in anticipo il suo funzionamento in nuove condizioni.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 la chiave per una semplice scalabilit\u00e0 orizzontale<\/h3>\n

\nIn generale, il nostro team segue un approccio ben noto: i servizi non dovrebbero avere uno stato interno (stateless) e devono essere indipendenti dall'ambiente di esecuzione. Questo ci ha permesso di affrontare l'aumento del carico con una semplice scalabilit\u00e0 orizzontale. Tuttavia, abbiamo avuto un servizio eccezione: il gestore di compiti di lunga durata. Si occupava dell'invio di email e sms, della gestione di eventi, della generazione di feed, dell'importazione di prezzi e stock, e dell'elaborazione delle immagini. Sfortunatamente, dipendeva da un'archiviazione locale e si trovava in un singolo esemplare.\u00a0<\/p>\n

Con l'aumento del numero di attivit\u00e0 nella coda del gestore (che \u00e8 naturalmente aumentato con la crescita degli ordini), le prestazioni dell'host su cui erano ospitati il gestore e lo storage dei file sono diventate il fattore limitante. Di conseguenza, si \u00e8 fermato l'aggiornamento dell'assortimento e dei prezzi, l'invio di notifiche agli utenti e molte altre funzioni critiche, bloccate in coda. Il team Ops ha rapidamente migrato lo storage dei file in uno storage di rete simile a S3, permettendoci di attivare diverse macchine potenti per scalare il gestore delle attivit\u00e0 di back-end.<\/p>\n

Risultato: <\/strong>La regola Stateless deve essere rispettata per tutti i componenti senza eccezioni, anche se sembra 'che qui non ci troveremo mai in difficolt\u00e0'. \u00c8 meglio dedicare un po' di tempo a organizzare correttamente il funzionamento di tutti i sistemi, piuttosto che poi dover riscrivere il codice e riparare un servizio sottoposto a sovraccarico in fretta.<\/p><\/blockquote>\n

<\/p>\n

7 principi per una crescita intensa<\/h2>\n

\nNonostante la disponibilit\u00e0 di risorse aggiuntive, abbiamo incontrato alcuni ostacoli nel processo di crescita. In questo periodo, il numero di ordini \u00e8 aumentato di oltre 4 volte. Ora consegniamo pi\u00f9 di 17.000 ordini al giorno in 62 citt\u00e0 e pianifichiamo di espandere ulteriormente la nostra geografia \u2014 nel primo semestre del 2020 \u00e8 prevista l'introduzione del servizio in tutta la Russia. Per affrontare il crescente carico, considerando gli errori gi\u00e0 commessi, abbiamo definito 7 principi fondamentali per lavorare in un contesto di crescita continua:<\/p>\n

    \n
  1. Incident Management<\/strong>. Abbiamo creato una bacheca in Jira, dove ogni incidente \u00e8 rappresentato come un ticket. Questo aiuter\u00e0 a prioritizzare e portare a termine i compiti associati all'incidente. Infondamentalmente, non \u00e8 spaventoso commettere errori \u2014 \u00e8 spaventoso ripetere gli stessi errori. Per i casi in cui gli incidenti si ripetono prima che si riesca a correggere la causa, deve essere pronta un'istruzione operativa, poich\u00e9 durante un grosso carico \u00e8 fondamentale reagire immediatamente.<\/li>\n
  2. Monitoraggio <\/strong>\u00e8 necessario per tutti gli elementi dell'infrastruttura senza eccezione. Grazie ad esso, siamo stati in grado di prevedere l'aumento del carico e di identificare correttamente i \"colli di bottiglia\" da prioritizzare per la risoluzione. Probabilmente, sotto un carico elevato, tutto ci\u00f2 che non ti aspetteresti si romper\u00e0 o inizier\u00e0 a rallentare. Pertanto, \u00e8 meglio creare nuovi allerta subito dopo i primi incidenti, per monitorarli e anticiparli.<\/li>\n
  3. Allerta corrette<\/strong> sono semplicemente necessarie in caso di aumento repentino del carico. In primo luogo, devono segnalare esattamente ci\u00f2 che si \u00e8 rotto. In secondo luogo, non devono essere troppi, poich\u00e9 un eccesso di allerta non critiche porta all'ignorare completamente tutte le notifiche.<\/li>\n
  4. Le applicazioni devono essere stateless. <\/strong>Ci siamo assicurati che per questa regola non ci siano eccezioni. \u00c8 necessaria una totale indipendenza dal runtime. A tal fine, \u00e8 possibile memorizzare i dati condivisi nel DB o, ad esempio, direttamente in S3. E ancora meglio seguire le linee guida. https:\/\/12factor.net<\/a><\/noindex>. Durante una crescita rapida, ottimizzare il codice diventa impossibile, e per gestire il carico si deve ricorrere all'aumento diretto delle risorse computazionali e alla scalabilit\u00e0 orizzontale.<\/li>\n
  5. Quote e prestazioni dei servizi esterni. <\/strong>In caso di rapida crescita, il problema pu\u00f2 sorgere non solo nella vostra infrastruttura, ma anche nel servizio esterno. \u00c8 particolarmente frustrante quando ci\u00f2 avviene non per un guasto, ma a causa del raggiungimento di quote o limiti. Pertanto, i servizi esterni devono scalare altrettanto bene quanto voi.\u00a0<\/li>\n
  6. Separare i processi e le code. <\/strong>Questo \u00e8 molto utile quando uno dei gateway si intasa. Non avremmo riscontrato ritardi nei trasferimenti di dati se le code di invio SMS non avessero interferito con lo scambio di notifiche tra i sistemi informativi. Inoltre, sarebbe stato pi\u00f9 semplice aumentare il numero di worker se avessero operato separatamente.<\/li>\n
  7. Realt\u00e0 finanziarie.<\/strong> Quando si verifica una crescita esplosiva del flusso di dati, non c'\u00e8 tempo per riflettere su tariffe e abbonamenti. Ma \u00e8 importante tenerne conto, soprattutto se si \u00e8 una piccola azienda. Un grosso conto pu\u00f2 arrivare sia dal proprietario di qualsiasi API sia dal vostro fornitore di hosting. Quindi, \u00e8 fondamentale leggere attentamente i contratti.<\/li>\n<\/ol>\n

    <\/p>\n

    Conclusione<\/h2>\n

    \nNon senza perdite, ma abbiamo superato questa fase e oggi cerchiamo di seguire tutti i principi che abbiamo trovato. Ogni macchina ha la possibilit\u00e0 di aumentare facilmente le prestazioni fino a 4 volte per affrontare eventuali imprevisti.\u00a0<\/p>\n

    Nei prossimi post condivideremo la nostra esperienza nell'indagine sulla diminuzione delle prestazioni in Apache Solr e parleremo di ottimizzazione delle query e di come l'interazione con l'agenzia fiscale aiuti l'azienda a risparmiare denaro. Iscriviti al nostro blog per non perdere nulla e facci sapere nei commenti se hai mai avuto problemi simili durante un aumento del traffico.<\/p>\n

    \"Come<\/p>\n

    Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n

    Hai mai subito rallentamenti o interruzioni del servizio durante un brusco aumento del carico a causa di:<\/h2>\n