Ամպերը նման են կախարդական տուփի. դուք հարցնում եք, թե ինչ է ձեզ հարկավոր, և ռեսուրսները պարզապես հայտնվում են ոչ մի տեղից: Վիրտուալ մեքենաներ, տվյալների բազաներ, ցանց՝ այս ամենը պատկանում է միայն ձեզ: Կան այլ ամպերի վարձակալներ, բայց ձեր Տիեզերքում դուք միակ տիրակալն եք: Համոզված եք, որ միշտ կստանաք պահանջվող ռեսուրսները, ոչ մեկի հետ հաշվի չեք նստում և ինքնուրույն եք որոշում, թե ինչպիսին կլինի ցանցը։ Ինչպե՞ս է գործում այս կախարդանքը, որը ստիպում է ամպին առաձգականորեն հատկացնել ռեսուրսները և ամբողջությամբ մեկուսացնել վարձակալներին միմյանցից:
AWS ամպը մեգա-գերբարդ համակարգ է, որը էվոլյուցիոն ճանապարհով զարգանում է 2006 թվականից: Այս զարգացման մի մասը տեղի ունեցավ Վասիլի Պանտյուխին - Amazon Web Services Architect. Որպես ճարտարապետ՝ նա ներքուստ է նայում ոչ միայն վերջնական արդյունքին, այլև AWS-ի հաղթահարած մարտահրավերներին: Որքան մեծ է համակարգի աշխատանքի ըմբռնումը, այնքան մեծ է վստահությունը: Ուստի Վասիլին կկիսվի AWS ամպային ծառայությունների գաղտնիքներով։ Ստորև ներկայացված են ֆիզիկական AWS սերվերների դիզայնը, տվյալների բազայի առաձգական մասշտաբայնությունը, հատուկ Amazon տվյալների բազան և վիրտուալ մեքենաների արդյունավետությունը բարձրացնելու մեթոդները՝ միաժամանակ նվազեցնելով դրանց գինը: Amazon-ի ճարտարապետական մոտեցումների իմացությունը կօգնի ձեզ ավելի արդյունավետ օգտագործել AWS ծառայությունները և կարող է նոր գաղափարներ տալ ձեր սեփական լուծումները ստեղծելու համար:
Բանախոսի մասին՝ Վասիլի Պանտյուխին () սկսել է որպես Unix-ի ադմինիստրատոր .ru ընկերություններում, 6 տարի աշխատել է Sun Microsystem-ի խոշոր սարքավորումների վրա և 11 տարի EMC-ում քարոզել է տվյալների վրա հիմնված աշխարհ: Այն, բնականաբար, վերածվեց մասնավոր ամպերի, իսկ 2017-ին տեղափոխվեց հանրային: Այժմ նա տրամադրում է տեխնիկական խորհրդատվություն՝ օգնելու ապրել և զարգանալ AWS ամպում:
Հրաժարում. ստորև բերված ամեն ինչ Վասիլի անձնական կարծիքն է և կարող է չհամընկնել Amazon Web Services-ի դիրքորոշման հետ: Զեկույցը, որի վրա հիմնված է հոդվածը, հասանելի է մեր YouTube ալիքում։
Ինչու՞ եմ ես խոսում Amazon սարքի մասին:
Իմ առաջին մեքենան ուներ մեխանիկական փոխանցման տուփ: Հիանալի էր այն զգացողության պատճառով, որ ես կարող եմ վարել մեքենան և լիովին վերահսկել այն: Ինձ դուր եկավ նաև, որ ես գոնե մոտավորապես հասկացա դրա գործողության սկզբունքը։ Բնականաբար, ես պատկերացնում էի տուփի կառուցվածքը բավականին պարզունակ՝ հեծանիվով փոխանցման տուփի նման մի բան:
Ամեն ինչ հիանալի էր, բացառությամբ մի բանի՝ խցանումների մեջ: Թվում է, թե նստած եք և ոչինչ չեք անում, բայց դուք անընդհատ փոխում եք փոխանցումները, սեղմում կալանքը, գազը, արգելակը՝ դա իսկապես հոգնեցնում է ձեզ: Խցանման խնդիրը մասամբ լուծվել է, երբ ընտանիքը ստացել է ավտոմատ մեքենա։ Վարելիս ժամանակ էի ունենում ինչ-որ բան մտածելու և աուդիոգիրք լսելու:
Մեկ այլ առեղծված հայտնվեց իմ կյանքում, քանի որ ես ամբողջովին դադարեցի հասկանալ, թե ինչպես է աշխատում իմ մեքենան։ Ժամանակակից մեքենան բարդ սարք է։ Մեքենան միաժամանակ հարմարվում է տասնյակ տարբեր պարամետրերի՝ գազի սեղմում, արգելակ, վարելու ոճ, ճանապարհի որակ: Ես այլևս չեմ հասկանում, թե ինչպես է դա աշխատում:
Երբ ես սկսեցի աշխատել Amazon ամպի վրա, դա նույնպես առեղծված էր ինձ համար: Միայն այս առեղծվածը մեծության կարգով ավելի մեծ է, քանի որ մեքենայում կա մեկ վարորդ, իսկ AWS-ում նրանք միլիոնավոր են: Բոլոր օգտվողները միաժամանակ ղեկավարում են, սեղմում գազը և արգելակում: Զարմանալի է, որ նրանք գնում են այնտեղ, որտեղ ուզում են, դա ինձ համար հրաշք է: Համակարգը ավտոմատ կերպով հարմարվում է, մասշտաբում և առաձգականորեն հարմարվում է յուրաքանչյուր օգտագործողի հետ այնպես, որ նրան թվում է, թե նա մենակ է այս Տիեզերքում:
Կախարդանքը մի փոքր մաշվեց, երբ ես ավելի ուշ եկա Ամազոնում որպես ճարտարապետ աշխատելու: Ես տեսա, թե ինչ խնդիրների ենք հանդիպում, ինչպես ենք դրանք լուծում, ինչպես ենք զարգացնում ծառայությունները։ Համակարգի աշխատանքի վերաբերյալ ավելի մեծ ըմբռնումով, ավելի մեծ վստահություն է առաջանում ծառայության նկատմամբ: Այսպիսով, ես ուզում եմ կիսվել նկարով, թե ինչ է AWS ամպի գլխարկի տակ:
Ինչի՞ մասին խոսենք
Ես ընտրեցի դիվերսիֆիկացված մոտեցում՝ ընտրեցի 4 հետաքրքիր ծառայություններ, որոնց մասին արժե խոսել։
Սերվերի օպտիմիզացում. Ֆիզիկական մարմնավորմամբ անցողիկ ամպեր. ֆիզիկական տվյալների կենտրոններ, որտեղ կան ֆիզիկական սերվերներ, որոնք բզզում, տաքանում և թարթում են լույսերով:
Առանց սերվերի գործառույթներ (Lambda) հավանաբար ամպի մեջ ամենամասշտաբային ծառայությունն է:
Տվյալների բազայի մասշտաբավորում. Ես ձեզ կասեմ այն մասին, թե ինչպես ենք մենք կառուցում մեր սեփական մասշտաբային տվյալների բազաները:
Ցանցի մասշտաբավորում. Վերջին մասը, որում ես կբացեմ մեր ցանցի սարքը։ Սա հրաշալի բան է՝ յուրաքանչյուր ամպի օգտատեր հավատում է, որ ինքը մենակ է ամպի մեջ և ընդհանրապես չի տեսնում այլ վարձակալների։
Նշում. Այս հոդվածում կքննարկվեն սերվերի օպտիմալացումը և տվյալների բազայի մասշտաբը: Մենք կքննարկենք ցանցի մասշտաբը հաջորդ հոդվածում: Որտեղ են առանց սերվերի գործառույթները: Նրանց մասին առանձին սղագրություն է հրապարակվել»« Այն խոսում է մասշտաբավորման մի քանի տարբեր մեթոդների մասին և մանրամասն քննարկում Firecracker լուծումը՝ վիրտուալ մեքենայի և բեռնարկղերի լավագույն որակների սիմբիոզ:
Սերվերներ
Ամպը անցողիկ է: Բայց այս անցողիկությունը դեռևս ունի ֆիզիկական մարմնացում՝ սերվերներ: Սկզբում նրանց ճարտարապետությունը դասական էր։ Ստանդարտ x86 չիպսեթ, ցանցային քարտեր, Linux, Xen հիպերվիզոր, որոնց վրա գործարկվել են վիրտուալ մեքենաներ:
2012 թվականին այս ճարտարապետությունը բավականին լավ է հաղթահարել իր խնդիրները։ Xen-ը հիանալի հիպերվիզոր է, բայց ունի մեկ կարևոր թերություն. Նա բավական է սարքի էմուլյացիայի համար բարձր ծախսեր. Քանի որ նոր, ավելի արագ ցանցային քարտերը կամ SSD կրիչները հասանելի են դառնում, այս ծախսերը չափազանց բարձր են դառնում: Ինչպե՞ս վարվել այս խնդրի հետ: Մենք որոշեցինք աշխատել միանգամից երկու ճակատով. օպտիմիզացնել և՛ սարքաշարը, և՛ հիպերվիզորը. Խնդիրը շատ լուրջ է.
Սարքավորումների և հիպերվիզորի օպտիմիզացում
Ամեն ինչ միանգամից անելը և լավ անելը չի աշխատի: Թե ինչ է «լավը», ի սկզբանե նույնպես պարզ չէր:
Մենք որոշեցինք էվոլյուցիոն մոտեցում ցուցաբերել՝ մենք փոխում ենք ճարտարապետության մեկ կարևոր տարրը և նետում այն արտադրության:
Մենք քայլում ենք յուրաքանչյուր փոցխի վրա, լսում բողոքներ ու առաջարկություններ։ Այնուհետև մենք փոխում ենք մեկ այլ բաղադրիչ: Այսպիսով, փոքր քայլերով մենք արմատապես փոխում ենք ամբողջ ճարտարապետությունը՝ հիմնվելով օգտատերերի արձագանքների և աջակցության վրա:
Փոխակերպումը սկսվել է 2013 թվականին ամենաբարդ բանով՝ ցանցով։ IN С3 Օրինակներ, ցանցային արագացուցիչի հատուկ քարտը ավելացվել է ստանդարտ ցանցային քարտին: Այն բառացիորեն միացված էր առջևի վահանակի վրա գտնվող կարճ հանգույցով մալուխով: Այն գեղեցիկ չէ, բայց ամպի մեջ չի երևում: Բայց սարքաշարի հետ անմիջական փոխազդեցությունը հիմնովին բարելավեց ջիթերն ու ցանցի թողունակությունը:
Հաջորդիվ մենք որոշեցինք բարելավել մուտքը տվյալների արգելափակման EBS - Elastic Block Storage: Դա ցանցի և պահեստավորման համակցություն է: Դժվարությունն այն է, որ մինչ ցանցային արագացուցչի քարտերը գոյություն ունեին շուկայում, պարզապես Storage Accelerator սարքավորում գնելու տարբերակ չկար: Այսպիսով, մենք դիմեցինք ստարտափին Annapurna Labs, ովքեր մեզ համար մշակել են հատուկ ASIC չիպեր: Նրանք թույլ տվեցին, որ հեռավոր EBS ծավալները տեղադրվեն որպես NVMe սարքեր:
Դեպքերում C4 մենք երկու խնդիր լուծեցինք. Առաջինն այն է, որ մենք ներդրեցինք ապագա խոստումնալից, բայց այն ժամանակ նոր NVMe տեխնոլոգիայի հիմքը: Երկրորդ՝ մենք զգալիորեն բեռնաթափեցինք կենտրոնական պրոցեսորը՝ EBS հարցումների մշակումը տեղափոխելով նոր քարտ։ Լավ ստացվեց, ուստի այժմ Annapurna Labs-ը Amazon-ի մի մասն է:
2017 թվականի նոյեմբերին մենք հասկացանք, որ ժամանակն է փոխել հիպերվիզորը:
Նոր հիպերվիզորը մշակվել է KVM միջուկի փոփոխված մոդուլների հիման վրա:
Այն հնարավորություն տվեց հիմնովին նվազեցնել սարքի էմուլյացիան և ուղղակիորեն աշխատել նոր ASIC-ների հետ: Օրինակներ С5 առաջին վիրտուալ մեքենաներն էին նոր հիպերվիզորով, որն աշխատում էր գլխարկի տակ: Մենք նրա անունը դրեցինք Nitro.
Դեպքերի էվոլյուցիան ժամանակացույցի վրա:
Վիրտուալ մեքենաների բոլոր նոր տեսակները, որոնք հայտնվել են 2017 թվականի նոյեմբերից, աշխատում են այս հիպերվիզորի վրա: Bare Metal օրինակները չունեն հիպերվիզոր, բայց դրանք նաև կոչվում են Nitro, քանի որ նրանք օգտագործում են մասնագիտացված Nitro քարտեր:
Հաջորդ երկու տարիների ընթացքում Nitro-ի տիպերի թիվը գերազանցեց մի քանի տասնյակը՝ A1, C5, M5, T3 և այլն:
Օրինակների տեսակները.
Ինչպես են աշխատում ժամանակակից Nitro մեքենաները
Նրանք ունեն երեք հիմնական բաղադրիչ՝ Nitro hypervisor (քննարկված վերևում), անվտանգության չիպ և Nitro քարտեր:
Անվտանգության չիպ ուղղակիորեն ինտեգրված մայր տախտակի մեջ: Այն վերահսկում է շատ կարևոր գործառույթներ, ինչպիսիք են հյուրընկալող ՕՀ-ի բեռնումը:
Նիտրո քարտեր -Դրանց չորս տեսակ կա. Դրանք բոլորը մշակվել են Annapurna Labs-ի կողմից և հիմնված են ընդհանուր ASIC-ների վրա: Նրանց որոշ որոնվածը նույնպես տարածված է:
Չորս տեսակի Nitro քարտեր.
Քարտերից մեկը նախատեսված է աշխատելու համար ցանցVPC. Սա այն է, ինչ տեսանելի է վիրտուալ մեքենաներում որպես ցանցային քարտ ՀԷՑ - Էլաստիկ ցանցային ադապտեր. Այն նաև ներառում է երթևեկությունը ֆիզիկական ցանցի միջոցով փոխանցելիս (այս մասին կխոսենք հոդվածի երկրորդ մասում), վերահսկում է Անվտանգության խմբերի firewall-ը և պատասխանատու է երթուղղման և ցանցային այլ բաների համար։
Ընտրված քարտերը աշխատում են բլոկային պահեստով EBS և սկավառակներ, որոնք ներկառուցված են սերվերում: Նրանք հայտնվում են հյուրի վիրտուալ մեքենային որպես NVMe ադապտերներ. Նրանք նաև պատասխանատու են տվյալների կոդավորման և սկավառակի մոնիտորինգի համար:
Nitro քարտերի, հիպերվիզորի և անվտանգության չիպի համակարգը ինտեգրված է SDN ցանցին կամ Ծրագրային ապահովման սահմանած ցանց. Պատասխանատու է այս ցանցի կառավարման համար (Control Plane) վերահսկիչ քարտ.
Իհարկե, մենք շարունակում ենք նոր ASIC-ների մշակումը: Օրինակ, 2018-ի վերջին նրանք թողարկեցին Inferentia չիպը, որը թույլ է տալիս ավելի արդյունավետ աշխատել մեքենայական ուսուցման առաջադրանքների հետ։
Inferentia Machine Learning Processor չիպ:
Scalable Database
Ավանդական տվյալների բազան ունի շերտավոր կառուցվածք: Մեծապես պարզեցնելու համար առանձնանում են հետևյալ մակարդակները.
- SQL — հաճախորդը և հարցումների դիսպետչերները աշխատում են դրա վրա:
- Դրույթներ գործարքներ - Այստեղ ամեն ինչ պարզ է, ACID և այդ ամենը:
- caching, որն ապահովվում է բուֆերային լողավազաններով։
- անտառահատումներ — ապահովում է աշխատանք վերափոխման տեղեկամատյանների հետ: MySQL-ում դրանք կոչվում են Bin Logs, PosgreSQL-ում՝ Write Ahead Logs (WAL):
- Պահեստավորում - ուղղակի ձայնագրություն սկավառակի վրա:
Շերտավոր տվյալների բազայի կառուցվածքը:
Տվյալների բազաները մասշտաբավորելու տարբեր եղանակներ կան՝ sharding, Shared Nothing ճարտարապետություն, ընդհանուր սկավառակներ:
Այնուամենայնիվ, այս բոլոր մեթոդները պահպանում են տվյալների բազայի նույն մոնոլիտ կառուցվածքը: Սա զգալիորեն սահմանափակում է մասշտաբը: Այս խնդիրը լուծելու համար մենք մշակեցինք մեր սեփական տվյալների բազան − Amazon Aurora. Այն համատեղելի է MySQL-ի և PostgreSQL-ի հետ:
Amazon Aurora
Հիմնական ճարտարապետական գաղափարը պահեստավորման և գրանցման մակարդակներն առանձնացնելն է հիմնական տվյալների բազայից:
Նայելով առաջ՝ ես կասեմ, որ մենք նաև անկախացրինք քեշավորման մակարդակը: Ճարտարապետությունը դադարում է լինել մոնոլիտ, և մենք ձեռք ենք բերում ազատության լրացուցիչ աստիճաններ առանձին բլոկների մասշտաբով:
Գրանցամատյանների և պահպանման մակարդակները առանձին են տվյալների բազայից:
Ավանդական DBMS-ը տվյալները գրում է պահեստավորման համակարգում՝ բլոկների տեսքով: Amazon Aurora-ում մենք ստեղծել ենք խելացի պահեստ, որը կարող է խոսել լեզվով redo-logs. Ներսում պահեստը տեղեկամատյանները վերածում է տվյալների բլոկների, վերահսկում է դրանց ամբողջականությունը և ինքնաբերաբար կրկնօրինակում:
Այս մոտեցումը թույլ է տալիս իրականացնել այնպիսի հետաքրքիր բաներ, ինչպիսիք են կլոնավորում. Այն աշխատում է սկզբունքորեն ավելի արագ և ավելի տնտեսապես, քանի որ այն չի պահանջում ստեղծել բոլոր տվյալների ամբողջական պատճենը:
Պահպանման շերտը իրականացվում է որպես բաշխված համակարգ: Այն բաղկացած է շատ մեծ թվով ֆիզիկական սերվերներից: Յուրաքանչյուր վերափոխման մատյան մշակվում և պահվում է միաժամանակ վեց հանգույց. Սա ապահովում է տվյալների պաշտպանություն և բեռի հավասարակշռում:
Ընթերցման մասշտաբը կարելի է ձեռք բերել՝ օգտագործելով համապատասխան կրկնօրինակներ: Բաշխված պահեստավորումը վերացնում է տվյալների բազայի հիմնական օրինակի համաժամացման անհրաժեշտությունը, որի միջոցով մենք գրում ենք տվյալները, և մնացած կրկնօրինակները: Թարմ տվյալները երաշխավորված են հասանելի բոլոր կրկնօրինակների համար:
Միակ խնդիրը կարդալու կրկնօրինակների վրա հին տվյալների քեշավորումն է: Բայց այս խնդիրը լուծվում է վերափոխումների բոլոր տեղեկամատյանների փոխանցում կրկնօրինակներին ներքին ցանցի միջոցով: Եթե գրանցամատյանը գտնվում է քեշում, այն նշվում է որպես սխալ և վերագրված: Եթե այն քեշում չէ, ապա այն պարզապես դեն է նետվում:
Մենք դասավորեցինք պահեստը:
Ինչպես մեծացնել DBMS մակարդակները
Այստեղ հորիզոնական մասշտաբը շատ ավելի դժվար է: Այսպիսով, եկեք գնանք ծեծված ճանապարհով դասական ուղղահայաց մասշտաբավորում.
Ենթադրենք, որ մենք ունենք ծրագիր, որը շփվում է DBMS-ի հետ գլխավոր հանգույցի միջոցով։
Ուղղահայաց մասշտաբավորման ժամանակ մենք հատկացնում ենք նոր հանգույց, որը կունենա ավելի շատ պրոցեսորներ և հիշողություն:
Հաջորդը, մենք դիմումը անցնում ենք հին հիմնական հանգույցից նորին: Խնդիրներ են առաջանում.
- Սա կպահանջի կիրառման զգալի ժամանակամիջոց:
- Նոր հիմնական հանգույցը կունենա սառը քեշ: Տվյալների բազայի արդյունավետությունը կլինի առավելագույնը միայն քեշի տաքացումից հետո:
Ինչպե՞ս բարելավել իրավիճակը: Ստեղծեք վստահված անձ հավելվածի և հիմնական հանգույցի միջև:
Ի՞նչ կտա սա մեզ: Այժմ բոլոր հավելվածները պետք չէ ձեռքով վերահղել դեպի նոր հանգույց: Անջատիչը կարող է կատարվել վստահված անձի ներքո և սկզբունքորեն ավելի արագ է:
Կարծես թե խնդիրը լուծված է։ Բայց ոչ, մենք դեռ տառապում ենք քեշը տաքացնելու անհրաժեշտությունից: Բացի այդ, նոր խնդիր է առաջացել՝ այժմ վստահված անձը պոտենցիալ ձախողման կետ է։
Վերջնական լուծում Amazon Aurora-ի հետ առանց սերվերի
Ինչպե՞ս լուծեցինք այս խնդիրները։
Թողել է վստահված անձ. Սա առանձին օրինակ չէ, այլ վստահված անձանց մի ամբողջ բաշխված նավատորմ, որի միջոցով հավելվածները միանում են տվյալների բազային: Խափանման դեպքում հանգույցներից որևէ մեկը կարող է փոխարինվել գրեթե ակնթարթորեն:
Ավելացվեց տարբեր չափերի տաք հանգույցների լողավազան. Հետեւաբար, եթե անհրաժեշտ է հատկացնել ավելի մեծ կամ փոքր չափի նոր հանգույց, այն անմիջապես հասանելի է: Կարիք չկա սպասել, որ այն բեռնվի:
Ողջ մասշտաբի գործընթացը վերահսկվում է հատուկ մոնիտորինգի համակարգով: Մոնիտորինգը մշտապես վերահսկում է ընթացիկ հիմնական հանգույցի վիճակը: Եթե, օրինակ, հայտնաբերում է, որ պրոցեսորի ծանրաբեռնվածությունը հասել է կրիտիկական արժեքի, այն ծանուցում է ջերմ դեպքերի լողավազանին նոր հանգույց հատկացնելու անհրաժեշտության մասին:
Բաշխված վստահված անձինք, ջերմ ատյաններ և մոնիտորինգ:
Հասանելի է անհրաժեշտ հզորությամբ հանգույց: Բուֆերային լողավազանները պատճենվում են դրան, և համակարգը սկսում է սպասել անվտանգ պահի անցնելու համար:
Սովորաբար անցնելու պահը բավականին արագ է գալիս։ Այնուհետև պրոքսիի և հին հիմնական հանգույցի միջև կապը կասեցվում է, բոլոր նիստերը փոխարկվում են նոր հանգույցին:
Աշխատեք տվյալների բազայի ռեզյումեների հետ:
Գրաֆիկը ցույց է տալիս, որ կասեցումն իսկապես շատ կարճ է: Կապույտ գրաֆիկը ցույց է տալիս ծանրաբեռնվածությունը, իսկ կարմիր քայլերը՝ մասշտաբային պահերը: Կապույտ գրաֆիկի կարճաժամկետ անկումները հենց այդ կարճ ուշացումն են:
Ի դեպ, Amazon Aurora-ն թույլ է տալիս ամբողջությամբ խնայել գումարը և անջատել տվյալների բազան, երբ այն չի օգտագործվում, օրինակ՝ հանգստյան օրերին։ Բեռը դադարեցնելուց հետո DB-ն աստիճանաբար նվազեցնում է իր հզորությունը և որոշ ժամանակով անջատվում է: Երբ բեռը վերադառնա, այն կրկին հարթ կբարձրանա:
Amazon սարքի մասին պատմության հաջորդ մասում մենք կխոսենք ցանցի մասշտաբի մասին: Բաժանորդագրվել և հետևեք, որպեսզի բաց չթողնեք հոդվածը:
On Վասիլի Պանտյուխինը զեկույց կտա.« Բաշխված համակարգերի նախագծման ինչպիսի օրինաչափություններ են օգտագործում Amazon-ի ծրագրավորողները, որոնք են ծառայության խափանումների պատճառները, որն է Բջջային ճարտարապետությունը, Constant Work, Shuffle Sharding - հետաքրքիր կլինի: Համաժողովին մեկ ամսից էլ քիչ ժամանակ է մնացել. . հոկտեմբերի 24-ի վերջնական թանկացում.
Source: www.habr.com