У лето се традиционално смањује и куповна активност и интензитет промена у инфраструктури веб пројеката, каже нам Капетан Очигледни. Једноставно зато што чак и ИТ стручњаци понекад оду на одмор. И ЦТО такође. Утолико је теже онима који остају на функцији, али то сада није поента: можда је зато лето најбољи период да полако размислите о постојећој шеми резервација и направите план за њено унапређење. И искуство Јегора Андреева из , о чему је говорио на конференцији .
Постоји неколико замки у које можете упасти када правите резервне локације. И апсолутно је немогуће бити ухваћен у њима. А оно што нас у свему овоме, као и у многим другим стварима, квари је перфекционизам и... лењост. Покушавамо да урадимо све, све, све савршено, али не треба да радимо савршено! Потребно је само да урадите одређене ствари, али да их урадите исправно, да их довршите тако да раде како треба.
Фаиловер није нека забавна, забавна ствар; ово је ствар која треба да уради само једну ствар - да смањи застоје тако да услуга, компанија, губи мање новца. И у свим методама резервације предлажем размишљање у следећем контексту: где је новац?
Прва замка: када градимо велике, поуздане системе и укључимо се у редундантност, смањујемо број незгода. Ово је страшно погрешно схватање. Када се укључимо у вишак, вероватно ћемо повећати број несрећа. А ако све урадимо како треба, онда ћемо колективно смањити застоје. Биће још незгода, али ће се десити по нижим трошковима. Шта је резервација? - ово је компликација система. Свака компликација је лоша: имамо више зупчаника, више зупчаника, једном речју, више елемената - и, стога, веће шансе за квар. И заиста ће се сломити. И чешће ће се ломити. Једноставан пример: рецимо да имамо веб локацију са ПХП и МиСКЛ. И то хитно треба резервисати.
Штош (ц) Узимамо другу локацију, градимо идентичан систем... Комплексност постаје дупло већа - имамо два ентитета. Такође уводимо одређену логику за пренос података са једног сајта на други – то јест, репликацију података, копирање статичких података, итд. Дакле, логика репликације је обично веома сложена, па стога укупна сложеност система може бити не 2, већ 3, 5, 10 пута већа.
Друга замка: када градимо заиста велике сложене системе, маштамо о томе шта желимо да добијемо на крају. Воила: желимо да добијемо супер-поуздан систем који ради без икаквих застоја, пребацује се за пола секунде (или још боље, тренутно) и почињемо да остварујемо снове. Али овде постоји и једна нијанса: што је краће жељено време пребацивања, системска логика постаје сложенија. Што сложенији морамо да направимо ову логику, то ће се систем чешће кварити. И можете завршити у веома непријатној ситуацији: свим силама покушавамо да смањимо застоје, а у ствари све компликујемо, а када нешто крене наопако, застој ће на крају бити дужи. Овде се често ухватите како мислите: па... боље би било да не резервишете. Било би боље да ради сам и са разумљивим застојима.
Како се можете борити против овога? Морамо да престанемо да лажемо себе, да престанемо да ласкамо себи да ћемо сада овде да правимо свемирски брод, али да адекватно схватимо колико дуго пројекат може да лежи. И за ово максимално време, ми ћемо изабрати које методе ћемо заправо користити да повећамо поузданост нашег система.
Време је за „приче из в”... из живота, наравно.
Пример број један
Замислите веб страницу са визит картама за Ваљаоницу цеви број 1 у граду Н. На њој пише огромним словима - ВАЉАНКА ЦЕВИ бр. Одмах испод је слоган: „Наше луле су најокруглије луле у Н.“ А испод је телефонски број генералног директора и његово име. Разумемо да морате да резервишете - ово је веома важна ствар! Почнимо да схватимо од чега се састоји. Хтмл-статика - то јест, пар слика где генерални директор, у ствари, разговара о некаквом следећем договору за столом у купатилу са својим партнером. Почињемо да размишљамо о застоју. Пада ми на памет: треба лежати пет минута, не више. И онда се поставља питање колико је уопште било продаја са овог нашег сајта? Колико-колико? Шта значи "нула"? А то значи: зато што је генерал све четири трансакције прошле године направио за истим столом, са истим људима са којима иду у купатило и седе за столом. И разумемо да се ништа страшно неће догодити чак и ако сајт остане један дан.
На основу уводних информација, постоји дан за подизање ове приче. Почнимо да размишљамо о шеми редундантности. И ми бирамо најидеалнију шему редунданције за овај пример: не користимо редунданцију. Целу ову ствар сваки админ може да подигне за пола сата са паузама. Инсталирајте веб сервер, додајте датотеке - то је то. Упалиће. Не треба ништа да пазите, не треба ни на шта да обраћате посебну пажњу. Односно, закључак из примера број један је сасвим очигледан: услуге које не треба резервисати не морају бити резервисане.
Пример број два
Блог компаније: тамо пишу вести специјално обучени људи, учествовали смо на таквој и таквој изложби, али смо избацили још један нови производ и тако даље. Рецимо да је ово стандардни ПХП са ВордПресс-ом, малом базом података и мало статике. Наравно, поново ми пада на памет да ни у ком случају не треба лежати - "не више од пет минута!" То је све. Али хајде да размислимо даље. Шта ради овај блог? Људи тамо долазе из Иандек-а, из Гугла на основу неких упита, органски. Велики. Да ли продаја има везе са тим? Богојављење: не баш. Промет оглашавања иде на главни сајт, који се налази на другој машини. Почнимо да размишљамо о шеми резервације. У добром смислу, треба да се подигне за пар сати и било би лепо да се припремите за ово. Било би разумно узети машину из другог дата центра, убацити окружење на њу, односно веб сервер, ПХП, ВордПресс, МиСКЛ и оставити је тамо. У тренутку када схватимо да је све покварено, треба да урадимо две ствари - да развучемо мискл думп 50 метара, он ће долетети тамо за минут, и да извучемо одређени број слика из бекапа. Овога такође нема богзна колико дуго. Тако се за пола сата цела ствар диже. Нема репликације, или Боже опрости ми, аутоматско преклапање. Закључак: оно што можемо брзо да избацимо из резервне копије не мора да се прави резервна копија.
Пример број три, компликованији
Онлине продавница. ПхП отвореног срца је мало измењен, мискл са солидном основом. Доста статике (на крају крајева, онлајн продавница има прелепе ХД слике и све те ствари), Редис за сесију и Еластицсеарцх за претрагу. Почињемо да размишљамо о застоју. И овде је, наравно, очигледно да онлајн продавница не може безболно да лежи један дан. На крају крајева, што дуже лежи, губимо више новца. Вреди убрзати. Колико? Мислим да ако легнемо сат времена, нико неће полудети. Да, изгубићемо нешто, али ако почнемо да се трудимо, биће само још горе. Дефинишемо шему дозвољеног застоја по сату.
Како се све ово може резервисати? Ауто вам је у сваком случају потребан: сат времена је мало. Мискл: овде нам је већ потребна репликација, репликација уживо, јер за сат времена 100 ГБ највероватније неће бити додато у думп. Статика, слике: опет, за сат времена 500 ГБ можда неће имати времена да се дода. Због тога је боље одмах копирати слике. Редис: овде ствари постају занимљиве. У Редис-у се сесије чувају - не можемо га само узети и закопати. Јер ово неће бити добро: сви корисници ће бити одјављени, њихове корпе ће бити испражњене, итд. Људи ће бити приморани да поново унесу своје корисничко име и лозинку, а многи људи могу да се одвоје и не заврше куповину. Опет, конверзије ће пасти. С друге стране, Редис је директно ажуран, при чему вероватно нису потребни ни последњи пријављени корисници. А добар компромис је да узмете Редис и вратите га из резервне копије од јуче, или, ако то радите сваки сат, од пре сат времена. На срећу, враћање из резервне копије значи копирање једне датотеке. А најзанимљивија прича је Еластицсеарцх. Ко је икада преузео МиСКЛ репликацију? Ко је икада покупио Еластицсеарцх репликацију? А коме је после нормално функционисало? Оно што мислим је да видимо одређени ентитет у нашем систему. Чини се да је корисно - али је сложено.
Комплексан у смислу да наши колеге инжењери немају искуства у раду са њим. Или постоји негативно искуство. Или схватамо да је ово још увек прилично нова технологија са нијансама или сировошћу. Мислимо... Проклетство, и еластична је здрава, такође је потребно доста времена да се врати из бекапа, шта да радим? Разумемо да се еластична у нашем случају користи за претрагу. Како се продаје наша интернет продавница? Идемо код продавача и питамо одакле људи долазе. Они одговарају: „90% са Иандек Маркета долази директно на картицу производа. И или га купују или не. Дакле, претрага је потребна за 10% корисника. А одржавање еластичне репликације, посебно између различитих центара података у различитим зонама, заиста има много нијанси. Који излаз? Узимамо еластичну са резервисаног сајта и не радимо ништа са њом. Ако се ствар одужи, вероватно ћемо је једном покренути, али то није сигурно. Заправо, закључак је исти, плус или минус: ми, опет, не резервишемо услуге које не утичу на новац. Да би дијаграм био једноставнији.
Пример број четири, још тежи
Интегратор: продаја цвећа, позивање таксија, продаја робе, уопште, било шта. Озбиљна ствар која ради 24/7 за велики број корисника. Са пуноправним занимљивим стеком, где постоје занимљиве основе, решења, велико оптерећење, и што је најважније, боли лежати више од 5 минута. Не само и не толико зато што људи неће да купују, већ зато што ће људи видети да ово не функционише, узнемириће се и можда се уопште неће вратити.
ОК. Пет минута. Шта ћемо да радимо поводом овога? У овом случају, ми, као и одрасли, користимо сав новац да направимо прави резервни сајт, са репликацијом свега, а можда чак и аутоматизујемо прелазак на овај сајт колико год је то могуће. И поред овога, морате запамтити да урадите једну важну ствар: заправо, напишите прописе о пребацивању. Прописи, чак и ако имате све аутоматизовано, могу бити веома једноставни. Из серије „покрени ту и такву ансибле скрипту“, „кликни на тај и такав квадратић на рути 53“ и тако даље - али ово мора бити нека врста тачне листе акција.
И све изгледа јасно. Промена репликације је тривијалан задатак, или ће се сама променити. Преписивање имена домена у ДНС-у је из исте серије. Невоља је у томе што када такав пројекат пропадне, почиње паника, па чак и најјачи, брадати администратори могу бити подложни томе. Без јасних упутстава „отвори терминал, дођи овамо, адреса нашег сервера је и даље оваква“, тешко је испоштовати временско ограничење од 5 минута за реанимацију. Па, плус, када користимо ове прописе, лако је забележити неке промене у инфраструктури, на пример, и сходно томе променити прописе.
Па, ако је систем резервација веома сложен и у неком тренутку смо направили грешку, онда можемо да уништимо нашу резервну локацију, а поред тога претворимо податке у бундеву на оба сајта - ово ће бити потпуно тужно.
Пример број пет, потпуни хардкор
Међународна услуга са стотинама милиона корисника широм света. Постоје све временске зоне, велико оптерећење при максималној брзини, уопште не можете лежати. Минут - и биће тужно. Шта да радим? Резервишите, опет, по пуном програму. Урадили смо све о чему сам говорио у претходном примеру, и мало више. Идеалан свет, а наша инфраструктура је у складу са свим концептима ИааЦ девопс-а. То јест, све је у гит-у, а ви само притиснете дугме.
Шта недостаје? Један - вежбе. Без њих је немогуће. Чини се да је код нас све савршено, генерално све имамо под контролом. Притиснемо дугме, све се дешава. Чак и ако је то тако – а ми разумемо да се то не дешава на овај начин – наш систем је у интеракцији са неким другим системима. На пример, ово је днс са руте 53, с3 складиште, интеграција са неким АПИ-јем. У овом спекулативном експерименту нећемо моћи све да предвидимо. И док заправо не повучемо прекидач, нећемо знати да ли ће радити или не.
То је вероватно све. Не будите лењи и не претерујте. И нека радња буде са вама!
Извор: ввв.хабр.цом