Ամռանը և՛ գնման ակտիվությունը, և՛ վեբ նախագծերի ենթակառուցվածքում փոփոխությունների ինտենսիվությունը ավանդաբար նվազում է, ասում է մեզ կապիտան Օբիուսը։ Պարզապես այն պատճառով, որ անգամ ՏՏ ոլորտի մասնագետները երբեմն արձակուրդ են գնում։ Եվ CTO նույնպես: Ավելի դժվար է նրանց համար, ովքեր շարունակում են պաշտոնավարել, բայց հիմա հարցը դա չէ. թերևս դրա համար ամառը լավագույն շրջանն է կամաց-կամաց մտածելու առկա ամրագրումների սխեմայի մասին և այն բարելավելու ծրագիր կազմելու համար: Եվ Եգոր Անդրեևի փորձը , ինչի մասին նա խոսել է համաժողովում .
Կան մի քանի որոգայթներ, որոնց մեջ կարող եք ընկնել պահեստային կայքեր կառուցելիս: Եվ նրանց մեջ բռնվելը բացարձակապես անհնար է: Եվ այս ամենում մեզ կործանում է, ինչպես շատ այլ բաներում, պերֆեկցիոնիզմն ու... ծուլությունն է։ Մենք փորձում ենք ամեն ինչ, ամեն ինչ, ամեն ինչ կատարելապես, բայց մեզ պետք չէ դա կատարելապես: Պետք է միայն որոշակի բաներ անել, բայց դրանք ճիշտ անել, ավարտին հասցնել, որպեսզի ճիշտ աշխատեն։
Failover-ը զվարճալի, զվարճալի բան չէ. սա մի բան է, որը պետք է անի հենց մեկ բան՝ կրճատել պարապուրդը, որպեսզի ծառայությունը, ընկերությունը, ավելի քիչ գումար կորցնի: Իսկ ամրագրման բոլոր մեթոդներում առաջարկում եմ մտածել հետևյալ համատեքստում՝ որտե՞ղ է փողը։
Առաջին թակարդըԵրբ մենք կառուցում ենք մեծ, հուսալի համակարգեր և ներգրավվում ենք ավելորդության մեջ, մենք նվազեցնում ենք վթարների թիվը: Սա սարսափելի թյուր կարծիք է։ Երբ մենք ներգրավվում ենք ավելորդության մեջ, ամենայն հավանականությամբ կավելացնենք վթարների թիվը: Եվ եթե մենք ամեն ինչ ճիշտ անենք, ապա միասին կկրճատենք պարապուրդի ժամանակը: Կլինեն ավելի շատ վթարներ, բայց դրանք տեղի կունենան ավելի ցածր գնով: Ի՞նչ է վերապահումը: - Սա համակարգի բարդություն է։ Ցանկացած բարդություն վատ է. մենք ունենք ավելի շատ կոճեր, ավելի շատ շարժակներ, մի խոսքով, ավելի շատ տարրեր, և, հետևաբար, խափանման ավելի մեծ հնարավորություն: Եվ նրանք իսկապես կկոտրվեն: Եվ նրանք ավելի հաճախ կկոտրվեն: Պարզ օրինակ. ենթադրենք, որ մենք ունենք PHP և MySQL կայք: Եվ դա շտապ անհրաժեշտ է վերապահել։
Շտոշ (գ) Մենք վերցնում ենք երկրորդ կայքը, կառուցում ենք նույնական համակարգ... Բարդությունը կրկնակի մեծանում է՝ մենք ունենք երկու սուբյեկտ։ Մենք նաև մշակում ենք որոշակի տրամաբանություն տվյալների մի կայքից մյուսը փոխանցելու համար, այսինքն՝ տվյալների կրկնօրինակում, ստատիկ տվյալների պատճենում և այլն: Այսպիսով, կրկնօրինակման տրամաբանությունը սովորաբար շատ բարդ է, և հետևաբար, համակարգի ընդհանուր բարդությունը կարող է լինել ոչ թե 2, այլ 3, 5, 10 անգամ ավելի մեծ:
Երկրորդ թակարդԵրբ մենք կառուցում ենք իսկապես մեծ բարդ համակարգեր, մենք երևակայում ենք այն մասին, թե ինչ ենք ուզում ստանալ վերջում: Voila. մենք ցանկանում ենք ստանալ գերհուսալի համակարգ, որն աշխատում է առանց որևէ խափանման, անջատվում է կես վայրկյանում (կամ ավելի լավ է, ակնթարթորեն), և մենք սկսում ենք իրականացնել երազանքները: Բայց այստեղ կա նաև մի նրբերանգ՝ որքան կարճ է ցանկալի միացման ժամանակը, այնքան ավելի բարդ է դառնում համակարգի տրամաբանությունը։ Ինչքան բարդացնենք այս տրամաբանությունը, այնքան հաճախ համակարգը կփչանա: Եվ դուք կարող եք հայտնվել շատ տհաճ իրավիճակում. մենք ամբողջ ուժով փորձում ենք կրճատել պարապուրդի ժամանակը, բայց իրականում մենք ամեն ինչ ավելի ենք բարդացնում, և երբ ինչ-որ բան սխալ է լինում, պարապուրդը կավարտվի ավելի երկար: Այստեղ հաճախ ես քեզ բռնում մտածելու մեջ՝ լավ... լավ կլինի վերապահում չանես։ Ավելի լավ կլիներ, եթե այն աշխատեր միայնակ և հասկանալի պարապ ժամանակներով:
Ինչպե՞ս կարող ես պայքարել դրա դեմ: Մենք պետք է դադարենք ստել ինքներս մեզ, դադարենք ինքներս մեզ շողոքորթել, որ մենք հիմա այստեղ տիեզերանավ ենք կառուցելու, բայց համարժեք հասկանանք, թե որքան երկար կարող է լինել այդ նախագիծը: Եվ այս առավելագույն ժամանակի համար մենք կընտրենք, թե իրականում ինչ մեթոդներ ենք կիրառելու մեր համակարգի հուսալիությունը բարձրացնելու համար:
Ժամանակն է «պատմություններ w-ից»... կյանքից, իհարկե:
Օրինակ թիվ մեկ
Պատկերացրեք Ն քաղաքի թիվ 1 Խողովակների Գլանման Գործարանի այցեքարտի կայք, ահռելի տառերով գրված է՝ PIPE ROLLING PLANT No 1: Հենց ներքևում գրված է «Մեր խողովակները N-ի ամենակլոր խողովակներն են» կարգախոսը։ Իսկ ստորև նշված է գործադիր տնօրենի հեռախոսահամարը և նրա անունը: Մենք հասկանում ենք, որ դուք պետք է ամրագրեք. սա շատ կարևոր բան է: Եկեք սկսենք պարզել, թե ինչից է այն բաղկացած: Html-statics, այսինքն՝ մի քանի նկար, որտեղ գլխավոր մենեջերը, փաստորեն, քննարկում է ինչ-որ հերթական գործարքը բաղնիքի սեղանի շուրջ իր գործընկերոջ հետ: Մենք սկսում ենք մտածել պարապուրդի մասին: Մտքիս է գալիս՝ պետք է այնտեղ պառկել հինգ րոպե, ոչ ավելին։ Եվ հետո հարց է առաջանում՝ մեր այս կայքից ընդհանրապես քանի՞ վաճառք է եղել։ Որքա՞ն-որքա՞ն: Ի՞նչ է նշանակում «զրո»: Իսկ դա նշանակում է, որ որովհետև գեներալն անցած տարի բոլոր չորս գործարքները կատարել է նույն սեղանի շուրջ, նույն մարդկանց հետ, ում հետ նրանք գնում են բաղնիք և նստում սեղանի շուրջ։ Եվ մենք հասկանում ենք, որ եթե նույնիսկ կայքը մի օր նստի, ոչ մի սարսափելի բան չի լինի։
Ելնելով ներածական տեղեկություններից՝ կա այս պատմությունը բարձրաձայնելու օր: Եկեք սկսենք մտածել ավելորդության սխեմայի մասին: Եվ այս օրինակի համար մենք ընտրում ենք ավելորդության ամենաիդեալական սխեման. մենք չենք օգտագործում ավելորդություն: Այս ամբողջը ցանկացած ադմին կարող է բարձրաձայնել կես ժամվա ընթացքում ծխի ընդմիջումներով։ Տեղադրեք վեբ սերվեր, ավելացրեք ֆայլեր. վերջ: Դա կաշխատի։ Պետք չէ ոչ մի բանի վրա աչք պահել, ոչ մի բանի հատուկ ուշադրություն դարձնել պետք չէ։ Այսինքն՝ թիվ մեկ օրինակից եզրակացությունը միանգամայն ակնհայտ է՝ այն ծառայությունները, որոնք ամրագրման կարիք չունեն, վերապահման կարիք չունեն։
Օրինակ թիվ երկու
Ընկերության բլոգ. հատուկ վերապատրաստված մարդիկ այնտեղ նորություններ են գրում, մենք մասնակցել ենք այսինչ ցուցահանդեսի, բայց թողարկել ենք ևս մեկ նոր ապրանք և այլն։ Ենթադրենք, սա ստանդարտ PHP է WordPress-ով, փոքր տվյալների բազա և մի քիչ ստատիկ: Իհարկե, նորից մտքիս է գալիս, որ ոչ մի դեպքում չպետք է պառկես՝ «հինգ րոպեից ոչ ավել»: Ահա և վերջ: Բայց եկեք ավելին մտածենք: Ի՞նչ է անում այս բլոգը: Մարդիկ գալիս են այնտեղ Yandex-ից, Google-ից՝ որոշ հարցումների հիման վրա, օրգանապես: Հիանալի: Արդյո՞ք վաճառքը կապ ունի դրա հետ: Epiphany. ոչ իրականում: Գովազդային տրաֆիկը գնում է դեպի հիմնական կայք, որը գտնվում է այլ մեքենայի վրա: Եկեք սկսենք մտածել ամրագրման սխեմայի մասին: Լավ իմաստով, այն պետք է բարձրացվի մի քանի ժամում, և լավ կլիներ պատրաստվել դրան: Խելամիտ կլիներ մեկ այլ տվյալների կենտրոնից մեքենա վերցնել, շրջակա միջավայրը գլորել դրա վրա, այսինքն՝ վեբ սերվեր, PHP, WordPress, MySQL և թողնել այնտեղ: Այն պահին, երբ մենք հասկանում ենք, որ ամեն ինչ կոտրված է, մենք պետք է երկու բան անենք՝ 50 մետր գլորում ենք mysql-ի աղբանոցը, այն մեկ րոպեից կթռչի այնտեղ, իսկ պահեստային պահոցից որոշակի քանակությամբ նկարներ գլորում այնտեղ։ Սա նույնպես չկա, քանի որ Աստված գիտի, թե որքան ժամանակ: Այսպիսով, կես ժամից ամբողջը բարձրանում է։ Ոչ մի կրկնօրինակում, կամ Աստված ների ինձ, ավտոմատ ձախողում: Եզրակացություն. այն, ինչ մենք կարող ենք արագ դուրս բերել կրկնօրինակից, կարիք չունի կրկնօրինակման:
Օրինակ թիվ երեք, ավելի բարդ
Առցանց խանութ. Բաց սրտով PhP-ն մի փոքր շտկված է, mysql-ը՝ ամուր հիմքով: Բավականին շատ ստատիկ (ի վերջո, առցանց խանութն ունի գեղեցիկ HD պատկերներ և այդ ամենը), Redis նիստի համար և Elasticsearch որոնման համար: Մենք սկսում ենք մտածել պարապուրդի մասին: Եվ այստեղ, իհարկե, ակնհայտ է, որ առցանց խանութը չի կարող մեկ օր առանց ցավի պառկել։ Ի վերջո, որքան երկար է այն ստում, այնքան ավելի շատ գումար ենք կորցնում: Արժե արագացնել: Ինչքան? Կարծում եմ, եթե մի ժամ պառկենք, ոչ ոք չի խելագարվի։ Այո, մենք ինչ-որ բան կկորցնենք, բայց եթե սկսենք քրտնաջան աշխատել, դա միայն ավելի կվատանա։ Մենք սահմանում ենք ժամում թույլատրելի պարապուրդի սխեման:
Ինչպե՞ս կարելի է վերապահել այս ամենը։ Մեքենա պետք է ամեն դեպքում. մեկ ժամը բավականին քիչ է։ Mysql: Այստեղ մեզ արդեն անհրաժեշտ է կրկնօրինակում, կենդանի կրկնօրինակում, քանի որ մեկ ժամից 100 ԳԲ, ամենայն հավանականությամբ, չի ավելացվի աղբանոցում: Ստատիկա, նկարներ. նորից, մեկ ժամից 500 ԳԲ կարող է ժամանակ չունենալ ավելացնելու: Հետեւաբար, ավելի լավ է անմիջապես պատճենել նկարները: Ռեդիս. այստեղ ամեն ինչ հետաքրքիր է դառնում: Redis-ում նիստերը պահվում են. մենք չենք կարող պարզապես վերցնել այն և թաղել: Որովհետև սա այնքան էլ լավ չի լինի. բոլոր օգտվողները դուրս կգան համակարգից, նրանց զամբյուղները կդատարկվեն և այլն: Մարդիկ ստիպված կլինեն նորից մուտքագրել իրենց օգտանունը և գաղտնաբառը, և շատ մարդիկ կարող են բաժանվել և չավարտել գնումը: Կրկին փոխակերպումները կնվազեն: Մյուս կողմից, Redis-ը ուղղակիորեն արդիական է, և վերջին մուտք գործած օգտվողները հավանաբար նույնպես կարիք չունեն: Եվ լավ փոխզիջում է Redis-ը վերցնելը և այն վերականգնել երեկվա պահուստից, կամ, եթե դա անում եք ամեն ժամ, ապա մեկ ժամ առաջ: Բարեբախտաբար, կրկնօրինակից վերականգնելը նշանակում է մեկ ֆայլ պատճենել: Իսկ ամենահետաքրքիր պատմությունը Elasticsearch-ն է։ Ո՞վ է երբևէ վերցրել MySQL-ի կրկնօրինակումը: Ո՞վ է երբևէ ընտրել Elasticsearch-ի կրկնօրինակումը: Իսկ հետո ո՞ւմ մոտ է նորմալ աշխատել։ Ես նկատի ունեմ այն, որ մենք տեսնում ենք որոշակի սուբյեկտ մեր համակարգում: Թվում է, թե դա օգտակար է, բայց դա բարդ է:
Բարդ է այն առումով, որ մեր գործընկեր ինժեներները դրա հետ աշխատելու փորձ չունեն։ Կամ կա բացասական փորձ: Կամ մենք հասկանում ենք, որ սա դեռ բավականին նոր տեխնոլոգիա է՝ նրբերանգներով կամ հումքով: Մտածում ենք... անիծյալ, էլաստիկը նույնպես առողջարար է, պահեստայինից վերականգնելն էլ երկար է պահանջում, ի՞նչ անեմ։ Մենք հասկանում ենք, որ էլաստիկը մեր դեպքում օգտագործվում է որոնման համար։ Ինչպե՞ս է վաճառվում մեր առցանց խանութը: Մենք գնում ենք շուկայագետների մոտ և հարցնում, թե որտեղից են մարդիկ գալիս: Նրանք պատասխանում են. «Yandex Market-ի 90%-ը գալիս է անմիջապես ապրանքի քարտին»: Եվ կամ նրանք գնում են այն, կամ չեն գնում: Հետևաբար, որոնումն անհրաժեշտ է օգտատերերի 10%-ին: Իսկ առաձգական կրկնօրինակումը պահպանելը, հատկապես տարբեր գոտիներում գտնվող տվյալների տարբեր կենտրոնների միջև, իսկապես շատ նրբերանգներ ունի: Ո՞ր ելքը: Մենք վերապահված կայքից վերցնում ենք էլաստիկ և ոչինչ չենք անում դրա հետ: Եթե հարցը ձգձգվի, մենք, հավանաբար, մի օր կբարձրաձայնենք, բայց դա հաստատ չէ։ Փաստորեն, եզրակացությունը նույնն է՝ գումարած կամ մինուս՝ մենք կրկին չենք վերապահում ծառայությունները, որոնք չեն ազդում փողի վրա։ Դիագրամն ավելի պարզ պահելու համար:
Օրինակ թիվ չորս, նույնիսկ ավելի դժվար
Ինտեգրատոր՝ ծաղիկ վաճառել, տաքսի կանչել, ապրանք վաճառել, ընդհանրապես՝ ցանկացած բան։ Լուրջ բան, որն աշխատում է 24/7 մեծ թվով օգտատերերի համար: Լրիվ հետաքրքիր ստեկով, որտեղ կան հետաքրքիր հիմքեր, լուծումներ, մեծ ծանրաբեռնվածություն, և որ ամենակարեւորն է՝ 5 րոպեից ավելի պառկելը ցավում է։ Ոչ միայն և ոչ այնքան, որ մարդիկ չեն գնի, այլ որովհետև մարդիկ կտեսնեն, որ այս բանը չի ստացվում, նրանք կնեղանան և կարող են ընդհանրապես չվերադառնալ։
ԼԱՎ. Հինգ րոպե. Ի՞նչ ենք անելու սրա հետ կապված։ Այս դեպքում մենք, ինչպես մեծահասակները, օգտագործում ենք ամբողջ գումարը իրական պահուստային կայք կառուցելու համար՝ ամեն ինչի կրկնօրինակմամբ և, հնարավոր է, նույնիսկ հնարավորինս ավտոմատացնել այս կայք անցնելը: Եվ բացի սրանից, դուք պետք է հիշեք, որ պետք է անեք մեկ կարևոր բան. իրականում գրեք անջատման կանոնները: Կանոնակարգերը, նույնիսկ եթե դուք ունեք ամեն ինչ ավտոմատացված, կարող են լինել շատ պարզ: «Գործարկել այսինչ և այսքան անիմաստ սկրիպտը», «սեղմեք այսինչ վանդակը 53-րդ երթուղում» և այլն շարքից, բայց սա պետք է լինի գործողությունների որոշակի ճշգրիտ ցուցակ:
Եվ թվում է, թե ամեն ինչ պարզ է. Կրկնօրինակումը փոխարկելը չնչին խնդիր է, կամ այն ինքնին կփոխվի: DNS-ում տիրույթի անունը վերագրելը նույն շարքից է։ Դժբախտությունն այն է, որ երբ նման նախագիծը ձախողվում է, խուճապ է սկսվում, և նույնիսկ ամենաուժեղ, մորուքավոր ադմինները կարող են ենթարկվել դրան: Առանց հստակ հրահանգների «բացեք տերմինալը, եկեք այստեղ, մեր սերվերի հասցեն դեռ այսպիսին է», դժվար է պահպանել վերակենդանացման համար հատկացված 5 րոպեանոց ժամկետը: Դե, գումարած, երբ մենք օգտագործում ենք այս կանոնակարգերը, հեշտ է արձանագրել, օրինակ, ենթակառուցվածքի որոշ փոփոխություններ և համապատասխանաբար փոխել կանոնակարգերը:
Դե, եթե ամրագրման համակարգը շատ բարդ է, և ինչ-որ պահի մենք սխալ ենք թույլ տվել, ապա մենք կարող ենք ոչնչացնել մեր պահեստային կայքը և, բացի այդ, տվյալները վերածել դդմի երկու կայքերի վրա, սա բոլորովին տխուր կլինի:
Օրինակ թիվ հինգ, ամբողջական հարդքոր
Միջազգային ծառայություն, որն ունի հարյուր միլիոնավոր օգտատերեր ամբողջ աշխարհում: Կան բոլոր ժամային գոտիները, բարձր ծանրաբեռնվածություն առավելագույն արագությամբ, դուք ընդհանրապես չեք կարող պառկել: Մի րոպե, և դա տխուր կլինի: Ինչ անել? Ամրագրեք, դարձյալ՝ ըստ ամբողջական ծրագրի։ Մենք արեցինք այն ամենը, ինչի մասին խոսեցի նախորդ օրինակում, և մի փոքր ավելին: Իդեալական աշխարհ, և մեր ենթակառուցվածքը համապատասխանում է IaaC devops-ի բոլոր հասկացություններին: Այսինքն՝ ամեն ինչ ի վիճակի է, և դուք պարզապես սեղմում եք կոճակը։
Ի՞նչն է պակասում։ Մեկ - վարժություններ. Առանց նրանց անհնար է: Կարծես մեզ մոտ ամեն ինչ կատարյալ է, մենք ընդհանրապես ամեն ինչ վերահսկողության տակ ունենք։ Մենք սեղմում ենք կոճակը, ամեն ինչ տեղի է ունենում: Նույնիսկ եթե դա այդպես է, և մենք հասկանում ենք, որ դա այդպես չի լինում, մեր համակարգը փոխազդում է որոշ այլ համակարգերի հետ: Օրինակ, սա dns է 53-րդ երթուղուց, s3 պահեստավորում, ինտեգրում որոշ api-ի հետ: Մենք չենք կարողանա ամեն ինչ կանխատեսել այս սպեկուլյատիվ փորձի մեջ։ Եվ մինչև մենք իրականում չքաշենք անջատիչը, մենք չենք իմանա՝ այն կաշխատի, թե ոչ:
Երևի այսքանն է: Մի ծույլ մի եղեք կամ չափազանցեք: Եվ թող ժամանակի աշխատանքը ձեզ հետ լինի:
Source: www.habr.com