{"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 aumento improvviso del carico x10 in remote working 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 quadruplicato il numero di ordini e ha lanciato il servizio in 17 nuove citt\u00e0. L'esplosivo aumento della domanda per la consegna di prodotti ha richiesto da parte nostra un adeguamento dell'infrastruttura. Leggete dopo il tag per i dettagli pi\u00f9 interessanti e utili.<\/p>\n

\"Come
\n<\/a><\/noindex>
\nMi chiamo Dima Bobylev, sono il direttore tecnico di SberMarket. Poich\u00e9 questo \u00e8 il primo post del nostro blog, dir\u00f2 alcune parole su di me e sull'azienda. Lo scorso autunno ho partecipato a un concorso per giovani leader di Runet. Per il contest, 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 ho vinto il concorso, ho comunque formulato i principi fondamentali per lo sviluppo dell'ecosistema IT. <\/p>\n

Gestire un team richiede di comprendere e trovare un equilibrio tra ci\u00f2 che serve al business e le esigenze di ogni singolo sviluppatore. Attualmente SberMarket cresce di 13 volte anno dopo anno, e questo influisce sul prodotto, richiedendo un costante incremento delle quantit\u00e0 e dei ritmi di sviluppo. Nonostante ci\u00f2, dedichiamo abbastanza tempo agli sviluppatori per un'analisi preliminare e una scrittura di codice di qualit\u00e0. L'approccio consolidato aiuta non solo nella creazione di un prodotto funzionante, ma anche nella sua successiva scalabilit\u00e0 e sviluppo. Come risultato di questa crescita, SberMarket \u00e8 gi\u00e0 diventato un leader tra i servizi di consegna di prodotti: consegniamo quotidianamente circa 18.000 ordini al giorno, mentre all'inizio di febbraio erano circa 3.500.<\/p>\n

\"Come
\nUna volta un cliente ha chiesto a un corriere di SberMarket di consegnare i prodotti in modo contactless \u2014 direttamente sul balcone.<\/i><\/p>\n

Passiamo ai dettagli. Negli ultimi mesi, abbiamo lavorato attivamente per scalare l'infrastruttura della nostra azienda. Questa necessit\u00e0 \u00e8 stata motivata da fattori esterni e interni. Allo stesso tempo, con l\u2019espansione della base clienti, il numero dei negozi connessi \u00e8 aumentato da 90 all'inizio dell'anno a pi\u00f9 di 200 a met\u00e0 maggio. Ci siamo naturalmente preparati, riservando l'infrastruttura principale e prevedendo la possibilit\u00e0 di scalare verticalmente e orizzontalmente tutte le macchine virtuali ospitate nel cloud di Yandex. Tuttavia, la pratica ha dimostrato che: \u00abTutto ci\u00f2 che pu\u00f2 andare storto, andr\u00e0 storto\u00bb. Oggi voglio condividere con voi le situazioni pi\u00f9 curiose che si sono verificate durante queste settimane. Spero che la nostra esperienza possa esservi utile.<\/p>\n

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

\nAncora prima dell'inizio della pandemia, ci siamo trovati ad affrontare un aumento delle richieste sui nostri server backend. La tendenza a ordinare prodotti con consegna a domicilio stava guadagnando slancio e, con l'introduzione delle prime misure di isolamento sociale a causa del COVID-19, il carico aumentava drammaticamente durante tutto il giorno. Si \u00e8 resa necessaria un'operazione rapida per scaricare i master server del database principale e spostare parte delle richieste di lettura sui server replica (slave).<\/p>\n

Ci eravamo preparati in anticipo a questo passo e per tale manovra erano gi\u00e0 stati attivati 2 server slave. Su di essi lavoravano principalmente i task 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 \u00abper qualche mese\u00bb prima.\u00a0<\/p>\n

Poich\u00e9 su Slave avveniva la replica, abbiamo seguito il concetto secondo cui le applicazioni possono interagire con essi solo in modalit\u00e0 di sola lettura. Il Piano di Disaster Recovery prevedeva che, in caso di catastrofe, potessimo semplicemente montare Slave al posto di Master e reindirizzare tutte le richieste di scrittura e lettura su Slave. Tuttavia, volevamo anche utilizzare le repliche per le esigenze del dipartimento di analisi, quindi i server non erano completamente convertiti in modalit\u00e0 di sola lettura, con un set di utenti specifico su ciascun host, e alcuni avevano diritti di scrittura per salvare i risultati intermedi dei calcoli.<\/p>\n

Fino a un certo livello di carico, avevamo sufficienti risorse per scrivere e leggere durante l'elaborazione delle richieste http. A met\u00e0 marzo, proprio quando Sbermarket ha deciso di passare completamente al lavoro da remoto, abbiamo iniziato a vedere una crescita esponenziale del RPS. Sempre pi\u00f9 clienti si sono messi in autoisolamento o hanno iniziato a lavorare da casa, il che ha avuto un impatto sui parametri di carico.<\/p>\n

La capacit\u00e0 del \"master\" non era pi\u00f9 sufficiente, quindi abbiamo iniziato a trasferire parte delle richieste di lettura pi\u00f9 pesanti su una replica. Per dirigere in modo trasparente le richieste di scrittura al master e quelle di lettura allo slave, abbiamo utilizzato la gemma ruby \u201cOctopus<\/a><\/noindex>\u201d. Abbiamo creato un utente speciale con il suffisso _readonly senza diritti di scrittura. Ma a causa di un errore nella configurazione di uno degli host, parte delle richieste di scrittura \u00e8 andata al server slave a nome di un utente che aveva i diritti appropriati.<\/p>\n

Il problema non si \u00e8 manifestato subito, poich\u00e9 il carico aumentato ha aumentato il ritardo degli slave. L'incoerenza dei dati \u00e8 stata scoperta al mattino, quando, dopo le importazioni notturne, gli slave non hanno \"raggiunto\" il master. Abbiamo attribuito questo all'alta pressione sul servizio stesso e all'importazione legata all'apertura di nuovi negozi. Tuttavia, fornire dati con un ritardo di molte ore era inaccettabile, cos\u00ec abbiamo spostato i processi su un secondo slave analitico, poich\u00e9 aveva risorse bun<\/strong>larghe ed era poco caricato da richieste di lettura (il che ha spiegato a noi stessi l'assenza di lag nella replica).<\/p>\n

Quando abbiamo risolto le cause del \"disallineamento\" dello slave principale, lo slave analitico era gi\u00e0 fuori uso per la stessa ragione. Nonostante ci fosse un certo numero di server aggiuntivi su cui avevamo pianificato di trasferire il carico in caso di crash del master, a causa di un errore imprevisto ci siamo trovati senza alcuno di essi nel momento critico.<\/p>\n

Ma poich\u00e9 non ci limitavamo solo a un dump del database (il ripristino in quel momento richiedeva circa 5 ore), ma anche a uno snapshot del server master, siamo riusciti a avviare la replica in 2 ore. Tuttavia, dopo questo ci aspettava un lungo processo di applicazione del log di replica (poich\u00e9 il processo avviene in modalit\u00e0 a thread singolo, ma questa \u00e8 un'altra storia).<\/p>\n

Conclusione:<\/strong> Dopo un incidente di questo tipo, \u00e8 diventato chiaro che era necessario abbandonare la pratica di limitare la registrazione per gli utenti e dichiarare in sola lettura l'intero server. Con questo approccio, non c'\u00e8 dubbio che le repliche saranno disponibili in un momento critico.<\/p><\/blockquote>\n

<\/p>\n

L'ottimizzazione anche di una sola query pesante pu\u00f2 \"ridare vita\" al database.<\/h3>\n

\nAnche se aggiorniamo costantemente il catalogo sul sito, le query che eseguiamo sui server Slave mostrano un leggero ritardo rispetto al Master. Il tempo impiegato per scoprire e risolvere il problema dei \"Slave improvvisamente disattivati\" \u00e8 stato superiore al \"confine psicologico\" (in quel lasso di tempo potrebbe essere avvenuto un aggiornamento dei prezzi e i clienti avrebbero visto dati obsoleti), e abbiamo dovuto reindirizzare tutte le query al server principale del database. Di conseguenza, il sito \u00e8 stato lento... ma almeno funzionava. E mentre lo Slave si riprendeva, non ci rimaneva altro da fare se non ottimizzare.\u00a0<\/p>\n

Mentre i server Slave si riprendevano, i minuti passavano lentamente, il Master era sovraccarico e noi abbiamo concentrato tutte le forze nell'ottimizzazione delle attivit\u00e0 attive secondo la \"Regola di Pareto\": abbiamo scelto le query TOP che generavano la maggior parte del carico e abbiamo iniziato a fare tuning. Questo \u00e8 stato fatto \"in tempo reale\".<\/p>\n

Un effetto interessante era che un MySQL carico rispondeva anche a un miglioramento minimo dei processi. L'ottimizzazione di un paio di query che davano solo il 5% del carico totale ha gi\u00e0 mostrato un notevole alleviamento della CPU. Di conseguenza, siamo riusciti a garantire un adeguato margine di risorse per far funzionare il Master con il database e ottenere il tempo necessario per ripristinare le repliche.\u00a0<\/p>\n

Conclusione:<\/strong> Anche una piccola ottimizzazione consente di \"sopravvivere\" in caso di sovraccarico per alcune ore. Questo \u00e8 stato sufficiente per il recupero dei server con le repliche. A proposito, discuteremo l'aspetto tecnico dell'ottimizzazione delle query in uno dei prossimi post. Quindi iscriviti al nostro blog se potrebbe esserti utile.<\/p><\/blockquote>\n

<\/p>\n

Organizza il monitoraggio della funzionalit\u00e0 dei servizi partner.<\/h3>\n

\nCi occupiamo dell'elaborazione degli ordini dei clienti e, per questo motivo, i nostri servizi interagiscono costantemente con API esterne: sono gateway per l'invio di SMS, piattaforme di pagamento, sistemi di routing, geocodifica, servizi fiscali e molte altre persone. E quando il carico ha iniziato a crescere rapidamente, abbiamo cominciato a scontrarci con le limitazioni delle API dei nostri partner, che prima non avevamo nemmeno considerato.<\/p>\n

Un'improvvisa superamento delle quote dei servizi partner pu\u00f2 portare a tempi di inattivit\u00e0 per il proprio. Molte API bloccano i clienti che superano i limiti e, in alcune situazioni, un eccesso di richieste pu\u00f2 sovraccaricare il partner in produzione.\u00a0<\/p>\n

Ad esempio, nel momento in cui cresceva il numero delle consegne, i servizi di accompagnamento non riuscivano a gestire i compiti di distribuzione e determinazione dei percorsi. Di conseguenza, accadeva che gli ordini fossero stati effettuati, ma il servizio che creava il percorso non funzionava. Va detto che i nostri logisti hanno fatto l'impossibile in queste condizioni, e la chiara interazione del team ha contribuito a compensare i fallimenti temporanei dei servizi. Ma un tale volume di richieste non pu\u00f2 essere gestito manualmente in modo continuato, e dopo un po' ci saremmo trovati di fronte a un'interruzione inaccettabile tra gli ordini e la loro esecuzione.\u00a0<\/p>\n

\u00c8 stata adottata una serie di misure organizzative, e il lavoro coordinato della squadra ha aiutato a guadagnare tempo mentre discutevamo nuove condizioni e aspettavamo l'aggiornamento dei servizi da parte di alcuni partner. Esistono anche altre API che si distinguono per l'alta resistenza e tariffe ridicole in caso di alti volumi di traffico. Ad esempio, all'inizio abbiamo utilizzato un noto API di mapping per determinare l'indirizzo del punto di consegna. Ma alla fine del mese abbiamo ricevuto una fattura di quasi 2 milioni di rubli. Dopo di ci\u00f2, abbiamo deciso di sostituirlo rapidamente. Non far\u00f2 pubblicit\u00e0, ma dir\u00f2 che le nostre spese sono diminuite significativamente.
\n\"Come<\/p>\n

Conclusione: <\/strong>\u00c8 assolutamente necessario monitorare le condizioni operative di tutti i servizi partner e tenerle a mente. Anche se oggi sembra che abbiano un \"ampio margine\", non significa che domani non diventino un ostacolo per la crescita. E, ovviamente, \u00e8 meglio stabilire 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>\" (\u0441)<\/h3>\n

\nSiamo abituati a blocchi nel database principale o nei server delle applicazioni, ma durante la scalabilit\u00e0 i problemi possono manifestarsi dove meno te lo aspetti. Per la ricerca full-text sul sito utilizziamo il motore Apache Solr. Con l'aumento del carico abbiamo notato un abbassamento dei tempi di risposta, mentre il carico della CPU del server raggiungeva gi\u00e0 il 100%. Che cosa c'\u00e8 di pi\u00f9 semplice: forniamo al container Solr pi\u00f9 risorse.<\/p>\n

Invece dell'atteso aumento delle prestazioni, il server \u00e8 semplicemente '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 aiuta: abbiamo dato al server 8 core e 32 GB. \u00c8 andato tutto molto peggio (come e perch\u00e9 lo racconteremo in un post a parte).\u00a0<\/p>\n

In pochi giorni abbiamo approfondito le sottigliezze di questa questione e abbiamo raggiunto prestazioni ottimali con 8 core e 32 GB. Questa configurazione ci consente ancora oggi di continuare a incrementare il carico, il che \u00e8 molto importante, perch\u00e9 la crescita non sta avvenendo solo per i clienti, ma anche per il numero di negozi collegati: in 2 mesi il loro numero \u00e8 raddoppiato.\u00a0<\/p>\n

Conclusione: <\/strong>I metodi standard, come 'aggiungere pi\u00f9 hardware', non funzionano sempre. Quindi, durante la scalabilit\u00e0 di qualsiasi servizio, \u00e8 importante comprendere bene come utilizza le risorse e testarne prima il funzionamento in nuove condizioni.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

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

\nNel complesso, il nostro team adotta l'approccio noto: i servizi non devono avere uno stato interno (stateless) e devono essere indipendenti dall'ambiente di esecuzione. Questo ci ha permesso di affrontare l'aumento del carico attraverso una semplice scalabilit\u00e0 orizzontale. Ma abbiamo avuto un servizio eccezionale: un gestore di lunghi processi in background. Si occupava dell'invio di email e sms, della gestione di eventi, della generazione di feed, dell'importazione di prezzi e scorte, della lavorazione delle immagini. Cos\u00ec \u00e8 capitato che dipendesse da un'archiviazione locale e fosse presente in un unico esemplare.\u00a0<\/p>\n

Quando \u00e8 aumentato il numero di compiti in coda nel processore (cosa accaduta naturalmente con l'aumento del numero di ordini), le prestazioni dell'host su cui erano ospitati il processore e il sistema di archiviazione files sono diventati un fattore limitante. Di conseguenza, l'aggiornamento dell'assortimento e dei prezzi, l'invio di notifiche agli utenti e molte altre funzioni critiche si sono bloccate in coda. Il team Ops ha migrato rapidamente il sistema di archiviazione a un deposito di rete simile a S3, il che ci ha permesso di attivare diverse macchine potenti per scalare il processore dei compiti in background.<\/p>\n

Conclusione: <\/strong>La regola Stateless deve essere rispettata per tutti i componenti senza eccezione, anche se sembra \"che qui non ci sia il rischio di problemi\". \u00c8 meglio spendere un po' di tempo nella corretta organizzazione del lavoro di tutti i sistemi piuttosto che dover riscrivere il codice e riparare il servizio sovraccarico in fretta.<\/p><\/blockquote>\n

<\/p>\n

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

\nNonostante la disponibilit\u00e0 di capacit\u00e0 aggiuntive, durante il processo di crescita abbiamo incontrato alcuni ostacoli. In questo periodo il numero di ordini \u00e8 aumentato di oltre 4 volte. Ora consegniamo gi\u00e0 pi\u00f9 di 17.000 ordini al giorno in 62 citt\u00e0 e prevediamo di espandere ulteriormente la nostra geografia: nel primo semestre del 2020 \u00e8 prevista l'apertura del servizio in tutta la Russia. Per affrontare il carico crescente, tenendo conto delle esperienze gi\u00e0 fatte, abbiamo definito 7 principi fondamentali per lavorare in condizioni di crescita costante:<\/p>\n

    \n
  1. Incident management<\/strong>. Abbiamo creato una bacheca in Jira, dove ogni incidente \u00e8 rappresentato da un ticket. Questo aiuta a prioritizzare e a svolgere i compiti relativi all'incidente. Infatti, non \u00e8 spaventoso commettere errori \u2014 ci\u00f2 che spaventa \u00e8 sbagliare due volte per la stessa cosa. Per quei casi in cui gli incidenti si ripetono prima che si riesca a correggere la causa, si deve avere pronte delle istruzioni su cosa fare, poich\u00e9 durante un carico elevato \u00e8 importante rispondere prontamente.<\/li>\n
  2. Monitoraggio <\/strong>\u00e8 richiesto per tutti gli elementi dell'infrastruttura senza eccezioni. \u00c8 grazie a questo che siamo stati in grado di prevedere la crescita del carico e di identificare correttamente i \"collo di bottiglia\" per la priorit\u00e0 di risoluzione. \u00c8 probabile che, in caso di carico elevato, si rompa o inizi a rallentare tutto ci\u00f2 di cui non avresti pensato. Pertanto, \u00e8 meglio creare nuovi avvisi subito dopo i primi incidenti, per monitorarli e prevenirli.<\/li>\n
  3. Avvisi corretti<\/strong> sono semplicemente necessari in caso di aumento improvviso del carico. In primo luogo, devono segnalare esattamente cosa si \u00e8 rotto. In secondo luogo, non dovrebbero esserci troppi avvisi, poich\u00e9 un eccesso di avvisi non critici porta all'ignoranza di tutte le notifiche.<\/li>\n
  4. Le applicazioni devono essere stateless. <\/strong>Ci siamo assicurati che non ci siano eccezioni per questa regola. \u00c8 necessaria una completa indipendenza dall'ambiente di esecuzione. A questo proposito, puoi memorizzare i dati condivisi in un database o, ad esempio, direttamente in S3. \u00c8 anche meglio seguire le regole https:\/\/12factor.net<\/a><\/noindex>. Durante un aumento improvviso del tempo, non c'\u00e8 modo di ottimizzare il codice e affrontare il carico sar\u00e0 necessario farlo aumentando direttamente le risorse di calcolo e con la scalabilit\u00e0 orizzontale.<\/li>\n
  5. Quote e prestazioni dei servizi esterni. <\/strong>Con una rapida crescita, il problema pu\u00f2 sorgere non solo nella tua infrastruttura, ma anche nel servizio esterno. La cosa pi\u00f9 frustrante \u00e8 quando ci\u00f2 accade non a causa di un guasto, ma a causa del raggiungimento di quote o limiti. Pertanto, i servizi esterni devono scalare altrettanto bene quanto te.\u00a0<\/li>\n
  6. Separare i processi e le code. <\/strong>Questo aiuta molto quando uno dei gateway ha un intoppo. Non avremmo avuto ritardi nella trasmissione dei dati se le code piene per l'invio degli SMS non avessero ostacolato lo scambio di notifiche tra i sistemi informativi. Inoltre, sarebbe stato pi\u00f9 semplice aumentare il numero di worker se avessero lavorato separatamente.<\/li>\n
  7. Realt\u00e0 finanziarie.<\/strong> Quando si verifica una crescita esplosiva dei flussi di dati, non c'\u00e8 tempo per pensare alle tariffe e agli abbonamenti. Ma \u00e8 necessario ricordarle, soprattutto se siete una piccola azienda. Una grande fattura pu\u00f2 essere presentata dal proprietario di qualsiasi API, cos\u00ec come dal tuo provider di hosting. Pertanto, \u00e8 importante leggere attentamente i contratti.<\/li>\n<\/ol>\n

    <\/p>\n

    Conclusione<\/h2>\n

    \nNon senza perdite, ma siamo riusciti a superare questa fase e oggi ci impegniamo a rispettare tutti i principi trovati, e ogni macchina ha la possibilit\u00e0 di un facile aumento delle prestazioni di x4 per affrontare eventuali imprevisti.\u00a0<\/p>\n

    Nei prossimi post condivideremo la nostra esperienza nell'indagine sui cali di performance in Apache Solr, e parleremo dell'ottimizzazione delle richieste e di come l'interazione con l'FNS aiuti l'azienda a risparmiare denaro. Iscriviti al nostro blog per non perdere nulla e raccontaci nei commenti se hai mai avuto simili problemi durante l'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 riscontrato rallentamenti\/o inattivit\u00e0 del servizio a causa di un improvviso aumento del carico dovuto a:<\/h2>\n