{"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\/pl\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Jak przetrwali\u015bmy nag\u0142y wzrost obci\u0105\u017cenia x10 w pracy zdalnej i jakie wyci\u0105gn\u0119li\u015bmy wnioski","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cze\u015b\u0107, Habr! Ostatnie kilka miesi\u0119cy sp\u0119dzili\u015bmy w bardzo interesuj\u0105cej sytuacji i chcia\u0142bym podzieli\u0107 si\u0119 nasz\u0105 histori\u0105 skalowania infrastruktury. W tym czasie SberMarket zwi\u0119kszy\u0142 liczb\u0119 zam\u00f3wie\u0144 czterokrotnie i uruchomi\u0142 serwis w 17 nowych miastach. Eksplozja popytu na dostaw\u0119 produkt\u00f3w wymaga\u0142a od nas skalowania infrastruktury. O najciekawszych i najbardziej u\u017cytecznych wnioskach przeczytasz poni\u017cej.<\/p>\n

\"Jak
\n<\/a><\/noindex>
\nNazywam si\u0119 Dima Bobylev, jestem dyrektorem technicznym SberMarketu. Poniewa\u017c to pierwszy post w naszym blogu, powiem kilka s\u0142\u00f3w o sobie i o naszej firmie. Zesz\u0142ej jesieni bra\u0142em udzia\u0142 w konkursie m\u0142odych lider\u00f3w Runetu. Na potrzeby konkursu napisa\u0142em kr\u00f3tk\u0105 histori\u0119<\/a><\/noindex> o tym, jak w SberMarkecie postrzegamy wewn\u0119trzn\u0105 kultur\u0119 i podej\u015bcie do rozwoju serwisu. I cho\u0107 nie uda\u0142o mi si\u0119 wygra\u0107 w konkursie, to sformu\u0142owa\u0142em dla siebie podstawowe zasady rozwoju ekosystemu IT. <\/p>\n

Zarz\u0105dzaj\u0105c zespo\u0142em, wa\u017cne jest zrozumienie i znalezienie r\u00f3wnowagi pomi\u0119dzy potrzebami biznesowymi a wymaganiami ka\u017cdego pojedynczego programisty. Obecnie SberMarket ro\u015bnie 13 razy rok do roku, co wp\u0142ywa na produkt, wymagaj\u0105c ci\u0105g\u0142ego zwi\u0119kszania obj\u0119to\u015bci i tempa pracy nad rozwojem. Mimo to, zapewniamy programistom wystarczaj\u0105co du\u017co czasu na wst\u0119pn\u0105 analiz\u0119 i jako\u015bciowe napisanie kodu. Uformowane podej\u015bcie pomaga nie tylko w tworzeniu dzia\u0142aj\u0105cego produktu, ale tak\u017ce w jego dalszym skalowaniu i rozwoju. W rezultacie takiego wzrostu SberMarket sta\u0142 si\u0119 ju\u017c liderem w\u015br\u00f3d serwis\u00f3w dostaw produkt\u00f3w: codziennie dostarczamy oko\u0142o 18 tysi\u0119cy zam\u00f3wie\u0144 dziennie, chocia\u017c jeszcze na pocz\u0105tku lutego by\u0142o ich oko\u0142o 3500.<\/p>\n

\"Jak
\nPewnego dnia klient poprosi\u0142 kuriera SberMarketu o dostaw\u0119 produkt\u00f3w w spos\u00f3b bezkontaktowy \u2014 prosto na balkon.<\/i><\/p>\n

Przejd\u017amy do konkret\u00f3w. Ostatnie kilka miesi\u0119cy intensywnie zajmowali\u015bmy si\u0119 skalowaniem infrastruktury naszej firmy. Ta potrzeba by\u0142a spowodowana czynnikami zewn\u0119trznymi i wewn\u0119trznymi. R\u00f3wnocze\u015bnie z rozszerzeniem bazy klient\u00f3w liczba pod\u0142\u0105czonych sklep\u00f3w wzros\u0142a z 90 na pocz\u0105tku roku do ponad 200 w po\u0142owie maja. Oczywi\u015bcie przygotowali\u015bmy si\u0119, zarezerwowali\u015bmy g\u0142\u00f3wn\u0105 infrastruktur\u0119, a tak\u017ce liczyli\u015bmy na mo\u017cliwo\u015b\u0107 poziomego i pionowego skalowania wszystkich maszyn wirtualnych umieszczonych w chmurze Yandex. Jednak praktyka pokaza\u0142a: \u201eWszystko, co mo\u017ce p\u00f3j\u015b\u0107 \u017ale, p\u00f3jdzie \u017ale\u201d. Dzi\u015b chcia\u0142bym podzieli\u0107 si\u0119 najciekawszymi sytuacjami, kt\u00f3re mia\u0142y miejsce w ci\u0105gu tych tygodni. Mam nadziej\u0119, \u017ce nasze do\u015bwiadczenie oka\u017ce si\u0119 u\u017cyteczne dla Was.<\/p>\n

Slave w pe\u0142nej gotowo\u015bci bojowej<\/h3>\n

\nJu\u017c przed rozpocz\u0119ciem pandemii napotkali\u015bmy wzrost liczby zapyta\u0144 do naszych serwer\u00f3w backendowych. Trend zamawiania produkt\u00f3w z dostaw\u0105 do domu zyskiwa\u0142 na sile, a po wprowadzeniu pierwszych \u015brodk\u00f3w samoizolacji w zwi\u0105zku z COVID-19, obci\u0105\u017cenie dramatycznie ros\u0142o w ci\u0105gu ca\u0142ego dnia. Powsta\u0142a potrzeba szybkiego odci\u0105\u017cenia serwer\u00f3w g\u0142\u00f3wnych bazy danych (master) i przeniesienia cz\u0119\u015bci zapyta\u0144 dotycz\u0105cych odczytu na serwery replikacyjne (slave).<\/p>\n

Z wyprzedzeniem przygotowali\u015bmy si\u0119 do tego kroku, a do takiego manewru uruchomiono ju\u017c 2 serwery slave. Na nich g\u0142\u00f3wnie pracowa\u0142y zadania wsadowe zwi\u0105zane z generowaniem informacji do wymiany danych z partnerami. Procesy te generowa\u0142y dodatkowe obci\u0105\u017cenie i s\u0142usznie zosta\u0142y wy\u0142\u0105czone \u201ena boku\u201d par\u0119 miesi\u0119cy wcze\u015bniej.\u00a0<\/p>\n

Poniewa\u017c na Slave zachodzi\u0142a replikacja, trzymali\u015bmy si\u0119 koncepcji, \u017ce aplikacje mog\u0105 z nimi pracowa\u0107 tylko w trybie tylko do odczytu. Plan odzyskiwania po awarii zak\u0142ada\u0142, \u017ce w przypadku katastrofy b\u0119dziemy mogli po prostu zamontowa\u0107 Slave w miejscu Master i przekierowa\u0107 wszystkie zapytania do zapisu i odczytu na Slave. Jednak chcieli\u015bmy r\u00f3wnie\u017c wykorzysta\u0107 replikacje do potrzeb dzia\u0142u analityki, dlatego serwery nie zosta\u0142y ca\u0142kowicie przekszta\u0142cone w tryb tylko do odczytu, a na ka\u017cdym ho\u015bcie znajdowa\u0142 si\u0119 sw\u00f3j zestaw u\u017cytkownik\u00f3w, z kt\u00f3rych niekt\u00f3rzy mieli uprawnienia do zapisu dla zachowania po\u015brednich wynik\u00f3w oblicze\u0144.<\/p>\n

Do pewnego poziomu obci\u0105\u017cenia wystarcza\u0142 nam master zar\u00f3wno do zapisu, jak i odczytu przy przetwarzaniu zapyta\u0144 http. W po\u0142owie marca, kiedy Sbermarket zdecydowa\u0142 si\u0119 ca\u0142kowicie przej\u015b\u0107 na prac\u0119 zdaln\u0105, zacz\u0119li\u015bmy do\u015bwiadcza\u0107 znacz\u0105cego wzrostu RPS. Coraz wi\u0119cej naszych klient\u00f3w przechodzi\u0142o na samoizolacj\u0119 lub prac\u0119 z domu, co wp\u0142yn\u0119\u0142o na wska\u017aniki obci\u0105\u017cenia.<\/p>\n

Wydajno\u015bci \u201emastera\u201d przesta\u0142o wystarcza\u0107, dlatego zacz\u0119li\u015bmy przenosi\u0107 cz\u0119\u015b\u0107 najci\u0119\u017cszych zapyta\u0144 do odczytu na replik\u0119. Aby przejrzysto kierowa\u0107 zapytania do zapisu do mastera, a odczytu \u2014 do slave\u2019a, u\u017cyli\u015bmy rubinowego gema \u201eOctopus<\/a><\/noindex>\u201d. Stworzyli\u015bmy specjalnego u\u017cytkownika z postfiksem _readonly bez praw do zapisu. Jednak z powodu b\u0142\u0119du w konfiguracji jednego z host\u00f3w cz\u0119\u015b\u0107 zapyta\u0144 do zapisu trafi\u0142a na serwer slave w imieniu u\u017cytkownika, kt\u00f3ry mia\u0142 odpowiednie uprawnienia.<\/p>\n

Problem nie ujawni\u0142 si\u0119 od razu, poniewa\u017c zwi\u0119kszone obci\u0105\u017cenie spowodowa\u0142o, \u017ce op\u00f3\u017anienie replik zwi\u0119kszy\u0142o si\u0119. Niekonsystencja danych ujawni\u0142a si\u0119 rano, kiedy po nocnych importach replikacje nie \u201edogoni\u0142y\u201d mastera. Zrzucili\u015bmy to na wysokie obci\u0105\u017cenie samego serwisu i import zwi\u0105zany z uruchomieniem nowych sklep\u00f3w. Jednak przekazywanie danych z kilkugodzinnym op\u00f3\u017anieniem by\u0142o niedopuszczalne, wi\u0119c prze\u0142\u0105czyli\u015bmy procesy na drugiego analitycznego slave\u2019a, poniewa\u017c mia\u0142 on bwi\u0119ksz\u0105<\/strong>ardziej zasobne i nie by\u0142 obci\u0105\u017cony zapytaniami do odczytu (co t\u0142umaczyli\u015bmy sobie jako pow\u00f3d braku op\u00f3\u017anienia replikacji).<\/p>\n

Gdy uporali\u015bmy si\u0119 z przyczynami \u201erozpadania si\u0119\u201d g\u0142\u00f3wnego slave\u2019a, analityczny ju\u017c przesta\u0142 dzia\u0142a\u0107 z tego samego powodu. Mimo istnienia dw\u00f3ch dodatkowych serwer\u00f3w, na kt\u00f3re planowali\u015bmy przenie\u015b\u0107 obci\u0105\u017cenie w przypadku awarii mastera, z powodu niefortunnego b\u0142\u0119du okaza\u0142o si\u0119, \u017ce w krytycznym momencie nie ma \u017cadnego.<\/p>\n

Jednak poniewa\u017c robili\u015bmy nie tylko dump bazy danych (odtworzenie trwa\u0142o wtedy oko\u0142o 5 godzin), ale tak\u017ce snapshot mastera, uda\u0142o si\u0119 uruchomi\u0107 replik\u0119 w ci\u0105gu 2 godzin. Niestety po tym czeka\u0142o nas nak\u0142adanie logu replikacji przez d\u0142ugi czas (poniewa\u017c proces odbywa si\u0119 w trybie jednoprocesowym, ale to ju\u017c ca\u0142kiem inna historia).<\/p>\n

Wynik:<\/strong> Po takim incydencie sta\u0142o si\u0119 jasne, \u017ce nale\u017cy zrezygnowa\u0107 z praktyki ograniczania dost\u0119pu do nagrywania dla u\u017cytkownik\u00f3w i og\u0142osi\u0107 ca\u0142y serwer jako readonly. Przy takim podej\u015bciu mo\u017cna by\u0107 pewnym, \u017ce repliki b\u0119d\u0105 dost\u0119pne w krytycznym momencie.<\/p><\/blockquote>\n

<\/p>\n

Optymalizacja nawet jednego ci\u0119\u017ckiego zapytania mo\u017ce \"przywr\u00f3ci\u0107 do \u017cycia\" baz\u0119 danych.<\/h3>\n

\nChocia\u017c stale aktualizujemy katalog na stronie, zapytania, kt\u00f3re kierowali\u015bmy na serwery Slave, mia\u0142y ma\u0142e op\u00f3\u017anienie w stosunku do Mastera. Czas, w kt\u00f3rym odkryli\u015bmy i usun\u0119li\u015bmy problem z \"niespodziewanie odstaj\u0105cymi\" slave'ami, przekroczy\u0142 \"psychologiczny pr\u00f3g\" (w tym czasie mog\u0142a nast\u0105pi\u0107 aktualizacja cen, a klienci widzieliby nieaktualne dane), i musieli\u015bmy prze\u0142\u0105czy\u0107 wszystkie zapytania na g\u0142\u00f3wny serwer bazy danych. W rezultacie strona dzia\u0142a\u0142a wolno\u2026 ale przynajmniej dzia\u0142a\u0142a. I podczas gdy Slave si\u0119 odbudowywa\u0142, nie pozosta\u0142o nam nic innego, jak tylko optymalizacja.\u00a0<\/p>\n

Podczas gdy serwery Slave si\u0119 odbudowywa\u0142y, minuty powoli mija\u0142y, Master pozostawa\u0142 przeci\u0105\u017cony, a my po\u015bwi\u0119cili\u015bmy wszystkie si\u0142y na optymalizacj\u0119 aktywnych zada\u0144 wed\u0142ug \"Zasady Pareto\": wybrali\u015bmy TOP zapyta\u0144, kt\u00f3re generowa\u0142y najwi\u0119ksze obci\u0105\u017cenie i zacz\u0119li\u015bmy tuning. By\u0142o to robione na bie\u017c\u0105co.<\/p>\n

Ciekawy efekt polega\u0142 na tym, \u017ce MySQL przeci\u0105\u017cony do granic mo\u017cliwo\u015bci reagowa\u0142 nawet na niewielkie poprawy proces\u00f3w. Optymalizacja kilku zapyta\u0144, kt\u00f3re generowa\u0142y tylko 5% \u0142\u0105cznego obci\u0105\u017cenia, ju\u017c pokaza\u0142a wyra\u017ane odci\u0105\u017cenie CPU. W rezultacie uda\u0142o nam si\u0119 zapewni\u0107 akceptowalny zapas zasob\u00f3w dla pracy Mastera z baz\u0105 danych i uzyska\u0107 niezb\u0119dny czas na odbudow\u0119 replik.\u00a0<\/p>\n

Wynik:<\/strong> Nawet niewielka optymalizacja pozwala \"przetrwa\u0107\" przy przeci\u0105\u017ceniu przez kilka godzin. Tyle potrzebowali\u015bmy na czas odbudowy serwer\u00f3w z replikami. A tak przy okazji, techniczne aspekty optymalizacji zapyta\u0144 om\u00f3wimy w jednym z nast\u0119pnych post\u00f3w. Tak wi\u0119c zasubskrybuj nasz blog, je\u015bli to mo\u017ce okaza\u0107 si\u0119 przydatne.<\/p><\/blockquote>\n

<\/p>\n

Zorganizuj monitorowanie funkcjonalno\u015bci us\u0142ug partner\u00f3w.<\/h3>\n

\nZajmujemy si\u0119 przetwarzaniem zam\u00f3wie\u0144 od klient\u00f3w, dlatego nasze us\u0142ugi nieustannie wsp\u00f3\u0142pracuj\u0105 z zewn\u0119trznymi interfejsami API \u2014 to bramy do wysy\u0142ania SMS-\u00f3w, platformy p\u0142atnicze, systemy routingu, geokodery, s\u0142u\u017cba skarbowa i wiele innych system\u00f3w. Kiedy obci\u0105\u017cenie zacz\u0119\u0142o szybko rosn\u0105\u0107, zacz\u0119li\u015bmy napotyka\u0107 ograniczenia API naszych us\u0142ug partnerskich, o kt\u00f3rych wcze\u015bniej nawet nie my\u015bleli\u015bmy.<\/p>\n

Niespodziewane przekroczenie limit\u00f3w us\u0142ug partnerskich mo\u017ce prowadzi\u0107 do przestoju w\u0142asnych us\u0142ug. Wiele API blokuje klient\u00f3w, kt\u00f3rzy przekraczaj\u0105 limity, a w niekt\u00f3rych przypadkach nadmiar zapyta\u0144 mo\u017ce obci\u0105\u017cy\u0107 produkcj\u0119 u partnera.\u00a0<\/p>\n

Na przyk\u0142ad, w momencie wzrostu liczby dostaw, towarzysz\u0105ce us\u0142ugi nie radzi\u0142y sobie z zadaniami ich rozdzielania i wyznaczania tras. W rezultacie okazywa\u0142o si\u0119, \u017ce zam\u00f3wienia zosta\u0142y z\u0142o\u017cone, a us\u0142uga generuj\u0105ca tras\u0119 nie dzia\u0142a. Nale\u017cy zaznaczy\u0107, \u017ce nasi logistycy zrobili praktycznie to, co niemo\u017cliwe w tych warunkach, a \u015bcis\u0142a wsp\u00f3\u0142praca zespo\u0142u pomog\u0142a zrekompensowa\u0107 tymczasowe awarie us\u0142ug. Jednak tak du\u017c\u0105 liczb\u0119 zg\u0142osze\u0144 niemo\u017cliwe jest nieustanne przetwarzanie r\u0119czne, a po pewnym czasie zmierzyli\u015bmy si\u0119 z niedopuszczalnym op\u00f3\u017anieniem mi\u0119dzy zam\u00f3wieniami a ich realizacj\u0105.\u00a0<\/p>\n

Podj\u0119to szereg dzia\u0142a\u0144 organizacyjnych, a zgrana praca zespo\u0142u pomog\u0142a zaoszcz\u0119dzi\u0107 czas, podczas gdy negocjowali\u015bmy nowe warunki i czekali\u015bmy na modernizacj\u0119 us\u0142ug ze strony niekt\u00f3rych partner\u00f3w. Istniej\u0105 r\u00f3wnie\u017c inne API, kt\u00f3re ciesz\u0105 si\u0119 wysok\u0105 wydajno\u015bci\u0105 i niebotycznymi stawkami w przypadku du\u017cego ruchu. Na przyk\u0142ad na pocz\u0105tku korzystali\u015bmy z jednego znanego interfejsu API do geokodowania, aby ustali\u0107 adres punktu dostawy. Jednak na koniec miesi\u0105ca otrzymali\u015bmy rachunek na prawie 2 miliony rubli. Po tym postanowili\u015bmy szybko go wymieni\u0107. Nie zamierzam promowa\u0107, ale powiem, \u017ce nasze wydatki znacznie si\u0119 zmniejszy\u0142y.
\n\"Jak<\/p>\n

Wynik: <\/strong>Nale\u017cy koniecznie monitorowa\u0107 warunki pracy wszystkich us\u0142ug partnerskich i mie\u0107 je na uwadze. Nawet je\u015bli dzi\u015b wydaje si\u0119, \u017ce maj\u0105 Pa\u0144stwo \"du\u017cy zapas\", nie oznacza to, \u017ce jutro nie stan\u0105 si\u0119 przeszkod\u0105 dla rozwoju. I oczywi\u015bcie najlepiej jest wcze\u015bniej uzgodni\u0107 warunki finansowe wzrastaj\u0105cych zapyta\u0144 do us\u0142ugi.\u00a0<\/p><\/blockquote>\n

<\/p>\n

Czasami okazuje si\u0119, \u017ce \"trzeba wi\u0119cej z\u0142ota<\/a><\/noindex>\" (c) nie pomaga<\/h3>\n

\nJeste\u015bmy przyzwyczajeni do \"zator\u00f3w\" w g\u0142\u00f3wnych bazach danych lub na serwerach aplikacyjnych, ale podczas skalowania problemy mog\u0105 si\u0119 ujawnia\u0107 tam, gdzie si\u0119 ich nie spodziewano. Do pe\u0142notekstowego wyszukiwania na stronie u\u017cywamy silnika Apache Solr. W miar\u0119 wzrostu obci\u0105\u017cenia zauwa\u017cyli\u015bmy spadek czasu odpowiedzi, a obci\u0105\u017cenie procesora serwera osi\u0105ga\u0142o ju\u017c 100%. Co mo\u017ce by\u0107 prostsze \u2014 przydzielimy kontenerowi z Solr wi\u0119cej zasob\u00f3w.<\/p>\n

Zamiast oczekiwanego wzrostu wydajno\u015bci, serwer po prostu \"umar\u0142\". Od razu obci\u0105\u017ca\u0142 si\u0119 w 100% i odpowiada\u0142 jeszcze wolniej. Pocz\u0105tkowo mieli\u015bmy 2 rdzenie i 2 GB RAM. Zdecydowali\u015bmy si\u0119 zrobi\u0107 to, co zazwyczaj pomaga \u2014 dali\u015bmy serwerowi 8 rdzeni i 32 GB. Wszystko sta\u0142o si\u0119 znacznie gorsze (jak dok\u0142adnie i dlaczego \u2014 opowiemy w osobnym po\u015bcie).\u00a0<\/p>\n

W ci\u0105gu kilku dni zrozumieli\u015bmy szczeg\u00f3\u0142y tej kwestii i osi\u0105gn\u0119li\u015bmy optymaln\u0105 wydajno\u015b\u0107 przy 8 rdzeniach i 32 GB. Ta konfiguracja pozwala nadal zwi\u0119ksza\u0107 obci\u0105\u017cenie, co jest bardzo wa\u017cne, poniewa\u017c wzrost nast\u0119puje nie tylko w\u015br\u00f3d klient\u00f3w, ale tak\u017ce liczby pod\u0142\u0105czonych sklep\u00f3w \u2014 w ci\u0105gu 2 miesi\u0119cy ich liczba podwoi\u0142a si\u0119.\u00a0<\/p>\n

Wynik: <\/strong>Standardowe metody typu \"doda\u0107 wi\u0119cej sprz\u0119tu\" nie dzia\u0142aj\u0105 zawsze. Dlatego przy skalowaniu jakiejkolwiek us\u0142ugi nale\u017cy dobrze zrozumie\u0107, w jaki spos\u00f3b wykorzystuje zasoby i z wyprzedzeniem testowa\u0107 jej dzia\u0142anie w nowych warunkach.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 klucz do prostego poziomego skalowania.<\/h3>\n

\nOg\u00f3lnie nasz zesp\u00f3\u0142 trzyma si\u0119 znanego podej\u015bcia: us\u0142ugi nie powinny mie\u0107 wewn\u0119trznego stanu (stateless) i powinny by\u0107 niezale\u017cne od \u015brodowiska uruchomieniowego. To pozwala\u0142o nam wytrzymywa\u0107 wzrost obci\u0105\u017cenia poprzez proste poziome skalowanie. Mieli\u015bmy jednak jedn\u0105 us\u0142ug\u0119- wyj\u0105tek \u2013 obs\u0142ugiwacz d\u0142ugich zada\u0144 w tle. Zajmowa\u0142 si\u0119 wysy\u0142k\u0105 emaili i sms\u00f3w, przetwarzaniem zdarze\u0144, generowaniem feed\u00f3w, importowaniem cen i stan\u00f3w magazynowych oraz przetwarzaniem obraz\u00f3w. Tak si\u0119 z\u0142o\u017cy\u0142o, \u017ce by\u0142 on uzale\u017cniony od lokalnego magazynu plik\u00f3w i istnia\u0142 w jedynym egzemplarzu.\u00a0<\/p>\n

Kiedy liczba zada\u0144 w kolejce przetwornika wzros\u0142a (co naturalnie mia\u0142o miejsce wraz ze wzrostem liczby zam\u00f3wie\u0144), wydajno\u015b\u0107 hosta, na kt\u00f3rym znajdowa\u0142y si\u0119 przetwornik i pami\u0119\u0107 plikowa, sta\u0142a si\u0119 czynnikiem ograniczaj\u0105cym. W efekcie zasta\u0142o zatrzymane aktualizowanie asortymentu i cen, wysy\u0142anie powiadomie\u0144 do u\u017cytkownik\u00f3w i wiele innych krytycznych funkcji, kt\u00f3re utkn\u0119\u0142y w kolejce. Zesp\u00f3\u0142 Ops szybko przeni\u00f3s\u0142 pami\u0119\u0107 plikow\u0105 do przechowywania w sieci podobnego do S3, co pozwoli\u0142o nam uruchomi\u0107 kilka mocnych maszyn, aby skalowa\u0107 przetwornik zada\u0144 w tle.<\/p>\n

Wynik: <\/strong>Zasada Stateless musi by\u0107 przestrzegana dla wszystkich komponent\u00f3w bez wyj\u0105tku, nawet je\u015bli wydaje si\u0119, \u017ce \u201etutaj na pewno si\u0119 nie utkwimy\u201d. Lepiej po\u015bwi\u0119ci\u0107 troch\u0119 czasu na odpowiedni\u0105 organizacj\u0119 pracy wszystkich system\u00f3w, ni\u017c p\u00f3\u017aniej w po\u015bpiechu przepisywa\u0107 kod i naprawia\u0107 serwis poddany przeci\u0105\u017ceniu.<\/p><\/blockquote>\n

<\/p>\n

7 zasad intensywnego wzrostu<\/h2>\n

\nMimo dost\u0119pno\u015bci dodatkowych zasob\u00f3w, podczas wzrostu natrafili\u015bmy na kilka przeszk\u00f3d. W tym czasie liczba zam\u00f3wie\u0144 wzros\u0142a ponad 4-krotnie. Obecnie dostarczamy ju\u017c ponad 17 000 zam\u00f3wie\u0144 dziennie w 62 miastach i planujemy jeszcze bardziej rozszerzy\u0107 geografi\u0119 \u2014 w pierwszej po\u0142owie 2020 roku planowane jest uruchomienie serwisu w ca\u0142ej Rosji. Aby poradzi\u0107 sobie z rosn\u0105cym obci\u0105\u017ceniem, uwzgl\u0119dniaj\u0105c ju\u017c zebrane do\u015bwiadczenia, sformu\u0142owali\u015bmy 7 podstawowych zasad pracy w warunkach sta\u0142ego wzrostu:<\/p>\n

    \n
  1. Zarz\u0105dzanie incydentami<\/strong>. Stworzyli\u015bmy plansz\u0119 w Jira, gdzie ka\u017cdy incydent jest odzwierciedlany w postaci biletu. To pomo\u017ce rzeczywi\u015bcie priorytetowa\u0107 i realizowa\u0107 zadania zwi\u0105zane z incydentem. W ko\u0144cu w istocie nie ma nic z\u0142ego w pope\u0142nianiu b\u0142\u0119d\u00f3w \u2014 \u017ale jest pope\u0142nia\u0107 je dwa razy w tej samej sprawie. Na wypadek, gdy incydenty powtarzaj\u0105 si\u0119 szybciej, ni\u017c mo\u017cna naprawi\u0107 przyczyn\u0119, powinna by\u0107 gotowa instrukcja dzia\u0142ania, poniewa\u017c w czasach du\u017cego obci\u0105\u017cenia wa\u017cne jest szybkie reagowanie.<\/li>\n
  2. Monitoring <\/strong>jest wymagany dla wszystkich element\u00f3w infrastruktury bez wyj\u0105tku. To dzi\u0119ki niemu mogli\u015bmy prognozowa\u0107 wzrost obci\u0105\u017cenia i prawid\u0142owo wybiera\u0107 \u201ew\u0105skie gard\u0142a\u201d do priorytetyzacji eliminacji. Prawdopodobnie przy du\u017cym obci\u0105\u017ceniu zawiedzie lub zacznie spowalnia\u0107 wszystko, o czym nawet nie my\u015bla\u0142e\u015b. Dlatego nowe alerty najlepiej tworzy\u0107 tu\u017c po wyst\u0105pieniu pierwszych incydent\u00f3w, aby monitorowa\u0107 i przewidywa\u0107 je.<\/li>\n
  3. Prawid\u0142owe alerty<\/strong> s\u0105 po prostu niezb\u0119dne przy nag\u0142ym wzro\u015bcie obci\u0105\u017cenia. Po pierwsze, powinny informowa\u0107 o tym, co dok\u0142adnie zawiod\u0142o. Po drugie, nie powinno by\u0107 ich zbyt wiele, poniewa\u017c nadmiar niekrytycznych alert\u00f3w prowadzi do ignorowania wszystkich powiadomie\u0144 w og\u00f3le.<\/li>\n
  4. Aplikacje powinny by\u0107 bezstanowe. <\/strong>Upewnili\u015bmy si\u0119, \u017ce dla tej zasady nie powinno by\u0107 wyj\u0105tk\u00f3w. Potrzebna jest pe\u0142na niezale\u017cno\u015b\u0107 od \u015brodowiska uruchomieniowego. Mo\u017cna przechowywa\u0107 wsp\u00f3\u0142dzielone dane w bazie danych lub, na przyk\u0142ad, bezpo\u015brednio w S3. A jeszcze lepiej trzyma\u0107 si\u0119 zasad https:\/\/12factor.net<\/a><\/noindex>. W trakcie gwa\u0142townego wzrostu czasu na optymalizacj\u0119 kodu po prostu nie ma, wi\u0119c nale\u017cy radzi\u0107 sobie z obci\u0105\u017ceniem metod\u0105 bezpo\u015bredniego zwi\u0119kszenia zasob\u00f3w obliczeniowych oraz skalowania poziomego.<\/li>\n
  5. Limity i wydajno\u015b\u0107 zewn\u0119trznych us\u0142ug. <\/strong>Przy szybkim wzro\u015bcie problem mo\u017ce wyst\u0105pi\u0107 nie tylko w twojej infrastrukturze, ale i w zewn\u0119trznej us\u0142udze. Najbardziej frustruj\u0105ce jest to, gdy dzieje si\u0119 to nie z powodu awarii, a z powodu osi\u0105gni\u0119cia limit\u00f3w lub kwot. Tak wi\u0119c zewn\u0119trzne us\u0142ugi musz\u0105 skalowa\u0107 si\u0119 tak dobrze, jak ty sam.\u00a0<\/li>\n
  6. Dziel procesy i kolejki. <\/strong>Bardzo to pomaga, gdy na jednym z bram zjawia si\u0119 zator. Nie napotkaliby\u015bmy op\u00f3\u017anie\u0144 w przesy\u0142aniu danych, gdyby wype\u0142nione kolejki wysy\u0142ania SMS-\u00f3w nie przeszkadza\u0142y w wymianie powiadomie\u0144 mi\u0119dzy systemami informatycznymi. A liczba pracownik\u00f3w by\u0142aby \u0142atwiejsza do zwi\u0119kszenia, gdyby pracowali osobno.<\/li>\n
  7. Finansowe realia.<\/strong> Gdy nast\u0119puje eksplozja wzrostu przep\u0142yw\u00f3w danych, nie ma czasu na my\u015blenie o taryfach i subskrypcjach. Ale trzeba o nich pami\u0119ta\u0107, zw\u0142aszcza je\u015bli jeste\u015b ma\u0142\u0105 firm\u0105. Du\u017ce rachunki mog\u0105 wystawi\u0107 w\u0142a\u015bciciele dowolnego API, a tak\u017ce tw\u00f3j dostawca us\u0142ug hostingowych. Dlatego umowy nale\u017cy czyta\u0107 uwa\u017cnie.<\/li>\n<\/ol>\n

    <\/p>\n

    Podsumowanie<\/h2>\n

    \nNie bez strat, ale przetrwali\u015bmy ten etap i dzi\u015b staramy si\u0119 trzyma\u0107 wszystkich znalezionych zasad, a ka\u017cda maszyna ma mo\u017cliwo\u015b\u0107 \u0142atwego zwi\u0119kszenia wydajno\u015bci x4, aby poradzi\u0107 sobie z nieoczekiwanymi sytuacjami.\u00a0<\/p>\n

    W kolejnych postach podzielimy si\u0119 naszym do\u015bwiadczeniem w badaniu spadku wydajno\u015bci w Apache Solr, a tak\u017ce opowiemy o optymalizacji zapyta\u0144 i o tym, jak wsp\u00f3\u0142praca z FNS pomaga firmie oszcz\u0119dza\u0107 pieni\u0105dze. Subskrybuj naszego bloga, aby niczego nie przegapi\u0107, i opowiedz w komentarzach, czy mieli\u015bcie podobne problemy podczas wzrostu ruchu.<\/p>\n

    \"Jak<\/p>\n

    Tylko zarejestrowani u\u017cytkownicy mog\u0105 bra\u0107 udzia\u0142 w ankiecie. Zaloguj si\u0119<\/a><\/noindex>, prosz\u0119.<\/p>\n

    Czy do\u015bwiadczyli\u015bcie spowolnienia\/spadku us\u0142ugi podczas gwa\u0142townego wzrostu obci\u0105\u017cenia z powodu:<\/h2>\n