Շատ ստարտափներ անցել են այս ամենի միջով. ամեն օր գրանցվում են նոր օգտատերերի բազմություն, և մշակողների թիմը պայքարում է ծառայությունը շարունակելու համար:

Հաճելի խնդիր է ունենալը, բայց համացանցում քիչ հստակ տեղեկատվություն կա այն մասին, թե ինչպես կարելի է զգուշորեն ընդլայնել վեբ հավելվածը ոչնչից մինչև հարյուր հազարավոր օգտատերեր: Սովորաբար կան կամ հակահրդեհային լուծումներ կամ խցանման լուծումներ (և հաճախ երկուսն էլ): Հետևաբար, մարդիկ օգտագործում են բավականին սեղմ տեխնիկա՝ իրենց սիրողական նախագիծը իսկապես լուրջ բանի վերածելու համար:

Փորձենք զտել տեղեկատվությունը և գրի առնել հիմնական բանաձևը. Մենք պատրաստվում ենք քայլ առ քայլ ընդլայնել մեր նոր լուսանկարների փոխանակման կայքը՝ 1-ից մինչև 100 օգտվող:

Եկեք գրենք, թե կոնկրետ ինչ գործողություններ պետք է ձեռնարկվեն, երբ լսարանը ավելանում է մինչև 10, 100, 1000, 10 և 000 մարդ:

1 օգտվող՝ 1 մեքենա

Գրեթե յուրաքանչյուր հավելված, լինի դա կայք կամ բջջային հավելված, ունի երեք հիմնական բաղադրիչ.

• API
• տվյալների բազա
• հաճախորդ (բջջային հավելված կամ կայք)

Տվյալների բազան պահպանում է մշտական ​​տվյալները: API-ն սպասարկում է հարցումներ այս տվյալներին և դրանց շուրջ: Հաճախորդը տվյալներ է փոխանցում օգտագործողին:

Ես եկա այն եզրակացության, որ շատ ավելի հեշտ է խոսել հավելվածի մասշտաբավորման մասին, եթե ճարտարապետական ​​տեսանկյունից հաճախորդը և API սուբյեկտները լիովին տարանջատված են:

Երբ մենք առաջին անգամ սկսում ենք հավելված ստեղծել, բոլոր երեք բաղադրիչները կարող են գործարկվել նույն սերվերի վրա: Որոշ առումներով սա նման է մեր զարգացման միջավայրին. մեկ ինժեներ գործարկում է տվյալների բազան, API-ն և հաճախորդը նույն մեքենայի վրա:

Տեսականորեն, մենք կարող ենք այն տեղադրել ամպի մեջ մեկ DigitalOcean Droplet կամ AWS EC2 օրինակով, ինչպես ցույց է տրված ստորև.

Այս ամենի հետ մեկտեղ, եթե կայքում կլինեն մեկից ավելի օգտվողներ, գրեթե միշտ իմաստ ունի նվիրել տվյալների բազայի շերտը:

10 օգտատեր. տվյալների բազան տեղափոխել առանձին մակարդակ

Տվյալների բազան բաժանելը կառավարվող ծառայությունների, ինչպիսիք են Amazon RDS-ը կամ Digital Ocean Managed Database-ը, մեզ երկար ժամանակ լավ կծառայի: Դա մի փոքր ավելի թանկ է, քան ինքնուրույն հոսթինգը մեկ մեքենայի կամ EC2 օրինակի վրա, բայց այս ծառայությունների միջոցով դուք կստանաք շատ օգտակար ընդլայնումներ, որոնք ապագայում օգտակար կլինեն. կրկնօրինակումներ և այլն:

Ահա թե ինչ տեսք ունի համակարգը հիմա.

100 օգտվող. հաճախորդին տեղափոխել առանձին մակարդակ

Բարեբախտաբար, մեր առաջին օգտատերերին շատ դուր եկավ մեր հավելվածը։ Երթևեկությունը դառնում է ավելի կայուն, ուստի ժամանակն է հաճախորդին տեղափոխել առանձին մակարդակ: Հարկ է նշել, որ տարանջատում սուբյեկտները մասշտաբային հավելված ստեղծելու հիմնական ասպեկտն է: Քանի որ համակարգի մի մասը ստանում է ավելի շատ տրաֆիկ, մենք կարող ենք բաժանել այն՝ վերահսկելու համար, թե ինչպես է ծառայության մասշտաբը հիմնված երթևեկության հատուկ ձևերի վրա:

Ահա թե ինչու ես սիրում եմ հաճախորդի մասին մտածել որպես API-ից առանձին: Սա շատ հեշտ է դարձնում մտածել մի քանի հարթակների համար՝ վեբ, բջջային վեբ, iOS, Android, աշխատասեղանի հավելվածներ, երրորդ կողմի ծառայություններ և այլն մշակելու մասին մտածելը:

Օրինակ՝ այժմ մեր օգտատերերն ամենից հաճախ խնդրում են թողարկել բջջային հավելված։ Եթե ​​բաժանեք հաճախորդին և API-ի սուբյեկտները, դա ավելի հեշտ է դառնում:

Ահա թե ինչ տեսք ունի նման համակարգը.

1000 օգտատեր. ավելացրեք բեռի հավասարակշռող

Իրերը լավ են նայում: Graminsta-ի օգտատերերը ավելի ու ավելի շատ լուսանկարներ են վերբեռնում: Աճում է նաև գրանցումների թիվը։ Մեր միայնակ API սերվերը դժվարանում է հետևել ամբողջ տրաֆիկին: Ավելի շատ երկաթ է պետք:

Load balancer-ը շատ հզոր հասկացություն է: Հիմնական գաղափարն այն է, որ մենք API-ի առջև դնում ենք բեռի հավասարակշռիչ, և այն բաշխում է երթևեկությունը առանձին սպասարկման օրինակների վրա: Ահա թե ինչպես ենք մենք մասշտաբում հորիզոնական, այսինքն՝ ավելացնում ենք նույն կոդով ավելի շատ սերվերներ՝ ավելացնելով հարցումների քանակը, որոնք մենք կարող ենք մշակել:

Մենք պատրաստվում ենք առանձին բեռի հավասարակշռիչներ տեղադրել վեբ հաճախորդի և API-ի դիմաց: Սա նշանակում է, որ դուք կարող եք գործարկել մի քանի օրինակներ, որոնք աշխատում են API կոդով և վեբ հաճախորդի կոդով: Բեռի հավասարակշռիչը հարցումները կուղղորդի ավելի քիչ բեռնված սերվերին:

Այստեղ մենք ստանում ենք ևս մեկ կարևոր առավելություն՝ ավելորդություն։ Երբ մեկ օրինակ ձախողվում է (գուցե ծանրաբեռնված կամ խափանված), մենք մնում ենք մյուսների հետ, որոնք շարունակում են պատասխանել մուտքային հարցումներին: Եթե ​​միայն մեկ օրինակ աշխատեր, ապա խափանման դեպքում ամբողջ համակարգը կխափանվեր:

Բեռի հավասարակշռիչը նաև ապահովում է ավտոմատ մասշտաբավորում: Մենք կարող ենք կարգավորել այն, որպեսզի մեծացնենք դեպքերի քանակը մինչև առավելագույն բեռնվածությունը և նվազեցնել այն, երբ բոլոր օգտվողները քնած են:

Բեռի հավասարակշռող սարքի միջոցով API-ի մակարդակը կարող է մեծացվել գրեթե անորոշ ժամանակով, պարզապես ավելացնելով նոր օրինակներ, քանի որ հարցումների թիվը մեծանում է:

Նշում. Այս պահին մեր համակարգը շատ նման է PaaS ընկերություններին, ինչպիսիք են Heroku-ն կամ Elastic Beanstalk-ը AWS-ում, առաջարկում են առանց տուփի (այդ պատճառով էլ նրանք այդքան հայտնի են): Heroku-ն տեղադրում է տվյալների բազան առանձին հոսթի վրա, կառավարում է ավտոմատ մասշտաբային բեռի հավասարակշռիչ և թույլ է տալիս հյուրընկալել վեբ հաճախորդը API-ից առանձին: Սա հիանալի պատճառ է Heroku-ն օգտագործելու վաղ փուլի նախագծերի կամ ստարտափների համար. դուք ստանում եք բոլոր հիմնական ծառայությունները առանց տուփի:

10 օգտվող՝ CDN

Երևի հենց սկզբից պետք է դա անեինք։ Հարցումների մշակումը և նոր լուսանկարների ընդունումը սկսում են չափազանց մեծ ճնշում գործադրել մեր սերվերների վրա:

Այս փուլում դուք պետք է օգտագործեք ամպային ծառայություն՝ ստատիկ բովանդակություն պահելու համար՝ պատկերներ, տեսանյութեր և շատ ավելին (AWS S3 կամ Digital Ocean Spaces): Ընդհանուր առմամբ, մեր API-ն պետք է խուսափի այնպիսի բաներից, ինչպիսիք են պատկերների սպասարկումը և պատկերները սերվեր վերբեռնելը:

Ամպային հոսթինգի մեկ այլ առավելություն CDN-ն է (AWS-ն այս հավելումն անվանում է Cloudfront, բայց ամպային պահեստավորման շատ մատակարարներ այն առաջարկում են առանց տուփի): CDN-ն ավտոմատ կերպով պահում է մեր պատկերները աշխարհի տարբեր տվյալների կենտրոններում:

Թեև մեր հիմնական տվյալների կենտրոնը կարող է տեղակայված լինել Օհայոյում, եթե ինչ-որ մեկը Ճապոնիայից պատկեր պահանջի, ամպային մատակարարը պատճենը կստեղծի և կպահի այն իր ճապոնական տվյալների կենտրոնում: Հաջորդ մարդը, ով այս նկարը կխնդրի Ճապոնիայում, այն շատ ավելի արագ կստանա: Սա կարևոր է, երբ մենք աշխատում ենք մեծ ֆայլերի հետ, ինչպիսիք են լուսանկարները կամ տեսանյութերը, որոնք երկար ժամանակ են պահանջում ներբեռնելու և ամբողջ մոլորակով փոխանցելու համար:

100 օգտատեր. տվյալների շերտի չափում

CDN-ն շատ է օգնել. տրաֆիկը մեծանում է ամբողջ արագությամբ: Հայտնի վիդեոբլոգեր Մավիդ Մոբրիկը հենց նոր է գրանցվել մեզ մոտ և տեղադրել իր «պատմությունը», ինչպես ասում են։ Բեռնվածության հավասարակշռիչի շնորհիվ API սերվերների վրա պրոցեսորի և հիշողության օգտագործումը պահպանվում է ցածր (աշխատում է API-ի տասը դեպք), բայց մենք սկսում ենք ստանալ շատ ժամանակի ընդհատումներ հարցումների դեպքում... որտեղի՞ց են գալիս այս ուշացումները:

Մի փոքր փորփրելով չափումները՝ մենք տեսնում ենք, որ տվյալների բազայի սերվերի պրոցեսորը բեռնված է 80-90%-ով: Մենք սահմանի վրա ենք:

Տվյալների շերտի մասշտաբավորումը, հավանաբար, հավասարման ամենադժվար մասն է: API սերվերները սպասարկում են քաղաքացիություն չունեցող հարցումներ, ուստի մենք պարզապես ավելացնում ենք API-ի ավելի շատ օրինակներ: Քիթ մեծամասնությունը տվյալների բազաները չեն կարող դա անել: Մենք կխոսենք հանրահայտ հարաբերական տվյալների բազայի կառավարման համակարգերի մասին (PostgreSQL, MySQL և այլն):

caching

Մեր տվյալների բազայի արդյունավետությունը բարձրացնելու ամենահեշտ ձևերից մեկը նոր բաղադրիչի ներդրումն է՝ քեշի շերտը: Ամենատարածված քեշավորման մեթոդը հիշողության մեջ բանալիների արժեքով գրառումների պահեստն է, օրինակ՝ Redis կամ Memcached: Ամպերի մեծ մասն ունի այս ծառայությունների կառավարվող տարբերակը՝ Elasticache AWS-ում և Memorystore Google Cloud-ում:

Քեշը օգտակար է, երբ ծառայությունը բազմաթիվ կրկնվող զանգեր է կատարում տվյալների բազա՝ նույն տեղեկատվությունը ստանալու համար: Ըստ էության, մենք մուտք ենք գործում տվյալների բազա միայն մեկ անգամ, տեղեկատվությունը պահում ենք քեշում և այլևս չենք դիպչում դրան:

Օրինակ, մեր Graminsta ծառայությունում, ամեն անգամ, երբ ինչ-որ մեկը գնում է աստղ Mobrik-ի պրոֆիլի էջ, API սերվերը հարցում է անում տվյալների բազայից՝ իր պրոֆիլից տեղեկություններ ստանալու համար: Սա կրկնվում է նորից ու նորից: Քանի որ Mobrik-ի պրոֆիլի տեղեկատվությունը չի փոխվում յուրաքանչյուր հարցումով, այն հիանալի է քեշավորման համար:

Արդյունքները տվյալների բազայից մենք կքեշավորենք Redis-ում ըստ բանալիի user:id 30 վայրկյան գործողության ժամկետով: Հիմա, երբ ինչ-որ մեկը գնում է Mobrik-ի պրոֆիլ, մենք նախ ստուգում ենք Redis-ը, և եթե տվյալներն այնտեղ են, մենք ուղղակի փոխանցում ենք դրանք անմիջապես Redis-ից։ Այժմ կայքի ամենահայտնի պրոֆիլին ուղղված հարցումները գործնականում չեն բեռնում մեր տվյալների բազան:

Քեշավորման ծառայությունների մեծ մասի մեկ այլ առավելությունն այն է, որ դրանք ավելի հեշտ են մասշտաբային, քան տվյալների բազայի սերվերները: Redis-ն ունի ներկառուցված Redis Cluster ռեժիմ: Նման է բեռի հավասարակշռողին1, այն թույլ է տալիս ձեզ բաշխել ձեր Redis քեշը մի քանի մեքենաների վրա (անհրաժեշտության դեպքում հազարավոր սերվերների միջով):

Գրեթե բոլոր լայնածավալ հավելվածներն օգտագործում են քեշավորում, այն արագ API-ի բացարձակապես անբաժանելի մասն է: Հարցումների ավելի արագ մշակումը և ավելի արդյունավետ ծածկագիրը բոլորն էլ կարևոր են, բայց առանց քեշի գրեթե անհնար է ծառայությունը մեծացնել միլիոնավոր օգտատերերի համար:

Կարդացեք կրկնօրինակները

Երբ տվյալների բազայի հարցումների թիվը զգալիորեն ավելացել է, ևս մեկ բան, որ մենք կարող ենք անել, տվյալների բազայի կառավարման համակարգում կարդալու կրկնօրինակներ ավելացնելն է: Վերը նկարագրված կառավարվող ծառայությունների միջոցով դա կարելի է անել մեկ սեղմումով: Կարդացված կրկնօրինակը կմնա ընթացիկ հիմնական տվյալների բազայում և հասանելի է SELECT հայտարարությունների համար:

Ահա մեր համակարգը հիմա.

Հաջորդ քայլերը

Քանի որ հավելվածը շարունակում է մասշտաբավորվել, մենք կշարունակենք առանձնացնել ծառայությունները՝ դրանք ինքնուրույն չափելու համար: Օրինակ, եթե մենք սկսենք օգտագործել Websockets, ապա իմաստ ունի քաշել Websockets մշակման կոդը առանձին ծառայության մեջ: Մենք կարող ենք տեղադրել այն նոր օրինակների վրա մեր սեփական բեռի հավասարակշռիչի հետևում, որը կարող է մեծանալ և իջեցնել՝ հիմնվելով բաց Websockets կապերի վրա և անկախ HTTP հարցումների քանակից:

Մենք կշարունակենք նաև պայքարել տվյալների բազայի մակարդակով սահմանափակումների դեմ։ Հենց այս փուլում է, որ ժամանակն է ուսումնասիրել տվյալների բազայի բաժանումը և փոխանակումը: Երկու մոտեցումներն էլ պահանջում են լրացուցիչ ծախսեր, սակայն թույլ են տալիս չափել տվյալների բազան գրեթե անորոշ ժամանակով:

Մենք նաև ցանկանում ենք տեղադրել մոնիտորինգի և վերլուծական ծառայություն, ինչպիսին է New Relic-ը կամ Datadog-ը: Սա կօգնի ձեզ բացահայտել դանդաղ հարցումները և հասկանալ, թե որտեղ է անհրաժեշտ բարելավումը: Երբ մենք մասշտաբ ենք անում, մենք ցանկանում ենք կենտրոնանալ խոչընդոտներ գտնելու և դրանք վերացնելու վրա՝ հաճախ օգտագործելով նախորդ բաժինների որոշ գաղափարներ:

Տեղեկատվության աղբյուրներ

Այս գրառումը ոգեշնչված է մեկից իմ սիրելի գրառումները բարձր մասշտաբայնության մասին. Ես ուզում էի հոդվածը մի փոքր ավելի կոնկրետացնել նախագծերի սկզբնական փուլերի համար և անջատել այն մեկ վաճառողից: Համոզվեք, որ կարդացեք, եթե ձեզ հետաքրքրում է այս թեման:

Ծանոթագրություններ

1. Չնայած բեռների բաշխման առումով նման են բազմաթիվ ատյաններում, Redis կլաստերի հիմքում ընկած իրականացումը շատ տարբեր է բեռի հավասարակշռողից: [վերադարձ]

Source: www.habr.com