Соңғы жылдары серверсіз технологиялар тез танымал болғанымен, олармен байланысты көптеген қате түсініктер мен қорқыныштар әлі де бар. Жеткізушіге тәуелділік, құрал-саймандар, шығындарды басқару, суық бастау, бақылау және әзірлеудің өмірлік циклі серверсіз технологияларға қатысты өзекті тақырыптар болып табылады. Бұл мақалада біз аталған тақырыптардың кейбірін зерттейміз, сондай-ақ жаңадан бастаушыларға қуатты, икемді және үнемді серверсіз қолданбаларды жасауға көмектесу үшін пайдалы ақпарат көздеріне кеңестер мен сілтемелермен бөлісеміз.
Серверсіз технологиялар туралы қате түсініктер
Көптеген адамдар серверсіз және серверсіз өңдеуді (, FaaS) дерлік бірдей нәрсе. Бұл айырмашылық тым үлкен емес және жаңалық енгізуге тұрарлық дегенді білдіреді. AWS Lambda серверсіз гүлдену дәуірінің жұлдыздарының бірі және серверсіз архитектураның ең танымал элементтерінің бірі болғанымен, бұл архитектура FaaS-тен әлдеқайда көп.
Серверсіз технологиялардың негізгі қағидасы - инфрақұрылымды басқару және масштабтау туралы алаңдамаудың қажеті жоқ, сіз тек пайдаланғаныңыз үшін төлейсіз. Көптеген қызметтер осы критерийлерге сәйкес келеді - AWS DynamoDB, S3, SNS немесе SQS, Graphcool, Auth0, Now, Netlify, Firebase және т.б. Тұтастай алғанда, серверсіз бұл инфрақұрылымды басқару және оны масштабтау үшін оңтайландыру қажеттілігінсіз бұлттық есептеулердің толық қуатын пайдалануды білдіреді. Бұл сондай-ақ инфрақұрылым деңгейіндегі қауіпсіздік бұдан былай сізді алаңдатпайтынын білдіреді, бұл қауіпсіздік стандарттарына сәйкес келудің қиындығы мен күрделілігін ескере отырып, үлкен пайда. Ақырында, сізге берілген инфрақұрылымды сатып алудың қажеті жоқ.
Серверсіз «көңіл күйі» деп санауға болады: шешімдерді жобалау кезіндегі белгілі бір менталитет. Кез келген инфрақұрылымға техникалық қызмет көрсетуді қажет ететін тәсілдерден аулақ болыңыз. Серверсіз тәсілмен біз жобаға тікелей әсер ететін және пайдаланушыларымызға пайда әкелетін тапсырмаларды шешуге уақыт бөлеміз: біз тұрақты бизнес логикасын жасаймыз, пайдаланушы интерфейстерін дамытамыз және бейімделгіш және сенімді API әзірлейміз.
Мысалы, еркін мәтінді іздеу платформасын басқарудан және қолдаудан аулақ болу мүмкін болса, біз мұны істейміз. Қолданбаларды құрудың бұл тәсілі нарыққа шығу уақытын айтарлықтай жылдамдатады, өйткені күрделі инфрақұрылымды басқару туралы енді ойланудың қажеті жоқ. Инфрақұрылымды басқарудың жауапкершіліктері мен шығындарын жойып, тұтынушыларға қажет қолданбалар мен қызметтерді құруға назар аударыңыз. Патрик Дебуа бұл тәсілді атады , термин серверсіз қауымдастықта қабылданған. Функцияларды орналастыруға болатын модульдер ретінде қызметтерге сілтеме ретінде қарастыру керек (бүкіл кітапхананы немесе веб-қосымшаны орналастырудың орнына). Бұл қолданбаны орналастыруды және өзгертулерді басқару үшін керемет түйіршіктілікті қамтамасыз етеді. Функцияларды осылай орналастыра алмасаңыз, бұл функциялардың тым көп тапсырмаларды орындайтынын және қайта өңдеуді қажет ететінін көрсетуі мүмкін.
Кейбіреулер бұлттық қолданбаларды әзірлеу кезінде жеткізушіге тәуелділікпен шатастырады. Бұл серверсіз технологияларға қатысты және бұл қате түсінік емес. Біздің тәжірибемізде AWS жүйесінде серверсіз қолданбаларды құру және AWS Lambda басқа AWS қызметтерін біріктіру мүмкіндігі серверсіз архитектуралардың күшті бөлігі болып табылады. Бұл синергетиканың жақсы мысалы, комбинацияның нәтижесі терминдердің қосындысынан көп болған кезде. Жеткізушіге тәуелділіктен аулақ болуға тырысу одан да көп мәселелерге әкелуі мүмкін. Контейнерлермен жұмыс істегенде, бұлттық провайдерлер арасында өзіңіздің абстракциялық қабатыңызды басқару оңайырақ. Бірақ серверсіз шешімдерге келетін болсақ, күш-жігер ақталмайды, әсіресе үнемділік басынан бастап ескерілсе. Сатушылар қызметтерді қалай көрсететінін біліңіз. Кейбір мамандандырылған қызметтер басқа жеткізушілермен біріктіру нүктелеріне сүйенеді және қораптан тыс қосу және ойнату қосылымын қамтамасыз етуі мүмкін. Кейбір контейнерге немесе EC2 данасына сұрауды прокси арқылы жіберуге қарағанда, шлюз API соңғы нүктесінен Lambda қоңырауын беру оңайырақ. Graphcool Auth0 көмегімен оңай конфигурацияны қамтамасыз етеді, бұл үшінші тарап аутентификация құралдарын пайдаланудан оңайырақ.
Серверсіз қолданба үшін дұрыс жеткізушіні таңдау архитектуралық шешім болып табылады. Қолданбаны жасаған кезде сіз бір күні серверлерді басқаруға ораласыз деп күтпейсіз. Бұлтты жеткізушіні таңдау контейнерлерді немесе дерекқорды, тіпті бағдарламалау тілін пайдалануды таңдаудан еш айырмашылығы жоқ.
Қарастырыңыз:
- Сізге қандай қызметтер қажет және не үшін.
- Бұлттық провайдерлер қандай қызметтерді ұсынады және оларды таңдалған FaaS шешімімен қалай біріктіруге болады.
- Қандай бағдарламалау тілдеріне қолдау көрсетіледі (динамикалық немесе статикалық терумен, құрастырылған немесе түсіндірілетін, эталондар қандай, суық іске қосудағы өнімділік қандай, ашық бастапқы экожүйе дегеніміз не және т.б.).
- Қауіпсіздік талаптары қандай (SLA, 2FA, OAuth, HTTPS, SSL, т.б.).
- CI/CD және бағдарламалық құралды әзірлеу циклдерін қалай басқаруға болады.
- Код ретінде қандай инфрақұрылымдық шешімдерді пайдалана аласыз.
Егер сіз бұрыннан бар қолданбаны кеңейтіп, серверсіз функцияларды біртіндеп қоссаңыз, бұл қолжетімді мүмкіндіктерді біршама шектеуі мүмкін. Дегенмен, серверсіз технологиялардың барлығы дерлік API-нің қандай да бір түрін (REST немесе хабарлар кезегі арқылы) қамтамасыз етеді, бұл қолданба өзегінен тәуелсіз және оңай біріктіру арқылы кеңейтімдерді жасауға мүмкіндік береді. Түсінікті API интерфейстері, жақсы құжаттамалары және күшті қауымдастықтары бар қызметтерді іздеңіз және қателесе алмайсыз. Интеграцияның қарапайымдылығы көбінесе негізгі көрсеткіш болуы мүмкін және AWS 2015 жылы Lambda шығарылғаннан бері сәтті болуының басты себептерінің бірі болуы мүмкін.
Серверсіз жақсы болған кезде
Серверсіз технологияларды барлық жерде дерлік қолдануға болады. Дегенмен, олардың артықшылықтары қолданудың бір тәсілімен шектелмейді. Серверсіз технологиялардың арқасында бүгінде бұлтты есептеулерге кіруге кедергі өте төмен. Егер әзірлеушілердің идеясы болса, бірақ олар бұлтты инфрақұрылымды қалай басқаруға және шығындарды оңтайландыруға болатынын білмесе, онда олар мұны істеу үшін қандай да бір инженер іздеудің қажеті жоқ. Егер стартап платформаны құрғысы келсе, бірақ шығындар бақылаудан шығып кетуі мүмкін деп қорқатын болса, олар серверсіз шешімдерге оңай жүгіне алады.
Шығындарды үнемдеу және масштабтаудың қарапайымдылығы арқасында серверсіз шешімдер ішкі және сыртқы жүйелер үшін, көп миллиондық аудиториясы бар веб-қосымшаға дейін бірдей қолданылады. Шоттар еуромен емес, центпен өлшенеді. AWS EC2 (t1.micro) ең қарапайым данасын бір айға жалға алу, тіпті онымен ештеңе жасамасаңыз да (оны өшіруді кім ұмытпады?!) €15 тұрады. Салыстырмалы түрде алғанда, сол уақыт аралығындағы шығынның осы деңгейіне жету үшін сізге 512 МБ Lambda-ны 1 секундқа шамамен 3 миллион рет іске қосу қажет болады. Ал егер сіз бұл мүмкіндікті пайдаланбасаңыз, онда сіз ештеңе төлемейсіз.
Серверсіз негізінен оқиғаға негізделгендіктен, ескі жүйелерге серверсіз инфрақұрылымды қосу өте оңай. Мысалы, AWS S3, Lambda және Kinesis көмегімен деректерді API арқылы қабылдай алатын ескі бөлшек сауда жүйесі үшін талдау қызметін жасауға болады.
Көптеген серверсіз платформалар бірнеше тілді қолдайды. Көбінесе бұл Python, JavaScript, C#, Java және Go. Әдетте барлық тілдердегі кітапханаларды пайдалануға ешқандай шектеулер жоқ, сондықтан сүйікті ашық бастапқы кітапханаларды пайдалануға болады. Дегенмен, сіздің функцияларыңыз оңтайлы жұмыс істеуі және серверсіз қолданбаларыңыздың ауқымды ауқымдылығының артықшылықтарын жоққа шығармауы үшін тәуелділіктерді теріс пайдаланбаған жөн. Контейнерге неғұрлым көп пакеттерді салу керек болса, суықты бастау соғұрлым ұзаққа созылады.
Суық бастау контейнерді, орындалу уақытын және қате өңдегішті қолданбас бұрын алдымен инициализациялау қажет болғанда. Осыған байланысты функцияларды орындаудағы кідіріс 3 секундқа дейін болуы мүмкін және бұл шыдамсыз пайдаланушылар үшін ең жақсы нұсқа емес. Дегенмен, бірнеше минут жұмыс істемей тұрғаннан кейін бірінші қоңырауда суыту пайда болады. Көптеген адамдар мұны аздап тітіркендіргіш деп санайды, оны жұмыс істемей тұру үшін функцияны үнемі пингтеу арқылы шешуге болады. Немесе олар бұл жағын мүлде елемейді.
AWS шығарылғаныменДегенмен, SQL дерекқорлары бұл қолданба үшін өте қолайлы емес, өйткені олар транзакцияларды орындау үшін қосылымдарға тәуелді, бұл AWS Lambda-да көп трафикпен тез тығырықтан шығуы мүмкін. Иә, әзірлеушілер Serverless Aurora-ны үнемі жетілдіріп отырады және сіз онымен тәжірибе жасауыңыз керек, бірақ бүгінде NoSQL шешімдері. Дегенмен, бұл жағдайдың тез арада өзгеретініне күмән жоқ.
Құралдар жинағы сонымен қатар көптеген шектеулер қояды, әсіресе жергілікті тестілеу саласында. Docker-Lambda, DynamoDB Local және LocalStack сияқты шешімдер бар болса да, олар қажырлы жұмысты және айтарлықтай конфигурацияны қажет етеді. Дегенмен, бұл жобалардың барлығы белсенді түрде әзірленуде, сондықтан құралдар жинағы бізге қажетті деңгейге жеткенше уақыт мәселесі.
Серверсіз технологиялардың даму цикліне әсері
Инфрақұрылым жай ғана конфигурация болғандықтан, қабық сценарийлері сияқты сценарийлерді пайдаланып кодты анықтауға және орналастыруға болады. Немесе код ретінде конфигурация сыныбының шешімдеріне жүгінуге болады . Бұл қызмет барлық аймақтар үшін конфигурацияны қамтамасыз етпесе де, ол Lambda функциялары ретінде пайдалану үшін арнайы ресурстарды анықтауға мүмкіндік береді. Яғни, CloudFormation сізге сәтсіздікке ұшыраған жағдайда, бұл олқылықты жоятын жеке ресурсыңызды (Lambda функциясы) жаза аласыз. Осылайша сіз кез келген нәрсені жасай аласыз, тіпті AWS ортаңыздан тыс тәуелділіктерді конфигурациялай аласыз.
Мұның бәрі жай конфигурация болғандықтан, қолдану сценарийлерін арнайы орталар, аймақтар және пайдаланушылар үшін теңшей аласыз, әсіресе CloudFormation сияқты инфрақұрылымды код ретінде шешімдерін пайдаланып жатсаңыз. Мысалы, әзірлеу кезінде оларды толығымен оқшауланған түрде сынау үшін репозиторийдегі әрбір филиал үшін инфрақұрылымның көшірмесін орналастыруға болады. Бұл әзірлеушілер коды тірі ортада тиісті түрде жұмыс істейтінін түсінгісі келгенде, олар үшін кері байланысты айтарлықтай жылдамдатады. Менеджерлер бірнеше ортаны орналастыру құны туралы алаңдамауы керек, өйткені олар тек нақты пайдалану үшін төлейді.
DevOps-тың алаңдаушылығы аз, өйткені олар әзірлеушілердің дұрыс конфигурацияға ие екеніне көз жеткізуі керек. Енді даналарды, теңгергіштерді немесе қауіпсіздік топтарын басқару қажет емес. Сондықтан, NoOps термині барған сайын жиі қолданылады, дегенмен инфрақұрылымды конфигурациялау мүмкіндігі әлі де маңызды, әсіресе IAM конфигурациясына және бұлттық ресурстарды оңтайландыруға қатысты.
Epsagon, Thundra, Dashbird және IOPipe сияқты өте қуатты бақылау және визуализация құралдары бар. Олар серверсіз қолданбалардың ағымдағы күйін бақылауға, тіркеуді және бақылауды қамтамасыз етуге, өнімділік көрсеткіштерін және архитектуралық кедергілерді түсіруге, шығындарды талдау мен болжауды орындауға және т.б. мүмкіндік береді. Олар DevOps инженерлеріне, әзірлеушілеріне және сәулетшілеріне қолданба өнімділігінің жан-жақты көрінісін беріп қана қоймайды, сонымен қатар менеджерлерге секундтық ресурстар шығындары мен шығындарды болжау арқылы нақты уақыт режимінде жағдайды бақылауға мүмкіндік береді. Басқарылатын инфрақұрылыммен мұны ұйымдастыру әлдеқайда қиын.
Серверсіз қолданбаларды жобалау әлдеқайда оңай, себебі сізге веб-серверлерді орналастыру, виртуалды машиналарды немесе контейнерлерді, патч-серверлерді, операциялық жүйелерді, интернет шлюздерін және т.б. басқарудың қажеті жоқ. Осы жауапкершіліктердің барлығын алып тастау арқылы серверсіз архитектура ядроға назар аудара алады - шешім.бизнес және тұтынушы қажеттіліктері.
Құралдар жинағы жақсырақ болуы мүмкін болса да (ол күн сайын жақсарып келеді), әзірлеушілер бизнес логикасын енгізуге және архитектурадағы әртүрлі қызметтерге қолданбаның күрделілігін жақсырақ таратуға назар аудара алады. Серверсіз қолданбаны басқару оқиғаға негізделген және бұлттық провайдермен абстракцияланады (мысалы, SQS, S3 оқиғалары немесе DynamoDB ағындары). Сондықтан әзірлеушілер белгілі бір оқиғаларға жауап беру үшін тек іскерлік логиканы жазуы керек және дерекқорлар мен хабарламалар кезегін қалай ең жақсы іске асыру керек немесе нақты аппараттық қоймалардағы деректермен оңтайлы жұмысты қалай ұйымдастыру керектігі туралы алаңдамау керек.
Кез келген әзірлеу процесіндегі сияқты кодты жергілікті түрде іске қосуға және жөндеуге болады. Бірлікті сынау сол күйінде қалады. Қолданбаның толық инфрақұрылымын теңшелетін стек конфигурациясымен қолдану мүмкіндігі әзірлеушілерге тестілеу құны немесе қымбат басқарылатын орталарға әсер ету туралы ойламай-ақ маңызды кері байланысты жылдам алуға мүмкіндік береді.
Серверсіз қосымшаларды құру құралдары мен әдістері
Серверсіз қосымшаларды құрудың арнайы жолы жоқ. Сондай-ақ осы тапсырма бойынша қызметтер жиынтығы. AWS бүгінгі күні қуатты серверсіз шешімдердің көшбасшысы болып табылады, бірақ сонымен бірге қараңыз , и . AWS қолданып жатсаңыз, қолданбаларды жинауға ұсынылатын әдіс (SAM), әсіресе C# пайдалану кезінде, өйткені Visual Studio бағдарламасының тамаша құралдары бар. SAM CLI Visual Studio жасай алатын барлық нәрсені жасай алады, сондықтан басқа IDE немесе мәтіндік редакторға ауыссаңыз, ештеңе жоғалтпайсыз. Әрине, SAM басқа тілдермен де жұмыс істейді.
Егер сіз басқа тілдерде жазып жатсаңыз, Serverless Framework өте қуатты YAML конфигурация файлдарымен кез келген нәрсені конфигурациялауға мүмкіндік беретін тамаша ашық бастапқы құрал болып табылады. Serverless Framework сонымен қатар әртүрлі бұлттық қызметтерді қолдайды, сондықтан оны көп бұлтты шешімді іздейтіндерге ұсынамыз. Онда кез келген қажеттілік үшін көптеген плагиндер жасаған үлкен қауымдастық бар.
Жергілікті тестілеу үшін Docker-Lambda, Serverless Local, DynamoDB Local және LocalStack ашық бастапқы құралдары өте қолайлы. Серверсіз технологиялар әлі де дамудың бастапқы сатысында, олар үшін құралдар, сондықтан күрделі сынақ сценарийлерін орнату кезінде сізге көп жұмыс істеу керек болады. Дегенмен, жай ғана стекті ортада орналастыру және онда сынақтан өткізу өте арзан. Және бұлттық орталардың нақты жергілікті көшірмесін жасаудың қажеті жоқ.
Орналастырылған пакеттердің өлшемін азайту және жүктеп алуды жылдамдату үшін AWS Lambda Layers пайдаланыңыз.
Арнайы тапсырмалар үшін дұрыс бағдарламалау тілдерін пайдаланыңыз. Әртүрлі тілдердің өзіндік артықшылықтары мен кемшіліктері бар. Көптеген эталондар бар, бірақ JavaScript, Python және C# (.NET Core 2.1+) AWS Lambda өнімділігі бойынша көшбасшылар болып табылады. Жақында AWS Lambda Runtime API интерфейсін ұсынды, ол сізге қажетті тіл мен орындалу ортасын көрсетуге мүмкіндік береді, осылайша эксперимент жасаңыз.
Орналастыру үшін бума өлшемдерін кішкентай ұстаңыз. Олар неғұрлым аз болса, соғұрлым тезірек жүктеледі. Үлкен кітапханаларды пайдаланбаңыз, әсіресе олардың бірнеше мүмкіндіктерін пайдалансаңыз. JavaScript тілінде бағдарламалап жатсаңыз, құрастыруды оңтайландыру үшін Webpack сияқты құрастыру құралын пайдаланыңыз және шын мәнінде қажет нәрсені ғана қосыңыз. .NET Core 3.0 жүйесінде өнімділікті жақсартатын және суық іске қосу кезінде көп көмектесетін QuickJit және деңгейлі жинақ бар.
Серверсіз функциялардың оқиғаларға тәуелділігі бастапқыда бизнес логикасын үйлестіруді қиындатады. Осыған байланысты хабарламалар кезегі мен күй машиналары керемет пайдалы болуы мүмкін. Lambda функциялары бір-бірін шақыра алады, бірақ мұны жауап күтпесеңіз («өрт және ұмытыңыз») орындаңыз - басқа функцияның аяқталуын күткеніңіз үшін шот алғыңыз келмейді. Хабарламалар кезегі бизнес логикасының бөліктерін оқшаулау, қолданбаның кедергілерін басқару және транзакцияларды өңдеу (FIFO кезектерін пайдалану) үшін пайдалы. AWS Lambda функцияларын кейінірек талдау үшін сәтсіз хабарларды қадағалайтын тұрып қалған хабарлар кезегі ретінде SQS кезектеріне тағайындауға болады. AWS қадам функциялары (күй машиналары) функцияларды тізбектеуді қажет ететін күрделі процестерді басқару үшін өте пайдалы. Басқа функцияны шақыратын Lambda функциясының орнына қадамдық функциялар күй ауысуларын үйлестіре алады, функциялар арасында деректерді жібереді және функциялардың ғаламдық күйін басқарады. Бұл қайталау шарттарын анықтауға немесе белгілі бір қате орын алған кезде не істеу керектігін анықтауға мүмкіндік береді - белгілі бір жағдайларда өте қуатты құрал.
қорытынды
Соңғы жылдары серверсіз технологиялар бұрын-соңды болмаған қарқынмен дамып келеді. Бұл парадигманың ауысуына байланысты белгілі бір қате түсініктер бар. Инфрақұрылымды абстракциялау және басқаруды масштабтау арқылы серверсіз шешімдер оңайлатылған әзірлеу мен DevOps процестерінен операциялық шығындарды жаппай азайтуға дейін айтарлықтай артықшылықтар ұсынады.
Серверсіз тәсілдің кемшіліктері болмаса да, сенімді серверсіз қолданбаларды құру немесе серверсіз элементтерді бар архитектураларға біріктіру үшін пайдалануға болатын сенімді дизайн үлгілері бар.
Ақпарат көзі: www.habr.com