Gjatë verës, tradicionalisht, aktivizmi i blerjeve dhe intensiteti i ndryshimit të infrastrukturës së projekteve web zvogëlohen, na thotë Kapiteni i Qartë. Thjesht sepse edhe specialistët e IT-it, ndodhin, shkojnë në pushime. Dhe edhe CTO-të. Sa më e vështirë që është për ata që mbeten në detyrë, por tani nuk është kjo çështja: ndoshta pikërisht për këtë arsye vera është periudha më e mirë për të marrë kohë për të reflektuar mbi skemën ekzistuese të rezervimit dhe për të hartuar një plan për përmirësimin e saj. Në këtë, përvoja e Egor Andreev nga , e cila ai e ndau në konferencën .
Kur ndërtojmë faqe rezervë, ka disa gracka në të cilat mund të bjerë. Dhe është krejtësisht e papranueshme të biesh në to. Perfeksionizmi dhe... lenia na dëmtojnë në të gjithë këtë, ashtu si në shumë gjëra të tjera. Ne përpiqemi ta bëjmë gjithçka të përsosur, por nuk duhet ta bëjmë gjithçka të përsosur! Duhet të bëjmë vetëm disa gjëra, por t'i bëjmë ato mirë, për t'i çuar deri në fund, në mënyrë që ato të funksionojnë normalisht.
Failover nuk është një gjë argëtuese për të qenë; është diçka që duhet të bëjë një gjë të vetme - të zvogëlojë kohën e dështimit, në mënyrë që shërbimi, kompania, të humbasin më pak para. Dhe në të gjitha metodat e rezervimit, unë sugjeroj të mendojmë në kontekstin e mëposhtëm: ku janë paratë?
Gracka e parë: kur ndërtuojmë sisteme të mëdha dhe të besueshme dhe merremi me rezervimin - ne zvogëlojmë numrin e fatkeqësive. Ky është një iluzion i frikshëm. Kur merremi me rezervimin, numri i fatkeqësive, për fat të keq, rritet. Dhe nëse e bëjmë gjithçka siç duhet, atëherë ne, përmbledhtas, do të zvogëlojmë kohën e të qënit mbrapa. Do të ketë më shumë fatkeqësi, por ato do të ndodhin me më pak kosto. Sepse çfarë është rezervimi? - kjo është komplikuimi i sistemit. Çdo komplikuim është i keq: ne kemi më shumë vida, më shumë ingranazhe, thjesht më shumë elemente - dhe, për pasojë, më shumë mundësi për dështim. Dhe ato do të dështojnë. Dhe do të dështojnë më shpesh. Një shembull i thjeshtë: le të themi, kemi një faqe, me PHP, MySQL. Dhe duhet ta rezervojmë atë urgjentisht.
E pra (c) Marrim një sit tjetër, ndjejmë një sistem identik... Kompleksiteti bëhet dyfish më i lartë - ne kemi dy entitete. Dhe më pas shtojmë një logjikë të caktuar për transferimin e të dhënave nga një site në tjetrin - pra, replikimi i të dhënave, kopjimi i statikës dhe kështu me radhë. Tani, logjika e replikimit - është zakonisht shumë e ndërlikuar, kështu që kompleksiteti i përgjithshëm i sistemit mund të jetë jo dy, por 3, 5, 10 herë më i lartë.
Gracka e dytë: kur ndërtojmë sisteme vërtet të mëdha dhe të ndërlikuara, ne fantazojmë se çfarë duam të arrijmë si rezultat. Hë, ne duam të kemi një sistem super të besueshëm, i cili punon pa ndalesa, kalon për një gjysmë sekonde (apo më mirë akoma, menjëherë), dhe fillojmë të realizojmë ëndrrat tona në realitet. Por ka edhe një nuancë: sa më i vogël të jetë koha e dëshiruar e kalimit, aq më e ndërlikuar bëhet logjika e sistemit. Sa më ndërlikuar të jetë logjika, aq më shpesh do të dështojë sistemi. Ndërsa përpiqemi me çdo mënyrë të zvogëlojmë kohën e mbrapshmërisë, në të vërtetë e komplikohemi gjithnjë e më shumë, dhe kur diçka shkon keq, koha e mbrapshmërisë do të jetë më e madhe. Këtu shpesh e kap veten të mendosh: do të ishte më mirë të mos e kisha rezervuar. Do të ishte më mirë që një gjë të funksiononte me një kohë të qartë ndalese.
Si mund ta luftojmë këtë? Duhet të ndalojmë së gënjyerit veten, të ndalojmë së fërkuari, se ne këtu do të ndërtojmë një kozmoplan, por të kuptojmë se sa kohë mund të qëndrojë një projekt. Dhe mbështetur në këtë kohë maksimale, do të zgjedhim se cilat metoda do të përdorim për të rritur besueshmërinë e sistemit tonë.
Ka ardhur koha për "histori nga jeta"... nga jeta, natyrisht.
Shembulli numër një
Imagjinoni një faqe vizitë të fabrikës së tubave numër 1 në qytetin N. Ajo ka shkruar me shkronja të mëdha - FABRIKA E TUBAVE NUMËR 1. Pak më poshtë - slogan: "Tubat tanë janë tubat më të rrumbullakët në N". Dhe poshtë numri i telefonit të drejtorit të përgjithshëm dhe emri i tij. E kuptojmë, se është e domosdoshme ta rezervojmë - kjo është një gjë shumë e rëndësishme! Fillojmë të studiojmë se çfarë përbën atë. Html-statika - pra, disa imazhe, ku drejtori, në të vërtetë, në tryezë në banjë me partnerin e tij po diskuton për një marrëveshje të re. Fillojmë të mendojmë për kohën e ndalesës. Në mendje na vjen: duhet të rrijë atje pesë minuta, më shumë jo. Dhe këtu është pyetja: sa shitje ka pasur nga kjo faqe e jonë? Sa- sa? Çfarë do të thotë "zero"? Ajo do të thotë se të gjitha katër marrëveshjet e vitit të kaluar drejtori i ka bërë nga e njëjta tryezë, me të njëjtit njerëz, me të cilët ata shkojnë në banjë. Dhe kuptojmë se madje edhe nëse faqja qëndron një ditë - nuk do të jetë asgjë shqetësuese.
Duke nga informacionet, kemi një ditë për të ngritur këtë histori. Fillojmë të mendojmë për skemën e ruajtjes. Dhe zgjedhim skemën më të përshtatshme për ruajtjen për këtë rast: nuk e përdorim ruajtjen. E gjithë kjo gjë ngrihet nga çdo administrator për gjysmë ore me ndalesa. Të vendosësh një server web, të vendosësh skedarët – gjithçka. Do të funksionojë. Nuk ka nevojë të ndjekësh ndonjë gjë, asgjë nuk kërkon vëmendje të veçantë. Pra, përfundimi nga shembulli i parë është mjaft evidente: shërbimet që nuk kanë nevojë për ruajtje – nuk duhet të ruhen.
Shembulli i dytë
Blogu i kompanisë: të trajnuar me qëllim shkruajnë atje lajme, ne morëm pjesë në një ekspozitë të caktuar, dhe ja ne lançuam një produkt të ri dhe kështu me radhë. Supozoni, ky është PHP standarte me WordPress, një bazë të vogël të dhënash dhe pak statikë. Natyrisht, përsëri vjen në mendje se nuk duhet të ndalojmë për asnjë arsye – "jo më shumë se pesë minuta!", e gjitha kjo. Por le të mendojmë më tej. Çfarë bën ky blog? Aty vijnë nga Yandex, nga Google për disa kërkesa, për organikën. Shumë mirë. Po si lidhen shitjet mbi të? Zbulimi: jo shumë. Trajektoria e reklamave shkon në faqen kryesore, e cila është në një aparat tjetër. Fillojmë të mendojmë për skemën e ruajtjes së blogut. Në mënyrë të arsyeshme, do të duhej të ngrihej për pak orë, dhe do të ishte mirë të pregatitemi për këtë. Do të ishte e mençur të merrni një makinë në një qendër të të dhënave tjetër, për të instaluar mjedisin, pra, serverin web, PHP, WordPress, MySQL dhe ta lëmë atë të pushojë. Në momentin kur kuptojmë se gjithçka është prishur, duhet të bëjmë dy gjëra – të rikthejmë dump-in mysql prej 50 megabajtësh, ai do të kalojë për një minutë, dhe të rikthejmë disa pamje nga backup-i. Kjo gjithashtu nuk është shumë. Kështu, për gjysmë ore e gjithë kjo do të ngrihet. Asnjë replikim, apo dmth, ndonjë failover automatik. Përfundimi: ajo që mund të rikthejmë shpejt nga backup-i – nuk ka nevojë të ruhet.
Shembulli i tretë, më i komplikuar
Dyqani online. PHP me open heart pak i modifikuar, mysql me një bazë të rëndësishme. Ka mjaft statikë (sepse në dyqanin online ka pamje HD të bukura dhe gjithçka tjetër), Redis për sesionin dhe Elasticsearch për kërkimin. Fillojmë të mendojmë për kohën e papunësisë. Dhe këtu, sigurisht, është evidente se një ditë dyqani online nuk mund të jetë offline pa pasojat. Sepse sa më gjatë të qëndrojë offline, aq më shumë para humbasim. Duhet të përshpejtojmë. Po sa? Mendoj se nëse qëndrojmë offline për një orë, askush nuk do të ndjehet keq. Po, ne do të humbasim diçka, por do të fillojmë të studiojmë – do të bëhet edhe më keq. Kështu, përcaktojmë skemën e papunësisë, e përballueshme për një orë.
Si mund të ruhet gjithçka kjo? Një makinë është e nevojshme në çdo rast: një orë kohe – kjo është mjaft pak. MySQL: këtu është e nevojshme replikimi, replikimi aktiv, sepse për një orë 100 GB në dump, me siguri nuk do të futet. Statika, imazhet: gjithashtu, për një orë 500 GB mund të mos jetë në gjendje të futet. Pra, është më mirë të filloni menjëherë të kopjoni imazhet. Redis: këtu është më interesante. Në Redis qëndrojnë sesionet – nuk mund ta hedhim thjesht. Sepse kjo nuk do të ishte shumë mirë: të gjithë përdoruesit do të ishin të çregjistruar, karrocat do të ishin bosh dhe kështu me radhë. Njerëzit do të detyroheshin të futnin përsëri emrin dhe fjalëkalimin e tyre, dhe shumë mund të ikin dhe të mos përfundojnë blerjen. Po ashtu, konverzimi do të bjerë. Nga ana tjetër, Redis me siguri është aktual, me përdoruesit më të fundit të regjistruar, ndoshta as që është i nevojshëm. Një kompromis i mirë – të marrësh Redis dhe ta rikthesh nga backup-i, nga dje, ose, nëse e keni bërë çdo orë – nga një orë më parë. Fatmirësisht rikthimi i tij nga backup-i është thjesht kopjimi i një skedari. Dhe historia më interesante është Elasticsearch. Kush ka ngritur ndonjëherë replikimin e MySQL? Kush ka ngritur ndonjëherë replikimin e Elasticsearch? Dhe kujt i ka funksionuar pas kësaj? Po çfarë do të them: shohim në sistemin tonë një entitet të tillë. Ai duket si i dobishëm – por është kompleks.
E komplikuar në kuptimin që kolegët tanë inxhinierë nuk kanë përvojë me të. Ose kanë përvojë negative. Ose ne e kuptojmë që kjo është një teknologji e re me nuanca ose paqartësi. Po mendonim... Më vijën elastic gjithashtu është i madh, rikuperimi nga backup-i gjithashtu zgjat, çfarë të bëjmë? E kuptojmë se elastic në këtë rast përdoret për kërkimin. Por si shitet dyqani ynë online? Shkojmë te marketerët dhe pyesim, nga vijnë njerëzit. Ata përgjigjen: "90% vijnë direkt në kartelën e produktit nga Yandex-Market". Ose blejnë, ose jo. Prandaj, kërkesa për kërkimin është vetëm për 10% të përdoruesve. Dhe të mbash replikimin e elastic-it, sidomos mes qendrave të të dhënave në zona të ndryshme, vërtet ka shumë nuanca. Çfarë mund të bëjmë? Ne e marrim elastic në një platformë rezervate dhe nuk bëjmë asgjë me të. Nëse gjëja zgjat, ndoshta do ta aktivizojmë ndonjëherë, por nuk është e sigurt. Prandaj, përfundimi është i ngjashëm: shërbimet që nuk ndikon në para, ne, përsëri, nuk i rezervojmë. Që skema të mbetet më e thjeshtë.
Shembulli numër katër, akoma më kompleks
Integratori: shitje lulesh, thirrje taksish, shitje mallrash, në përgjithësi, çfarëdo. Një projekt serioz që funksionon 24/7 për një numër të madh përdoruesish. Me një stack interesante, ku ka baza interesante, zgjidhje, ngarkesë të lartë, dhe më e rëndësishmja, nuk mund të qëndrojë më shumë se 5 minuta pa funksionuar. Jo vetëm sepse njerëzit nuk do të blejnë, por sepse ata do të shohin që kjo gjë nuk funksionon, do të shprehin zhgënjim dhe mund të mos kthehen më një herë të dytë.
Mirë. Pesë minuta. Çfarë do të bëjmë me këtë? Në këtë rast ne, si të rritur, ndërtuam një platformë rezervate të vërtetë, me replikimin e gjithçkaje, dhe ndoshta madje do ta automatizojmë maksimalisht kalimin në këtë platformë. Dhe përveç kësaj, nuk duhet harruar që të bëjmë një gjë të rëndësishme: të shkruajmë rregullat e kalimit. Rregulli, edhe sikur të keni gjithçka të automatizuar, mund të jetë shumë i thjeshtë. Një seri si "aktivizo skenarin e tillë të ansible", "në route 53 shtyp ndonjë buton", dhe kështu me radhë — por duhet të jetë një listë e saktë e veprimeve.
Dhe duket se gjithçka është e qartë. Të kalosh replikimin — është një detyrë triviale, ose do të kalojë vetë. Të rishkruash emrin e domain-it në dns — po nga e njëjta kategori. Problemi është që kur një projekt i tillë dështon, fillon paniku, dhe madje administratoret më të fortë dhe më të përvojë gjithashtu mund të bien nën ndikimin e tij. Pa një udhëzim të qartë "hap terminalin, shko këtu, adresa e serverit tonë ende është kjo", është e vështirë ta mbash afatin 5-minutësh të caktuar për rikuperim. Po ashtu, kur përdorim këtë rregullore, është e lehtë të regjistrojmë ndonjë ndryshim në infrastrukturë, për shembull, dhe përkatësisht të modifikojmë rregulloren.
E po, nëse sistemi i rezervimit është shumë i komplikuar dhe në një moment bëjmë një gabim, atëherë mund të dështojmë edhe platformën tonë rezervate dhe përveç kësaj të kthejmë të dhënat në një farë gjendjeje në të dyja platformat — kjo do të ishte shumë e trishtueshme.
Shembulli numër pesë, me dhimbje të madhe
Një shërbim ndërkombëtar me qindra milion përdorues në të gjithë botën. Të gjitha zonat e kohës, siç janë, ngarkesë të lartë në maksimum, nuk mund të mbesin fare. Një minutë — dhe do të jetë e trishtueshme. Çfarë të bëjmë? Të rezervojmë, përsëri, në mënyrë të plotë. Bëmë gjithçka që thamë në shembullin e mëparshëm, dhe më shumë. Një botë ideale, dhe infrastruktura jonë — është në të gjitha aspektet një IaaC devops. Do të thotë, gjithçka është në git, dhe thjesht shtypni butonin.
Çfarë na mungon? Një gjë — stërvitjet. Pa to nuk mundemi. Duket se gjithçka është perfekte, gjithçka është nën kontroll. Shtypim butonin dhe gjithçka ndodh. Edhe nëse është kështu — dhe ne e dimë se kështu nuk ndodh gjithmonë — sistemi ynë ndërvepron me disa sisteme të tjera. Për shembull, kjo është dns nga route 53, magazinat s3, integrimi me disa api. Nuk mund ta parashikojmë gjithçka në këtë eksperiment teorik. Dhe deri sa realisht nuk e çojmë ndonjëherë levën — nuk do ta dimë nëse do të funksionojë apo jo.
Këtë ndoshta duhet ta përfundojmë. Mos e ngutni dhe mos e teproni. Dhe qoftë me ju uptime!
Burimi: habr.com
