Ang serverless ay hindi tungkol sa pisikal na kawalan ng mga server. Ito ay hindi isang container killer o isang passing trend. Ito ay isang bagong diskarte sa pagbuo ng mga system sa cloud. Sa artikulong ngayon ay hipuin natin ang arkitektura ng mga Serverless na application, tingnan natin kung ano ang papel na ginagampanan ng Serverless service provider at mga open-source na proyekto. Panghuli, pag-usapan natin ang mga isyu sa paggamit ng Serverless.
Gusto kong magsulat ng isang bahagi ng server ng isang application (o kahit isang online na tindahan). Maaaring ito ay isang chat, isang serbisyo sa pag-publish ng nilalaman, o isang balanse ng pagkarga. Sa anumang kaso, magkakaroon ng maraming sakit ng ulo: kakailanganin mong ihanda ang imprastraktura, tukuyin ang mga dependency ng application, at isipin ang tungkol sa host operating system. Pagkatapos ay kakailanganin mong i-update ang mga maliliit na bahagi na hindi nakakaapekto sa pagpapatakbo ng natitirang bahagi ng monolith. Well, huwag nating kalimutan ang tungkol sa pag-scale sa ilalim ng pagkarga.
Paano kung kukuha tayo ng mga ephemeral na lalagyan, kung saan ang mga kinakailangang dependency ay paunang naka-install, at ang mga lalagyan mismo ay nakahiwalay sa isa't isa at sa host OS? Hahatiin namin ang monolith sa mga microservice, na ang bawat isa ay maaaring i-update at i-scale nang hiwalay sa iba. Sa pamamagitan ng paglalagay ng code sa naturang lalagyan, maaari ko itong patakbuhin sa anumang imprastraktura. Mas maganda na.
Paano kung ayaw mong mag-configure ng mga container? Hindi ko gustong isipin ang tungkol sa pag-scale ng application. Hindi ko gustong magbayad para sa mga idle running container kapag minimal ang load sa serbisyo. Gusto kong magsulat ng code. Tumutok sa lohika ng negosyo at dalhin ang mga produkto sa merkado sa bilis ng liwanag.
Ang ganitong mga pag-iisip ay humantong sa akin sa serverless computing. Serverless sa kasong ito ay nangangahulugan hindi ang pisikal na kawalan ng mga server, ngunit ang kawalan ng pananakit ng ulo sa pamamahala ng imprastraktura.
Ang ideya ay ang lohika ng aplikasyon ay pinaghiwa-hiwalay sa mga independiyenteng pag-andar. Mayroon silang istraktura ng kaganapan. Ang bawat function ay gumaganap ng isang "microtask". Ang kailangan lang mula sa developer ay i-load ang mga function sa console na ibinigay ng cloud provider at iugnay ang mga ito sa mga source ng event. Ang code ay isasagawa kapag hinihiling sa isang awtomatikong inihanda na lalagyan, at babayaran ko lang ang oras ng pagpapatupad.
Tingnan natin kung ano ang magiging hitsura ng proseso ng pagbuo ng application ngayon.
Mula sa panig ng developer
Kanina nagsimula kaming mag-usap tungkol sa isang application para sa isang online na tindahan. Sa tradisyonal na diskarte, ang pangunahing lohika ng system ay ginagampanan ng isang monolitikong aplikasyon. At ang server na may application ay patuloy na tumatakbo, kahit na walang load.
Upang lumipat sa walang server, hinahati namin ang application sa mga microtasks. Sinusulat namin ang aming sariling function para sa bawat isa sa kanila. Ang mga function ay independiyente sa bawat isa at hindi nag-iimbak ng impormasyon ng estado (stateless). Maaari pa nga silang isulat sa iba't ibang wika. Kung ang isa sa kanila ay "bumagsak", ang buong aplikasyon ay hindi titigil. Ang arkitektura ng application ay magiging ganito:
Ang paghahati sa mga function sa Serverless ay katulad ng pagtatrabaho sa mga microservice. Ngunit ang isang microservice ay maaaring magsagawa ng ilang mga gawain, at ang isang function ay dapat na perpektong gumanap ng isa. Isipin natin na ang gawain ay upang mangolekta ng mga istatistika at ipakita ang mga ito sa kahilingan ng gumagamit. Sa microservice approach, ang isang gawain ay ginagawa ng isang serbisyo na may dalawang entry point: pagsusulat at pagbabasa. Sa serverless computing, ito ay dalawang magkaibang function na hindi nauugnay sa isa't isa. Ang nag-develop ay nagse-save ng mga mapagkukunan sa pag-compute kung, halimbawa, ang mga istatistika ay ina-update nang mas madalas kaysa sa na-download ang mga ito.
Ang mga function na walang server ay dapat isagawa sa maikling panahon (timeout), na tinutukoy ng service provider. Halimbawa, para sa AWS ang timeout ay 15 minuto. Nangangahulugan ito na ang mga pangmatagalang pag-andar ay kailangang baguhin upang umangkop sa mga kinakailangan - ito ang pinagkaiba ng Serverless mula sa iba pang mga sikat na teknolohiya ngayon (mga lalagyan at Platform bilang isang Serbisyo).
Nagtatalaga kami ng isang kaganapan sa bawat function. Ang isang kaganapan ay isang trigger para sa isang aksyon:
Kaganapan
Ang aksyon na ginagawa ng function
Isang larawan ng produkto ang na-upload sa repositoryo.
I-compress ang larawan at i-upload sa isang direktoryo
Ang address ng pisikal na tindahan ay na-update sa database
Mag-load ng bagong lokasyon sa mga mapa
Nagbabayad ang kliyente para sa mga kalakal
Simulan ang pagproseso ng pagbabayad
Ang mga kaganapan ay maaaring mga kahilingan sa HTTP, streaming ng data, pila ng mensahe, at iba pa. Ang mga pinagmulan ng kaganapan ay mga pagbabago o paglitaw ng data. Bilang karagdagan, ang mga function ay maaaring ma-trigger ng isang timer.
Ang arkitektura ay ginawa, at ang application ay halos naging walang server. Susunod na pumunta kami sa service provider.
Mula sa panig ng provider
Karaniwan, ang serverless computing ay inaalok ng mga cloud service provider. Iba ang tawag sa kanila: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Gagamitin namin ang serbisyo sa pamamagitan ng console o personal na account ng provider. Maaaring ma-download ang function code sa isa sa mga sumusunod na paraan:
- magsulat ng code sa mga built-in na editor sa pamamagitan ng web console,
- i-download ang archive na may code,
- gumana sa mga pampubliko o pribadong git repository.
Dito namin ise-set up ang mga kaganapan na tumatawag sa function. Maaaring magkaiba ang mga hanay ng mga kaganapan para sa iba't ibang provider.
Ang provider ay bumuo at nag-automate ng Function as a Service (FaaS) system sa imprastraktura nito:
- Ang code ng function ay napupunta sa storage sa panig ng provider.
- Kapag naganap ang isang kaganapan, ang mga lalagyan na may nakahanda na kapaligiran ay awtomatikong nade-deploy sa server. Ang bawat instance ng function ay may sariling nakahiwalay na lalagyan.
- Mula sa storage, ipinapadala ang function sa container, kinakalkula, at ibinabalik ang resulta.
- Ang bilang ng mga magkakatulad na kaganapan ay lumalaki - ang bilang ng mga lalagyan ay lumalaki. Awtomatikong nag-i-scale ang system. Kung hindi ma-access ng mga user ang function, ito ay magiging hindi aktibo.
- Ang provider ay nagtatakda ng idle time para sa mga container - kung sa panahong ito ay hindi lilitaw ang mga function sa container, ito ay masisira.
Sa paraang ito mailalabas namin ang Serverless. Magbabayad kami para sa serbisyo gamit ang modelong pay-as-you-go at para lamang sa mga function na ginagamit, at para lamang sa oras kung kailan ginamit ang mga ito.
Upang ipakilala ang mga developer sa serbisyo, nag-aalok ang mga provider ng hanggang 12 buwan ng libreng pagsubok, ngunit nililimitahan ang kabuuang oras ng pag-compute, bilang ng mga kahilingan bawat buwan, mga pondo o paggamit ng kuryente.
Ang pangunahing bentahe ng pakikipagtulungan sa isang provider ay ang kakayahang huwag mag-alala tungkol sa imprastraktura (server, virtual machine, container). Sa bahagi nito, maaaring ipatupad ng provider ang FaaS gamit ang sarili nitong mga pag-unlad at paggamit ng mga open-source na tool. Pag-usapan pa natin sila.
Mula sa open source side
Ang open-source na komunidad ay aktibong nagtatrabaho sa mga tool na Walang Server sa nakalipas na ilang taon. Ang pinakamalaking manlalaro sa merkado ay nag-aambag din sa pagbuo ng mga platform na walang server:
- Google nag-aalok sa mga developer ng open-source na tool nito - . Lumahok ang IBM, RedHat, Pivotal at SAP sa pagpapaunlad nito;
- IBM nagtrabaho sa isang Serverless platform , na naging proyekto ng Apache Foundation;
- microsoft bahagyang binuksan ang platform code .
Ang mga pag-unlad ay isinasagawa din sa direksyon ng walang server na mga balangkas. и naka-deploy sa loob ng mga pre-prepared na Kubernetes cluster, gumagana sa parehong Kubernetes at Docker Swarm. Ang balangkas ay gumaganap bilang isang uri ng controller - kapag hiniling, naghahanda ito ng runtime na kapaligiran sa loob ng cluster, pagkatapos ay naglulunsad ng isang function doon.
Ang mga framework ay nag-iiwan ng puwang para sa pag-configure ng tool upang umangkop sa iyong mga pangangailangan. Kaya, sa Kubeless, maaaring i-configure ng developer ang timeout ng pagpapatupad ng function (ang default na halaga ay 180 segundo). Ang Fission, sa pagtatangkang lutasin ang malamig na problema sa pagsisimula, ay nagmumungkahi na panatilihing tumatakbo ang ilang lalagyan sa lahat ng oras (bagama't nangangailangan ito ng mga gastos sa downtime ng mapagkukunan). At nag-aalok ang OpenFaaS ng isang set ng mga trigger para sa bawat panlasa at kulay: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT at iba pa.
Ang mga tagubilin para sa pagsisimula ay makikita sa opisyal na dokumentasyon ng mga balangkas. Ang pakikipagtulungan sa kanila ay nangangailangan ng pagkakaroon ng kaunting mga kasanayan kaysa kapag nagtatrabaho sa isang provider - ito ay hindi bababa sa kakayahang maglunsad ng isang Kubernetes cluster sa pamamagitan ng CLI. Sa karamihan, isama ang iba pang mga open-source na tool (halimbawa, ang Kafka queue manager).
Hindi alintana kung paano kami nagtatrabaho sa Serverless - sa pamamagitan ng isang provider o paggamit ng open-source, makakatanggap kami ng ilang mga pakinabang at disadvantages ng Serverless na diskarte.
Mula sa punto ng view ng mga pakinabang at disadvantages
Binubuo ng Serverless ang mga ideya ng isang imprastraktura ng container at isang diskarte sa microservice, kung saan maaaring magtrabaho ang mga team sa isang multilinggwal na mode nang hindi nakatali sa isang platform. Ang pagbuo ng isang sistema ay pinasimple at ang mga error ay mas madaling itama. Binibigyang-daan ka ng arkitektura ng microservice na magdagdag ng bagong functionality sa system nang mas mabilis kaysa sa kaso ng monolitikong aplikasyon.
Ang walang server ay nagpapababa pa ng oras ng pag-unlad, na nagbibigay-daan sa developer na tumuon lamang sa lohika at coding ng negosyo ng application. Bilang resulta, ang oras sa merkado para sa mga pagpapaunlad ay nabawasan.
Bilang isang bonus, nakakakuha kami ng awtomatikong pag-scale para sa pagkarga, at nagbabayad lamang kami para sa mga mapagkukunang ginamit at sa oras lamang na ginagamit ang mga ito.
Tulad ng anumang teknolohiya, ang Serverless ay may mga disadvantages.
Halimbawa, ang ganitong kawalan ay maaaring ang malamig na oras ng pagsisimula (sa average na hanggang 1 segundo para sa mga wika tulad ng JavaScript, Python, Go, Java, Ruby).
Sa isang banda, sa katotohanan, ang malamig na oras ng pagsisimula ay nakasalalay sa maraming mga variable: ang wika kung saan nakasulat ang function, ang bilang ng mga aklatan, ang halaga ng code, komunikasyon sa mga karagdagang mapagkukunan (ang parehong mga database o mga server ng pagpapatunay). Dahil kontrolado ng developer ang mga variable na ito, maaari niyang bawasan ang oras ng pagsisimula. Ngunit sa kabilang banda, hindi makokontrol ng developer ang oras ng pagsisimula ng container - depende ang lahat sa provider.
Ang malamig na simula ay maaaring maging mainit na simula kapag ginamit muli ng isang function ang isang container na inilunsad ng isang nakaraang kaganapan. Ang sitwasyong ito ay lilitaw sa tatlong mga kaso:
- kung madalas gamitin ng mga kliyente ang serbisyo at tumataas ang bilang ng mga tawag sa function;
- kung pinapayagan ka ng provider, platform o framework na panatilihing tumatakbo ang ilang container sa lahat ng oras;
- kung ang developer ay nagpapatakbo ng mga function sa isang timer (sabihin bawat 3 minuto).
Para sa maraming mga aplikasyon, ang malamig na pagsisimula ay hindi isang problema. Dito kailangan mong bumuo sa uri at mga gawain ng serbisyo. Ang pagkaantala sa pagsisimula ng isang segundo ay hindi palaging kritikal para sa isang aplikasyon sa negosyo, ngunit maaari itong maging kritikal para sa mga serbisyong medikal. Sa kasong ito, malamang na hindi na angkop ang serverless approach.
Ang susunod na disbentaha ng Serverless ay ang maikling buhay ng isang function (timeout kung saan dapat isagawa ang function).
Ngunit, kung kailangan mong magtrabaho sa mga pangmatagalang gawain, maaari kang gumamit ng hybrid na arkitektura - pagsamahin ang Serverless sa isa pang teknolohiya.
Hindi lahat ng system ay gagana gamit ang Serverless scheme.
Ang ilang mga application ay mag-iimbak pa rin ng data at estado sa panahon ng pagpapatupad. Ang ilang mga arkitektura ay mananatiling monolitik at ang ilang mga tampok ay mahaba ang buhay. Gayunpaman (tulad ng mga teknolohiya sa cloud at pagkatapos ay mga lalagyan), ang Serverless ay isang teknolohiyang may magandang kinabukasan.
Sa ganitong ugat, nais kong maayos na magpatuloy sa isyu ng paggamit ng Serverless na diskarte.
Mula sa gilid ng aplikasyon
Para sa 2018, ang porsyento ng paggamit ng Walang Server . Kabilang sa mga kumpanyang nagpatupad na ng teknolohiya sa kanilang mga serbisyo ay ang mga higanteng merkado tulad ng Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Kasabay nito, kailangan mong maunawaan na ang Serverless ay hindi isang panlunas sa lahat, ngunit isang tool para sa paglutas ng isang tiyak na hanay ng mga problema:
- Bawasan ang downtime ng mapagkukunan. Hindi na kailangang patuloy na panatilihin ang isang virtual machine para sa mga serbisyo na may kaunting mga tawag.
- Iproseso ang data sa mabilisang. I-compress ang mga larawan, gupitin ang mga background, baguhin ang pag-encode ng video, gumana sa mga sensor ng IoT, magsagawa ng mga operasyong matematikal.
- "Pagdikitin" ang iba pang mga serbisyo nang magkasama. Git repository na may mga panloob na programa, chat bot sa Slack na may Jira at kalendaryo.
- Balansehin ang load. Tingnan natin ang mas malapit dito.
Sabihin nating mayroong serbisyo na umaakit ng 50 tao. Sa ilalim nito ay may isang virtual machine na may mahinang hardware. Paminsan-minsan, ang pagkarga sa serbisyo ay tumataas nang malaki. Kung gayon ang mahinang hardware ay hindi makayanan.
Maaari kang magsama ng balancer sa system na mamamahagi ng load, halimbawa, sa tatlong virtual machine. Sa yugtong ito, hindi namin tumpak na mahulaan ang pag-load, kaya pinapanatili namin ang isang tiyak na halaga ng mga mapagkukunan na tumatakbo "na nakalaan." At sobra ang binabayaran namin para sa downtime.
Sa ganoong sitwasyon, maaari naming i-optimize ang system sa pamamagitan ng hybrid na diskarte: nag-iiwan kami ng isang virtual machine sa likod ng load balancer at naglalagay ng link sa Serverless Endpoint na may mga function. Kung ang pag-load ay lumampas sa threshold, ang balancer ay maglulunsad ng mga instance ng function na humahawak sa bahagi ng pagproseso ng kahilingan.
Kaya, maaaring gamitin ang Serverless kung saan kinakailangan upang iproseso ang isang malaking bilang ng mga kahilingan hindi masyadong madalas, ngunit intensively. Sa kasong ito, ang pagpapatakbo ng ilang mga function sa loob ng 15 minuto ay mas kumikita kaysa sa pagpapanatili ng isang virtual machine o server sa lahat ng oras.
Sa lahat ng mga pakinabang ng serverless computing, bago ang pagpapatupad, dapat mo munang suriin ang application logic at maunawaan kung anong mga problema ang maaaring malutas ng Serverless sa isang partikular na kaso.
Walang Server at Selectel
Sa Selectel na kami sa pamamagitan ng aming control panel. Ngayon ay gumagawa kami ng sarili naming platform ng FaaS. Gusto naming malutas ng mga developer ang kanilang mga problema gamit ang Serverless sa pamamagitan ng isang maginhawa at nababagong interface.
Kung mayroon kang mga ideya kung ano dapat ang perpektong platform ng FaaS at kung paano mo gustong gamitin ang Serverless sa iyong mga proyekto, ibahagi ang mga ito sa mga komento. Isasaalang-alang namin ang iyong mga kagustuhan kapag binubuo ang platform.
Mga materyales na ginamit sa artikulo:
Pinagmulan: www.habr.com