Серверсиз серверлердин физикалык жоктугу жөнүндө эмес. Бул контейнер өлтүргүч же өтүүчү тенденция эмес. Бул булуттагы системаларды куруунун жаңы ыкмасы. Бүгүнкү макалада биз Serverless тиркемелеринин архитектурасына токтолобуз, келгиле, Serverless тейлөө провайдери жана ачык булак долбоорлору кандай роль ойноорун карап көрөлү. Акырында, келгиле, Serverless колдонуу маселелери жөнүндө сүйлөшөлү.
Мен тиркеменин сервер бөлүгүн жазгым келет (же онлайн дүкөн). Бул чат, мазмунду жарыялоо кызматы же жүк балансы болушу мүмкүн. Кандай болгон күндө да, баш оору көп болот: сиз инфраструктураны даярдап, тиркемелердин көз карандылыгын аныктап, хосттун операциялык системасы жөнүндө ойлонушуңуз керек. Андан кийин сиз монолиттин калган бөлүгүнүн иштешине таасирин тийгизбеген кичинекей компоненттерди жаңыртышыңыз керек. Ооба, жүк астында масштабдоо жөнүндө унутпашыбыз керек.
Эгер талап кылынган көз карандылыктар алдын ала орнотулган жана контейнерлердин өздөрү бири-биринен жана хост ОСтен обочолонгон эфемердик контейнерлерди алсакчы? Монолитти микросервистерге бөлөбүз, алардын ар бири башкалардан көз карандысыз жаңыртылып, масштабдалат. Кодду ушундай контейнерге жайгаштыруу менен мен аны каалаган инфраструктурада иштете алам. Ансыз деле жакшыраак.
Эгер контейнерлерди конфигурациялагыңыз келбесечи? Мен колдонмону масштабдоо жөнүндө ойлонгум келбейт. Кызматтагы жүк минималдуу болгондо, бош турган контейнерлер үчүн төлөгүм келбейт. Мен код жазгым келет. Бизнес логикасына көңүл буруңуз жана өнүмдөрдү жарык ылдамдыгы менен базарга чыгарыңыз.
Мындай ойлор мени серверсиз эсептөөлөргө алып келди. Бул учурда серверсиз дегенди билдирет серверлердин физикалык жоктугу эмес, инфраструктураны башкаруунун баш оорусунун жоктугу.
Колдонмо логикасы көз карандысыз функцияларга бөлүнөт деген идея. Алар окуянын структурасына ээ. Ар бир функция бир "микро тапшырманы" аткарат. Иштеп чыгуучудан талап кылынган нерсе бул булут провайдери тарабынан берилген консолго функцияларды жүктөө жана аларды окуя булактары менен байланыштыруу. Код автоматтык түрдө даярдалган контейнерде талап боюнча аткарылат жана мен аткаруу убактысы үчүн гана төлөйм.
Эми колдонмону иштеп чыгуу процесси кандай болорун карап көрөлү.
Иштеп чыгуучу тараптан
Буга чейин биз интернет-дүкөн үчүн арыз жөнүндө сөз баштады. Салттуу мамиледе системанын негизги логикасы монолиттүү тиркеме аркылуу аткарылат. Ал эми тиркеме менен сервер жүк болбосо да, тынымсыз иштеп турат.
Серверсиз режимге өтүү үчүн биз тиркемени микротапшырмаларга бөлөбүз. Алардын ар бири үчүн өзүбүздүн функциябызды жазабыз. Функциялар бири-биринен көз карандысыз жана мамлекеттик маалыматты сактабайт (жарандыгы жок). Алар ар кандай тилдерде да жазылган болушу мүмкүн. Эгерде алардын бири "түшүп кетсе", бүтүндөй тиркеме токтоп калбайт. Колдонмонун архитектурасы төмөнкүдөй болот:
Serverless'те функцияларга бөлүнүү микросервистер менен иштөөгө окшош. Бирок микросервис бир нече тапшырмаларды аткара алат жана функция эң идеалдуу түрдө бирин аткарышы керек. Келгиле, тапшырма статистиканы чогултуу жана колдонуучунун талабы боюнча аларды көрсөтүү экенин элестетип көрөлү. Микросервис мамилесинде тапшырма эки кирүү пункту бар бир кызмат тарабынан аткарылат: жазуу жана окуу. Серверсиз эсептөөдө булар бири-бирине байланышпаган эки башка функция болот. Иштеп чыгуучу эсептөө ресурстарын үнөмдөйт, эгерде, мисалы, статистика жүктөлүп алынгандан көбүрөөк жаңыланып турса.
Серверсиз функциялар кызмат көрсөтүүчү тарабынан аныкталуучу кыска мөөнөттө (тайм-аут) аткарылышы керек. Мисалы, AWS үчүн күтүү 15 мүнөт. Бул узак мөөнөттүү функцияларды талаптарга ылайык өзгөртүүгө туура келет дегенди билдирет - Serverlessти бүгүнкү күндө башка популярдуу технологиялардан айырмалап турган нерсе (контейнерлер жана Платформа Кызмат катары).
Ар бир функцияга бир окуяны дайындайбыз. Окуя иш-аракет үчүн триггер болуп саналат:
окуя
Функция аткарган иш-аракет
Продукциянын сүрөтү репозиторийге жүктөлдү.
Сүрөттү кысып, каталогго жүктөңүз
Дүкөндүн физикалык дареги маалымат базасында жаңыртылды
Карталарга жаңы жерди жүктөңүз
Кардар товардын акысын төлөйт
Төлөмдү иштетүүнү баштаңыз
Окуялар HTTP суроо-талаптары, агымдык маалыматтар, билдирүү кезектери жана башкалар болушу мүмкүн. Окуя булактары - бул маалыматтардын өзгөрүшү же пайда болушу. Мындан тышкары, функциялар таймер аркылуу ишке ашырылышы мүмкүн.
Архитектура иштелип чыгып, колдонмо дээрлик серверсиз болуп калды. Андан кийин биз кызмат көрсөтүүчүгө барабыз.
Провайдер тараптан
Адатта, серверсиз эсептөө булут кызмат көрсөтүүчүлөрү тарабынан сунушталат. Алар башкача аталат: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Биз кызматты провайдердин консолу же жеке аккаунту аркылуу колдонобуз. Функциянын кодун төмөнкү жолдордун бири менен жүктөп алса болот:
- веб консолу аркылуу камтылган редакторлордо код жазуу,
- код менен архивди жүктөп алуу,
- коомдук же жеке git репозиторийлери менен иштөө.
Бул жерде биз функцияны чакырган окуяларды орнотобуз. Окуялардын топтому ар кандай камсыздоочулар үчүн ар кандай болушу мүмкүн.
Провайдер өзүнүн инфраструктурасында Function as a Service (FaaS) тутумун курган жана автоматташтырган:
- Функциянын коду провайдер тарабында сактагычта аяктайт.
- Окуя болгондо, даярдалган чөйрөсү бар контейнерлер серверде автоматтык түрдө жайгаштырылат. Ар бир функция инстанциясынын өзүнүн изоляцияланган контейнери бар.
- Сактагычтан функция контейнерге жөнөтүлүп, эсептелинет жана натыйжаны кайтарат.
- Параллель окуялардын саны өсүүдө – контейнерлердин саны өсүүдө. Система автоматтык түрдө масштабдалат. Эгер колдонуучулар функцияга кирбесе, ал жигердүү эмес болот.
- Провайдер контейнерлердин бош туруу убактысын белгилейт - эгерде бул убакыттын ичинде функциялар контейнерде пайда болбосо, ал жок кылынат.
Ошентип, биз кутудан Serverless чыгарабыз. Биз кызмат үчүн акы төлөө моделин колдонуу менен жана колдонулган функциялар үчүн жана алар колдонулган убакыт үчүн гана төлөйбүз.
Иштеп чыгуучуларды кызмат менен тааныштыруу үчүн провайдерлер 12 айга чейин акысыз тестирлөөнү сунушташат, бирок жалпы эсептөө убактысын, айына суроо-талаптардын санын, каражаттарды же энергия керектөөнү чектешет.
Провайдер менен иштөөнүн негизги артыкчылыгы - инфраструктура (серверлер, виртуалдык машиналар, контейнерлер) жөнүндө кабатырланбоо мүмкүнчүлүгү. Өз кезегинде, провайдер FaaSди өзүнүн иштеп чыгууларын жана ачык булак куралдарын колдонуу менен ишке ашыра алат. Келгиле, алар жөнүндө кененирээк сүйлөшөлү.
Ачык булак тараптан
Ачык булак коомчулугу акыркы эки жылдан бери Serverless куралдарында жигердүү иштеп жатат. Рыноктун эң ири оюнчулары серверсиз платформаларды өнүктүрүүгө салым кошушат:
- Гугл иштеп чыгуучуларга анын ачык булак куралын сунуш кылат - . Аны иштеп чыгууга IBM, RedHat, Pivotal жана SAP катышты;
- IBM Serverless платформасында иштеген , андан кийин Apache Фондунун долбоору болуп калды;
- Microsoft жарым-жартылай платформа кодун ачты .
Иштеп чыгуулар серверсиз алкактар багытында да жүрүп жатат. и алдын ала даярдалган Kubernetes кластерлеринин ичинде жайгаштырылган, Kubernetes жана Docker Swarm менен иштейт. Алкак контроллердин бир түрү катары иштейт - суроо-талап боюнча, ал кластердин ичинде иштөө чөйрөсүн даярдайт, андан кийин ал жерде функцияны ишке киргизет.
Алкактар сиздин муктаждыктарыңызга ылайыктуу куралды конфигурациялоо үчүн орун калтырат. Ошентип, Kubelessте иштеп чыгуучу функциянын аткарылышынын күтүү убактысын конфигурациялай алат (демейки маани - 180 секунд). Бөлүнүү, муздак баштоо көйгөйүн чечүү аракети менен, кээ бир контейнерлерди дайыма иштеп турууну сунуштайт (бирок бул ресурстардын токтоп калуу чыгымдарын талап кылат). Жана OpenFaaS ар кандай табит жана түс үчүн триггерлердин топтомун сунуштайт: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs жана башкалар.
Баштоо боюнча нускамаларды алкактардын расмий документтеринен тапса болот. Алар менен иштөө провайдер менен иштөөгө караганда бир аз көбүрөөк көндүмдөрдү талап кылат - бул жок дегенде CLI аркылуу Kubernetes кластерин ишке киргизүү мүмкүнчүлүгү. Көпчүлүк учурда, башка ачык булак куралдарын (мисалы, Кафка кезектеги менеджери) кошуңуз.
Биз Serverless менен кантип иштешкенибизге карабастан - провайдер аркылуу же ачык булак аркылуу, биз Serverless мамиленин бир катар артыкчылыктарын жана кемчиликтерин алабыз.
Артыкчылыктары жана кемчиликтери жагынан
Serverless контейнер инфраструктурасынын идеяларын жана микросервис ыкмасын иштеп чыгат, мында командалар бир платформага байланбастан көп тилдүү режимде иштей алат. Системаны куруу жөнөкөйлөштүрүлүп, каталарды оңдоо оңой. Микросервис архитектурасы тутумга жаңы функцияларды монолиттүү тиркемеге караганда тезирээк кошууга мүмкүндүк берет.
Serverless иштеп чыгуу убактысын дагы кыскартат, иштеп чыгуучуга колдонмонун бизнес логикасына жана коддоосуна гана көңүл бурууга мүмкүндүк берет. Натыйжада, иштеп чыгуулар үчүн рынокко убакыт кыскарат.
Бонус катары биз жүктөө үчүн автоматтык масштабды алабыз, жана биз пайдаланылган ресурстар үчүн жана алар колдонулган учурда гана төлөйбүз.
Бардык технологиялар сыяктуу эле, Serverless кемчиликтери бар.
Мисалы, мындай кемчилик муздак баштоо убактысы болушу мүмкүн (JavaScript, Python, Go, Java, Ruby сыяктуу тилдер үчүн орточо 1 секундага чейин).
Бир жагынан, чындыгында, муздак баштоо убактысы көптөгөн өзгөрмөлөргө көз каранды: функция жазылган тил, китепканалардын саны, коддун көлөмү, кошумча ресурстар менен байланыш (ошол эле маалымат базалары же аутентификация серверлери). Иштеп чыгуучу бул өзгөрмөлөрдү башкаргандыктан, ал ишке киргизүү убактысын кыскарта алат. Бирок, экинчи жагынан, иштеп чыгуучу контейнердин ишке киргизүү убактысын көзөмөлдөй албайт - бардыгы провайдерден көз каранды.
Функция мурунку окуя тарабынан ишке киргизилген контейнерди кайра колдонгондо муздак башталгыч жылуу башталышка айланышы мүмкүн. Бул жагдай үч учурда пайда болот:
- эгерде кардарлар кызматты көп колдонсо жана функцияга чалуулар көбөйсө;
- эгерде провайдер, платформа же алкак кээ бир контейнерлерди дайыма иштеп турууга мүмкүндүк берсе;
- эгерде иштеп чыгуучу функцияларды таймерде иштетсе (ар бир 3 мүнөт сайын айталы).
Көптөгөн колдонмолор үчүн муздак баштоо көйгөй эмес. Бул жерде сиз кызматтын түрүн жана милдеттерин куруу керек. Иштин башталышы үчүн бир секундага кечигүү дайыма эле маанилүү эмес, бирок медициналык кызматтар үчүн маанилүү болуп калышы мүмкүн. Бул учурда, серверсиз ыкма мындан ары ылайыктуу болбой калат.
Серверсиздин кийинки кемчилиги функциянын кыска иштөө мөөнөтү (функция аткарылышы керек болгон тайм-аут).
Бирок, эгер сиз узак мөөнөттүү тапшырмалар менен иштешиңиз керек болсо, анда гибрид архитектурасын колдоно аласыз - Serverless башка технология менен айкалыштыруу.
Бардык системалар Serverless схемасын колдонуу менен иштей албайт.
Кээ бир колдонмолор дагы эле дайындарды жана аткаруу учурунда абалын сактайт. Кээ бир архитектуралар монолиттүү бойдон калат, ал эми кээ бир өзгөчөлүктөрү көпкө жашайт. Бирок (булут технологиялары жана андан кийин контейнерлер сыяктуу), Serverless - бул чоң келечеги бар технология.
Бул жагынан мен Серверсиз ыкманы колдонуу маселесине акырындык менен өткүм келет.
Колдонмо тараптан
2018-жылы Serverless колдонуу пайызы . Технологияны өз кызматтарына киргизген компаниялардын арасында Twitter, PayPal, Netflix, T-Mobile, Coca-Cola сыяктуу рыноктун гиганттары бар. Ошол эле учурда, сиз Serverless панацея эмес экенин түшүнүү керек, бирок көйгөйлөрдүн белгилүү бир спектрин чечүү үчүн курал:
- Ресурстардын токтоп калуу убактысын кыскартуу. Чалуулар аз болгон кызматтар үчүн виртуалдык машинаны тынымсыз кармоонун кажети жок.
- Маалыматты ылдам иштетүү. Сүрөттөрдү кысуу, фондорду кесип, видео коддоону өзгөртүү, IoT сенсорлору менен иштөө, математикалык операцияларды аткаруу.
- Башка кызматтарды чогуу "клей". Ички программалары бар Git репозиторийси, Jira жана календары менен Slack'теги чат боту.
- Жүктү тең салмакта. Келгиле, бул жерде кененирээк карап көрөлү.
50 адамды тарта турган кызмат бар дейли. Анын астында начар жабдыктары бар виртуалдык машина бар. Мезгил-мезгили менен кызмат жүктөө кыйла көбөйөт. Ошондо алсыз аппараттык туруштук бере албайт.
Сиз системага жүктү, айталы, үч виртуалдык машинага бөлүштүрө турган баланстоочуну кошо аласыз. Бул этапта биз жүктү так алдын ала айта албайбыз, ошондуктан биз ресурстардын белгилүү бир көлөмүн "запаста" иштетебиз. Ал эми токтоп калгандар үчүн ашыкча төлөйбүз.
Мындай кырдаалда биз системаны гибриддик ыкма аркылуу оптималдаштырсак болот: биз бир виртуалдык машинаны жүк балансынын артына калтырабыз жана функциялары менен Serverless Endpoint'ке шилтеме коёбуз. Эгер жүк босогодон ашып кетсе, баланстоочу суроо-талапты иштетүүнүн бир бөлүгүн алган функция инстанцияларын ишке киргизет.
Ошентип, Serverless көп сандагы суроо-талаптарды тез-тез эмес, интенсивдүү иштеп чыгуу зарыл болгон жерде колдонулушу мүмкүн. Бул учурда виртуалдык машинаны же серверди дайыма кармап турууга караганда 15 мүнөттө бир нече функцияларды иштетүү пайдалуураак.
Серверсиз эсептөөнүн бардык артыкчылыктары менен, ишке ашыруудан мурун, адегенде колдонмонун логикасына баа берүү жана белгилүү бир учурда Serverless кандай көйгөйлөрдү чече аларын түшүнүү керек.
Серверсиз жана тандалган
Selectelде биз буга чейин барбыз биздин башкаруу панели аркылуу. Азыр биз өзүбүздүн FaaS платформабызды куруп жатабыз. Биз иштеп чыгуучулар ыңгайлуу, ийкемдүү интерфейс аркылуу Serverless аркылуу өз көйгөйлөрүн чече алышын каалайбыз.
Эгерде сизде идеалдуу FaaS платформасы кандай болушу керектиги жана долбоорлоруңузда Serverless кантип колдонууну кааласаңыз, аларды комментарийлерде бөлүшүңүз. Платформаны иштеп чыгууда биз сиздин каалооңузду эске алабыз.
Макалада колдонулган материалдар:
Source: www.habr.com