Backend, մեքենայական ուսուցում և առանց սերվերի՝ ամենահետաքրքիր բաները հուլիսյան Habr կոնֆերանսից

Հաբրի համաժողովը դեբյուտային պատմություն չէ։ Նախկինում 300-400 հոգու համար բավականին մեծ Toaster միջոցառումներ էինք անցկացնում, բայց հիմա որոշեցինք, որ փոքր թեմատիկ հանդիպումները տեղին կլինեն, որոնց ուղղությունը կարող եք սահմանել, օրինակ, մեկնաբանություններում։ Այս ձևաչափի առաջին կոնֆերանսը տեղի ունեցավ հուլիսին և նվիրված էր backend-ի զարգացմանը։ Մասնակիցները լսեցին զեկույցներ Backend-ից ML-ին անցնելու առանձնահատկությունների և Պետական ​​ծառայությունների պորտալում Quadrupel ծառայության նախագծման մասին, ինչպես նաև մասնակցեցին կլոր սեղանին՝ նվիրված Serverless-ին: Նրանց համար, ովքեր չեն կարողացել անձամբ ներկա գտնվել միջոցառմանը, այս գրառման մեջ պատմում ենք ամենահետաքրքիր բաները:

Backend-ի մշակումից մինչև մեքենայական ուսուցում

Ի՞նչ են անում տվյալների ինժեներները ML-ում: Ինչպե՞ս են հետին պլան մշակողի և ML ինժեների առաջադրանքները նման և տարբեր: Ի՞նչ ճանապարհով պետք է անցնեք ձեր առաջին մասնագիտությունը երկրորդի փոխելու համար: Այս մասին պատմել է Ալեքսանդր Պարինովը, ով անցել է մեքենայական ուսուցման 10 տարվա հետախուզական աշխատանքից հետո:

Ալեքսանդր Պարինով

Այսօր Ալեքսանդրն աշխատում է որպես համակարգչային տեսողության համակարգերի ճարտարապետ X5 Retail Group-ում և նպաստում է համակարգչային տեսողության և խորը ուսուցման հետ կապված բաց կոդով նախագծերին (github.com/creafz): Նրա հմտությունները հաստատվում են Kaggle Master-ի (kaggle.com/creafz) համաշխարհային վարկանիշի թոփ 100-ում՝ մեքենայական ուսուցման մրցույթների ամենահայտնի հարթակի մասնակցությամբ։

Ինչու՞ անցնել մեքենայական ուսուցման

Մեկուկես տարի առաջ Google-ի արհեստական ​​ինտելեկտի խորը ուսուցման վրա հիմնված հետազոտական ​​նախագծի՝ Google Brain-ի ղեկավար Ջեֆ Դինը նկարագրեց, թե ինչպես Google Translate-ում կոդերի կես միլիոն տող փոխարինվեց Tensor Flow նեյրոնային ցանցով, որը բաղկացած էր ընդամենը 500 տողից: Ցանցի վերապատրաստումից հետո տվյալների որակը բարձրացավ, և ենթակառուցվածքն ավելի պարզ դարձավ: Թվում է, թե սա մեր պայծառ ապագան է. մենք այլևս պետք չէ կոդ գրել, բավական է նեյրոններ ստեղծել և դրանք լրացնել տվյալների հետ: Բայց գործնականում ամեն ինչ շատ ավելի բարդ է։

ML ենթակառուցվածք Google-ում

Նյարդային ցանցերը ենթակառուցվածքի միայն մի փոքր մասն են կազմում (վերևի նկարում ներկայացված փոքր սև քառակուսին): Տվյալներ ստանալու, մշակելու, պահպանելու, որակը ստուգելու և այլնի համար պահանջվում են ավելի շատ օժանդակ համակարգեր, մեզ անհրաժեշտ են ենթակառուցվածք՝ վերապատրաստման, արտադրության մեջ մեքենայական ուսուցման կոդը տեղակայելու և այս կոդը փորձարկելու համար: Այս բոլոր առաջադրանքները ճիշտ նման են այն բանին, ինչ անում են հետին պլան մշակողները:

Մեքենայի ուսուցման գործընթաց

Ո՞րն է տարբերությունը ML-ի և backend-ի միջև:

Դասական ծրագրավորման մեջ մենք գրում ենք կոդ, և դա թելադրում է ծրագրի վարքագիծը: ML-ում մենք ունենք փոքր մոդելի կոդ և շատ տվյալներ, որոնք մենք նետում ենք մոդելի վրա: ML-ի տվյալները շատ կարևոր են. տարբեր տվյալների վրա պատրաստված նույն մոդելը կարող է ցույց տալ բոլորովին այլ արդյունքներ: Խնդիրն այն է, որ տվյալները գրեթե միշտ ցրված են և պահվում են տարբեր համակարգերում (հարաբերական տվյալների բազաներ, NoSQL տվյալների բազաներ, տեղեկամատյաններ, ֆայլեր):

Տվյալների տարբերակավորում

ML-ն պահանջում է ոչ միայն ծածկագրի տարբերակում, ինչպես դասական մշակման ժամանակ, այլև տվյալների. անհրաժեշտ է հստակ հասկանալ, թե ինչի վրա է վերապատրաստվել մոդելը: Դա անելու համար կարող եք օգտագործել հանրահայտ Data Science Version Control գրադարանը (dvc.org):

Տվյալների նշում

Հաջորդ խնդիրը տվյալների պիտակավորումն է: Օրինակ նշեք նկարի բոլոր առարկաները կամ ասեք, թե որ դասին է այն պատկանում: Դա անում են Յանդեքս.Տոլոկայի նման հատուկ ծառայությունները, որոնց հետ աշխատանքը մեծապես պարզեցվում է API-ի առկայությամբ: Դժվարություններն առաջանում են «մարդկային գործոնի» պատճառով. դուք կարող եք բարելավել տվյալների որակը և նվազագույնի հասցնել սխալները՝ վստահելով նույն առաջադրանքը մի քանի կատարողների:

Տեսողականացում Tensor Board-ում

Փորձերի գրանցումն անհրաժեշտ է արդյունքները համեմատելու և որոշ չափումների հիման վրա լավագույն մոդելն ընտրելու համար: Կա վիզուալիզացիայի գործիքների մեծ փաթեթ, օրինակ, Tensor Board: Սակայն փորձերը պահելու իդեալական եղանակներ չկան: Փոքր ընկերությունները հաճախ բավարարվում են Excel աղյուսակներով, մինչդեռ խոշորներն օգտագործում են հատուկ հարթակներ արդյունքները տվյալների բազայում պահելու համար:

Մեքենայական ուսուցման համար շատ հարթակներ կան, բայց դրանցից ոչ մեկը չի ծածկում կարիքների 70%-ը

Առաջին խնդիրը, որին պետք է բախվել վերապատրաստված մոդելը արտադրության մեջ դնելիս, կապված է տվյալների գիտնականների սիրելի գործիքի՝ Jupyter Notebook-ի հետ: Դրանում մոդուլյարություն չկա, այսինքն՝ ելքը կոդի այնպիսի «ոտքի շոր» է, որը բաժանված չէ տրամաբանական մասերի՝ մոդուլների։ Ամեն ինչ խառնված է` դասեր, գործառույթներ, կոնֆիգուրացիաներ և այլն: Այս կոդը դժվար է տարբերակել և փորձարկել:

Ինչպե՞ս վարվել սրա հետ: Դուք կարող եք ինքներդ հրաժարական տալ, ինչպես Netflix-ը, և ստեղծել ձեր սեփական հարթակը, որը թույլ է տալիս գործարկել այս դյուրակիր համակարգիչները անմիջապես արտադրության մեջ, փոխանցել նրանց տվյալները որպես մուտքագրում և ստանալ արդյունքներ: Դուք կարող եք ստիպել ծրագրավորողներին, ովքեր գլորում են մոդելը արտադրության մեջ, վերաշարադրել կոդը նորմալ՝ կոտրելով այն մոդուլների: Բայց այս մոտեցմամբ հեշտ է սխալվել, և մոդելը չի ​​աշխատի այնպես, ինչպես նախատեսված է: Հետևաբար, իդեալական տարբերակն է արգելել Jupyter Notebook-ի օգտագործումը մոդելային կոդի համար: Եթե, իհարկե, տվյալների գիտնականները համաձայնեն սրան։

Մոդել որպես սև տուփ

Մոդելը արտադրության մեջ մտցնելու ամենահեշտ ձևը այն որպես սև արկղ օգտագործելն է: Դուք ունեք ինչ-որ մոդելի դաս, ձեզ տրվել են մոդելի կշիռները (վարժեցված ցանցի նեյրոնների պարամետրերը), և եթե դուք նախաստորագրեք այս դասը (կանչեք կանխատեսման մեթոդը, կերակրեք այն նկարով), դուք կստանաք որոշակի կանխատեսումը որպես արդյունք: Այն, ինչ տեղի է ունենում ներսում, նշանակություն չունի:

Առանձին սերվերի գործընթացը մոդելի հետ

Կարող եք նաև բարձրացնել որոշակի առանձին գործընթաց և ուղարկել այն RPC հերթով (նկարներով կամ այլ աղբյուրի տվյալներով: Ելքում մենք կստանանք կանխատեսումներ:

Flask-ում մոդել օգտագործելու օրինակ.

@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)

Այս մոտեցման խնդիրը կատարողականի սահմանափակումն է: Ենթադրենք, մենք ունենք Phyton կոդ, որը գրված է տվյալների գիտնականների կողմից, որը դանդաղ է, և մենք ցանկանում ենք սեղմել առավելագույն արդյունավետությունը: Դա անելու համար կարող եք օգտագործել գործիքներ, որոնք ծածկագիրը վերածում են բնիկի կամ փոխակերպում են արտադրության համար հարմարեցված մեկ այլ շրջանակի: Նման գործիքներ կան յուրաքանչյուր շրջանակի համար, բայց իդեալականներ չկան, դուք ինքներդ պետք է դրանք ավելացնեք:

ML-ի ենթակառուցվածքը նույնն է, ինչ սովորական հետին պլանում: Կան Docker-ը և Kubernetes-ը, միայն Docker-ի համար պետք է տեղադրել Runtime NVIDIA-ից, որը թույլ է տալիս կոնտեյների ներսում պրոցեսներին մուտք գործել հոսթի վիդեո քարտեր։ Kubernetes-ին անհրաժեշտ է պլագին, որպեսզի կարողանա կառավարել սերվերները վիդեո քարտերով։

Ի տարբերություն դասական ծրագրավորման, ML-ի դեպքում ենթակառուցվածքում կան բազմաթիվ տարբեր շարժվող տարրեր, որոնք պետք է ստուգվեն և փորձարկվեն, օրինակ՝ տվյալների մշակման կոդը, մոդելի ուսումնական խողովակաշարը և արտադրությունը (տես վերևի գծապատկերը): Կարևոր է ստուգել խողովակաշարերի տարբեր մասերը միացնող ծածկագիրը. կան շատ կտորներ, և շատ հաճախ խնդիրներ են առաջանում մոդուլի սահմաններում:

Ինչպես է աշխատում AutoML-ը

AutoML ծառայությունները խոստանում են ընտրել ձեր նպատակների համար օպտիմալ մոդելը և պատրաստել այն: Բայց դուք պետք է հասկանաք. ML-ում տվյալները շատ կարևոր են, արդյունքը կախված է դրա պատրաստումից: Նշումը կատարվում է մարդկանց կողմից, ինչը հղի է սխալներով։ Առանց խիստ վերահսկողության արդյունքը կարող է լինել աղբ, և դեռ հնարավոր չէ ավտոմատացնել գործընթացը, անհրաժեշտ է ստուգում մասնագետների՝ տվյալների գիտնականների կողմից։ Այստեղ է, որ AutoML-ն խափանում է: Բայց դա կարող է օգտակար լինել ճարտարապետության ընտրության համար, երբ դուք արդեն պատրաստել եք տվյալները և ցանկանում եք մի շարք փորձեր կատարել լավագույն մոդելը գտնելու համար:

Ինչպես մտնել մեքենայական ուսուցում

ML մուտք գործելու ամենահեշտ ձևն այն է, եթե դուք զարգանում եք Python-ում, որն օգտագործվում է խորը ուսուցման բոլոր շրջանակներում (և սովորական շրջանակներում): Այս լեզուն գործնականում պարտադիր է գործունեության այս ոլորտի համար։ C++-ն օգտագործվում է համակարգչային տեսողության որոշ առաջադրանքների համար, օրինակ՝ ինքնակառավարվող մեքենաների կառավարման համակարգերում: JavaScript և Shell - վիզուալիզացիայի և այնպիսի տարօրինակ բաների համար, ինչպիսիք են բրաուզերում նեյրոն գործարկելը: Java-ն և Scala-ն օգտագործվում են Big Data-ի հետ աշխատելիս և մեքենայական ուսուցման համար: Ռ-ին և Ջուլիային սիրում են այն մարդիկ, ովքեր ուսումնասիրում են մաթեմատիկական վիճակագրությունը:

Սկսելու համար գործնական փորձ ձեռք բերելու ամենահարմար միջոցը Kaggle-ն է, պլատֆորմի մրցույթներից մեկին մասնակցելը տալիս է ավելի քան մեկ տարի տեսության ուսումնասիրություն: Այս հարթակում դուք կարող եք վերցնել ուրիշի տեղադրած և մեկնաբանված կոդը և փորձել բարելավել այն, օպտիմալացնել այն ձեր նպատակների համար: Բոնուս - ձեր Kaggle կոչումը ազդում է ձեր աշխատավարձի վրա:

Մեկ այլ տարբերակ է միանալ ML թիմին որպես backend ծրագրավորող: Կան բազմաթիվ մեքենայական ուսուցման ստարտափներ, որտեղ դուք կարող եք փորձ ձեռք բերել՝ օգնելով ձեր գործընկերներին լուծել իրենց խնդիրները: Վերջապես, դուք կարող եք միանալ տվյալների գիտնականների համայնքներից մեկին՝ Open Data Science (ods.ai) և այլն:

Թեմայի վերաբերյալ լրացուցիչ տեղեկություն բանախոսը տեղադրել է հղումով https://bit.ly/backend-to-ml

«Քվադրուպել»՝ «Պետական ​​ծառայություններ» պորտալի նպատակային ծանուցումների ծառայություն

Եվգենի Սմիրնով

Հաջորդ բանախոսը էլեկտրոնային կառավարման ենթակառուցվածքների զարգացման վարչության պետ Եվգենի Սմիրնովն էր, ով խոսեց Quadruple-ի մասին։ Սա նպատակային ծանուցման ծառայություն է Gosuslugi պորտալի համար (gosuslugi.ru), որն ամենաշատ այցելվող պետական ​​ռեսուրսն է Runet-ում: Օրական լսարանը 2,6 միլիոն է, ընդհանուր առմամբ կայքում կա 90 միլիոն գրանցված օգտատեր, որից 60 միլիոնը հաստատված է։ Պորտալի API-ի բեռը 30 հազար RPS է:

Պետական ​​ծառայությունների հետին պլանում օգտագործվող տեխնոլոգիաներ

«Quadrupel»-ը նպատակային ծանուցման ծառայություն է, որի օգնությամբ օգտատերը ստանում է ծառայության առաջարկ իր համար ամենահարմար պահին՝ սահմանելով ծանուցման հատուկ կանոններ։ Ծառայությունը մշակելիս հիմնական պահանջներն էին ճկուն կարգավորումները և փոստերի համար համապատասխան ժամանակը:

Ինչպե՞ս է աշխատում Quadrupel-ը:

Վերևի դիագրամը ցույց է տալիս Quadrupel-ի շահագործման կանոններից մեկը՝ օգտագործելով վարորդական իրավունքը փոխարինելու անհրաժեշտության իրավիճակի օրինակը: Նախ՝ ծառայությունը փնտրում է օգտատերերի, որոնց պիտանելիության ժամկետը լրանում է մեկ ամսից։ Նրանց ցուցադրվում է համապատասխան ծառայություն ստանալու առաջարկով պաստառ և էլփոստով հաղորդագրություն է ուղարկվում։ Այն օգտատերերի համար, որոնց վերջնաժամկետն արդեն լրացել է, բանները և էլ. Իրավունքների հաջող փոխանակումից հետո օգտվողը ստանում է այլ ծանուցումներ՝ ինքնության մեջ տվյալները թարմացնելու առաջարկով:

Տեխնիկական տեսակետից սրանք groovy սցենարներ են, որոնցում գրված է կոդը։ Մուտքը տվյալ է, ելքը ճիշտ/կեղծ է, համընկնում է/չհամընկնում: Ընդհանուր առմամբ կան ավելի քան 50 կանոններ՝ սկսած օգտատիրոջ ծննդյան օրը որոշելուց (ներկայիս ամսաթիվը հավասար է օգտատիրոջ ծննդյան ամսաթվին) մինչև բարդ իրավիճակներ: Ամեն օր այս կանոնները բացահայտում են մոտ մեկ միլիոն համընկնումներ՝ մարդիկ, ովքեր պետք է ծանուցվեն:

Quadrupel ծանուցման ալիքներ

Quadrupel-ի գլխարկի տակ կա տվյալների բազա, որտեղ պահվում են օգտատերերի տվյալները, և երեք հավելված. 

• Բանվոր նախատեսված է տվյալների թարմացման համար:
• Հանգստացեք API- ին ինքն է վերցնում և տրամադրում պաստառները պորտալին և բջջային հավելվածին:
• Scheduler սկսում է բաններների կամ զանգվածային փոստերի վերահաշվարկի աշխատանքները:

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

Տվյալները պահպանելուց հետո JMS-ում առաջադրանք է դրվում, որպեսզի բաններներն անմիջապես վերահաշվարկվեն. սա պետք է անմիջապես ցուցադրվի համացանցում: Համակարգը սկսվում է գիշերը. օգտատերերի ընդմիջումներով առաջադրանքները գցվում են JMS, ըստ որոնց կանոնները պետք է վերահաշվարկվեն: Սա վերցվում է վերահաշվարկի մեջ ներգրավված վերամշակողների կողմից: Հաջորդը, մշակման արդյունքները գնում են հաջորդ հերթ, որը կա՛մ պահում է վահանակները տվյալների բազայում, կա՛մ ուղարկում է օգտատերերի ծանուցման առաջադրանքները ծառայությանը: Գործընթացը տևում է 5-7 ժամ, այն հեշտությամբ մասշտաբային է, քանի որ դուք միշտ կարող եք կա՛մ ավելացնել մշակողներ, կա՛մ բարձրացնել օրինակներ նոր մշակիչներով:

Ծառայությունը բավականին լավ է աշխատում։ Սակայն տվյալների ծավալն աճում է, քանի որ ավելի շատ օգտվողներ կան: Սա հանգեցնում է տվյալների բազայի բեռի ավելացմանը՝ նույնիսկ հաշվի առնելով այն փաստը, որ Rest API-ն նայում է կրկնօրինակին: Երկրորդ կետը JMS-ն է, որը, ինչպես պարզվեց, այնքան էլ հարմար չէ հիշողության մեծ սպառման պատճառով։ Հերթի գերհոսքի մեծ ռիսկ կա, որը կհանգեցնի JMS-ի խափանման և մշակման դադարեցմանը: Առանց տեղեկամատյանները մաքրելու հնարավոր չէ բարձրացնել JMS-ը:

Նախատեսվում է խնդիրները լուծել Sharding-ի միջոցով, ինչը թույլ կտա հավասարակշռել տվյալների բազայի ծանրաբեռնվածությունը։ Նախատեսվում է նաև փոխել տվյալների պահպանման սխեման և փոխել JMS-ը Kafka-ի` ավելի սխալ հանդուրժող լուծում, որը կլուծի հիշողության խնդիրները:

Backend-as-a-Service ընդդեմ. Անսերվեր

Ձախից աջ՝ Ալեքսանդր Բորգարտ, Անդրեյ Տոմիլենկո, Նիկոլայ Մարկով, Արա Իսրայելյան

Backend որպես ծառայություն կամ առանց սերվերի լուծում: Կլոր սեղանի շուրջ այս հրատապ հարցի քննարկմանը մասնակցում էին.

• Արա Իսրայելյան, CTO CTO և Scorocode-ի հիմնադիր.
• Նիկոլայ Մարկով, Aligned Research Group-ի տվյալների ավագ ինժեներ:
• Անդրեյ Տոմիլենկո, RUVDS-ի զարգացման բաժնի ղեկավար. 

Զրույցը վարում էր ավագ ծրագրավորող Ալեքսանդր Բորգարտը: Բանավեճերը, որոնց մասնակցում էին նաեւ ունկնդիրները, ներկայացնում ենք կրճատ տարբերակով.

— Ի՞նչ է «Serverless»-ը ձեր պատկերացմամբ:

AndrewՍա հաշվողական մոդել է՝ Lambda ֆունկցիա, որը պետք է մշակի տվյալները, որպեսզի արդյունքը կախված լինի միայն տվյալներից: Տերմինը եկել է կամ Google-ից կամ Amazon-ից և նրա AWS Lambda ծառայությունից: Պրովայդերի համար ավելի հեշտ է կարգավորել նման գործառույթը՝ դրա համար հատկացնելով հզորությունների լողավազան: Տարբեր օգտվողներ կարող են ինքնուրույն հաշվառվել նույն սերվերների վրա:
NicholasՊարզ ասած՝ մենք մեր ՏՏ ենթակառուցվածքի և բիզնես տրամաբանության որոշ մասը փոխանցում ենք ամպին՝ աութսորսինգին:
ԱրաՄշակողների կողմից՝ ռեսուրսներ խնայելու լավ փորձ, մարքեթոլոգների կողմից՝ ավելի շատ գումար վաստակելու:

— Անսերվերը նույնն է, ինչ միկրոսերվիսները:

NicholasՈչ, Serverless-ը ավելի շատ ճարտարապետական ​​կազմակերպություն է: Միկրոծառայությունը որոշակի տրամաբանության ատոմային միավոր է: Անսերվերը մոտեցում է, այլ ոչ թե «առանձին սուբյեկտ»:
ԱրաԱռանց սերվերի ֆունկցիան կարող է փաթեթավորվել միկրոսերվիսում, բայց սա այլևս չի լինի առանց սերվերի, այլևս կդադարի լինել Lambda ֆունկցիա: Serverless-ում ֆունկցիան սկսում է աշխատել միայն այն պահին, երբ այն պահանջվում է:
AndrewՆրանք տարբերվում են իրենց կյանքի ընթացքում: Մենք գործարկեցինք Lambda ֆունկցիան և մոռացանք այն: Այն աշխատեց մի քանի վայրկյան, և հաջորդ հաճախորդը կարող է մշակել իր հարցումը մեկ այլ ֆիզիկական մեքենայի վրա:

- Ո՞ր կշեռքներն են ավելի լավ:

ԱրաՀորիզոնական մասշտաբման ժամանակ Lambda ֆունկցիաները գործում են ճիշտ այնպես, ինչպես միկրոսերվիսները:
NicholasԱնկախ նրանից, թե ինչ թվով կրկնօրինակներ եք սահմանում, դրանք կլինեն նույնքան, Serverless-ը մասշտաբավորման հետ կապված խնդիրներ չունի: Ես Kubernetes-ում կրկնօրինակ եմ պատրաստել, «ինչ-որ տեղ» գործարկել եմ 20 օրինակ և 20 անանուն հղումներ վերադարձվել են ձեզ: Առաջ!

— Հնարավո՞ր է առանց սերվերի վրա backend գրել:

AndrewՏեսականորեն, բայց դա անիմաստ է: Lambda գործառույթները հիմնվելու են մեկ պահոցի վրա. մենք պետք է երաշխավորենք: Օրինակ՝ եթե օգտատերը որոշակի գործարք է իրականացրել, ապա հաջորդ անգամ կապվելիս պետք է տեսնի՝ գործարքը կատարվել է, միջոցները մուտքագրվել են։ Բոլոր Lambda գործառույթները կարգելափակվեն այս զանգի ժամանակ: Իրականում, առանց սերվերի գործառույթների մի փունջ կվերածվի մեկ ծառայության՝ տվյալների բազայի մեկ շեղ մուտքի կետով:

— Ի՞նչ իրավիճակներում է իմաստ ունի օգտագործել առանց սերվերի ճարտարապետություն:

AndrewԱռաջադրանքներ, որոնք չեն պահանջում ընդհանուր պահեստավորում՝ նույն մայնինգը, բլոկչեյնը: Այնտեղ, որտեղ դուք պետք է շատ հաշվեք: Եթե ​​դուք ունեք շատ հաշվողական հզորություն, ապա կարող եք սահմանել այնպիսի ֆունկցիա, ինչպիսին է «հաշվիր այնտեղ ինչ-որ բանի հեշը...»: Բայց դուք կարող եք լուծել տվյալների պահպանման խնդիրը՝ վերցնելով, օրինակ, Amazon-ի Lambda ֆունկցիաները և դրանց բաշխված պահեստը: . Եվ պարզվում է, որ դուք սովորական ծառայություն եք գրում։ Lambda ֆունկցիաները կմտնեն պահեստ և ինչ-որ պատասխան կտա օգտագործողին:
NicholasԱնսերվերով աշխատող կոնտեյներները ռեսուրսներով չափազանց սահմանափակ են: Հիշողությունը քիչ է և մնացած ամեն ինչ: Բայց եթե ձեր ամբողջ ենթակառուցվածքն ամբողջությամբ տեղակայված է ինչ-որ ամպի վրա՝ Google-ը, Amazon-ը, և դուք մշտական ​​պայմանագիր ունեք նրանց հետ, այս ամենի համար կա բյուջե, ապա որոշ առաջադրանքների համար կարող եք օգտագործել առանց սերվերի կոնտեյներներ: Պետք է լինել այս ենթակառուցվածքի ներսում, քանի որ ամեն ինչ հարմարեցված է կոնկրետ միջավայրում օգտագործելու համար։ Այսինքն, եթե դուք պատրաստ եք ամեն ինչ կապել ամպային ենթակառուցվածքի հետ, կարող եք փորձարկել։ Առավելությունն այն է, որ դուք պետք չէ կառավարել այս ենթակառուցվածքը:
ԱրաԱյն, որ Serverless-ը ձեզանից չի պահանջում կառավարել Kubernetes-ը, Docker-ը, տեղադրել Kafka-ն և այլն, ինքնախաբեություն է։ Սա տեղադրում են նույն Amazon-ը և Google-ը: Մեկ այլ բան այն է, որ դուք ունեք SLA: Դուք կարող եք նաև ամեն ինչ փոխանցել, այլ ոչ թե ինքներդ կոդավորել:
AndrewԱնսերվերն ինքնին էժան է, բայց դուք պետք է շատ վճարեք Amazon-ի այլ ծառայությունների համար, օրինակ՝ տվյալների բազայի համար: Մարդիկ արդեն դատի են տվել նրանց, քանի որ նրանք խելահեղ գումարներ են գանձել API-ի դարպասի համար:
ԱրաԵթե ​​մենք խոսում ենք փողի մասին, ապա դուք պետք է հաշվի առնեք այս կետը. դուք ստիպված կլինեք ընկերությունում մշակման ողջ մեթոդաբանությունը շրջել 180 աստիճանով, որպեսզի ամբողջ կոդը փոխանցեք Serverless: Սա շատ ժամանակ և գումար կխլի:

— Կա՞ն արդյոք արժանի այլընտրանքներ Amazon-ից և Google-ից վճարովի Serverless-ին:

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

— Որքանո՞վ է կարևոր վերահսկել, թե ինչ է կատարվում Serverless-ում:

ԱրաԿախված է համակարգի ճարտարապետությունից և բիզնեսի պահանջներից: Ըստ էության, մատակարարը պետք է ներկայացնի հաշվետվություններ, որոնք կօգնեն devops թիմին հասկանալ հնարավոր խնդիրները:
NicholasAmazon-ն ունի CloudWatch, որտեղ հեռարձակվում են բոլոր տեղեկամատյանները, ներառյալ Lambda-ից: Ինտեգրել տեղեկամատյանների վերահասցեավորումը և օգտագործել առանձին գործիք՝ դիտելու, զգուշացնելու և այլնի համար: Դուք կարող եք նյութեր լցնել ձեր սկսած տարաների մեջ:

-Եկեք ամփոփենք:

AndrewԼամբդա ֆունկցիաների մասին մտածելն օգտակար է: Եթե ​​դուք ինքնուրույն եք ստեղծում ծառայություն՝ ոչ թե միկրոսերվիս, այլ այնպիսի ծառայություն, որը գրում է հարցում, մուտք է գործում տվյալների բազա և պատասխան ուղարկում, ապա Lambda ֆունկցիան լուծում է մի շարք խնդիրներ՝ բազմալեզու, մասշտաբայնություն և այլն: Եթե ​​ձեր տրամաբանությունը կառուցված է այս կերպ, ապա ապագայում դուք կկարողանաք փոխանցել այս Lambda-ները միկրոսերվիսներ կամ օգտվել երրորդ կողմի ծառայություններից, ինչպիսին Amazon-ն է: Տեխնոլոգիան օգտակար է, գաղափարը՝ հետաքրքիր։ Թե որքանով է դա արդարացված բիզնեսի համար, դեռ բաց հարց է։
Նիկոլայ. Անսերվերն ավելի լավ է օգտագործել գործառնական առաջադրանքների համար, քան որոշ բիզնես տրամաբանություն հաշվարկելու համար: Ես միշտ դա համարում եմ իրադարձությունների մշակում: Եթե ​​դուք ունեք այն Amazon-ում, եթե դուք Kubernetes-ում եք, այո: Հակառակ դեպքում, դուք ստիպված կլինեք բավականին մեծ ջանքեր գործադրել՝ առանց սերվերի ինքնուրույն գործարկելու համար: Պետք է դիտարկել կոնկրետ բիզնես դեպք։ Օրինակ, հիմա իմ առաջադրանքներից մեկն այն է, որ երբ ֆայլերը հայտնվում են սկավառակի վրա որոշակի ձևաչափով, ես պետք է դրանք վերբեռնեմ Կաֆկա: Ես կարող եմ օգտագործել WatchDog կամ Lambda: Տրամաբանական տեսանկյունից երկու տարբերակն էլ հարմար են, բայց իրականացման առումով Serverless-ն ավելի բարդ է, իսկ ես նախընտրում եմ ավելի պարզ տարբերակը՝ առանց Lambda-ի։
Արա«Առանց սերվերը» հետաքրքիր, կիրառելի և տեխնիկապես շատ գեղեցիկ գաղափար է: Վաղ թե ուշ տեխնոլոգիաները կհասնեն այն կետին, երբ ցանկացած գործառույթ կգործարկվի 100 միլիվայրկյանից պակաս ժամանակում: Այնուհետև, սկզբունքորեն, հարց չի լինի, թե արդյոք սպասման ժամանակը կարևոր է օգտագործողի համար: Միևնույն ժամանակ, Serverless-ի կիրառելիությունը, ինչպես արդեն ասել են գործընկերները, ամբողջովին կախված է բիզնեսի խնդրից:

Շնորհակալություն ենք հայտնում մեր հովանավորներին, ովքեր մեզ շատ օգնեցին.

• ՏՏ կոնֆերանսի տարածք «Գարուն» կոնֆերանսի կայքի համար:
• ՏՏ իրադարձությունների օրացույց Runet-ID և հրապարակում»Ինտերնետը թվերով» տեղեկատվական աջակցության և նորությունների համար:
• «Ակրոնիս«Նվերների համար.
• Ավիտոն համաստեղծման համար։
• «Էլեկտրոնային հաղորդակցության ասոցիացիա» RAEC ներգրավվածության և փորձի համար:
• Գլխավոր հովանավոր ՌՈՒՎԴՍ - բոլորի համար!

Source: www.habr.com