Gjatë verës, tradicionale është të bie aktivizmi blerës dhe intensiteti i ndryshimeve në infrastrukturën e projekteve web, na thotë Kapitani Qëndrueshmërisë. Thjesht sepse edhe IT-istët ndonjëherë shkojnë në pushim. Edhe CTO-të gjithashtu. Kaq më e vështirë është për ata që mbeten në punë, por tani nuk është ky razlogu: ndoshta, pikërisht për këtë arsye, vera është periudha më e mirë për të menduar me qetësi rreth skemës aktuale të rezervimit dhe për të përgatitur një plan për përmirësimin e saj. Dhe eksperienca e Egor Andreev nga , e cila u diskutua në konferencën .
Kur ndërtojmë platforma rezervë, ka disa kurthe në të cilat mund të bjerë. Dhe në ato nuk duhen bjerë aspak. Ajo që na shkatërron në këtë dhe në shumë të tjera është përsosmëria dhe… lenia. Ne mundohemi të bëjmë gjithçka perfekt, por nuk është e nevojshme të bëjmë gjithçka perfekt! Duhet të bëjmë vetëm disa gjëra, por t’i bëjmë ato siç duhet, t'i çojmë deri në fund, që ato të funksionojnë normalisht.
Failover — kjo nuk është ndonjë gjë argëtuese 'për të pasur'; është një sistem që duhet të bëjë një gjë të saktë — të reduktojë kohën e papunësisë, për të siguruar që shërbimi, kompania, të humbasë më pak para. Dhe në të gjitha metodat e rezervimit, unë sugjeroj të mendojmë në kontekstin e mëposhtëm: ku janë paratë?
Kurthi i parë: kur ndërtojmë sisteme të mëdha dhe të besueshme dhe merremi me rezervimin — ne zvogëlojmë numrin e aksidenteve. Kjo është një keqkuptim i tmerrshëm. Kur merremi me rezervimin, numri i aksidenteve me siguri do të rritet. Dhe nëse e bëjmë gjithçka siç duhet, atëherë në përmbledhje do të zvogëlojmë kohën e papunësisë. Do të ketë më shumë aksidente, por ato do të ndodhin me më pak kosto. Sepse çfarë është rezervimi? — është komplikuar e sistemit. Çdo kompleksitet është i keq: ne kemi më shumë ngadalë, më shumë rrotulla, fjalë për fjalë, më shumë elemente — dhe, për pasojë, shansi për të prishur është më i lartë. Dhe ata me të vërtetë do të thyhen. Dhe do të thyhen më shpesh. Një shembull i thjeshtë: le të themi se kemi një website, me PHP, MySQL. Dhe është urgjent të rezervojmë atë.
Mirë, po marrim një platformë të dytë, ndërtojmë një sistem identik... Vështirësia bëhet dyfish më e madhe — tani kemi dy entitete. Përveç kësaj, mbi to e vendosim një logjikë për transferimin e të dhënave nga një platformë në tjetrën — dmth. replikimi i të dhënave, kopjimi i statikës dhe kështu me radhë. Pra, logjika e replikimit — zakonisht është shumë e komplikuar, dhe kështu, kompleksiteti i përgjithshëm i sistemit mund të jetë jo 2, por 3, 5, 10 herë më i madh.
Kapja e dytë: kur ndërtojmë sisteme të vërtetë të mëdha dhe të komplikuara, ne fantazojmë se çfarë dëshirojmë të arrijmë në fund. Vala: duam të kemi një sistem super të besueshëm, i cili punon pa asnjë ndërprerje, kalon për gjysmë sekonde (ose më mirë, menjëherë), dhe fillojmë të realizojmë ëndrrat tona. Por këtu ka një nuancë të rëndësishme: sa më i vogël të jetë koha e dëshiruar për kalim, aq më e komplikuar bëhet logjika e sistemit. Sa më e komplikuar të duhet të jetë kjo logjikë, aq më shpesh do të prodhojë dështime sistemi. Dhe mund të përfundojmë në një situatë shumë të pakëndshme: përpiqemi me të gjitha forcat t'i zvogëlojmë kohët e ndërprerjes, por në të vërtetë po e komplikojmë gjithçka, dhe kur diçka nuk shkon siç duhet, koha e ndërprerjes përfundimisht do të jetë më e madhe. Këtu shpesh bën vetes këtë pyetje: më mirë do të ishte të mos kishim bërë rezervim. Më mirë do të ishte që të punonte një e vetme me një kohë ndërprerjeje të qartë.
Si mund të luftojmë me këtë? Duhet të ndalojmë së gënjyer vetveten, të ndalojmë së komplimentuari veten, se këtu tani po ndërtojmë një raketë, por të kuptojmë drejt se sa kohë projekti mund të qëndrojë. Dhe në këtë kohë maksimale ne do të zgjedhim se me çfarë metodash do të rrisim besueshmërinë e sistemit tonë.
Është koha për «historitë nga jeta»… nga jeta, natyrisht.
Shembulli numër një
Imagjinoni një faqe vizitë për fabrikën nr. 1 të tubave në qytetin N. Ajo shkruan me letra të mëdha - FABRIKA E TUBAVE NR. 1. Pak më poshtë - slogani: «Tubat tanë janë tubat më të rrethuar në N». Dhe poshtë është numri i telefonit të drejtorit të përgjithshëm dhe emri i tij. E kuptojmë, duhet të rezervojmë - kjo është një gjë shumë e rëndësishme! Fillojmë të shqyrtojmë se nga çfarë përbëhet. Html-statikë - pra një çift imazhesh, ku drejtorin, në fakt, e shohim duke biseduar për një marrëveshje të re me partnerin e tij në një sauna. Fillojmë të mendojmë për kohën e pezullimit. Më vjen në mendje: duhet të qëndrojmë atje pesë minuta, jo më shumë. Dhe këtu është pyetje: sa shitje ka pasur në këtë faqe tonë? Sa? Çfarë do të thotë «zero»? Madje do të thotë: sepse të katër marrëveshjet e vitit të kaluar drejtorin i bëri në të njëjtin tavolinë, me të njëjtit njerëz, me të cilët shkojnë në sauna dhe qëndrojnë në tavolinë. Dhe e kuptojmë, që edhe nëse dita kalon faqa - nuk do të ndodhi asgjë e frikshme.
Duke u bazuar në informacionin e dhënë, kemi një ditë për të ngritur këtë histori. Fillojmë të mendojmë për skemën e rezervimit. Dhe zgjedhim skemën më ideale për rezervim për këtë shembull: ne nuk përdorim rezervimin. E gjithë kjo gjë ngrihet nga çdo administrator për gjysmë ore me pushime. Të vendosësh serverin web, të vendosësh skedarët - gjithçka. Do të funksionojë. Asgjë nuk duhet ndjekur, asgjë s'ka nevojë për vëmendje të veçantë. Pra, përfundimi nga shembulli i parë është mjaft i qartë: shërbimet që nuk kanë nevojë për rezervim - nuk kanë nevojë për rezervim.
Shembulli i dytë
Blogu i kompanisë: shkruhen lajme nga të trajnuarit, ja si morëm pjesë në një ekspozitë, dhe ja, lançuam një produkt të ri e kështu me radhë. Le të themi, ky është PHP standard me WordPress, një bazë e vogël të dhënash dhe pak statikë. Natyrisht, në mendje vjen përsëri ideja se nuk duhet të jemi të papunë — "jo më shumë se pesë minuta!", e gjithë kjo. Por le të mendojmë më tej. Çfarë bën ky blog? Ai tërheq vizitorë nga Yandex dhe Google për disa kërkesa, përmes organikës. Shumë mirë. Por a ka ndonjë lidhje me shitjet? Ndërgjegjësimi: jo shumë. Trafiku reklamues shkon në faqen kryesore, e cila është në një server tjetër. Fillojmë të mendojmë për skemën e rezervimit të blogut. Në të vërtetë, brenda disa orëve duhet ta ngremë atë, dhe do të ishte mirë të përgatitemi për këtë. Do të kishte kuptim të merrnim një server në një qendër tjetër të të dhënave, të vendosnim mjedisin, dmth. serverin web, PHP, WordPress, MySQL, dhe ta lëmë atë të qetë. Në momentin kur kuptojmë se gjithçka është prishur, duhet të bëjmë dy gjëra - të rikthejmë dump-in mysql prej 50 megabait, ai do të kalojë aty për një minutë, dhe të ngarkojmë disa imazhe nga backup-i. Kjo gjithashtu nuk është ndonjësoj e madhe. Kështu, brenda një gjysmë ore, gjithë kjo gjë ngrihet. Asnjë replikim, ose zot e di, automatik failover. Përfundimi: ajo që mund të rikthejmë shpejt nga backup-i — nuk ka nevojë për rezervim.
Shembulli numër tre, më i komplikuar
Dyqani online. PHP me open heart pak i modifikuar, MySQL me një bazë të konsiderueshme. Më shumë statikë (sepse në dyqanin online ka imazhe të bukura HD dhe gjithçka tjetër), Redis për seancat dhe Elasticsearch për kërkimin. Fillojmë të mendojmë për kohën e shkëputjes. Dhe këtu, natyrisht, është e qartë se dyqani online nuk mund të qëndrojë pa veprim për një ditë. Sepse sa më gjatë të qëndrojë, aq më shumë para humbasim. Duhet të veprojmë shpejt. Po sa? Mendoj se nëse qëndrojmë për një orë, askush nuk do të çmendet. Po, do të humbasim diçka, por nëse përpiqemi shumë, do të jetë vetëm më keq. Përcaktojmë skemën e shkëputjes që është e pranueshme në një orë.
Si e rezervoni të gjitha këto? Automjeti është i nevojshëm në çdo rast: një orë është mjaft pak. Mysql: këtu ne kemi nevojë për replikim, replikim të gjallë, sepse për një orë 100 GB në dump, me siguri, nuk do të shpërndahen dot. Statika, imazhe: përsëri, për një orë 500 GB mund të mos arrijë të shpërndahet. Pra, është më mirë të kopjoni menjëherë imazhet. Redis: këtu është më interesante. Sesionet janë në Redis - ne nuk mund ta heqim atë lehtë. Sepse do të ishte jo shumë mirë: të gjithë përdoruesit do të ishin të çregjistruar, karrocet e blerjeve do të ishin të pastruar dhe kështu me radhë. Njerëzit do të detyrohen të futin përsëri logimin dhe fjalëkalimin e tyre, dhe shumë mund të largohen dhe të mos përfundojnë blerjen. Përsëri, konvertimi do të bjerë. Nga ana tjetër, Redis është një në një vijë me përdoruesit e fundit të regjistruar, ndoshta nuk është vërtet nevojshëm. Një kompromis i mirë është të marrim Redis dhe ta rikuperojmë atë nga backup-i, të djeshëm, ose, nëse bëhet çdo orë, - nga backup-i i një ore më parë. Fatmirësisht, rikthimi i tij nga backup-i është kopjimi i një skedari. Dhe historia më interesante është Elasticsearch. Kush ndonjëherë ka ngritur replikimin MySQL? Kush ndonjëherë ka ngritur replikimin Elasticsearch? Dhe kujt i ka funksionuar pas kësaj normalisht? Po kështu: shohim në sistemin tonë një entitet. Duket se është i dobishëm - por është i komplikuar.
E komplikuar në kuptimin që kolegët tanë inxhinierë nuk kanë përvojë me të. Ose kanë përvojë negative. Ose ne e kuptojmë se për momentin ajo është një teknologji mjaft e re me nuanca ose pa përfundime. E mendojmë... Po, elastic është gjithashtu i madh, rikuperimi i tij nga backup-i zgjat gjithashtu shumë; çfarë duhet të bëjmë? E kuptojmë se elastic në këtë rast përdoret për kërkim. Si e shet dyqani ynë online? Shkkojmë te marketingu dhe pyesim, nga vijnë njerëzit. Ata përgjigjen: "90% vijnë direkt nga Yandex Market në kartelën e produktit." Dhe ose blejnë, ose jo. Prandaj, kërkesa është e nevojshme për 10% të përdoruesve. Dhe mbajtja e replikacionit të elastic- it, sidomos midis qendrave të të dhënave në zona të ndryshme, ka shumë nuanca. Cilat janë zgjidhjet? Ne e marrim elastic në një vend të rezervuar dhe nuk bëjmë asgjë me të. Nëse procesi zgjas, ndoshta do ta ngremë ndonjëherë, por nuk është e sigurt. Pra, përfundimi është më shumë se njëlloj: shërbimet që nuk ndikon në financa, sërish nuk i rezervojmë. Që skema të jetë më e thjeshtë.
Shembulli numër katër, akoma më i ndërlikuar.
Integruesi: shitjet e luleve, thirrjet e taksive, shitjet e produkteve, në përgjithësi, çdo gjë. Një gjë serioze, e cila punon 24/7 për një numër të madh përdoruesish. Me një stak të plotë dhe interesant, ku ka baza interesante, zgjidhje, ngarkesë të madhe, dhe gjëja më e rëndësishme, nuk duhet të qëndrojë më shumë se 5 minuta. Jo vetëm për faktin që njerëzit nuk do të blejnë, por sepse do të shohin që kjo gjë nuk funksionon, do të shqetësohen dhe mund të mos kthehen më.
Ok. Pesë minuta. Çfarë do të bëjmë me këtë? Në këtë rast ne me seriozitet, me të gjitha paratë, ndërtuam një shkallë rezervë të vërtetë, me replikim të gjithçkaje, dhe ndoshta madje do ta automatizojmë sa më shumë kalimin në këtë shkallë. Dhe përveç kësaj, nuk duhet të harrojmë të bëjmë një gjë të rëndësishme: përkatësisht, të shkruajmë rregulloren e kalimit. Rregullorja, ndonëse e automatizuar, mund të jetë shumë e thjeshtë. Nga seria "të nisësh këtë skenar ansible", "në route 53 të shkosh dhe të klikosh këtë kutinë" dhe kështu me radhë - por duhet të ketë një listë të saktë veprimesh.
Dhe duket se çdo gjë është e qartë. Të kalosh replikimin — është një detyrë triviale, ose ajo do të kalojë vetë. Të shkruash emrin e domain-it në DNS — është nga e njëjta kategori. Problemi është se kur dështon një projekt i tillë, fillon paniku, dhe madje edhe administratoret më të fortë, me përvojë, mund të preken nga të njëjtat ndjenja. Pa një udhëzim të qartë "hap terminalin, shkoni këtu, adresa e serverit tonë është ende kjo" 5 minuta, të cilat janë dhënë për reanimim, është e vështirë t'i rezistosh. Dhe plus, kur përdorim këtë rregullore, është e lehtë të regjistrosh ndonjë ndryshim në infrastrukturë, për shembull, dhe të ndryshosh rregulloren përkatësisht.
Epo, nëse sistemi i rezervimit është shumë i komplikuar dhe në një moment ne kemi bërë një gabim, atëherë mund të dështojmë edhe rezervën tonë, dhe përveç kësaj, të dhënat të shndërrohen në një gjendje të keqe në të dyja platformat — kjo do të ishte shumë trishtuese.
Shembulli numër pesë, hardcore i plotë
Shërbimi ndërkombëtar me qindra miliona përdorues në të gjithë botën. Të gjitha zonat kohore, çfarëdo që të ketë, mësynë maksimalisht, të mos qëndrojnë aspak. Një minutë — dhe do të jetë e trishtueshme. Çfarë të bëjmë? Të rezervojmë, përsëri, në program të plotë. Bëmë gjithçka që thashë në shembullin e mëparshëm, dhe pak më shumë. Një botë ideale, dhe infrastruktura jonë — është sipas të gjitha koncepteve të DevOps IaaC. Pra, gjithçka është në git, dhe vetëm shtypni butonin.
Çfarë na mungon? Një gjë — stërvitjet. Pa to nuk mund të bëjmë. Duket se gjithçka është perfekte, gjithçka është nën kontroll. Shtypim butonin, gjithçka ndodh. Edhe nëse është kështu — dhe ne e kuptojmë se nuk ndodh asnjëherë kështu — sistemi ynë bashkëpunon me disa sisteme të tjera. Për shembull, kjo është DNS nga route 53, ruajtja S3, integrimi me disa API. Ne nuk do të mund të parashikojmë gjithçka në këtë eksperiment teorik. Dhe derisa ne realisht të rikthejmë ndonjë switch — nuk do të dimë nëse do të funksionojë apo jo.
Mendoj se kjo është gjithçka. Mos u leni dhe mos e teproni. Dhe qofshi me uptime!
Burimi: habr.com
