{"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\/sk\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Ako sme pre\u017eili v\u00fdrazn\u00fd n\u00e1rast z\u00e1\u0165a\u017ee x10 na dia\u013eku a ak\u00e9 pou\u010denia sme si z toho vzali","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ahojte, Habr! Posledn\u00e9 p\u00e1r mesiacov sme pre\u017eili vo ve\u013emi zauj\u00edmavej situ\u00e1cii a chcel by som sa podeli\u0165 o n\u00e1\u0161u pr\u00edbeh o \u0161k\u00e1lovan\u00ed infra\u0161trukt\u00fary. Po\u010das tohto obdobia SberMarket zv\u00fd\u0161il objem objedn\u00e1vok \u0161tvorn\u00e1sobne a spustil slu\u017ebu v 17 nov\u00fdch mest\u00e1ch. Exploz\u00edvny rast dopytu po doru\u010den\u00ed potrav\u00edn si vy\u017eiadal od n\u00e1s roz\u0161irovanie infra\u0161trukt\u00fary. O najzauj\u00edmavej\u0161\u00edch a naju\u017eito\u010dnej\u0161\u00edch poznatkoch \u010d\u00edtajte pod katom.<\/p>\n

\"Ako
\n<\/a><\/noindex>
\nVol\u00e1m sa Dima Bobylev, som technick\u00fd riadite\u013e SberMarketu. Ke\u010f\u017ee toto je prv\u00fd pr\u00edspevok v na\u0161om blogu, poviem p\u00e1r slov o sebe a o spolo\u010dnosti. Minul\u00fa jese\u0148 som sa z\u00fa\u010dastnil s\u00fa\u0165a\u017ee mlad\u00fdch l\u00eddrov RuNetu. Pre t\u00fato s\u00fa\u0165a\u017e som nap\u00edsal kr\u00e1tky pr\u00edbeh<\/a><\/noindex> o tom, ako my v SberMarkete vid\u00edme vn\u00fatorn\u00fa kult\u00faru a pr\u00edstup k rozvoju slu\u017eby. A hoci sa mi v s\u00fa\u0165a\u017ei nepodarilo vyhra\u0165, formuloval som si hlavn\u00e9 z\u00e1sady rozvoja IT-ekosyst\u00e9mu. <\/p>\n

Pri riaden\u00ed t\u00edmu je d\u00f4le\u017eit\u00e9 rozumie\u0165 a n\u00e1js\u0165 rovnov\u00e1hu medzi t\u00fdm, \u010do potrebuje biznis, a potrebami ka\u017ed\u00e9ho konkr\u00e9tneho v\u00fdvoj\u00e1ra. V s\u00fa\u010dasnosti SberMarket rastie 13-kr\u00e1t ro\u010dne, \u010do ovplyv\u0148uje produkt a vy\u017eaduje neust\u00e1le zvy\u0161ovanie objemov a tempa v\u00fdvoja. Napriek tomu vy\u010dle\u0148ujeme dostatok \u010dasu pre v\u00fdvoj\u00e1rov na predbe\u017en\u00fa anal\u00fdzu a kvalitn\u00e9 p\u00edsanie k\u00f3du. Ustanoven\u00fd pr\u00edstup pom\u00e1ha nielen pri vytv\u00e1ran\u00ed funk\u010dn\u00e9ho produktu, ale aj pri jeho \u010fal\u0161om \u0161k\u00e1lovan\u00ed a rozvoji. V d\u00f4sledku tak\u00e9ho rastu sa SberMarket u\u017e stal l\u00eddrom medzi slu\u017ebami doru\u010dovania potrav\u00edn: denne doru\u010dujeme pribli\u017ene 18 tis\u00edc objedn\u00e1vok, hoci e\u0161te na za\u010diatku febru\u00e1ra ich bolo len okolo 3500.<\/p>\n

\"Ako
\nRaz z\u00e1kazn\u00edk po\u017eiadal kuri\u00e9ra SberMarketu, aby mu doru\u010dil potraviny bezkontaktn\u00fdm sp\u00f4sobom \u2014 priamo na balk\u00f3n.<\/i><\/p>\n

Ale po\u010fme k praktick\u00e9mu. Posledn\u00e9 mesiace sme akt\u00edvne pracovali na roz\u0161irovan\u00ed infra\u0161trukt\u00fary na\u0161ej spolo\u010dnosti. Tento potrebn\u00fd krok bol sp\u00f4soben\u00fd vonkaj\u0161\u00edmi a vn\u00fatorn\u00fdmi faktormi. Spolu so zvy\u0161ovan\u00edm na\u0161ej klientely sa po\u010det pripojen\u00fdch obchodov zv\u00fd\u0161il z 90 na za\u010diatku roka na viac ako 200 do polovice m\u00e1ja. Samozrejme, pripravili sme sa, rezervovali sme hlavn\u00fa infra\u0161trukt\u00faru a kalkulovali sme s mo\u017enos\u0165ou vertik\u00e1lneho a horizont\u00e1lneho roz\u0161irovania v\u0161etk\u00fdch virtu\u00e1lnych strojov umiestnen\u00fdch v cloude Yandex. Av\u0161ak prax uk\u00e1zala: \u201eV\u0161etko, \u010do m\u00f4\u017ee \u00eds\u0165 zle, p\u00f4jde zle.\u201c Dnes by som chcel zdie\u013ea\u0165 nieko\u013eko zauj\u00edmav\u00fdch situ\u00e1ci\u00ed, ktor\u00e9 sa vyskytli po\u010das t\u00fdchto t\u00fd\u017ed\u0148ov. D\u00fafam, \u017ee na\u0161e sk\u00fasenosti bud\u00fa pre v\u00e1s u\u017eito\u010dn\u00e9.<\/p>\n

Slave je v plnej bojovej pohotovosti<\/h3>\n

\nE\u0161te pred za\u010diatkom pand\u00e9mie sme sa stretli s rastom po\u010dtu po\u017eiadaviek na na\u0161e backend servery. Trend objedn\u00e1vania produktov s doru\u010den\u00edm domov sa za\u010dal vyv\u00edja\u0165, a s pr\u00edchodom prv\u00fdch opatren\u00ed izol\u00e1cie v s\u00favislosti s COVID-19, sa z\u00e1\u0165a\u017e dramaticky zvy\u0161ovala pred o\u010dami po\u010das cel\u00e9ho d\u0148a. Vznikla potreba r\u00fdchlo uvo\u013eni\u0165 master servery hlavnej datab\u00e1zy a presun\u00fa\u0165 \u010das\u0165 po\u017eiadaviek na \u010d\u00edtanie na repliku serverov (slave).<\/p>\n

Na tento krok sme sa vopred pripravili, a pre tento man\u00e9ver sme u\u017e spustili 2 slave servery. Na nich sa preva\u017ene vykon\u00e1vali batch \u00falohy generovania informa\u010dn\u00fdch feedov na v\u00fdmenu \u00fadajov s partnermi. Tieto procesy vytv\u00e1rali zbyto\u010dn\u00fa z\u00e1\u0165a\u017e a pr\u00e1vom boli presunut\u00e9 \u201emimo zretelia\u201c pred nieko\u013ek\u00fdmi mesiacmi.\u00a0<\/p>\n

Ke\u010f\u017ee na Slave prebiehal replik\u00e1cia, dodr\u017eiavali sme koncepciu, \u017ee aplik\u00e1cie m\u00f4\u017eu s nimi pracova\u0165 iba v re\u017eime len na \u010d\u00edtanie. Disaster Recovery Plan predpokladal, \u017ee v pr\u00edpade katastrofy budeme m\u00f4c\u0165 jednoducho pripoji\u0165 Slave miesto Master a prepn\u00fa\u0165 v\u0161etky po\u017eiadavky na z\u00e1pis a \u010d\u00edtanie na Slave. Chceli sme v\u0161ak tie\u017e vyu\u017ei\u0165 repliky na potreby analytick\u00e9ho oddelenia, tak\u017ee servery neboli \u00faplne premenen\u00e9 na status len na \u010d\u00edtanie, a na ka\u017edom hoste bol svoj vlastn\u00fd s\u00fabor pou\u017e\u00edvate\u013eov, pri\u010dom niektor\u00ed mali pr\u00e1va na z\u00e1pis na uchovanie medzi\u010dasov\u00fdch v\u00fdsledkov v\u00fdpo\u010dtov.<\/p>\n

Do ur\u010dit\u00e9 \u00farovne za\u0165a\u017eenia n\u00e1m sta\u010dil master na z\u00e1pis aj \u010d\u00edtanie pri spracovan\u00ed http-\u017eiadost\u00ed. V polovici marca, pr\u00e1ve ke\u010f Sbermarket prijal rozhodnutie prejs\u0165 na pr\u00e1cu z domu, sme za\u017eili v\u00fdrazn\u00fd n\u00e1rast RPS. \u010coraz viac na\u0161ich klientov pre\u0161lo na samoizol\u00e1ciu alebo pr\u00e1cu z domu, \u010do sa odrazilo na ukazovate\u013eoch za\u0165a\u017eenia.<\/p>\n

V\u00fdkon \u201emastera\u201c prestal by\u0165 dosta\u010duj\u00faci, a preto sme za\u010dali pres\u00fava\u0165 \u010das\u0165 najn\u00e1ro\u010dnej\u0161\u00edch \u010d\u00edtac\u00edch po\u017eiadaviek na replik\u00e1ciu. Na transparentn\u00e9 smerovanie po\u017eiadaviek na z\u00e1pis do mastera, a \u010d\u00edtanie do slave, sme pou\u017eili ruby gem \u201eOctopus<\/a><\/noindex>\u201c. Vytvorili sme \u0161peci\u00e1lneho pou\u017e\u00edvate\u013ea s postfixom _readonly bez pr\u00e1v na z\u00e1pis. Ale v d\u00f4sledku chyby v konfigur\u00e1cii jedn\u00e9ho z hostite\u013eov sa \u010das\u0165 po\u017eiadaviek na z\u00e1pis dostala na slave-server pod menom pou\u017e\u00edvate\u013ea, ktor\u00fd mal pr\u00edslu\u0161n\u00e9 pr\u00e1va.<\/p>\n

Probl\u00e9m sa neprejavil hne\u010f, preto\u017ee zv\u00fd\u0161en\u00e9 za\u0165a\u017eenie zv\u00fd\u0161ilo oneskorenie sl\u00e1v. Nekonzistencia d\u00e1t bola zisten\u00e1 r\u00e1no, ke\u010f po no\u010dn\u00fdch importoch sl\u00e1vy nedohnali master. Prip\u00edsali sme to na vysok\u00e9 za\u0165a\u017eenie samotn\u00e9ho servisu a importy spojen\u00e9 so spusten\u00edm nov\u00fdch obchodov. Ale poskytovanie \u00fadajov s hodinov\u00fdm oneskoren\u00edm bolo neprijate\u013en\u00e9, a tak sme prepli procesy na druh\u00e9ho analytick\u00e9ho slave, preto\u017ee mal v\u00e4\u010d\u0161ie zdroje a nebol za\u0165a\u017een\u00fd po\u017eiadavkami na \u010d\u00edtanie (\u010d\u00edm sme si aj vysvetlili absenciu lagovania replik\u00e1cie).o<\/strong>Ke\u010f sme sa vysporiadali s pr\u00ed\u010dinami \u201erozchodu\u201c hlavn\u00e9ho slave, analytick\u00fd u\u017e bol mimo prev\u00e1dzky z rovnak\u00e9ho d\u00f4vodu. Napriek tomu, \u017ee sme mali dva \u010fal\u0161ie servery, na ktor\u00e9 sme pl\u00e1novali presun\u00fa\u0165 za\u0165a\u017eenie v pr\u00edpade zlyhania mastera, kv\u00f4li hl\u00fapej chybe sa uk\u00e1zalo, \u017ee v kritickej chv\u00edli neexistoval ani jeden.<\/p>\n

Ale ke\u010f\u017ee sme robili nielen dump datab\u00e1zy (obnova trvala pribli\u017ene 5 hod\u00edn), ale aj snapshot master-servera, podarilo sa n\u00e1m spusti\u0165 replik\u00e1ciu za 2 hodiny. Pravda, po tom n\u00e1s \u010dakalo nahr\u00e1vanie replika\u010dn\u00e9ho logu na dlh\u00fa dobu (preto\u017ee proces prebieha v jednopriestorovom re\u017eime, ale to je u\u017e \u00faplne in\u00fd pr\u00edbeh).<\/p>\n

Ke\u010f\u017ee sme nielen\u017ee robili dump datab\u00e1zy (restaur\u00e1cia trvala pribli\u017ene 5 hod\u00edn), ale aj snapshot master-servera, podarilo sa n\u00e1m spusti\u0165 replik\u00e1ciu za 2 hodiny. Po tom n\u00e1s v\u0161ak \u010dakal dlh\u00fd proces aplik\u00e1cie replika\u010dn\u00e9ho logu (preto\u017ee proces prebieha v jednovl\u00e1knovom re\u017eime, ale to je u\u017e \u00faplne in\u00fd pr\u00edbeh).<\/p>\n

V\u00fdstup:<\/strong> Po takom incidente sa stalo jasn\u00e9, \u017ee je potrebn\u00e9 vzda\u0165 sa praxe obmedzenia z\u00e1znamu pre pou\u017e\u00edvate\u013eov a vyhl\u00e1si\u0165 cel\u00fd server za readonly. Pri takomto pr\u00edstupe si m\u00f4\u017eeme by\u0165 ist\u00ed, \u017ee repliky bud\u00fa dostupn\u00e9 v kritickom okamihu.<\/p><\/blockquote>\n

<\/p>\n

Optimaliz\u00e1cia aj len jedn\u00e9ho \u0165a\u017ek\u00e9ho dopytu m\u00f4\u017ee \"vzbudi\u0165\" datab\u00e1zu.<\/h3>\n

\nAj ke\u010f neust\u00e1le aktualizujeme katal\u00f3g na str\u00e1nke, dopyty, ktor\u00e9 sme presunuli na Slave servery, mali mierne oneskorenie oproti Master. \u010cas, za ktor\u00fd sme objavili a odstr\u00e1nili probl\u00e9m \"n\u00e1silne odstaven\u00fdch\" slave-ov, bol dlh\u0161\u00ed ako \"psychologick\u00e1 bari\u00e9ra\" (po\u010das tohto \u010dasu mohlo d\u00f4js\u0165 k aktualiz\u00e1cii cien, a klienti by videli zastaran\u00e9 \u00fadaje), a boli sme n\u00faten\u00ed prepn\u00fa\u0165 v\u0161etky dopyty na hlavn\u00fd server datab\u00e1zy. V\u00fdsledkom bolo, \u017ee str\u00e1nka fungovala pomaly... ale aspo\u0148 fungovala. A k\u00fdm sa Slave obnovoval, nemali sme in\u00fa mo\u017enos\u0165, ne\u017e optimalizova\u0165.\u00a0<\/p>\n

K\u00fdm sa Slave servery obnovovali, min\u00faty sa pomaly \u0165ahali, Master zost\u00e1val pre\u0165a\u017een\u00fd a s\u00fastredili sme v\u0161etky sily na optimaliz\u00e1ciu akt\u00edvnych \u00faloh pod\u013ea \u201ePravidla Pareto\u201c: vybrali sme TOP dopyty, ktor\u00e9 sp\u00f4sobovali najv\u00e4\u010d\u0161iu z\u00e1\u0165a\u017e a za\u010dali s lad\u011bn\u00edm. Robilo sa to priamo \"za jazdy\".<\/p>\n

Zauj\u00edmav\u00fd efekt spo\u010d\u00edval v tom, \u017ee MySQL prisp\u00f4soben\u00fd na maximum reaguje na aj nepatrn\u00e9 zlep\u0161enie procesov. Optimaliz\u00e1cia nieko\u013ek\u00fdch dopytov, ktor\u00e9 tvorili len 5% celkovej z\u00e1\u0165a\u017ee, u\u017e uk\u00e1zala v\u00fdrazn\u00e9 uvo\u013enenie CPU. V\u00fdsledkom sa n\u00e1m podarilo zabezpe\u010di\u0165 akceptovate\u013en\u00fd prebytok zdrojov pre pr\u00e1cu Master s datab\u00e1zou a z\u00edska\u0165 potrebn\u00fd \u010das na obnovu replik.\u00a0<\/p>\n

V\u00fdstup:<\/strong> Aj drobn\u00e1 optimaliz\u00e1cia umo\u017e\u0148uje \"pre\u017ei\u0165\" pri pre\u0165a\u017eovan\u00ed po\u010das nieko\u013ek\u00fdch hod\u00edn. To n\u00e1m sta\u010dilo na \u010das obnovy serverov s replikami. Mimochodom, technick\u00fa str\u00e1nku optimaliz\u00e1cie dopytov prediskutujeme v jednom z nasleduj\u00facich pr\u00edspevkov. Tak sa prihl\u00e1ste na odber n\u00e1\u0161ho blogu, ak by sa v\u00e1m to mohlo hodi\u0165.<\/p><\/blockquote>\n

<\/p>\n

Zorganizujte monitorovanie funk\u010dnosti slu\u017eieb partnerov.<\/h3>\n

\nZaober\u00e1me sa spracovan\u00edm objedn\u00e1vok od z\u00e1kazn\u00edkov, a preto na\u0161e slu\u017eby neust\u00e1le komunikuj\u00fa so spo\u013eahliv\u00fdmi API \u2014 s\u00fa to br\u00e1ny na zasielanie SMS, platobn\u00e9 platformy, syst\u00e9my smerovania, geokod\u00e9r, slu\u017eba FSN a mno\u017estvo in\u00fdch syst\u00e9mov. A ke\u010f sa za\u0165a\u017eenie r\u00fdchlo zv\u00fd\u0161ilo, za\u010dali sme naraz\u00edna\u0165 na obmedzenia API na\u0161ich partnersk\u00fdch slu\u017eieb, o ktor\u00fdch sme predt\u00fdm ani neprem\u00fd\u0161\u013eali.<\/p>\n

Neo\u010dak\u00e1van\u00e9 prekro\u010denie kv\u00f3t partnersk\u00fdch slu\u017eieb m\u00f4\u017ee vies\u0165 k v\u00fdpadku vo va\u0161om vlastnom. Mnoh\u00e9 API blokuj\u00fa klientov, ktor\u00ed prekra\u010duj\u00fa limity, a v niektor\u00fdch pr\u00edpadoch nadbytok po\u017eiadaviek m\u00f4\u017ee pre\u0165a\u017ei\u0165 produkciu partnera.\u00a0<\/p>\n

Napr\u00edklad, v \u010dase rastu po\u010dtu dod\u00e1vok sprievodn\u00e9 slu\u017eby nezvl\u00e1dali \u00falohy ich rozdelenia a ur\u010dovania tr\u00e1s. V\u00fdsledkom bolo, \u017ee objedn\u00e1vky boli vytvoren\u00e9, ale slu\u017eba, ktor\u00e1 vytv\u00e1ra trasu, nefungovala. Treba poveda\u0165, \u017ee na\u0161i logistici urobili takmer nemo\u017en\u00e9 za t\u00fdchto podmienok a jasn\u00e1 spolupr\u00e1ca t\u00edmu pomohla kompenzova\u0165 do\u010dasn\u00e9 v\u00fdpadky slu\u017eieb. Ale tak\u00fd objem \u017eiadost\u00ed nie je mo\u017en\u00e9 st\u00e1le spracov\u00e1va\u0165 ru\u010dne, a po ur\u010ditom \u010dase by sme sa stretli s neakceptovate\u013en\u00fdm rozporom medzi objedn\u00e1vkami a ich vykonan\u00edm.\u00a0<\/p>\n

Bola prijat\u00e1 cel\u00e1 rada organiza\u010dn\u00fdch opatren\u00ed a s\u00falade pr\u00e1ce kolekt\u00edvu pomohlo z\u00edska\u0165 \u010das, k\u00fdm sme sa dohodli na nov\u00fdch podmienkach a \u010dakali na moderniz\u00e1ciu slu\u017eieb zo strany niektor\u00fdch partnerov. Existuj\u00fa aj in\u00e9 API, ktor\u00e9 sa vyzna\u010duj\u00fa vysokou odolnos\u0165ou a neuverite\u013en\u00fdmi tarifami v pr\u00edpade vysok\u00e9ho prenosu. Napr\u00edklad, na za\u010diatku sme pou\u017e\u00edvali jedno zn\u00e1me mapov\u00e9 API na ur\u010denie adresy odoslania. Ale na konci mesiaca sme dostali \u00fa\u010det takmer 2 mili\u00f3ny rub\u013eov. N\u00e1sledne sme sa rozhodli ho r\u00fdchlo vymeni\u0165. Nebudem robi\u0165 reklamu, ale poviem, \u017ee na\u0161e n\u00e1klady sa v\u00fdrazne zn\u00ed\u017eili.
\n\"Ako<\/p>\n

V\u00fdstup: <\/strong>Je potrebn\u00e9 neust\u00e1le monitorova\u0165 podmienky fungovania v\u0161etk\u00fdch partnersk\u00fdch slu\u017eieb a ma\u0165 ich na zreteli. Aj ke\u010f sa dnes zd\u00e1, \u017ee maj\u00fa \"ve\u013ek\u00fd rezerva\", neznamen\u00e1 to, \u017ee zajtra sa nestan\u00fa prek\u00e1\u017ekou pre rast. A samozrejme, je lep\u0161ie dohodn\u00fa\u0165 sa na finan\u010dn\u00fdch podmienkach zv\u00fd\u0161en\u00fdch po\u017eiadaviek na slu\u017ebu vopred.\u00a0<\/p><\/blockquote>\n

<\/p>\n

Niekedy sa uk\u00e1\u017ee, \u017ee \"potrebujete viac zlata<\/a><\/noindex>\" (c) nepom\u00e1ha<\/h3>\n

\nSme zvyknut\u00ed na \u201ez\u00e1cpy\u201c v hlavnej datab\u00e1ze alebo na serveroch aplik\u00e1ci\u00ed, no pri roz\u0161irovan\u00ed sa probl\u00e9my m\u00f4\u017eu prejavi\u0165 tam, kde ich ani ne\u010dak\u00e1te. Na fulltextov\u00e9 vyh\u013ead\u00e1vanie na webe pou\u017e\u00edvame engine Apache Solr. S rast\u00facim za\u0165a\u017een\u00edm sme si v\u0161imli zn\u00ed\u017eenie doby odozvy, zatia\u013e \u010do za\u0165a\u017eenie procesora servera dosiahlo u\u017e 100%. \u010co by mohlo by\u0165 jednoduch\u0161ie \u2014 poskytneme kontajneru so Solrom viac prostriedkov.<\/p>\n

Namiesto o\u010dak\u00e1van\u00e9ho n\u00e1rastu v\u00fdkonu server jednoducho \u201eumrel\u201c. Okam\u017eite sa za\u0165a\u017eoval na 100% a odpovedal e\u0161te pomal\u0161ie. P\u00f4vodne sme mali 2 jadr\u00e1 a 2 GB RAM. Rozhodli sme sa urobi\u0165 to, \u010do zvy\u010dajne pom\u00e1ha \u2014 dali sme serveru 8 jadier a 32 GB. V\u0161etko sa stalo ove\u013ea hor\u0161ie (ako presne a pre\u010do \u2014 povieme v samostatnom pr\u00edspevku).\u00a0<\/p>\n

Za p\u00e1r dn\u00ed sme pochopili nuansy tejto z\u00e1le\u017eitosti a dosiahli sme optim\u00e1lny v\u00fdkon pri 8 jadr\u00e1ch a 32 GB. T\u00e1to konfigur\u00e1cia n\u00e1m umo\u017e\u0148uje aj dnes pokra\u010dova\u0165 v zvy\u0161ovan\u00ed za\u0165a\u017eenia, \u010do je ve\u013emi d\u00f4le\u017eit\u00e9, preto\u017ee rast prebieha nielen u klientov, ale aj v po\u010dte pripojen\u00fdch obchodov \u2014 za 2 mesiace sa ich po\u010det zdvojn\u00e1sobil.\u00a0<\/p>\n

V\u00fdstup: <\/strong>\u0160tandardn\u00e9 met\u00f3dy ako \u201eprida\u0165 viac hardv\u00e9ru\u201c nefunguj\u00fa v\u017edy. Tak\u017ee pri roz\u0161irovan\u00ed akejko\u013evek slu\u017eby je potrebn\u00e9 dobre ch\u00e1pa\u0165, ako vyu\u017e\u00edva zdroje a vopred testova\u0165 jej pr\u00e1cu v nov\u00fdch podmienkach.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 k\u013e\u00fa\u010d k jednoduch\u00e9mu horizont\u00e1lnemu \u0161k\u00e1lovaniu.<\/h3>\n

\nV na\u0161om celkovom pr\u00edstupe sa na\u0161a t\u00edm riadi zn\u00e1mych princ\u00edpom: slu\u017eby by nemali ma\u0165 vn\u00fatorn\u00fd stav (stateless) a mali by by\u0165 nez\u00e1visl\u00e9 od prostredia behu. To n\u00e1m umo\u017enilo pre\u017ei\u0165 rast za\u0165a\u017eenia jednoduch\u00fdm horizont\u00e1lnym \u0161k\u00e1lovan\u00edm. Ale mali sme jednu v\u00fdnimku: spracovate\u013e dlh\u00fdch pozadov\u00fdch \u00faloh. Ten sa zaoberal odosielan\u00edm emailov a sms, spracovan\u00edm udalost\u00ed, generovan\u00edm feedov, importom cien a skladov, spracovan\u00edm obr\u00e1zkov. Tak sa stalo, \u017ee z\u00e1visel od lok\u00e1lneho s\u00faborov\u00e9ho \u00falo\u017eiska a bol v jedinom exempl\u00e1ri.\u00a0<\/p>\n

Ke\u010f sa zv\u00fd\u0161il po\u010det \u00faloh v porad\u00ed spracovate\u013ea (\u010do sa prirodzene stalo so zv\u00fd\u0161en\u00edm po\u010dtu objedn\u00e1vok), v\u00fdkon hos\u0165a, na ktorom boli umiestnen\u00e9 spracovate\u013e a \u00falo\u017eisko s\u00faborov, sa stal limituj\u00facim faktorom. V d\u00f4sledku toho sa zastavilo aktualizovanie sortimentu a cien, odosielanie notifik\u00e1ci\u00ed pou\u017e\u00edvate\u013eom a mno\u017estvo \u010fal\u0161\u00edch kritick\u00fdch funkci\u00ed, ktor\u00e9 uviazli v porad\u00ed. T\u00edm Ops r\u00fdchlo presunul \u00falo\u017eisko s\u00faborov do S3-podobn\u00e9ho sie\u0165ov\u00e9ho \u00falo\u017eiska, \u010do n\u00e1m umo\u017enilo nasadi\u0165 nieko\u013eko v\u00fdkonn\u00fdch strojov na \u0161k\u00e1lovanie spracovate\u013ea pozad\u00ed.<\/p>\n

V\u00fdstup: <\/strong>Pravidlo Stateless je potrebn\u00e9 dodr\u017eiava\u0165 pre v\u0161etky komponenty bez v\u00fdnimky, aj ke\u010f sa zd\u00e1, \u017ee \"tu sa ur\u010dite nezasekneme\". Rad\u0161ej investova\u0165 trochu \u010dasu do spr\u00e1vnej organiz\u00e1cie pr\u00e1ce v\u0161etk\u00fdch syst\u00e9mov, ne\u017e potom v zhone prepisova\u0165 k\u00f3d a opravova\u0165 slu\u017ebu, ktor\u00e1 za\u017e\u00edva pre\u0165a\u017eenie.<\/p><\/blockquote>\n

<\/p>\n

7 princ\u00edpov pre intenz\u00edvny rast<\/h2>\n

\nNapriek dostupnosti \u010fal\u0161\u00edch kapac\u00edt sme po\u010das rastu narazili na nieko\u013eko prek\u00e1\u017eok. Po\u010das tohto \u010dasu sa po\u010det objedn\u00e1vok zv\u00fd\u0161il viac ako 4-kr\u00e1t. Teraz u\u017e doru\u010dujeme viac ako 17 000 objedn\u00e1vok denne v 62 mest\u00e1ch a pl\u00e1nujeme e\u0161te viac roz\u0161\u00edri\u0165 geografiu \u2014 v prvom polroku 2020 sa o\u010dak\u00e1va spustenie slu\u017eby po celom Rusku. Aby sme sa vyrovnali s rast\u00facou z\u00e1\u0165a\u017eou a zoh\u013eadnili u\u017e nahromaden\u00e9 sk\u00fasenosti, definovali sme si 7 z\u00e1kladn\u00fdch princ\u00edpov pr\u00e1ce v podmienkach neust\u00e1leho rastu:<\/p>\n

    \n
  1. Incident management<\/strong>. Vytvorili sme dosku v Jira, kde sa ka\u017ed\u00fd incident odr\u00e1\u017ea vo forme tiketu. To pom\u00f4\u017ee fakticky prioritizova\u0165 a vykon\u00e1va\u0165 \u00falohy s\u00favisiace s incidentom. Ve\u010f v podstate nie je hrozn\u00e9 robi\u0165 chyby \u2014 hrozn\u00e9 je robi\u0165 chyby dvakr\u00e1t na tom istom mieste. Pre pr\u00edpady, ke\u010f sa incidenty opakuj\u00fa sk\u00f4r, ne\u017e sa podar\u00ed opravi\u0165 pr\u00ed\u010dinu, by mala by\u0165 pripraven\u00e1 in\u0161trukcia na postup, preto\u017ee po\u010das ve\u013ekej z\u00e1\u0165a\u017ee je d\u00f4le\u017eit\u00e9 reagova\u0165 okam\u017eite.<\/li>\n
  2. Monitorovanie <\/strong>je potrebn\u00fd pre v\u0161etky prvky infra\u0161trukt\u00fary bez v\u00fdnimky. Pr\u00e1ve v\u010faka nemu sme mohli predpoveda\u0165 rast za\u0165a\u017eenia a spr\u00e1vne vybera\u0165 \"\u00fazke hrdl\u00e1\" na prioritiz\u00e1ciu odstra\u0148ovania. Pravdepodobne pri vysokom za\u0165a\u017een\u00ed sa pokaz\u00ed alebo za\u010dne spoma\u013eova\u0165 v\u0161etko, o \u010dom by ste ani neprem\u00fd\u0161\u013eali. Preto je najlep\u0161ie vytv\u00e1ra\u0165 nov\u00e9 upozornenia hne\u010f po prv\u00fdch incidentoch, aby sme ich monitorovali a predv\u00eddali.<\/li>\n
  3. Spr\u00e1vne upozornenia<\/strong> s\u00fa jednoducho nevyhnutn\u00e9 pri n\u00e1hlom raste za\u0165a\u017eenia. Po prv\u00e9, musia informova\u0165 o tom, \u010do sa presne pokazilo. Po druh\u00e9, nemalo by by\u0165 ve\u013ea upozornen\u00ed, preto\u017ee mno\u017estvo nekritick\u00fdch upozornen\u00ed vedie k ignorovaniu v\u0161etk\u00fdch ozn\u00e1men\u00ed.<\/li>\n
  4. Aplik\u00e1cie musia by\u0165 stateless. <\/strong>Uistili sme sa, \u017ee pre toto pravidlo by nemali by\u0165 v\u00fdnimky. Potrebn\u00e1 je \u00fapln\u00e1 nez\u00e1vislos\u0165 od prostredia vykon\u00e1vania. Na tento \u00fa\u010del m\u00f4\u017eete uklada\u0165 zdie\u013ean\u00e9 \u00fadaje v datab\u00e1ze alebo, napr\u00edklad, priamo v S3. A e\u0161te lep\u0161ie je dodr\u017eiava\u0165 pravidl\u00e1 https:\/\/12factor.net<\/a><\/noindex>. Po\u010das n\u00e1hleho rastu nie je \u010das na optimaliz\u00e1ciu k\u00f3du a s za\u0165a\u017een\u00edm bude potrebn\u00e9 vysporiada\u0165 sa priamym zv\u00fd\u0161en\u00edm v\u00fdpo\u010dtov\u00fdch zdrojov a horizont\u00e1lnym \u0161k\u00e1lovan\u00edm.<\/li>\n
  5. Kv\u00f3ty a v\u00fdkon extern\u00fdch slu\u017eieb. <\/strong>Pri r\u00fdchlom raste m\u00f4\u017ee probl\u00e9m vznikn\u00fa\u0165 nielen vo va\u0161ej infra\u0161trukt\u00fare, ale aj v extern\u00fdch slu\u017eb\u00e1ch. Najviac mrz\u00ed, ke\u010f sa to stane nie z d\u00f4vodu zlyhania, ale kv\u00f4li dosiahnutiu kv\u00f3t alebo limitov. Tak\u017ee extern\u00e9 slu\u017eby by mali \u0161k\u00e1lova\u0165 rovnako dobre ako vy sami.\u00a0<\/li>\n
  6. Oddelujte procesy a fronty. <\/strong>To ve\u013emi pom\u00e1ha, ke\u010f na jednom zo vstupn\u00fdch bodov d\u00f4jde k zadrhnutiu. Nestretli by sme sa so zdr\u017ean\u00edm v prenose \u00fadajov, keby zaplnen\u00e9 fronty odosielania SMS nebr\u00e1nili v\u00fdmene ozn\u00e1men\u00ed medzi informa\u010dn\u00fdmi syst\u00e9mami. Rovnako by bolo jednoduch\u0161ie zv\u00fd\u0161i\u0165 po\u010det pracovn\u00edkov, ak by pracovali samostatne.<\/li>\n
  7. Finan\u010dn\u00e9 reality.<\/strong> Ke\u010f prebieha v\u00fdbu\u0161n\u00fd rast tokov \u00fadajov, nie je \u010das rozm\u00fd\u0161\u013ea\u0165 nad tarifami a predplatn\u00fdmi. Ale treba na ne pam\u00e4ta\u0165, najm\u00e4 ak ste mal\u00e1 spolo\u010dnos\u0165. Ve\u013ek\u00fd \u00fa\u010det m\u00f4\u017ee vystavi\u0165 vlastn\u00edk ak\u00e9hoko\u013evek API, ako aj v\u00e1\u0161 hostingov\u00fd poskytovate\u013e. Tak\u017ee zmluvy je potrebn\u00e9 \u010d\u00edta\u0165 starostlivo.<\/li>\n<\/ol>\n

    <\/p>\n

    Z\u00e1ver<\/h2>\n

    \nAj ke\u010f nie bez str\u00e1t, pre\u017eili sme t\u00fato etapu a dnes sa sna\u017e\u00edme dodr\u017eiava\u0165 v\u0161etky n\u00e1jden\u00e9 princ\u00edpy. Ka\u017ed\u00fd server m\u00e1 mo\u017enos\u0165 jednoduch\u00e9ho zv\u00fd\u0161enia v\u00fdkonu a\u017e 4-kr\u00e1t na zvl\u00e1danie ne\u010dakan\u00fdch situ\u00e1ci\u00ed.\u00a0<\/p>\n

    V nasleduj\u00facich pr\u00edspevkoch sa podel\u00edme o na\u0161e sk\u00fasenosti s anal\u00fdzou poklesu v\u00fdkonu v Apache Solr, ako aj o optimaliz\u00e1cii dopytov a o tom, ako spolupr\u00e1ca s da\u0148ov\u00fdm \u00faradom pom\u00e1ha spolo\u010dnosti \u0161etri\u0165 peniaze. Sledujte n\u00e1\u0161 blog, aby ste ni\u010d nezme\u0161kali, a pode\u013ete sa v koment\u00e1roch o to, \u010di ste aj vy za\u017eili podobn\u00e9 probl\u00e9my po\u010das rastu n\u00e1v\u0161tevnosti.<\/p>\n

    \"Ako<\/p>\n

    Len registrovan\u00ed pou\u017e\u00edvatelia sa m\u00f4\u017eu z\u00fa\u010dastni\u0165 prieskumu. Prihl\u00e1ste sa<\/a><\/noindex>, pros\u00edm.<\/p>\n

    Stretli ste sa s oneskoren\u00edm alebo poklesom slu\u017eieb pri n\u00e1hlom n\u00e1raste z\u00e1\u0165a\u017ee kv\u00f4li:<\/h2>\n