Сөрелерде серверсіз

Сөрелерде серверсіз
Серверсіз серверлердің физикалық болмауы туралы емес. Бұл контейнер өлтіру немесе өтіп бара жатқан тренд емес. Бұл бұлтта жүйелер құрудың жаңа тәсілі. Бүгінгі мақалада біз Серверсіз қолданбалардың архитектурасына тоқталамыз, Серверсіз қызмет провайдері мен ашық бастапқы жобалар қандай рөл атқаратынын көрейік. Соңында Serverless пайдалану мәселелеріне тоқталайық.

Мен қолданбаның сервер бөлігін (немесе тіпті интернет-дүкенді) жазғым келеді. Бұл чат, мазмұнды жариялау қызметі немесе жүктемені теңестіруші болуы мүмкін. Қалай болғанда да, көп бас ауруы болады: инфрақұрылымды дайындауға, қолданбалардың тәуелділіктерін анықтауға және хост операциялық жүйесі туралы ойлауға тура келеді. Содан кейін монолиттің қалған бөлігінің жұмысына әсер етпейтін шағын компоненттерді жаңарту қажет болады. Жүктеме астында масштабтау туралы ұмытпайық.

Қажетті тәуелділіктер алдын ала орнатылған және контейнерлердің өзі бір-бірінен және негізгі ОЖ-дан оқшауланған эфемерлі контейнерлерді алсақ ше? Монолитті микросервистерге бөлеміз, олардың әрқайсысы басқалардан тәуелсіз жаңартылып, масштабталады. Кодты осындай контейнерге орналастыру арқылы мен оны кез келген инфрақұрылымда іске қоса аламын. Енді жақсырақ.

Контейнерлерді конфигурациялағыңыз келмесе ше? Мен қолданбаны масштабтау туралы ойлағым келмейді. Қызметке жүктеме аз болған кезде бос тұрған контейнерлер үшін ақы төлегім келмейді. Мен код жазғым келеді. Бизнес логикасына назар аударыңыз және өнімді жарық жылдамдығымен нарыққа шығарыңыз.

Осындай ойлар мені серверсіз есептеулерге алып келді. Бұл жағдайда серверсіз дегенді білдіреді серверлердің физикалық болмауы емес, инфрақұрылымды басқарудың бас ауруларының болмауы.

Қолданба логикасы тәуелсіз функцияларға бөлінеді деген идея. Олардың оқиға құрылымы бар. Әрбір функция бір «микротапсырманы» орындайды. Әзірлеушіден талап етілетін нәрсе - бұлт провайдері ұсынған консольге функцияларды жүктеп, оларды оқиға көздерімен байланыстыру. Код автоматты түрде дайындалған контейнерде сұраныс бойынша орындалады, мен тек орындау уақыты үшін төлеймін.

Енді қолданбаларды әзірлеу процесі қалай болатынын көрейік.

Әзірлеуші ​​тарапынан

Бұрын біз интернет-дүкенге арналған өтінім туралы айта бастадық. Дәстүрлі тәсілде жүйенің негізгі логикасы монолитті қолданба арқылы орындалады. Ал қосымшасы бар сервер жүктеме болмаса да үздіксіз жұмыс істейді.

Серверсізге көшу үшін қолданбаны микротапсырмаларға бөлеміз. Олардың әрқайсысына өз функциямызды жазамыз. Функциялар бір-бірінен тәуелсіз және күй ақпаратын сақтамайды (азаматтығы жоқ). Олар тіпті әртүрлі тілдерде жазылуы мүмкін. Егер олардың біреуі «құлап кетсе», бүкіл қолданба тоқтамайды. Қолданбаның архитектурасы келесідей болады:

Сөрелерде серверсіз
Серверсіз функцияларға бөлу микросервистермен жұмыс істеуге ұқсас. Бірақ микросервис бірнеше тапсырманы орындай алады, ал функция біреуін орындауы керек. Тапсырма статистиканы жинау және пайдаланушының сұрауы бойынша көрсету екенін елестетіп көрейік. Микросервис тәсілінде тапсырма екі кіру нүктесі бар бір қызмет арқылы орындалады: жазу және оқу. Серверсіз есептеулерде бұл бір-бірімен байланысы жоқ екі түрлі функция болады. Әзірлеуші, мысалы, статистика жүктелгеннен гөрі жиі жаңартылатын болса, есептеу ресурстарын үнемдейді.

Серверсіз функциялар қызмет провайдері анықтайтын қысқа уақыт кезеңінде (тайм-аут) орындалуы керек. Мысалы, AWS үшін күту уақыты 15 минутты құрайды. Бұл ұзақ қызмет ететін функцияларды талаптарға сай өзгертуге тура келетінін білдіреді - бұл Serverless-ті басқа танымал технологиялардан (контейнерлер және қызмет ретінде платформа) ерекшелендіретін нәрсе.

Біз әрбір функцияға оқиға тағайындаймыз. Оқиға әрекеттің триггері болып табылады:

Оқиға
Функция орындайтын әрекет

Өнім суреті репозиторийге жүктеп салынды.
Кескінді сығып, каталогқа жүктеңіз

Дүкеннің физикалық мекенжайы дерекқорда жаңартылды
Карталарға жаңа орынды жүктеңіз

Клиент тауардың ақысын төлейді
Төлемді өңдеуді бастаңыз

Оқиғалар HTTP сұраулары, ағындық деректер, хабарламалар кезегі және т.б. болуы мүмкін. Оқиға көздері деректердің өзгерістері немесе пайда болуы болып табылады. Сонымен қатар, функциялар таймер арқылы іске қосылуы мүмкін.

Архитектура әзірленді және қолданба дерлік серверсіз болды. Әрі қарай біз қызмет провайдеріне барамыз.

Провайдер тарапынан

Әдетте, серверсіз есептеулерді бұлттық қызмет провайдерлері ұсынады. Олар басқаша аталады: Azure функциялары, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

Біз қызметті провайдердің консолі немесе жеке кабинеті арқылы қолданамыз. Функция кодын келесі жолдардың бірімен жүктеп алуға болады:

  • веб-консоль арқылы кірістірілген редакторларда код жазу,
  • мұрағатты кодпен жүктеп алыңыз,
  • жалпыға ортақ немесе жеке git репозиторийлерімен жұмыс істеу.

Мұнда функцияны шақыратын оқиғаларды орнатамыз. Оқиғалар жиыны әртүрлі провайдерлер үшін әр түрлі болуы мүмкін.

Сөрелерде серверсіз

Провайдер өзінің инфрақұрылымында Қызмет ретінде функция (FaaS) жүйесін құрды және автоматтандырды:

  1. Функция коды провайдер жағында сақтауда аяқталады.
  2. Оқиға орын алған кезде, дайындалған ортасы бар контейнерлер серверде автоматты түрде орналастырылады. Әрбір функция данасы өзінің оқшауланған контейнеріне ие.
  3. Сақтаудан функция контейнерге жіберіледі, есептеледі және нәтижені қайтарады.
  4. Параллельді оқиғалардың саны өсуде - контейнерлер саны артып келеді. Жүйе автоматты түрде масштабталады. Пайдаланушылар функцияға қол жеткізе алмаса, ол белсенді емес болады.
  5. Провайдер контейнерлердің бос тұру уақытын белгілейді - егер осы уақыт ішінде функциялар контейнерде пайда болмаса, ол жойылады.

Осылайша біз қораптан серверсіз аламыз. Біз қызмет үшін төлемді "қолданған сайын төлеу" үлгісін пайдаланып және тек пайдаланылған функциялар үшін және олар пайдаланылған уақыт үшін ғана төлейміз.

Әзірлеушілерді қызметпен таныстыру үшін провайдерлер 12 айға дейін тегін тестілеуді ұсынады, бірақ жалпы есептеу уақытын, айына сұраулар санын, қаражатты немесе қуат тұтынуды шектейді.

Провайдермен жұмыс істеудің басты артықшылығы - инфрақұрылым (серверлер, виртуалды машиналар, контейнерлер) туралы алаңдамау мүмкіндігі. Өз тарапынан провайдер FaaS-ті өзінің әзірлемелерімен де, ашық бастапқы құралдармен де енгізе алады. Олар туралы әрі қарай сөйлесейік.

Ашық дереккөз жағынан

Ашық коды бар қауымдастық соңғы екі жыл ішінде Серверсіз құралдармен белсенді жұмыс істеуде. Ең ірі нарық ойыншылары серверсіз платформаларды дамытуға үлес қосады:

  • Google әзірлеушілерге ашық бастапқы құралды ұсынады - Нативті. Оны әзірлеуге IBM, RedHat, Pivotal және SAP қатысты;
  • IBM серверсіз платформада жұмыс істеді OpenWhisk, содан кейін ол Apache қорының жобасы болды;
  • Microsoft платформа кодын ішінара ашты Azure функциялары.

Сондай-ақ серверсіз фреймворктар бағытында әзірлемелер жүргізілуде. Кубелес и Миссия алдын ала дайындалған Kubernetes кластерлерінің ішінде орналастырылған, OpenFaaS Kubernetes және Docker Swarm екеуімен де жұмыс істейді. Фреймворк контроллердің бір түрі ретінде әрекет етеді - сұраныс бойынша кластер ішінде орындалу ортасын дайындайды, содан кейін сол жерде функцияны іске қосады.

Жақтаулар сіздің қажеттіліктеріңізге сай құралды конфигурациялауға орын қалдырады. Сонымен, Kubeless бағдарламасында әзірлеуші ​​функцияның орындалу күту уақытын теңшей алады (әдепкі мән - 180 секунд). Бөліну, суық іске қосу мәселесін шешуге тырысып, кейбір контейнерлерді үнемі жұмыс істеп тұруды ұсынады (бірақ бұл ресурстардың тоқтап қалу шығындарын талап етеді). Және OpenFaaS кез келген дәм мен түс үшін триггерлер жиынтығын ұсынады: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs және т.б.

Жұмысты бастау нұсқауларын шеңберлердің ресми құжаттамасынан табуға болады. Олармен жұмыс істеу провайдермен жұмыс істеуге қарағанда біршама көбірек дағдыларды қажет етеді - бұл кем дегенде CLI арқылы Kubernetes кластерін іске қосу мүмкіндігі. Көбінесе басқа ашық бастапқы құралдарды қосыңыз (мысалы, Кафка кезек менеджері).

Провайдер арқылы немесе ашық бастапқы кодты пайдалану арқылы Serverless-пен қалай жұмыс істейтінімізге қарамастан, біз Серверсіз тәсілдің бірқатар артықшылықтары мен кемшіліктерін аламыз.

Артықшылықтары мен кемшіліктері тұрғысынан

Серверсіз командалар бір платформаға байланыссыз көптілді режимде жұмыс істей алатын контейнерлік инфрақұрылым мен микросервис тәсілінің идеяларын әзірлейді. Жүйені құру жеңілдетілген және қателерді түзету оңайырақ. Микросервис архитектурасы жүйеге жаңа функционалдылықты монолитті қолданбаға қарағанда әлдеқайда жылдам қосуға мүмкіндік береді.

Серверсіз әзірлеу уақытын одан әрі қысқартады, әзірлеушіге тек қолданбаның бизнес логикасына және кодтауға назар аударуға мүмкіндік береді. Нәтижесінде әзірлемелерді нарыққа шығару уақыты қысқарады.

Бонус ретінде біз жүктемені автоматты түрде масштабтауды аламыз, және біз тек пайдаланылған ресурстар үшін және олар пайдаланылған уақытта ғана төлейміз.

Кез келген технология сияқты, серверсіздің де кемшіліктері бар.

Мысалы, мұндай кемшілік суық басталу уақыты болуы мүмкін (JavaScript, Python, Go, Java, Ruby сияқты тілдер үшін орта есеппен 1 ​​секундқа дейін).

Бір жағынан, шын мәнінде, суық іске қосу уақыты көптеген айнымалыларға байланысты: функция жазылған тіл, кітапханалар саны, код саны, қосымша ресурстармен байланыс (бірдей дерекқорлар немесе аутентификация серверлері). Әзірлеуші ​​осы айнымалы мәндерді басқаратындықтан, ол іске қосу уақытын қысқарта алады. Бірақ екінші жағынан, әзірлеуші ​​контейнердің іске қосылу уақытын басқара алмайды - бәрі провайдерге байланысты.

Функция алдыңғы оқиға арқылы іске қосылған контейнерді қайта пайдаланған кезде, суық бастау жылы бастауға айналуы мүмкін. Бұл жағдай үш жағдайда пайда болады:

  • егер клиенттер қызметті жиі пайдаланса және функцияға қоңыраулар саны көбейсе;
  • егер провайдер, платформа немесе құрылым кейбір контейнерлерді үнемі жұмыс істеп тұруға мүмкіндік берсе;
  • егер әзірлеуші ​​функцияларды таймерде іске қосса (әр 3 минут сайын айтамыз).

Көптеген қолданбалар үшін суық бастау проблема емес. Мұнда қызмет түрі мен міндеттеріне негізделу керек. Іске қосудың бір секундтық кешігуі бизнес қолданбасы үшін әрқашан маңызды емес, бірақ ол медициналық қызметтер үшін маңызды болуы мүмкін. Бұл жағдайда серверсіз тәсіл енді жарамсыз болуы мүмкін.

Серверсіздің келесі кемшілігі - функцияның қысқа қызмет ету мерзімі (функция орындалуы керек күту уақыты).

Бірақ, егер сізге ұзақ мерзімді тапсырмалармен жұмыс істеу керек болса, гибридті архитектураны пайдалануға болады - Serverless басқа технологиямен біріктіріңіз.

Барлық жүйелер Серверсіз схеманы пайдаланып жұмыс істей алмайды.

Кейбір қолданбалар орындалу кезінде деректерді және күйді сақтайды. Кейбір архитектуралар монолитті болып қалады, ал кейбір ерекшеліктері ұзақ өмір сүреді. Дегенмен (бұлтты технологиялар, содан кейін контейнерлер сияқты), серверсіз - болашағы зор технология.

Осыған байланысты мен Серверсіз тәсілді пайдалану мәселесіне біртіндеп көшкім келеді.

Қолданба жағынан

2018 жылға серверсіз пайдалану пайызы бір жарым есе өсті. Технологияны өз қызметтеріне енгізген компаниялардың арасында Twitter, PayPal, Netflix, T-Mobile, Coca-Cola сияқты нарық алпауыттары бар. Сонымен қатар, сіз Serverless панацея емес, белгілі бір мәселелер ауқымын шешу құралы екенін түсінуіңіз керек:

  • Ресурстардың тоқтап қалу уақытын қысқарту. Қоңыраулар аз болатын қызметтер үшін виртуалды машинаны үнемі ұстаудың қажеті жоқ.
  • Деректерді жылдам өңдеу. Суреттерді қысыңыз, фонды кесіңіз, бейне кодтауын өзгертіңіз, IoT сенсорларымен жұмыс жасаңыз, математикалық операцияларды орындаңыз.
  • Басқа қызметтерді бірге «жабыңыз». Ішкі бағдарламалары бар Git репозиторийі, Jira және күнтізбемен Slack-тегі чат боты.
  • Жүктемені теңестіріңіз. Мұнда толығырақ қарастырайық.

50 адамды тартатын қызмет бар делік. Оның астында аппараттық құралдары әлсіз виртуалды машина орналасқан. Уақыт өте келе қызметке жүктеме айтарлықтай артады. Содан кейін әлсіз аппараттық құрал жеңе алмайды.

Жүйеге жүктемені, мысалы, үш виртуалды машинаға тарататын теңгерімді қосуға болады. Бұл кезеңде біз жүктемені дәл болжай алмаймыз, сондықтан біз белгілі бір көлемдегі ресурстарды «резервте» ұстаймыз. Ал біз тоқтап қалған уақыт үшін артық төлейміз.

Мұндай жағдайда біз жүйені гибридті тәсіл арқылы оңтайландыра аламыз: біз бір виртуалды машинаны жүктемені теңестірудің артында қалдырамыз және функциялары бар Serverless Endpoint сілтемесін қоямыз. Егер жүктеме шекті мәннен асып кетсе, теңгерімдеуші сұрауды өңдеудің бір бөлігін қабылдайтын функция даналарын іске қосады.

Сөрелерде серверсіз
Осылайша, серверсіз көп сұраныстарды жиі емес, қарқынды өңдеу қажет болған жағдайда қолдануға болады. Бұл жағдайда 15 минут бойы бірнеше функцияларды іске қосу виртуалды машинаны немесе серверді үнемі ұстап тұрудан гөрі тиімдірек.

Серверсіз есептеудің барлық артықшылықтарымен іске асырмас бұрын, сіз алдымен қолданба логикасын бағалап, белгілі бір жағдайда серверсіз қандай мәселелерді шеше алатынын түсінуіңіз керек.

Серверсіз және таңдаулы

Selectel-де біз қазірдің өзінде бармыз Кубернетеспен жеңілдетілген жұмыс басқару тақтасы арқылы. Қазір біз жеке FaaS платформасын жасап жатырмыз. Біз әзірлеушілерге ыңғайлы, икемді интерфейс арқылы серверсіз пайдалану арқылы өз мәселелерін шеше алуын қалаймыз.

Егер сізде идеалды FaaS платформасы қандай болуы керек және өз жобаларыңызда серверсіз қалай пайдаланғыңыз келетіні туралы идеяларыңыз болса, оларды түсініктемелерде бөлісіңіз. Платформаны әзірлеу кезінде біз сіздің тілектеріңізді ескереміз.
 
Мақалада пайдаланылған материалдар:

Ақпарат көзі: www.habr.com

пікір қалдыру