Raflarda serversiz

Raflarda serversiz
Serversiz serverlərin fiziki olmaması ilə bağlı deyil. Bu konteyner qatili və ya keçən bir tendensiya deyil. Bu, buludda sistemlərin qurulmasına yeni yanaşmadır. Bugünkü məqaləmizdə Serversiz proqramların arxitekturasına toxunacağıq, gəlin görək Serversiz xidmət provayderi və açıq mənbəli layihələr hansı rol oynayır. Nəhayət, Serversiz istifadə məsələlərindən danışaq.

Mən proqramın (və ya hətta onlayn mağazanın) server hissəsini yazmaq istəyirəm. Bu, söhbət, məzmun nəşri xidməti və ya yük balanslaşdırıcısı ola bilər. Hər halda, çoxlu baş ağrısı olacaq: infrastrukturu hazırlamalı, tətbiqdən asılılıqları müəyyənləşdirməli və host əməliyyat sistemi haqqında düşünməli olacaqsınız. Sonra monolitin qalan hissəsinin işinə təsir etməyən kiçik komponentləri yeniləməli olacaqsınız. Yaxşı, yük altında miqyasını unutmayaq.

Tələb olunan asılılıqların əvvəlcədən quraşdırıldığı və konteynerlərin özləri bir-birindən və host OS-dən təcrid olunmuş efemer konteynerləri götürsək nə olar? Monoliti mikroservislərə böləcəyik, onların hər biri digərlərindən asılı olmayaraq yenilənə və ölçülə bilər. Kodu belə bir konteynerə yerləşdirməklə onu istənilən infrastrukturda işlədə bilirəm. Artıq daha yaxşı.

Konteynerləri konfiqurasiya etmək istəmirsinizsə nə etməli? Tətbiqin miqyasını artırmaq barədə düşünmək istəmirəm. Xidmətin yükü minimal olduqda, boş işləyən konteynerlərə görə ödəniş etmək istəmirəm. Mən kod yazmaq istəyirəm. İş məntiqinə diqqət yetirin və məhsulları işıq sürəti ilə bazara çıxarın.

Bu cür fikirlər məni serversiz hesablamaya apardı. Bu vəziyyətdə serversiz deməkdir serverlərin fiziki olmaması deyil, infrastrukturun idarə edilməsində baş ağrılarının olmaması.

İdeya ondan ibarətdir ki, tətbiq məntiqi müstəqil funksiyalara bölünür. Onların hadisə quruluşu var. Hər bir funksiya bir “mikrotask” yerinə yetirir. Tərtibatçıdan tələb olunan bütün funksiyaları bulud provayderi tərəfindən təqdim edilən konsola yükləmək və onları hadisə mənbələri ilə əlaqələndirməkdir. Kod tələb əsasında avtomatik hazırlanmış konteynerdə icra olunacaq və mən yalnız icra müddətini ödəyəcəyəm.

Tətbiqlərin hazırlanması prosesinin indi necə görünəcəyini görək.

Tərtibatçı tərəfdən

Əvvəllər onlayn mağaza üçün ərizə haqqında danışmağa başladıq. Ənənəvi yanaşmada sistemin əsas məntiqi monolit tətbiqetmə ilə həyata keçirilir. Tətbiqi olan server isə heç bir yük olmasa belə, daim işləyir.

Serversiz rejimə keçmək üçün proqramı mikro tapşırıqlara bölürük. Onların hər biri üçün öz funksiyamızı yazırıq. Funksiyalar bir-birindən müstəqildir və dövlət məlumatlarını saxlamır (vətəndaşlığı olmayan). Onlar hətta müxtəlif dillərdə yazıla bilər. Onlardan biri "düşürsə", bütün proqram dayanmayacaq. Tətbiq arxitekturası belə görünəcək:

Raflarda serversiz
Serverless-də funksiyalara bölünmə mikroservislərlə işləməyə bənzəyir. Lakin mikroservis bir neçə vəzifəni yerinə yetirə bilər və funksiya ideal olaraq birini yerinə yetirməlidir. Təsəvvür edək ki, vəzifə statistik məlumatları toplamaq və istifadəçinin istəyi ilə göstərməkdir. Mikroservis yanaşmasında tapşırıq iki giriş nöqtəsi olan bir xidmət tərəfindən yerinə yetirilir: yazma və oxu. Serversiz hesablamada bunlar bir-biri ilə əlaqəli olmayan iki fərqli funksiya olacaq. Məsələn, statistika yükləndiklərindən daha tez-tez yenilənirsə, tərtibatçı hesablama resurslarına qənaət edir.

Serversiz funksiyalar xidmət təminatçısı tərəfindən müəyyən edilən qısa müddət ərzində (taym-out) yerinə yetirilməlidir. Məsələn, AWS üçün fasilə 15 dəqiqədir. Bu o deməkdir ki, uzunömürlü funksiyalar tələblərə uyğun olaraq dəyişdirilməli olacaq - Serverless-i bu gün digər populyar texnologiyalardan (konteynerlər və Platforma Xidmət kimi) fərqləndirən budur.

Hər bir funksiyaya bir hadisə təyin edirik. Hadisə bir hərəkət üçün tətikdir:

Hadisə
Funksiyanın yerinə yetirdiyi hərəkət

Məhsul şəkli depoya yükləndi.
Şəkli sıxın və qovluğa yükləyin

Fiziki mağaza ünvanı verilənlər bazasında yeniləndi
Xəritələrə yeni yer yükləyin

Müştəri malların pulunu ödəyir
Ödəniş emalına başlayın

Hadisələr HTTP sorğuları, axın məlumatları, mesaj növbələri və s. ola bilər. Hadisə mənbələri məlumatların dəyişmələri və ya baş vermələridir. Bundan əlavə, funksiyalar taymer tərəfindən işə salına bilər.

Arxitektura işlənib və proqram demək olar ki, serversiz olub. Sonra xidmət təminatçısına gedirik.

Provayder tərəfdən

Tipik olaraq, serversiz hesablama bulud xidməti təminatçıları tərəfindən təklif olunur. Onlar fərqli adlanır: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

Biz xidmətdən provayderin konsolu və ya şəxsi hesabı vasitəsilə istifadə edəcəyik. Funksiya kodunu aşağıdakı yollardan biri ilə yükləmək olar:

  • veb konsol vasitəsilə daxili redaktorlarda kod yazmaq,
  • arxivi kodla yükləyin,
  • ictimai və ya özəl git depoları ilə işləmək.

Burada funksiyanı çağıran hadisələri təyin edirik. Tədbirlər dəstləri müxtəlif provayderlər üçün fərqli ola bilər.

Raflarda serversiz

Provayder öz infrastrukturunda Xidmət kimi Funksiya (FaaS) sistemini qurdu və avtomatlaşdırdı:

  1. Funksiya kodu provayder tərəfində anbarda bitir.
  2. Hadisə baş verdikdə, hazırlanmış mühitə malik konteynerlər avtomatik olaraq serverdə yerləşdirilir. Hər bir funksiya nümunəsinin öz təcrid olunmuş konteyneri var.
  3. Saxlamadan funksiya konteynerə göndərilir, hesablanır və nəticəni qaytarır.
  4. Paralel hadisələrin sayı artır - konteynerlərin sayı artır. Sistem avtomatik olaraq miqyas alır. İstifadəçilər funksiyaya daxil olmasalar, o, qeyri-aktiv olacaq.
  5. Provayder konteynerlər üçün boş vaxt təyin edir - bu müddət ərzində konteynerdə funksiyalar görünmürsə, o, məhv edilir.

Bu yolla biz Serverless-i qutudan çıxarırıq. Biz xidmət haqqını getdikcə ödə modelindən istifadə edərək və yalnız istifadə olunan funksiyalar üçün və yalnız istifadə edildiyi vaxt üçün ödəyəcəyik.

Tərtibatçıları xidmətlə tanış etmək üçün provayderlər 12 aya qədər pulsuz sınaq təklif edirlər, lakin ümumi hesablama vaxtını, ayda sorğuların sayını, vəsaitləri və ya enerji istehlakını məhdudlaşdırırlar.

Provayderlə işləməyin əsas üstünlüyü infrastruktur (serverlər, virtual maşınlar, konteynerlər) barədə narahat olmamaq imkanıdır. Öz növbəsində, provayder həm öz inkişaflarından istifadə edərək, həm də açıq mənbə alətlərindən istifadə edərək FaaS tətbiq edə bilər. Onlar haqqında daha ətraflı danışaq.

Açıq mənbə tərəfdən

Açıq mənbə icması son bir neçə il ərzində Serversiz alətlər üzərində fəal işləyir. Ən böyük bazar oyunçuları da serversiz platformaların inkişafına töhfə verir:

  • google tərtibatçılara açıq mənbə alətini təklif edir - Bıçaqçı. Onun hazırlanmasında IBM, RedHat, Pivotal və SAP iştirak etmişdir;
  • IBM Serversiz platformada işləyib Açıq çırpma, daha sonra Apache Fondunun layihəsinə çevrildi;
  • microsoft platforma kodunu qismən açdı Azure funksiyaları.

Serversiz çərçivələr istiqamətində də inkişaflar davam edir. Kubeless и Missiya əvvəlcədən hazırlanmış Kubernetes klasterlərində yerləşdirilib, OpenFaaS həm Kubernetes, həm də Docker Swarm ilə işləyir. Çərçivə bir növ nəzarətçi kimi çıxış edir - sorğuya əsasən, klaster daxilində işləmə mühiti hazırlayır, sonra orada funksiyanı işə salır.

Çərçivələr aləti ehtiyaclarınıza uyğun konfiqurasiya etmək üçün yer buraxır. Beləliklə, Kubeless-də bir tərtibatçı funksiyanın icra müddətini konfiqurasiya edə bilər (standart dəyər 180 saniyədir). Fission, soyuq başlanğıc problemini həll etmək cəhdi olaraq, bəzi konteynerlərin daim işlək vəziyyətdə saxlanmasını təklif edir (baxmayaraq ki, bu, resursun dayanması xərclərinə səbəb olur). OpenFaaS isə hər zövqə və rəngə uyğun bir sıra tətiklər təklif edir: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs və s.

Başlamaq üçün təlimatlar çərçivələrin rəsmi sənədlərində tapıla bilər. Onlarla işləmək bir provayderlə işləməkdən bir az daha çox bacarıq tələb edir - bu, ən azı CLI vasitəsilə Kubernetes klasterini işə salmaq bacarığıdır. Ən çox digər açıq mənbə alətlərini (məsələn, Kafka növbə meneceri) daxil edin.

Serversiz ilə necə işləməyimizdən asılı olmayaraq - provayder vasitəsilə və ya açıq mənbədən istifadə etməklə, biz Serversiz yanaşmanın bir sıra üstünlükləri və çatışmazlıqlarını alacağıq.

Üstünlüklər və çatışmazlıqlar baxımından

Serverless, komandaların bir platformaya bağlanmadan çoxdilli rejimdə işləyə bildiyi konteyner infrastrukturu və mikroservis yanaşması ideyalarını inkişaf etdirir. Sistemin qurulması sadələşdirilmişdir və səhvləri düzəltmək daha asandır. Mikroservis arxitekturası sistemə monolit tətbiqdən daha sürətli yeni funksionallıq əlavə etməyə imkan verir.

Serversiz inkişaf müddətini daha da azaldır, tərtibatçıya yalnız tətbiqin biznes məntiqinə və kodlaşdırılmasına diqqət yetirməyə imkan verir. Nəticədə, inkişaflar üçün bazara çıxmaq vaxtı azalır.

Bonus olaraq, yük üçün avtomatik miqyas alırıq, və biz yalnız istifadə olunan resurslara görə və yalnız istifadə edildiyi vaxt ödəyirik.

İstənilən texnologiya kimi, Serverless-in çatışmazlıqları var.

Məsələn, belə bir çatışmazlıq soyuq başlama vaxtı ola bilər (JavaScript, Python, Go, Java, Ruby kimi dillər üçün orta hesabla 1 saniyəyə qədər).

Bir tərəfdən, reallıqda soyuq başlanğıc vaxtı bir çox dəyişənlərdən asılıdır: funksiyanın yazıldığı dil, kitabxanaların sayı, kodun miqdarı, əlavə resurslarla əlaqə (eyni verilənlər bazaları və ya autentifikasiya serverləri). Tərtibatçı bu dəyişənlərə nəzarət etdiyi üçün başlanğıc vaxtını azalda bilər. Ancaq digər tərəfdən, tərtibatçı konteynerin işə salınma vaxtını idarə edə bilmir - hamısı provayderdən asılıdır.

Soyuq başlanğıc, funksiya əvvəlki hadisə tərəfindən işə salınan konteyneri təkrar istifadə etdikdə isti başlanğıca çevrilə bilər. Bu vəziyyət üç halda yaranacaq:

  • müştərilər xidmətdən tez-tez istifadə edirsə və funksiyaya edilən zənglərin sayı artırsa;
  • provayder, platforma və ya çərçivə bəzi konteynerləri daim işlək vəziyyətdə saxlamağa imkan verirsə;
  • developer funksiyaları taymerdə işlədirsə (hər 3 dəqiqədən bir deyək).

Bir çox tətbiq üçün soyuq başlanğıc problem deyil. Burada xidmətin növü və vəzifələri üzərində qurulmalısınız. Bir saniyəlik başlanğıc gecikməsi biznes tətbiqi üçün həmişə kritik deyil, lakin tibbi xidmətlər üçün kritik ola bilər. Bu halda, serversiz yanaşma yəqin ki, artıq uyğun olmayacaq.

Serversizin növbəti çatışmazlığı funksiyanın qısa ömrüdür (funksiyanın icra edilməli olduğu müddət ərzində).

Lakin, uzunmüddətli tapşırıqlarla işləməlisinizsə, hibrid arxitekturadan istifadə edə bilərsiniz - Serverless-i başqa bir texnologiya ilə birləşdirin.

Bütün sistemlər Serversiz sxemdən istifadə etməklə işləyə bilməyəcək.

Bəzi proqramlar hələ də icra zamanı məlumatları və vəziyyəti saxlayacaq. Bəzi memarlıqlar monolit olaraq qalacaq və bəzi xüsusiyyətlər uzunömürlü olacaq. Bununla belə (bulud texnologiyaları və sonra konteynerlər kimi), Serverless böyük gələcəyi olan bir texnologiyadır.

Bu mənada mən Serversiz yanaşmadan istifadə məsələsinə rəvan keçmək istərdim.

Tətbiq tərəfdən

2018-ci il üçün Serversiz istifadə faizi bir yarım dəfə artdı. Artıq texnologiyanı öz xidmətlərində tətbiq edən şirkətlər arasında Twitter, PayPal, Netflix, T-Mobile, Coca-Cola kimi bazar nəhəngləri var. Eyni zamanda başa düşməlisiniz ki, Serverless panacea deyil, müəyyən bir sıra problemləri həll etmək üçün bir vasitədir:

  • Resursların dayanma müddətini azaldın. Zəngləri az olan xidmətlər üçün daim virtual maşın saxlamağa ehtiyac yoxdur.
  • Məlumatları tez emal edin. Şəkilləri sıxın, fonları kəsin, video kodlamasını dəyişdirin, IoT sensorları ilə işləyin, riyazi əməliyyatları yerinə yetirin.
  • Digər xidmətləri birlikdə "yapışdırın". Daxili proqramları olan Git deposu, Jira və təqvim ilə Slack-də söhbət botu.
  • Yükü tarazlayın. Gəlin bura daha yaxından nəzər salaq.

Tutaq ki, 50 nəfəri cəlb edən bir xidmət var. Onun altında zəif təchizatlı virtual maşın var. Zaman zaman xidmətin yükü əhəmiyyətli dərəcədə artır. Sonra zəif aparat öhdəsindən gələ bilməz.

Sistemə yükü, məsələn, üç virtual maşın arasında bölüşdürəcək bir balanslaşdırıcı əlavə edə bilərsiniz. Bu mərhələdə yükü dəqiq proqnozlaşdıra bilmirik, ona görə də müəyyən miqdarda resursları “ehtiyatda” saxlayırıq. Və dayanma vaxtı üçün artıq ödəniş edirik.

Belə bir vəziyyətdə, hibrid yanaşma vasitəsilə sistemi optimallaşdıra bilərik: bir virtual maşını yük balanslaşdırıcısının arxasında qoyuruq və funksiyaları olan Serverless Endpoint-ə keçid qoyuruq. Əgər yük həddi keçərsə, balanslaşdırıcı sorğunun işlənməsinin bir hissəsini öz üzərinə götürən funksiya nümunələrini işə salır.

Raflarda serversiz
Beləliklə, Serversiz çoxlu sayda sorğuları tez-tez deyil, intensiv şəkildə emal etmək lazım olduğu yerlərdə istifadə edilə bilər. Bu halda 15 dəqiqə ərzində bir neçə funksiyanı işlətmək virtual maşın və ya serveri hər zaman saxlamaqdan daha sərfəlidir.

Serversiz hesablamanın bütün üstünlükləri ilə, tətbiq etməzdən əvvəl, ilk növbədə proqram məntiqini qiymətləndirməli və müəyyən bir vəziyyətdə Serversizin hansı problemləri həll edə biləcəyini başa düşməlisiniz.

Serversiz və Seçilmiş

Biz artıq Selectel-dəyik Kubernetes ilə sadələşdirilmiş iş idarəetmə panelimiz vasitəsilə. İndi biz öz FaaS platformamızı qururuq. İstəyirik ki, tərtibatçılar rahat, çevik interfeys vasitəsilə Serverlessdən istifadə edərək problemlərini həll edə bilsinlər.

İdeal FaaS platformasının nə olması və layihələrinizdə Serversizdən necə istifadə etmək istədiyiniz barədə fikirləriniz varsa, şərhlərdə paylaşın. Platformanı hazırlayarkən istəklərinizi nəzərə alacağıq.
 
Məqalədə istifadə olunan materiallar:

Mənbə: www.habr.com

Добавить комментарий