Scalable API kūrimas naudojant AWS taškinius egzempliorius

Sveiki visi! Mano vardas Kirilas, aš esu „Adapty“ CTO. Didžioji dalis mūsų architektūros yra AWS, o šiandien kalbėsiu apie tai, kaip 3 kartus sumažinome serverio išlaidas, naudodami vietinius egzempliorius gamybinėje aplinkoje, taip pat kaip nustatyti jų automatinį mastelio keitimą. Pirmiausia bus apžvelgta, kaip tai veikia, o tada išsamios instrukcijos, kaip pradėti.

Kas yra taškiniai atvejai?

Vieta egzemplioriai yra kitų AWS vartotojų serveriai, kurie šiuo metu neveikia, ir jie juos parduoda su didele nuolaida (Amazon rašo iki 90%, mūsų patirtimi ~3x, skiriasi priklausomai nuo regiono, AZ ir egzempliorių tipo). Pagrindinis jų skirtumas nuo įprastų yra tas, kad jie gali bet kada išsijungti. Todėl ilgą laiką tikėjome, kad normalu juos naudoti grynoms aplinkoms arba kažko skaičiuojant, kai tarpiniai rezultatai išsaugomi S3 ar duomenų bazėje, bet ne pardavimui. Yra trečiųjų šalių sprendimų, leidžiančių gamyboje naudoti taškus, tačiau mūsų atveju yra daug ramentų, todėl mes jų neįdiegėme. Straipsnyje aprašytas metodas veikia tik naudojant standartines AWS funkcijas, be papildomų scenarijų, karūnėlių ir kt.

Toliau pateikiamos kelios ekrano kopijos, kuriose rodoma neatidėliotinų atvejų kainų istorija.

m5.didelis eu-west-1 (Airija) regione. Kaina buvo beveik stabili 3 mėnesius, šiuo metu sutaupoma 2.9 karto.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

m5.didelis us-east-1 regione (N. Virdžinija). Kaina nuolat kinta per 3 mėnesius, šiuo metu sutaupoma nuo 2.3x iki 2.8x priklausomai nuo prieinamumo zonos.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

t3.mažas us-East-1 regione (N. Virdžinija). Kaina buvo stabili 3 mėnesius, šiuo metu sutaupoma 3.4 karto.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Paslaugų architektūra

Pagrindinė paslaugos architektūra, apie kurią kalbėsime šiame straipsnyje, parodyta toliau pateiktoje diagramoje.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Taikymas Apkrovos balansavimo priemonė → EC2 tikslinė grupė → elastinių konteinerių paslauga

Taikomosios apkrovos balansavimo priemonė (ALB) naudojama kaip balansavimo priemonė, kuri siunčia užklausas EC2 tikslinei grupei (TG). TG yra atsakinga už ALB egzempliorių prievadų atidarymą ir jų prijungimą prie Elastic Container Service (ECS) konteinerių prievadų. ECS yra „Kubernetes“ analogas AWS, kuris valdo „Docker“ konteinerius.

Viename egzemplioriuje gali būti keli veikiantys konteineriai su tais pačiais prievadais, todėl negalime jų nustatyti fiksuotai. ECS praneša TG, kad paleidžia naują užduotį (Kubernetes terminologijoje tai vadinama pod), ji patikrina, ar egzemplioriuje nėra laisvų prievadų, ir vieną iš jų priskiria paleistai užduočiai. TG taip pat reguliariai tikrina, ar egzempliorius ir API veikia su juo, naudodamas sveikatos patikrinimą, ir, jei mato kokių nors problemų, nustoja siųsti užklausas.

EC2 automatinio mastelio keitimo grupės + ECS talpos teikėjai

Aukščiau pateiktoje diagramoje nerodoma EC2 automatinio mastelio keitimo grupių (ASG) paslauga. Iš pavadinimo galite suprasti, kad jis yra atsakingas už egzempliorių mastelio keitimą. Tačiau iki šiol AWS neturėjo integruotos galimybės valdyti ECS veikiančių mašinų skaičiaus. ECS leido keisti užduočių skaičių, pavyzdžiui, pagal procesoriaus naudojimą, RAM arba užklausų skaičių. Bet jei užduotys užėmė visus nemokamus egzempliorius, naujos mašinos nebuvo automatiškai sukurtos.

Tai pasikeitė, kai atsirado ECS pajėgumų teikėjai (ECS CP). Dabar kiekviena ECS paslauga gali būti susieta su ASG, o jei užduotys netelpa į vykdomus egzempliorius, bus iškeltos naujos (bet neviršijant nustatytų ASG ribų). Tai taip pat veikia priešinga kryptimi, jei ECS CP mato tuščiosios eigos egzempliorius be užduočių, tada jis duos ASG komandą juos išjungti. ECS CP turi galimybę nurodyti tikslinę egzempliorių apkrovos procentinę dalį, kad tam tikras skaičius mašinų visada būtų laisvos greitai keisti užduotis; apie tai pakalbėsiu šiek tiek vėliau.

EC2 paleidimo šablonai

Paskutinė paslauga, apie kurią kalbėsiu prieš išsamiai apie šios infrastruktūros kūrimą, yra EC2 Launch Templates. Tai leidžia susikurti šabloną, pagal kurį įsijungs visos mašinos, kad to nekartotų kiekvieną kartą nuo nulio. Čia galite pasirinkti paleidžiamo įrenginio tipą, saugos grupę, disko vaizdą ir daugelį kitų parametrų. Taip pat galite nurodyti vartotojo duomenis, kurie bus įkelti į visus paleistus egzempliorius. Galite paleisti scenarijus vartotojo duomenyse, pavyzdžiui, galite redaguoti failo turinį ECS agento konfigūracijos.

Vienas iš svarbiausių šio straipsnio konfigūracijos parametrų yra ECS_ENABLE_SPOT_INSTANCE_DRAINING= tiesa. Jei šis parametras įjungtas, kai tik ECS gauna signalą, kad vietinis egzempliorius atimamas, visas su juo susijusias užduotis ji perkelia į būseną Nusausinimas. Šiam egzemplioriui nebus priskirtos jokios naujos užduotys; jei yra užduočių, kurias norima įdiegti dabar, jos bus atšauktos. Balansuotojo prašymai taip pat nustoja gauti. Pranešimas apie egzemplioriaus ištrynimą gaunamas likus 2 minutėms iki tikrojo įvykio. Todėl, jei jūsų paslauga neatlieka užduočių ilgiau nei 2 minutes ir nieko neišsaugo diske, galite naudoti vietinius egzempliorius neprarasdami duomenų.

Dėl disko – AWS neseniai pagamintas Galima naudoti elastinę failų sistemą (EFS) kartu su ECS, naudojant šią schemą net diskas nėra kliūtis, bet mes to nebandėme, nes iš esmės mums nereikia disko būsenai išsaugoti. Pagal numatytuosius nustatymus, gavus SIGINT (siunčiama, kai užduotis perkeliama į išsekimo būseną), visos vykdomos užduotys bus sustabdytos po 30 sekundžių, net jei jos dar nėra baigtos; šį laiką galite pakeisti naudodami parametrą ECS_CONTAINER_STOP_TIMEOUT. Pagrindinis dalykas yra nenustatyti jo ilgiau nei 2 minutes taškinėms mašinoms.

Paslaugos kūrimas

Pereikime prie aprašytos paslaugos kūrimo. Proceso metu papildomai aprašysiu keletą naudingų dalykų, kurie nebuvo paminėti aukščiau. Apskritai tai yra žingsnis po žingsnio instrukcija, tačiau aš nenagrinėsiu kai kurių labai elementarių ar, priešingai, labai konkrečių atvejų. Visi veiksmai atliekami AWS vaizdo konsolėje, tačiau juos galima atkurti programiškai naudojant „CloudFormation“ arba „Terraform“. „Adapty“ naudojame „Terraform“.

EC2 paleidimo šablonas

Ši paslauga sukuria naudojamų mašinų konfigūraciją. Šablonai tvarkomi skyriuje EC2 -> Egzemplioriai -> Paleisti šablonus.

„Amazon“ mašinos vaizdas (AMI) — nurodykite disko vaizdą, su kuriuo bus paleisti visi egzemplioriai. Naudojant ECS, daugeliu atvejų verta naudoti optimizuotą vaizdą iš „Amazon“. Jis reguliariai atnaujinamas ir jame yra viskas, ko reikia, kad ECS veiktų. Norėdami sužinoti dabartinį vaizdo ID, eikite į puslapį Amazon ECS optimizuoti AMI, pasirinkite naudojamą regioną ir nukopijuokite jo AMI ID. Pavyzdžiui, us-east-1 regione dabartinis ID rašymo metu yra ami-00c7c1cf5bdc913ed. Šis ID turi būti įterptas į elementą Nurodykite tinkintą vertę.

Pavyzdžio tipas — nurodykite egzemplioriaus tipą. Pasirinkite tą, kuris geriausiai atitinka jūsų užduotį.

Raktų pora (prisijungimas) — nurodykite sertifikatą, su kuriuo, jei reikia, galite prisijungti prie egzemplioriaus per SSH.

Tinklo nustatymai — nurodyti tinklo parametrus. Tinklo platforma daugeliu atvejų turėtų būti virtualus privatus debesis (VPC). Apsaugos grupės - jūsų atvejų saugos grupės. Kadangi mes naudosime balansuotoją prieš egzempliorius, rekomenduoju čia nurodyti grupę, kuri leidžia įeinančius ryšius tik iš balansyro. Tai reiškia, kad turėsite 2 saugos grupes, vieną skirtą balansuotojui, kuri leidžia prisijungti prie bet kurios vietos 80 (http) ir 443 (https) prievaduose, o antrąją – mašinoms, leidžiančias prisijungti prie bet kurių prievadų iš balansavimo grupės. . Abiejų grupių išeinantys ryšiai turi būti atidaryti naudojant TCP protokolą į visus prievadus į visus adresus. Galite apriboti išeinančių jungčių prievadus ir adresus, bet tuomet turite nuolat stebėti, ar nebandote kažko pasiekti uždarame prievade.

Saugykla (tūriai) — nurodyti mašinų disko parametrus. Disko dydis negali būti mažesnis nei nurodytas AMI; ECS Optimized jis yra 30 GiB.

Išplėstinė informacija — nurodyti papildomus parametrus.

Pirkimo variantas — ar norime pirkti vietoje egzempliorius. Norime, bet nepažymėsime šio langelio; sukonfigūruosime jį automatinio mastelio keitimo grupėje, ten yra daugiau parinkčių.

IAM egzemplioriaus profilis — nurodykite vaidmenį, su kuriuo bus paleisti egzemplioriai. Kad egzemplioriai veiktų ECS, jiems reikia leidimų, kurie paprastai randami vaidmenyje ecsInstanceRole. Kai kuriais atvejais jį galima sukurti, jei ne, tai čia mokymas apie tai, kaip tai padaryti. Sukūrę tai nurodome šablone.
Toliau yra daug parametrų, iš esmės visur galite palikti numatytąsias reikšmes, tačiau kiekvienas iš jų turi aiškų aprašymą. Aš visada įjungiu EBS optimizuotą egzempliorių ir T2 / T3 Unlimited parinktis, jei naudoju sprogstamasis atvejų.

Vartotojas laikas — nurodyti vartotojo duomenis. Mes redaguosime failą /etc/ecs/ecs.config, kuriame yra ECS agento konfigūracija.
Pavyzdys, kaip gali atrodyti naudotojo duomenys:

#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.config

ECS_CLUSTER=DemoApiClusterProd — parametras nurodo, kad egzempliorius priklauso klasteriui su nurodytu pavadinimu, tai yra, šis klasteris galės įdėti savo užduotis šiame serveryje. Klasterio dar nesukūrėme, bet kurdami naudosime šį pavadinimą.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parametras nurodo, kad kai gaunamas signalas išjungti taškinį egzempliorių, visos jo užduotys turi būti perkeltos į būseną Nusausinimas.

ECS_CONTAINER_STOP_TIMEOUT=1m - parametras nurodo, kad gavus SIGINT signalą, visos užduotys turi 1 minutę iki nužudymo.

ECS_ENGINE_AUTH_TYPE=docker — parametras rodo, kad Docker schema naudojama kaip autorizacijos mechanizmas

ECS_ENGINE_AUTH_DATA=... — prisijungimo prie privataus konteinerio registro, kuriame saugomi jūsų Docker vaizdai, parametrai. Jei jis viešas, nieko nurodyti nereikia.

Šiame straipsnyje naudosiu viešą vaizdą iš Docker Hub, todėl nurodykite parametrus ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA nereikia.

Gera žinoti: Rekomenduojama reguliariai atnaujinti AMI, nes naujos versijos atnaujina Docker, Linux, ECS agento ir tt versijas. Norėdami to nepamiršti, galite nustatyti pranešimus apie naujų versijų išleidimą. Galite gauti pranešimus el. paštu ir atnaujinti rankiniu būdu arba galite parašyti Lambda funkciją, kuri automatiškai sukurs naują paleidimo šablono versiją su atnaujintu AMI.

EC2 automatinio mastelio keitimo grupė

Auto Scaling Group yra atsakinga už egzempliorių paleidimą ir mastelio keitimą. Grupės tvarkomos skyriuje EC2 -> Automatinis mastelio keitimas -> Automatinio mastelio keitimo grupės.

Paleisti šabloną — pasirinkite šabloną, sukurtą ankstesniame žingsnyje. Paliekame numatytąją versiją.

Pirkimo parinktys ir egzempliorių tipai — nurodykite klasterio egzempliorių tipus. Paleidimo šablono laikymasis naudoja egzemplioriaus tipą iš paleidimo šablono. Pirkimo parinkčių ir egzempliorių tipų derinimas leidžia lanksčiai konfigūruoti egzempliorių tipus. Mes jį panaudosime.

Pasirenkama pagal poreikį bazė — įprastų, netiesioginių atvejų, kurie visada veiks, skaičius.

Pagal poreikį procentas viršija bazę — procentinis reguliariųjų ir taškinių egzempliorių santykis, 50-50 bus paskirstyti po lygiai, 20-80 už kiekvieną įprastą egzempliorių pakeltos 4 vietoje. Šiame pavyzdyje nurodysiu 50-50, bet realiai dažniausiai darome 20-80, kai kuriais atvejais 0-100.

Pavyzdžių tipai — čia galite nurodyti papildomus egzempliorių tipus, kurie bus naudojami klasteryje. Niekada jo nenaudojome, nes nelabai suprantu istorijos prasmės. Galbūt taip yra dėl tam tikrų tipų atvejų apribojimų, tačiau juos galima lengvai padidinti naudojant palaikymą. Jei žinote programą, mielai perskaitysiu ją komentaruose)

Scalable API kūrimas naudojant AWS taškinius egzempliorius

tinklas — tinklo nustatymus, pasirinkite VPC ir mašinų potinklius, daugeliu atvejų turėtumėte pasirinkti visus galimus potinklius.

Apkrovos balansavimas - balanso nustatymai, bet mes tai darysime atskirai, čia nieko neliesime. Sveikatos patikrinimai taip pat bus sukonfigūruotas vėliau.

Grupės dydis — pradžioje nurodome mašinų skaičiaus limitus klasteryje ir pageidaujamą mašinų skaičių. Mašinų skaičius klasteryje niekada nebus mažesnis už nurodytą minimumą ir daugiau nei maksimalus, net jei mastelio keitimas turėtų įvykti pagal metriką.

Mastelio keitimo politika - mastelio keitimo parametrai, tačiau mastelį nustatysime pagal vykdomas ECS užduotis, todėl mastelio keitimą sukonfigūruosime vėliau.

Apsauga nuo mastelio — egzempliorių apsauga nuo ištrynimo mažinant mastelį. Įjungiame jį, kad ASG neištrintų mašinos, kurioje yra vykdomų užduočių. ECS pajėgumų teikėjas išjungs apsaugą tiems atvejams, kurie neturi užduočių.

Pridėti žymes — galite nurodyti egzempliorių žymas (tam reikia pažymėti žymimąjį laukelį Žymėti naujus atvejus). Rekomenduoju nurodyti pavadinimo žymą, tada visi grupėje paleisti egzemplioriai turės tą patį pavadinimą ir juos patogu peržiūrėti konsolėje.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Sukūrę grupę atidarykite ją ir eikite į skyrių Išplėstinės konfigūracijos Kodėl ne visos parinktys matomos konsolėje kūrimo etape.

Nutraukimo politika — taisyklės, į kurias atsižvelgiama ištrinant atvejus. Jie taikomi eilės tvarka. Dažniausiai naudojame tuos, kurie pavaizduoti žemiau esančiame paveikslėlyje. Pirmiausia ištrinami egzemplioriai su seniausiu paleidimo šablonu (pavyzdžiui, jei atnaujinome AMI, sukūrėme naują versiją, bet visi atvejai sugebėjo į ją persijungti). Tada pasirenkami atvejai, kurie yra arčiausiai kitos atsiskaitymo valandos. Ir tada pagal paleidimo datą atrenkami seniausi.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Gera žinoti: atnaujinti visas mašinas klasteryje, patogu naudoti Atnaujinti egzempliorių. Jei tai derinsite su Lambda funkcija iš ankstesnio veiksmo, turėsite visiškai automatizuotą egzempliorių atnaujinimo sistemą. Prieš atnaujindami visus įrenginius, turite išjungti visų grupės egzempliorių apsaugą nuo padidinimo. Ne konfigūracija grupėje, o apsauga nuo pačių mašinų, tai daroma egzempliorių valdymo skirtuke.

Taikymas apkrovos balansavimo priemonė ir EC2 tikslinė grupė

Balansuoklis sukurtas skyriuje EC2 → Load Balancing → Load Balancers. Naudosime Application Load Balancer; skirtingų tipų balansierių palyginimą galite perskaityti adresu paslaugų puslapį.

Klausytojai - prasminga padaryti 80 ir 443 prievadus ir vėliau peradresuoti iš 80 į 443 naudojant balansavimo taisykles.

Prieinamumo zonos — daugeliu atvejų pasiekiamumo zonas parenkame visiems.

Konfigūruokite saugos nustatymus — čia nurodytas balansatoriaus SSL sertifikatas, patogiausias variantas padaryti pažymą ACM. Apie skirtumus Saugumo politika galima perskaityti dokumentacija, galite palikti jį pasirinktą pagal numatytuosius nustatymus ELBSecurityPolicy-2016-08. Sukūrę balansyrą pamatysite DNS vardas, kurio reikia norint sukonfigūruoti savo domeno CNAME. Pavyzdžiui, taip jis atrodo „Cloudflare“.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Saugumo grupė — sukurti arba pasirinkti balansyro saugos grupę, daugiau apie tai rašiau aukščiau, skiltyje EC2 Launch Template → Network settings.

Tikslinė grupė — Mes sukuriame grupę, kuri yra atsakinga už užklausų nukreipimą iš balansyro į mašinas ir jų prieinamumo tikrinimą, kad iškilus problemoms jas būtų galima pakeisti. Tikslinis tipas turi būti pavyzdys, Protokolas и uostas bet, jei naudojate HTTPS ryšiui tarp balansyro ir egzempliorių, turite į juos įkelti sertifikatą. Šiame pavyzdyje mes to nedarysime, tiesiog paliksime 80 prievadą.

Sveikatos patikrinimai — paslaugos funkcionalumo tikrinimo parametrai. Realioje paslaugoje tai turėtų būti atskira užklausa, įgyvendinanti svarbias verslo logikos dalis; šiame pavyzdyje paliksiu numatytuosius nustatymus. Toliau galite pasirinkti užklausos intervalą, skirtąjį laiką, sėkmės kodus ir tt Mūsų pavyzdyje nurodysime sėkmės kodus 200-399, nes Docker vaizdas, kuris bus naudojamas, grąžina 304 kodą.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Registruoti taikinius — čia parenkami automobiliai grupei, bet mūsų atveju tai darys ECS, todėl šį žingsnį tiesiog praleidžiame.

Gera žinoti: balansavimo lygiu galite įjungti žurnalus, kurie bus išsaugoti S3 tam tikrame formatu. Iš ten juos galima eksportuoti į trečiųjų šalių paslaugas analitikai arba galite pateikti SQL užklausas tiesiai į S3 duomenis naudodami naudojant Athena. Tai patogu ir veikia be jokio papildomo kodo. Taip pat rekomenduoju nustatyti rąstų pašalinimą iš S3 kibiro po nurodyto laiko.

ECS užduoties apibrėžimas

Ankstesniuose žingsniuose sukūrėme viską, kas susiję su paslaugų infrastruktūra, o dabar pereiname prie konteinerių, kuriuos paleisime, aprašymo. Tai atliekama skyriuje ECS → Užduočių apibrėžimai.

Paleidimo tipo suderinamumas - pasirinkite EC2.

Užduoties vykdymo IAM vaidmuo - pasirinkti ecsTaskExecutionRole. Jį naudojant rašomi žurnalai, suteikiama prieiga prie slaptų kintamųjų ir kt.

Skiltyje Sudėtinio rodinio apibrėžimai spustelėkite Pridėti sudėtinį rodinį.

vaizdas — nuoroda į vaizdą su projekto kodu; šiame pavyzdyje naudosiu viešą vaizdą iš „Docker Hub“. bitnami/mazgas-pavyzdys:0.0.1.

Atminties ribos — talpyklos atminties apribojimai. Sunkus limitas — griežta riba, jei konteineris viršija nurodytą vertę, bus vykdoma docker kill komanda, konteineris iš karto mirs. Minkštas limitas — minkštoji riba, konteineris gali viršyti nurodytą vertę, tačiau į šį parametrą bus atsižvelgta atliekant užduotis mašinoms. Pavyzdžiui, jei įrenginyje yra 4 GiB RAM, o konteinerio minkštoji riba yra 2048 MiB, tada šis įrenginys su šiuo konteineriu gali atlikti daugiausia 2 vykdomas užduotis. Iš tikrųjų 4 GiB RAM yra šiek tiek mažiau nei 4096 MiB, tai galima pamatyti klasterio skirtuke ECS egzemplioriai. Minkšta riba negali būti didesnė už griežtą ribą. Svarbu suprasti, kad jei vienoje užduotyje yra keli konteineriai, tada jų ribos yra sumuojamos.

Uosto žemėlapiai - į Prieglobos prievadas Mes nurodome 0, tai reiškia, kad prievadas bus priskirtas dinamiškai ir bus stebimas tikslinės grupės. Konteinerių uostas — prievadas, kuriame veikia jūsų programa, dažnai nurodomas vykdymo komandoje arba priskiriamas jūsų programos kode, „Dockerfile“ ir kt. Mūsų pavyzdyje naudosime 3000, nes jis nurodytas dockerfile naudojamas vaizdas.

Sveikatos patikrinimas — konteinerio būklės patikros parametrai, kurių negalima painioti su sukonfigūruotu tikslinėje grupėje.

aplinka - aplinkos nustatymai. CPU vienetai - panašus į Atminties limitus, tik apie procesorių. Kiekviename procesoriaus branduolyje yra 1024 vienetai, taigi, jei serveryje yra dviejų branduolių procesorius, o konteineris nustatytas į 512, tada viename serveryje su šiuo konteineriu galima paleisti 4 užduotis. CPU vienetai visada atitinka branduolių skaičių, jų negali būti šiek tiek mažiau, kaip yra atminties atveju.

Komanda — komanda paleisti paslaugą konteineryje, visi parametrai nurodomi atskiriant kableliais. Tai gali būti ginklaragis, npm ir kt. Jei nenurodyta, bus naudojama CMD direktyvos reikšmė iš Dockerfile. Mes nurodome npm,start.

Aplinkos įvairovė — konteinerio aplinkos kintamieji. Tai gali būti paprasti tekstiniai duomenys arba slapti kintamieji iš Paslapčių vadybininkas arba Parametrų parduotuvė.

Sandėliavimas ir registravimas - čia nustatysime prisijungimą prie „CloudWatch Logs“ (AWS žurnalų paslauga). Norėdami tai padaryti, tiesiog įjunkite žymimąjį laukelį Automatiškai konfigūruoti CloudWatch žurnalus. Sukūrus užduoties apibrėžimą, žurnalų grupė bus automatiškai sukurta „CloudWatch“. Pagal numatytuosius nustatymus žurnalai jame saugomi neribotą laiką, rekomenduoju pakeisti saugojimo laikotarpį iš Niekada nesibaigia į reikiamą laikotarpį. Tai daroma „CloudWatch Log“ grupėse, reikia spustelėti esamą laikotarpį ir pasirinkti naują.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

ECS klasteris ir ECS pajėgumų tiekėjas

Norėdami sukurti grupę, eikite į ECS → Klasteriai. Kaip šabloną pasirenkame EC2 Linux + Networking.

Klasterio pavadinimas - labai svarbu, čia darome tą patį pavadinimą, kaip nurodyta parametre Launch Template ECS_CLUSTER, mūsų atveju - DemoApiClusterProd. Pažymėkite žymės langelį Kurti tuščią grupę. Pasirinktinai galite įgalinti „Container Insights“, kad galėtumėte peržiūrėti paslaugų metriką „CloudWatch“. Jei viską padarėte teisingai, skiltyje ECS egzemplioriai matysite mašinas, kurios buvo sukurtos automatinio mastelio keitimo grupėje.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Eikite į skirtuką Pajėgumų tiekėjai ir sukurti naują. Leiskite jums priminti, kad tai reikalinga norint valdyti mašinų kūrimą ir išjungimą, atsižvelgiant į vykdomų ECS užduočių skaičių. Svarbu pažymėti, kad tiekėjas gali būti priskirtas tik vienai grupei.

Automatinio mastelio keitimo grupė — pasirinkite anksčiau sukurtą grupę.

Valdomas mastelio keitimas — įjungti, kad teikėjas galėtų išplėsti paslaugą.

Tikslinis pajėgumas % — kiek procentų mašinų, pakrautų su užduotimis, mums reikia. Jei nurodysite 100%, tada visos mašinos visada bus užimtos vykdomomis užduotimis. Jei nurodysite 50%, tada pusė automobilių visada bus nemokami. Tokiu atveju, staigiai šoktelėjus apkrovai, nauji taksi automobiliai iš karto pateks į laisvus automobilius, nelaukiant, kol bus dislokuoti instanciai.

Valdoma nutraukimo apsauga — įgalinti, šis parametras leidžia teikėjui pašalinti egzempliorių apsaugą nuo ištrynimo. Taip atsitinka, kai įrenginyje nėra aktyvių užduočių ir leidžiama naudoti tikslinį pajėgumą%.

ECS paslauga ir mastelio nustatymas

Paskutinis žingsnis :) Norėdami sukurti paslaugą, turite eiti į anksčiau sukurtą klasterį, esantį skirtuke Paslaugos.

Paleidimo tipas — reikia spustelėti Perjungti į pajėgumų teikėjo strategiją ir pasirinkti anksčiau sukurtus tiekėjus.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Užduoties apibrėžimas — pasirinkite anksčiau sukurtą Užduočių apibrėžimą ir jo versiją.

Paslaugos pavadinimas — kad būtų išvengta painiavos, visada nurodome tą patį, kaip ir užduoties apibrėžimas.

Paslaugos tipas - visada replika.

Užduočių skaičius — pageidaujamas aktyvių užduočių skaičius tarnyboje. Šis parametras valdomas mastelio keitimu, bet vis tiek turi būti nurodytas.

Minimalus sveiko procentas и Maksimalus procentas — nustatyti užduočių elgesį diegimo metu. Numatytosios reikšmės yra 100 ir 200, o tai rodo, kad diegimo metu užduočių skaičius padidės kelis kartus, o tada grįš į norimą vertę. Jei turite 1 užduotį, kuri veikia, min=0 ir max=100, tai diegimo metu ji bus nužudyta, o po to bus iškelta nauja, tai yra prastovos. Jei vykdoma 1 užduotis, min=50, max=150, tai diegimas iš viso neįvyks, nes 1 užduotis negalima padalyti per pusę arba padidinti pusantro karto.

Diegimo tipas — palikite nuolatinį atnaujinimą.

Įdėjimo šablonai — užduočių išdėstymo mašinose taisyklės. Numatytoji vertė yra AZ subalansuota sklaida – tai reiškia, kad kiekviena nauja užduotis bus dedama į naują egzempliorių, kol mašinos visose pasiekiamumo zonose pakils. Paprastai atliekame „BinPack“ – CPU ir „Spread“ – AZ; taikant šią politiką užduotys dedamos kuo tankiau viename CPU viename kompiuteryje. Jei reikia sukurti naują įrenginį, jis sukuriamas naujoje prieinamumo zonoje.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Apkrovos balansavimo tipas — pasirinkite Application Load Balancer.

Paslaugos IAM vaidmuo - pasirinkti ecsServiceRole.

Krovinio balansavimo priemonės pavadinimas — pasirinkite anksčiau sukurtą balansytuvą.

Sveikatos patikrinimo lengvatinis laikotarpis — pristabdykite prieš atlikdami sveikatos patikrinimus išleidę naują užduotį, paprastai nustatome 60 sekundžių.

Konteineris apkrovos balansui — punkte Tikslinės grupės pavadinimas pasirinkite anksčiau sukurtą grupę ir viskas bus užpildyta automatiškai.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

Paslaugos automatinis mastelio keitimas — paslaugų mastelio parametrai. Pasirinkite Konfigūruoti paslaugos automatinį mastelį, kad sureguliuotumėte pageidaujamą paslaugos skaičių. Keisdami mastelį nustatome mažiausią ir didžiausią užduočių skaičių.

IAM vaidmuo paslaugų automatiniam mastelio keitimui - pasirinkti AWSServiceRoleForApplicationAutoScaling_ECSService.

Automatinio užduočių mastelio keitimo politika — mastelio keitimo taisyklės. Yra 2 tipai:

  1. Tikslinis stebėjimas — tikslinės metrikos stebėjimas (procesoriaus/RAM naudojimas arba užklausų skaičius kiekvienai užduočiai atlikti). Pavyzdžiui, norime, kad vidutinė procesoriaus apkrova būtų 85%, kai ji padidės, bus pridėta naujų užduočių, kol pasieks tikslinę vertę. Jei apkrova mažesnė, užduotys bus pašalintos, priešingai, nebent įjungta apsauga nuo sumažinimo (Išjungti padidinimą).
  2. Žingsnis mastelio keitimas - reakcija į savavališką įvykį. Čia galite sukonfigūruoti reakciją į bet kurį įvykį (CloudWatch Alarm), kai ji įvyksta, galite pridėti arba pašalinti nurodytą užduočių skaičių arba nurodyti tikslų užduočių skaičių.

Paslauga gali turėti keletą mastelio keitimo taisyklių, tai gali būti naudinga, svarbiausia yra užtikrinti, kad jos neprieštarautų viena kitai.

išvada

Jei vykdėte instrukcijas ir naudojote tą patį „Docker“ vaizdą, jūsų paslauga turėtų grąžinti tokį puslapį.

Scalable API kūrimas naudojant AWS taškinius egzempliorius

  1. Sukūrėme šabloną, pagal kurį paleidžiamos visos paslaugos mašinos. Taip pat sužinojome, kaip atnaujinti mašinas pasikeitus šablonui.
  2. Sukonfigūravome taškinio egzemplioriaus sustabdymo signalo apdorojimą, todėl per minutę po jo gavimo visos vykdomos užduotys pašalinamos iš mašinos, todėl niekas neprarandama ir nenutrūksta.
  3. Mes pakėlėme balansyrą, kad apkrova būtų tolygiai paskirstyta tarp mašinų.
  4. Sukūrėme paslaugą, kuri veikia vietoje, todėl mašinos sąnaudos sumažėja maždaug 3 kartus.
  5. Sukonfigūravome automatinį mastelio keitimą į abi puses, kad galėtume susidoroti su padidėjusiu darbo krūviu nepatirdami prastovos išlaidų.
  6. Naudojame Capacity Provider, kad programa valdytų infrastruktūrą (mašinas), o ne atvirkščiai.
  7. Esame puikūs.

Jei turite nuspėjamų apkrovos šuolių, pavyzdžiui, reklamuojate didelėje el. pašto kampanijoje, mastelio keitimą galite nustatyti tvarkaraštis.

Taip pat galite keisti mastelį pagal duomenis iš skirtingų sistemos dalių. Pavyzdžiui, mes turime funkcionalumą individualių reklaminių pasiūlymų siuntimas mobiliosios aplikacijos vartotojų. Kartais kampanija siunčiama daugiau nei 1 mln. žmonių. Po tokio platinimo visada labai padaugėja užklausų į API, nes daugelis vartotojų prisijungia prie programos tuo pačiu metu. Taigi, jei matome, kad reklaminių push pranešimų siuntimo eilėje yra žymiai daugiau standartinių rodiklių, galime iškart paleisti keletą papildomų mašinų ir užduočių, kad būtume pasiruošę apkrovai.

Man bus malonu, jei komentaruose papasakosite įdomių taškinių atvejų ir ECS naudojimo atvejų ar ką nors apie mastelio keitimą.

Netrukus bus straipsnių apie tai, kaip apdorojame tūkstančius analitinių įvykių per sekundę daugiausiai be serverio esančioje dėtuvėje (su pinigais) ir kaip veikia paslaugų diegimas naudojant GitLab CI ir Terraform Cloud.

Prenumeruokite mus, bus įdomu!

Apklausoje gali dalyvauti tik registruoti vartotojai. Prisijungti, Prašau.

Ar gamyboje naudojate taškinius egzempliorius?

  • 22,2%Taip 6

  • 66,7%Nr.18

  • 11,1%Sužinojau apie juos iš straipsnio ir planuoju juos naudoti3

Balsavo 27 vartotojų. 5 vartotojai susilaikė.

Šaltinis: www.habr.com

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