Përshëndetje të gjithë! Unë quhem Kirill, dhe jam CTO në Adapty. Pjesa më e madhe e arkitekturës sonë është në AWS, dhe sot do të flasë mbi atë se si e kemi reduktuar shpenzimet për serverët në 3 herë duke përdorur instanca spot në ambientin prodhues, si dhe si t'i konfiguroshim ato për automatikën e shkallëzimit. Fillimisht do të jap një përmbledhje sesi funksionon, pastaj një udhëzim të detajuar për fillimin.
ĂfarĂ« janĂ« instancat spot?
Instancat janë serverë të përdoruesve të tjerë AWS, të cilët në këtë moment nuk janë në përdorim, dhe ata i shesin ato me një zbritje të madhe (Amazon thotë deri në 90%, sipas përvojës sonë rreth 3x, variaton në varësi të rajonit, AZ dhe tipit të instancës). Dallimi kryesor i tyre nga të zakonshmit është se ata mund të fikën në çdo moment. Prandaj, për një kohë të gjatë menduam se ishte e pranueshme t'i përdornim për mjedise zhvillimi, ose për detyra që llogaritnin diçka, duke ruajtur rezultatet ndërmjetëse në S3 ose në bazë, por jo për prodhim. Ekzistojnë zgjidhje të jashtme që lejojnë përdorimin e spotëve në prodhim, por për rastin tonë ka shumë zgjidhje të thjeshta, prandaj nuk i kemi zbatuar ato. Qasja e përshkruar në artikull funksionon plotësisht brenda funksionalitetit standard të AWS, pa skripta, krone dhe kështu me radhë.
Më poshtë do të jap disa screenshot-e, të cilat tregojnë historikun e çmimeve për instancat spotë.
m5.large nĂ« rajonin eu-west-1 (Irlanda). Ămimi Ă«shtĂ« kryesisht stabil gjatĂ« 3 muajve, aktualisht kursimi Ă«shtĂ« 2.9x.
m5.large nĂ« rajonin us-east-1 (N. Virginia). Ămimi ndryshon vazhdimisht pĂ«r njĂ« periudhĂ« prej 3 muajsh, aktualisht kursimi Ă«shtĂ« nga 2.3x deri nĂ« 2.8x nĂ« varĂ«si tĂ« zonĂ«s sĂ« aksesueshmĂ«risĂ«.
t3.small nĂ« rajonin us-east-1 (N. Virginia). Ămimi Ă«shtĂ« stabil pĂ«r njĂ« periudhĂ« prej 3 muajsh, aktualisht kursimi Ă«shtĂ« 3.4x.
Arkitektura e shërbimit
Arkitektura bazë e shërbimit për të cilin do të flasim në këtë artikull është ilustruar në diagramin më poshtë.
Application Load Balancer â Grupi i Objektivave EC2 â ShĂ«rbimi Elastic Container
Si balancues përdoret Application Load Balancer (ALB), i cili dërgon kërkesat në Grupin e Objektivave EC2 (TG). TG është përgjegjës për hapjen e porteve në instancat për ALB dhe për t'i lidhur ato me portet e kontenjereve të Shërbimit Elastic Container (ECS). ECS është një ekuivalent i Kubernetes në AWS, që menaxhon kontenjerët Docker.
Në një instancë mund të ketë disa kontejnerë aktiv me porte të njëjta, prandaj nuk mund t'i caktomë ato në mënyrë të ngurtë. ECS informon TG se po nis një detyrë të re (në terminologjinë Kubernetes kjo quhet pod), ajo bën një verifikim të porteve të lira në instancë dhe cakton njërën prej tyre për detyrën që po niset. Po ashtu, TG kontrollon në mënyrë të rregullt nëse instanca dhe API-ja në të funksionojnë përmes kontrollit të shëndetit, dhe nëse sheh ndonjë problem, ndalon dërgimin e kërkesave atje.
EC2 Auto Scaling Groups + ECS Capacity Providers
Në diagramin e mësipërm nuk është treguar shërbimi EC2 Auto Scaling Groups (ASG). Nga emri mund të kuptohet se ai përgjigjet për shkallëzimin e instancave. Megjithatë, deri në kohët e fundit në AWS nuk kishte mundësi të integruar për të menaxhuar numrin e makinave të lëna aktiv nga ECS. ECS lejonte shkallëzimin e numrit të detyrave, për shembull, sipas përdorimit të CPU, RAM ose numrit të kërkesave. Por, nëse detyrat zinin të gjitha instancat e lira, makina të reja nuk ngriheshin automatikisht.
Kjo ka ndryshuar me shfaqjen e ECS Capacity Providers (ECS CP). Tani çdo shërbim në ECS mund të lidhet me ASG, dhe nëse detyrat nuk përputhen në instancat aktive, do të ngrihen të reja (por brenda kufijve të vendosur të ASG). Kjo funksionon edhe në anën tjetër, nëse ECS CP sheh instanca të papërdorura pa detyra, ai do të japë urdhër ASG që t'i çaktivizojë ato. ECS CP ka mundësinë të specifikojë përqindjen e targetuar të ngarkesës së instancave, në mënyrë që një numër makinash të jetë gjithmonë i lirë për shkallëzim të shpejtë të detyrave, për këtë do të flas më vonë.
EC2 Launch Templates
Shërbimi i fundit për të cilin do të flas para se të kaloj në përshkrimin e hollësishëm të krijimit të kësaj infrastrukture është EC2 Launch Templates. Ai lejon krijimin e një shablloje sipas së cilës do të nisen të gjitha makinave, për të mos e përsëritur këtë çdo herë nga e para. Këtu mund të zgjidhni tipin e makinës që do të nisni, grupin e sigurisë, imazhin e diskut dhe shumë parametrave të tjerë. Po ashtu, mund të specifiedi të dhëna personalizimi që do të ngarkohen në të gjitha instancat e nisura. Në të dhënat personale mund të realizoni skenarë, për shembull, mund të redaktoni përmbajtjen e një skedari. .
Një nga parametrat më të rëndësishëm të konfiguracionit në këtë artikull është =true. Nëse ky parametr është aktivizuar, sa herë që ECS merr një sinjal se një instancë spot po merret mbrapsht, ai i kalon të gjitha detyrat që punojnë mbi të në statusin Drejtuar. Asnjë detyrë e re nuk do të caktohet për këtë instancë; nëse ka detyra që dëshirojnë të nxirren, ato do të anulohen. Kërkesat nga balansuesi gjithashtu do të ndalen. Njoftimi për heqjen e instancës vjen 2 minuta përpara ngjarjes reale. Prandaj, nëse shërbimi juaj nuk ekzekuton detyra më shumë se 2 minuta dhe nuk ruan asgjë në disk, mund të përdorni instancat spot pa humbje të të dhënave.
Në lidhje me diskun - AWS së fundmi është e mundur përdorimi i Elastic File System (EFS) në bashkëpunim me ECS, me këtë skemë as disku nuk është një pengesë, por ne nuk e kemi provuar atë, pasi në parim nuk na nevojitet disku për ruajtjen e gjendjes. Në parim, pas marrjes së SIGINT (dërgohet në momentin e kalimit të detyrës në statusin Draining) të gjitha detyrat që punojnë do të ndalen brenda 30 sekondash, edhe nëse nuk kanë arritur të përfundojnë, ky kohë mund të modifikohet me parametrin . Gjëja kryesore është të mos e vendosni më shumë se 2 minuta për makinat spot.
Krijimi i shërbimit
Kalojmë drejtpërdrejt në krijimin e shërbimit të përshkruar. Gjatë procesit, do të përshkruaj disa pika të dobishme, të cilat nuk u përmendën më parë. Në përgjithësi, kjo është një udhëzues hap pas hapi, por nuk do të trajtoj asnjë rast të thjeshtë ose anasjelltas shumë specifik. Të gjitha veprimet kryhen në konsolën vizuale të AWS, por ato mund të riprodhohen programatisht me ndihmën e CloudFormation ose Terraform. Në Adapty ne përdorim Terraform.
EC2 Launch Template
Në këtë shërbim krijohet një konfigurim i makinave që do të përdoren. Menaxhimi i shablloneve ndodh në seksionin EC2 -> Instances -> Launch templates.
imazhi i makinĂ«s Amazon (AMI) â specifiko diskun e imazhit, me tĂ« cilin do tĂ« nisin tĂ« gjitha instancat. PĂ«r ECS, nĂ« shumicĂ«n e rasteve, Ă«shtĂ« e rekomanduar tĂ« pĂ«rdorni imazhin e optimizuar nga Amazon. Ai pĂ«rditĂ«sohet rregullisht dhe pĂ«rmban gjithçka tĂ« nevojshme pĂ«r funksionimin e ECS. PĂ«r tĂ« zbuluar ID-nĂ« aktuale tĂ« imazhit, vizitoni faqen , zgjidhni rajonin e pĂ«rdorur dhe kopjoni AMI ID-nĂ« pĂ«r tĂ«. PĂ«r shembull, pĂ«r rajonin us-east-1, ID aktuale nĂ« momentin e shkruar Ă«shtĂ« ami-00c7c1cf5bdc913ed. Kjo ID duhet tĂ« vendoset nĂ« pikĂ«n Specify a custom value.
Lloji i instancĂ«s â specifikoni llojin e instancĂ«s. Zgjidhni atĂ« qĂ« pĂ«rshtatet mĂ« mirĂ« pĂ«r detyrĂ«n tuaj.
Ăifti i çelĂ«save (login) â specifikoni sertifikatin, me tĂ« cilin mund tĂ« lidheni me instancĂ«n pĂ«rmes SSH, nĂ«se Ă«shtĂ« e nevojshme.
CilĂ«simet e rrjetit â specifikoni parametrat e rrjetit. Platforma e rrjetit nĂ« shumicĂ«n e rasteve duhet tĂ« jetĂ« Virtual Private Cloud (VPC). Grupet e sigurisĂ« â grupe sigurie pĂ«r instancat tuaja. Duke qenĂ« se do tĂ« pĂ«rdorim njĂ« balancues para instancave, rekomandoj tĂ« specifikoni kĂ«tu njĂ« grup, i cili lejon lidhjet hyrĂ«se vetĂ«m nga balancuesi. Pra, do tĂ« keni 2 grupe sigurie, njĂ« pĂ«r balancuesin, i cili lejon lidhjet hyrĂ«se nga tĂ« gjitha dretĂ« porteve 80 (http) dhe 443 (https), dhe tjetra pĂ«r makinat, e cila lejon lidhjet hyrĂ«se nga grupi i balancuesit nĂ« çfarĂ«do porti. Lidhjet dalĂ«se nĂ« tĂ« dy grupet duhet tĂ« jenĂ« tĂ« hapura me protokollin TCP nĂ« tĂ« gjitha portet pĂ«r tĂ« gjitha adresat. Mund tĂ« kufizoni portet dhe adresat pĂ«r lidhjet dalĂ«se, por atĂ«herĂ« duhet tĂ« monitoroni vazhdimisht qĂ« tĂ« mos pĂ«rpiqeni tĂ« lidhni diku me ndonjĂ« port tĂ« mbyllur.
Storage (volumes) â specifikojmĂ« parametrat e disqeve pĂ«r makinat. Kapaciteti i diskut nuk mund tĂ« jetĂ« mĂ« i vogĂ«l se ai qĂ« Ă«shtĂ« caktuar nĂ« AMI, pĂ«r ECS Optimized â 30 GiB.
Detaje tĂ« avancuara â specifikojmĂ« parametra tĂ« tjera.
MundĂ«si blerjeje â a dĂ«shirojmĂ« tĂ« blejmĂ« instanca spot. Ne duam, por kĂ«tu nuk do ta shĂ«nojmĂ« kĂ«tĂ«, do ta konfigurojmĂ« nĂ« Grupi i ShkallĂ«zimit Automatik, aty ka mĂ« shumĂ« mundĂ«si.
Profilin IAM tĂ« instancĂ«s â pĂ«rcaktojmĂ« rolin me tĂ« cilĂ«n do tĂ« komandohen instancat. PĂ«r tĂ« funksionuar instancat nĂ« ECS, ata kanĂ« nevojĂ« pĂ«r tĂ« drejta, tĂ« cilat zakonisht ndodhen nĂ« rol ecsInstanceRole. NĂ« disa raste, mund tĂ« krijohet, nĂ«se s'ka, atĂ«herĂ« kĂ«tu pĂ«r tĂ« bĂ«rĂ« kĂ«tĂ«. Pas krijimit, e pĂ«rcaktojmĂ« atĂ« nĂ« model.
Pastaj vijnë shumë parametra, kryesisht mund të lihen vlerat padrão, por çdo një prej tyre ka përshkrim të qartë. Unë gjithmonë përfshij parametrat EBS-optimized instance dhe T2/T3 Unlimited, nëse përdoren instancat.
TĂ« dhĂ«nat e pĂ«rdoruesit â pĂ«rcaktojmĂ« tĂ« dhĂ«nat e pĂ«rdoruesit. Ne do tĂ« redaktojmĂ« skedarin /etc/ecs/ecs.config, nĂ« tĂ« cilin ndodhet konfigurimi i agjentit ECS.
Shembulli i asaj se si mund të duken të dhënat e përdoruesit:
#!/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.configECS_CLUSTER=DemoApiClusterProd â parametri tregon se instanca i pĂ«rket njĂ« klasteri me emrin e dhĂ«nĂ«, qĂ« do tĂ« thotĂ« se ky klaster do tĂ« mund tĂ« vendosĂ« detyrat e tij nĂ« kĂ«tĂ« server. Ne akoma nuk e kemi krijuar klasterin, por gjatĂ« krijimit do tĂ« pĂ«rdorim kĂ«tĂ« emĂ«r.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true â parametri tregon se kur merr sinjal pĂ«r ndĂ«rprerjen e instancĂ«s sĂ« pikave, tĂ« gjitha detyrat nĂ« tĂ« duhet tĂ« transferohen nĂ« statusin Draining.
ECS_CONTAINER_STOP_TIMEOUT=1m â Parametri tregon se pas marrjes sĂ« sinjalit SIGINT, tĂ« gjitha detyrat kanĂ« 1 minutĂ«, para se tĂ« vriten.
ECS_ENGINE_AUTH_TYPE=docker â Parametri tregon se si mekanizĂ«m autentifikimi pĂ«rdoret skema docker.
ECS_ENGINE_AUTH_DATA=... â Parametrat e lidhjes me regjistrin privat tĂ« kontejnerĂ«ve, ku ruhen imazhet tuaja Docker. NĂ«se Ă«shtĂ« publik, atĂ«herĂ« nuk ka nevojĂ« tĂ« tregoni gjĂ«.
Në këtë artikull, do të përdor një imazh publik nga Docker Hub, prandaj nuk ka nevojë të tregoj parametrat ECS_ENGINE_AUTH_TYPE dhe ECS_ENGINE_AUTH_DATA nuk është e nevojshme.
E dobishme të dihet: rekomandohet që të përditësoni rregullisht AMI, sepse në versionet e reja përditësohen versionet e Docker, Linux, agjentit ECS etj. Për të mos e harruar këtë, mund për daljen e versioneve të reja. Ju mund të merrni njoftime në email dhe t'i përditësoni manualisht, ose mund të shkruani një funksion Lambda, i cili automatikisht do të krijojë një version të ri të Shabllonit të Nisjes me AMI të përditësuar.
Grupi i Auto Scaling të EC2
Grupi i Auto Scaling është përgjegjës për nisjen dhe shkallëzimin e instancave. Menaxhimi i grupeve bëhet në seksionin EC2 -> Auto Scaling -> Grupi i Auto Scaling.
Shablloni i nisjes â zgjidhni shabllonin e krijuar nĂ« hapin e mĂ«parshĂ«m. Lini versionin nĂ« parazgjedhje.
Opsionet e blerjes dhe llojet e instancave â specifikohet lloji i instancave pĂ«r klasĂ«n. Adhere to launch template pĂ«rdor llojin e instancĂ«s nga Launch Template. Combine purchase options and instance types lejon tĂ« konfigurosh fleksibĂ«l llojet e instancave. Ne do ta pĂ«rdorim atĂ«.
Baza opcional On-Demand â numri i instancave normale, jo spoto, qĂ« do tĂ« punojnĂ« gjithmonĂ«.
PĂ«rqindja On-Demand mbi bazĂ«n â pĂ«rqindja midis instancave normale dhe atyre spoto, 50-50 do tĂ« ndajĂ« baraz. 20-80 do tĂ« nĂ«nkuptojĂ« se pĂ«r çdo instancĂ« normale do tĂ« ngrihen 4 instanca spoto. NĂ« kĂ«tĂ« rast, do tĂ« tregoj 50-50, por nĂ« tĂ« vĂ«rtetĂ« shpesh bĂ«jmĂ« 20-80, nĂ« disa raste 0-100.
Llojet e instancave â kĂ«tu mund tĂ« specifikoni lloje tĂ« tjera instancash qĂ« do tĂ« pĂ«rdoren nĂ« klasĂ«n. Ne kurrĂ« nuk kemi pĂ«rdorur, sepse nuk e kuptoj shumĂ« kuptimin e kĂ«saj historie. Ndoshta Ă«shtĂ« çështje e kufijve pĂ«r lloje tĂ« caktuara instancash, por ato rriten lehtĂ«sisht pĂ«rmes mbĂ«shtetjes. NĂ«se e dini aplikimin, do tĂ« isha i lumtur tĂ« lexoj nĂ« komente)
Rrjeti regjistro log /dev/log local0 regjistro log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s pĂ«rdorues haproxy grup haproxy daemondefaults log global mode http opsion httplog opsion dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check â konfigurimet e rrjetit, zgjidhni VPC dhe subnetet pĂ«r makinat, nĂ« shumicĂ«n e rasteve Ă«shtĂ« mĂ« mirĂ« tĂ« zgjidhni tĂ« gjitha subnetet e disponueshme.
Balancimi i ngarkesĂ«s â konfigurimet e balancuesit, por ne do ta bĂ«jmĂ« atĂ« veçmas, kĂ«tu nuk prekim asgjĂ«. Kontrolli i shĂ«ndetit do tĂ« konfigurohen mĂ« vonĂ«.
Shuma e grupit â caktojmĂ« kufijtĂ« pĂ«r numrin e makinave nĂ« klasĂ«r dhe numrin e dĂ«shiruar tĂ« makinave nĂ« fillim. Numri i makinave nĂ« klasĂ«r nuk do tĂ« jetĂ« kurrĂ« mĂ« i vogĂ«l se sa minimali i caktuar dhe mĂ« i madh se maksimumi, edhe nĂ«se sipas statistikave duhet tĂ« ndodhĂ« shkallĂ«zimi.
Politikat e shkallĂ«zimit â parametrat e shkallĂ«zimit, por ne do tĂ« shkallĂ«zojmĂ« duke u bazuar nĂ« detyrat e ECS tĂ« cilat janĂ« aktive, prandaj do ta konfigurojmĂ« shkallĂ«zimin mĂ« vonĂ«.
Mbrojtja nga shkurtimi i instancave â mbrojtje e instancave nga fshirja gjatĂ« shkallĂ«zimit poshtĂ«. Aktivizohet qĂ« ASG tĂ« mos fshijĂ« makinĂ«n qĂ« ka detyra aktive. Do tĂ« çaktivizohet mbrojtja pĂ«r instancat qĂ« nuk kanĂ« detyra, qĂ« do tĂ« realzohet nga ECS Capacity Provider.
Shto etiketat â mund tĂ« specifikoni etiketa pĂ«r instancat (pĂ«r kĂ«tĂ« duhet tĂ« jetĂ« e shĂ«nuar kutia Tag new instances). Rekomandoj tĂ« specifikoni etiketĂ«n Name, kĂ«shtu qĂ« tĂ« gjitha instancat qĂ« nxjerrin nĂ« grup do tĂ« kenĂ« tĂ« njĂ«jtin emĂ«r dhe do tĂ« jetĂ« mĂ« e lehtĂ« t'i shihni nĂ« konsolĂ«.
Pasi të krijoni grupin, hapeni dhe shkoni në seksionin Advanced configurations, pse gjatë procesit të krijimit në konsolë nuk duken të gjitha opsionet.
Politikat e pĂ«rfundimit â rregullat qĂ« merren parasysh gjatĂ« fshirjes sĂ« instancave. Ato zbatohen nĂ« rend. Ne zakonisht pĂ«rdorim ato si nĂ« imazhin mĂ« poshtĂ«. SĂ« pari, fshihen instancat me Template-in mĂ« tĂ« vjetĂ«r tĂ« Lancimit (pĂ«r shembull, nĂ«se kemi pĂ«rditĂ«suar AMI-nĂ«, Ă«shtĂ« krijuar njĂ« version i ri, por tĂ« gjitha instancat kanĂ« kaluar nĂ« tĂ«). Pastaj zgjidhen instancat qĂ« janĂ« mĂ« afĂ«r orĂ«s sĂ« ardhshme tĂ« llogaritjes sipas faturimit. Dhe mĂ« pas zgjidhen ato mĂ« tĂ« vjetrat sipas datĂ«s sĂ« nisjes.
E dobishme tĂ« dihet: pĂ«r pĂ«rditĂ«simin e tĂ« gjitha makinave nĂ« klaster, Ă«shtĂ« e pĂ«rshtatshme tĂ« pĂ«rdoret . NĂ«se e kombinojmĂ« kĂ«tĂ« me njĂ« funksion Lambda nga hapi i mĂ«parshĂ«m, do tĂ« keni njĂ« sistem tĂ« plotĂ« pĂ«r automatizimin e pĂ«rditĂ«simit tĂ« instancave. Para se tĂ« pĂ«rditĂ«soni tĂ« gjitha makinat, Ă«shtĂ« e nevojshme tĂ« çaktivizoni mbrojtjen pĂ«r shkallĂ«zim nĂ« grup pĂ«r tĂ« gjitha instancat nĂ« grup. Jo konfigurimin nĂ« grup, por mbrojtjen e instancave, kjo bĂ«het nĂ« ĐČĐșлаЎĐșĐ° Menaxhimi i Instancave.
Balancuesi i Ngarkesës Aplikative dhe Grupi i Objektivave EC2
Balancuesi krijohet nĂ« seksionin EC2 â Balancimi i NgarkesĂ«s â Balancuesit e NgarkesĂ«s. Ne do tĂ« pĂ«rdorim Balancuesin e NgarkesĂ«s Aplikative, krahasimi i llojeve tĂ« ndryshme tĂ« balancuesve mund tĂ« lexohet nĂ« .
DĂ«gjuesit â ka sens tĂ« krijoni portet 80 dhe 443 dhe tĂ« bĂ«ni njĂ« ridirektim nga 80 nĂ« 443 mĂ« pas me ndihmĂ«n e rregullave tĂ« balancuesit.
Zona tĂ« Disponibilitetit â nĂ« shumicĂ«n e rastĂ«ve zgjidhim tĂ« gjitha zonat e disponueshmĂ«risĂ«.
Konfiguro CilĂ«simet e SigurisĂ« â kĂ«tu tregohet certifikata SSL pĂ«r balancuesin, opsioni mĂ« i pĂ«rshtatshĂ«m Ă«shtĂ« nĂ« ACM. PĂ«r dallimet Politika e SigurisĂ« mund tĂ« lexoni nĂ« , mund tĂ« lĂ«ni atĂ« tĂ« zgjedhur si parazgjedhje ELBSecurityPolicy-2016-08. Pas krijimit tĂ« balancuesit, do tĂ« shihni emrin DNS, pĂ«r tĂ« cilin duhet tĂ« konfiguroni CNAME pĂ«r domenin tuaj. PĂ«r shembull, kĂ«shtu duket nĂ« Cloudflare.
Grupi i SigurisĂ« â krijojmĂ« ose zgjedhim njĂ« grup sigurie pĂ«r balancuesin, mĂ« shumĂ« rreth kĂ«saj kam shkruar pak mĂ« sipĂ«r nĂ« seksionin EC2 Launch Template â CilĂ«simet e rrjetit.
Grupi i Objektivave â krijojmĂ« njĂ« grup qĂ« Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r rrouterimin e kĂ«rkesave nga balancuesi tek makinat dhe kontrollon disponueshmĂ«rinĂ« e tyre pĂ«r t'u zĂ«vendĂ«suar nĂ« rast problemesh. Tipi i Objektivit duhet tĂ« jetĂ« Instance, Protokolli dhe Port çdo, nĂ«se pĂ«rdorni HTTPS pĂ«r komunikimin midis balancuesit dhe instancave, atĂ«herĂ« duhet tĂ« ngarkoni certifikatĂ«n tek ato. NĂ« kuadĂ«r tĂ« kĂ«tij shembulli nuk do ta bĂ«jmĂ« kĂ«tĂ«, thjesht do ta lĂ«mĂ« portin 80.
Kontrolli i shĂ«ndetit â parametrat e kontrollit tĂ« funksionimit tĂ« shĂ«rbimit. NĂ« kĂ«tĂ« shĂ«rbim, kjo duhet tĂ« jetĂ« njĂ« kĂ«rkesĂ« e veçantĂ«, e cila realizon pjesĂ«t e rĂ«ndĂ«sishme tĂ« logjikĂ«s biznesore; pĂ«r kĂ«tĂ« shembull, unĂ« do tĂ« lĂ« cilĂ«simet siç janĂ«. MĂ« pas, mund tĂ« zgjidhni intervalin e kĂ«rkesave, kohĂ«n e pritjes, kodet e pĂ«rgjigjeve tĂ« suksesshme dhe tĂ« tjera. NĂ« shembullin tonĂ« do tĂ« specifikojmĂ« kodet e suksesit 200-399, sepse imazhi Docker qĂ« do tĂ« pĂ«rdoret ktheu kodin 304.
Regjistro Targets â kĂ«tu zgjidhen makinat pĂ«r grupin, por nĂ« rastin tonĂ«, kĂ«tĂ« do ta bĂ«jĂ« ECS, prandaj thjesht kalojmĂ« kĂ«tĂ« hap.
E dobishme të dihet: në nivelin e balancuesit të ngarkesave mund të aktivizoni logë, të cilat do të ruhen në S3 në një . Prej aty, mund t'i eksportoni në shërbime të palës së tretë për analitikë, ose mund të bëni kërkesa SQL direkt në të dhënat në S3 me . Kjo është e përshtatshme dhe funksionon pa ndonjë kod të shtuar. Gjithashtu, rekomandoj të konfiguroni fshirjen e logëve nga baku S3 pas kalimit të një periudhe të caktuar kohore.
Përcaktimi i Detyrës ECS
NĂ« hapat e mĂ«parshĂ«m, krijuam gjithçka qĂ« ka tĂ« bĂ«jĂ« me infrastrukturĂ«n e shĂ«rbimit, tani po kalojmĂ« nĂ« pĂ«rshkrimin e kontejnerĂ«ve qĂ« do tĂ« lançojmĂ«. Kjo bĂ«het nĂ« seksionin ECS â Definicionet e Task-eve.
PĂ«rshtatshmĂ«ria e llojit tĂ« lançimit â zgjidhni EC2.
Roli IAM i ekzekutimit tĂ« task-eve â zgjidhni ecsTaskExecutionRole. PĂ«rmes saj e shkruhen log-et, jepet akses nĂ« variablat sekretĂ« dhe tĂ« tjera.
Në seksionin Definicionet e Kontejnerëve, klikoni Shto Kontejner.
Image â linku nĂ« imazhin me kodin e projektit, nĂ« kĂ«tĂ« shembull do tĂ« pĂ«rdor njĂ« imazh publik nga Docker Hub .
Kufizimet e Memories â kufizimet mbi memorinĂ« pĂ«r kontejnerin. Kufiri i FortĂ« â kufiri i fortĂ«, nĂ«se kontejneri kalon vlerĂ«n e specifikuar, komanda docker kill do tĂ« ekzekutohet, kontejneri do tĂ« vdesĂ« menjĂ«herĂ«. Kufiri i ButĂ« â kufiri i butĂ«, kontejneri mund tĂ« kalojĂ« vlerĂ«n e specifikuar, por gjatĂ« vendosjes sĂ« detyrave nĂ« makina do tĂ« merret parasysh ky pĂ«rllogaritje. PĂ«r shembull, nĂ«se nĂ« makinĂ« ka 4 GiB memorie tĂ« punĂ«s, dhe kufiri i butĂ« i kontejnerit Ă«shtĂ« 2048 MiB, atĂ«herĂ« maksimumi i detyrave qĂ« mund tĂ« funksionojnĂ« nĂ« kĂ«tĂ« makinĂ« me kĂ«tĂ« kontejner Ă«shtĂ« 2. NĂ« tĂ« vĂ«rtetĂ«, 4 GiB memorie tĂ« punĂ«s Ă«shtĂ« pak mĂ« pak se 4096 MiB, mund ta shihni kĂ«tĂ« nĂ« skedarin ECS Instances nĂ« klastrin. Kufiri i butĂ« nuk mund tĂ« jetĂ« mĂ« i madh se kufiri i fortĂ«. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se nĂ«se njĂ« detyrĂ« ka disa kontejnerĂ«, atĂ«herĂ« kufijtĂ« e tyre pĂ«rmbledhen.
Harta e porteve â nĂ« Porti i hostit nĂ«se specifikoni 0, do tĂ« thotĂ« se porta do tĂ« caktohet dinamikisht, dhe do tĂ« monitorohet nga Grupi i Objektivave. Porti i kontejnerit â porta nĂ« tĂ« cilĂ«n funksionon aplikacioni juaj, shpesh pĂ«rcaktohet nĂ« komandĂ«n pĂ«r ekzekutim ose caktohet nĂ« kodin e aplikacionit tuaj, Dockerfile etj. PĂ«r shembullin tonĂ«, pĂ«rdorim 3000, sepse Ă«shtĂ« e specifikuar nĂ« imazhin e pĂ«rdorur.
Kontrolli i shĂ«ndetit â parametrat e kontrollit tĂ« funksionit tĂ« kontejnerit, mos e ngatĂ«rroni atĂ« me atĂ« tĂ« cilin e ka caktuar Grupi i Objektivave.
Mjedisi â cilĂ«simet e mjedisit. NjĂ«sitĂ« CPU â ngjan me kufijtĂ« e memories, vetĂ«m pĂ«r procesorin. Ădo bĂ«rthamĂ« procesori â 1024 njĂ«si, kĂ«shtu qĂ« nĂ«se serveri ka njĂ« procesor dy-bĂ«rthamĂ«sh dhe vlera e caktuar pĂ«r kontejnerin Ă«shtĂ« 512, atĂ«herĂ« nĂ« njĂ« server mund tĂ« ekzekutohen 4 detyra me kĂ«tĂ« kontejner. NjĂ«sitĂ« CPU gjithmonĂ« pĂ«rputhen me numrin e bĂ«rthamave, nuk mund tĂ« jenĂ« pak mĂ« pak siç Ă«shtĂ« rasti me memorien.
Komanda â urdhr pĂ«r tĂ« nisur shĂ«rbimin brenda konteinerrit, tĂ« gjitha parametrat japin nĂ«pĂ«rmjet presjes. Kjo mund tĂ« jetĂ« gunicorn, npm etj. NĂ«se nuk Ă«shtĂ« specifikuar, do tĂ« pĂ«rdoret vlera e drejtorisĂ« CMD nga Dockerfile. Specifikoni npm,start.
Variablat e mjedisit â variablat e mjedisit tĂ« kontejnerit. KĂ«to mund tĂ« jenĂ« si tĂ« dhĂ«na tekstuale, ashtu edhe variabla sekret nga ose .
Ruajtja dhe Ekuipazhi â kĂ«tu do tĂ« konfiguroni regjistrimin nĂ« CloudWatch Logs (shĂ«rbimi pĂ«r regjistrat nga AWS). PĂ«r kĂ«tĂ«, mjafton tĂ« aktivizoni opsionin Auto-configure CloudWatch Logs. Pas krijimit tĂ« Task Definition, automatikisht do tĂ« krijohet njĂ« grup regjistrash nĂ« CloudWatch. Sipas parazgjedhjes, regjistrat nĂ« tĂ« ruhen pafundĂ«sisht, rekomandoj tĂ« ndryshoni periudhĂ«n e ruajtjes nga Never Expire nĂ« periudhĂ«n e kĂ«rkuar. Kjo bĂ«het nĂ« grupet e regjistrave CloudWatch, duhet tĂ« klikoni nĂ« periudhĂ«n aktuale dhe tĂ« zgjidhni njĂ« tĂ« re.
ECS Cluster dhe ECS Capacity Provider
Shkoni nĂ« seksionin ECS â Klustera pĂ«r tĂ« krijuar njĂ« kluster. Si model zgjidhni EC2 Linux + RrjetĂ«zim.
Emri i klustrit â Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme, bĂ«ni kĂ«tu tĂ« njĂ«jtin emĂ«r siç Ă«shtĂ« treguar nĂ« Shabllonin e Lancimit nĂ« parametrin ECS_CLUSTER, nĂ« rastin tonĂ« â DemoApiClusterProd. ShĂ«noni kutinĂ« Create an empty cluster. Opsional mund tĂ« aktivizoni Container Insights pĂ«r tĂ« parĂ« metrikat pĂ«r shĂ«rbimet nĂ« CloudWatch. NĂ«se keni bĂ«rĂ« gjithçka siç duhet, nĂ« seksionin ECS Instances do tĂ« shihni makinat qĂ« janĂ« krijuar nĂ« grupin Auto Scaling.
Shkosh nĂ« skedĂ«n Furnizuesit e kapacitetit dhe krijoni tĂ« ri. KujtojmĂ« se ai Ă«shtĂ« i nevojshĂ«m pĂ«r tĂ« menaxhuar krijimin dhe fikjen e makinave sipas numrit tĂ« ECS taskeve qĂ« po punojnĂ«. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se furnizuesi mund tĂ« lidhĂ«t vetĂ«m me njĂ« grup.
Grupi i Auto Scaling â zgjidhni grupin qĂ« Ă«shtĂ« krijuar mĂ« parĂ«.
ShkallĂ«zimi i menaxhuar â aktivizoni nĂ« mĂ«nyrĂ« qĂ« furnizuesi tĂ« mund tĂ« shkallĂ«zojĂ« shĂ«rbimin.
Kapaciteti i targetuar % â sa duhet tĂ« jetĂ« cila Ă«shtĂ« pĂ«rqindja e ngarkesĂ«s sĂ« makinave me detyra. NĂ«se specifikoni 100%, tĂ« gjitha makinat do tĂ« jenĂ« gjithmonĂ« tĂ« zĂ«na me detyra aktive. NĂ«se specifikoni 50%, gjysma e makinave do tĂ« jenĂ« gjithmonĂ« tĂ« lira. NĂ« kĂ«tĂ« rast, nĂ«se ndodh njĂ« rritje e papritur nĂ« ngarkesĂ«, taksitĂ« e reja do tĂ« shkojnĂ« menjĂ«herĂ« nĂ« makinat e lira, pa nevojĂ«n pĂ«r tĂ« pritur pĂ«r shpĂ«rndarjen e instancave.
Mbrojtje e menaxhuar pĂ«r ndĂ«rprerje â e aktivizojmĂ«, ky parameter lejon ofruesin tĂ« heqĂ« mbrojtjen nga fshirja e instancave. Kjo ndodh kur nĂ« makinĂ« nuk ka detyra aktive dhe lejon Target capacity %.
Shërbimi ECS dhe konfigurimi i shkallëzimit
Hapi i fundit :) Për të krijuar një shërbim, duhet të hyni në klasterin e krijuar më parë në seksionin Shërbimet.
Lloji i lançimit â duhet tĂ« klikoni nĂ« Switch to capacity provider strategy dhe tĂ« zgjidhni ofruesin e krijuar mĂ« parĂ«.
PĂ«rkufizimi i detyrĂ«s â zgjidhim pĂ«rkufizimin e detyrĂ«s sĂ« krijuar mĂ« parĂ« dhe pĂ«rmirĂ«simin e tij.
Emri i shĂ«rbimit â pĂ«r tĂ« mos u ngatĂ«rruar, ne gjithmonĂ« e specifikojmĂ« tĂ« njĂ«jtin si pĂ«rkufizimi i detyrĂ«s.
Lloji i shĂ«rbimit â gjithmonĂ« Replica.
Numri i detyrave â numri i dĂ«shiruar i detyrave aktive nĂ« shĂ«rbim. Ky parameter menaxhohet nga shkallĂ«zimi, por gjithsesi duhet ta especificoni.
PĂ«rqindja minimale e shĂ«ndetshme dhe PĂ«rqindja maksimale â pĂ«rcakton sjelljen e detyrave gjatĂ« implementimit. Vlerat e paracaktuara 100 dhe 200 tregojnĂ« se gjatĂ« implementimit numri i detyrave do tĂ« rritet disa herĂ«, dhe mĂ« pas do tĂ« kthehet nĂ« tĂ« dĂ«shirueshĂ«m. NĂ«se keni njĂ« detyrĂ« nĂ« punĂ«, min=0, dhe max=100, atĂ«herĂ« gjatĂ« implementimit do tĂ« eliminohet, dhe pas kĂ«saj do tĂ« ngrihet njĂ« e re, qĂ« do tĂ« thotĂ« se do tĂ« ketĂ« njĂ« ndalesĂ«. NĂ«se Ă«shtĂ« nĂ« punĂ« njĂ« detyrĂ«, min=50, max=150, atĂ«herĂ« implementimi nuk do tĂ« ndodh, sepse njĂ« detyrĂ« nuk mund tĂ« ndahet nĂ« dy ose tĂ« rritet nĂ« njĂ« dhe njĂ« gjysmĂ«.
Lloji i implementimit â lĂ«mĂ« Rolling update.
ShabllonĂ«t e vendosjes â rregullat e vendosjes sĂ« detyrave nĂ« makina. PĂ«r parazgjedhje Ă«shtĂ« AZ Balanced Spread â do tĂ« thotĂ« se çdo detyrĂ« e re do tĂ« vendoset nĂ« njĂ« instancĂ« tĂ« re deri sa tĂ« ngrihen makinat nĂ« tĂ« gjitha zonat e disponueshmĂ«risĂ«. Ne zakonisht e bĂ«jmĂ« BinPack â CPU dhe Spread â AZ, me kĂ«tĂ« politikĂ« detyrat vendosen sa mĂ« afĂ«r qĂ« tĂ« jetĂ« e mundur nĂ« njĂ« makinĂ« sipas CPU. NĂ«se Ă«shtĂ« e nevojshme tĂ« krijohet njĂ« makinĂ« e re, ajo krijohet nĂ« njĂ« zonĂ« tĂ« re disponueshmĂ«rie.
Lloji i balancuesit tĂ« ngarkesĂ«s â zgjedhim Application Load Balancer.
Roli IAM i shĂ«rbimit â zgjedhim ecsServiceRole.
Emri i balancuesit tĂ« ngarkesĂ«s â zgjedhim balancuesin e krijuar mĂ« parĂ«.
Periudha e miratimit tĂ« kontrollit tĂ« shĂ«ndetit â pauza para ekzekutimin e kontrollit tĂ« funksionit pas lĂ«shimit tĂ« njĂ« detyre tĂ« re, zakonisht e vendosim nĂ« 60 sekonda.
Konteineri pĂ«r balancimin e ngarkesĂ«s â nĂ« pikĂ«n Emri i grupit tĂ« destinacionit zgjedhim grupin e krijuar mĂ« parĂ« dhe gjithçka do tĂ« plotĂ«sohet automatikisht.
ShĂ«rbimi i Auto-Skalimit â parametrat e skalimit tĂ« shĂ«rbimit. Zgjedhim Configure Service Auto Scaling to adjust your serviceâs desired count. Vendosim numrin minimal dhe maksimal tĂ« detyrave gjatĂ« skalimit.
Roli IAM pĂ«r ShĂ«rbimin e Auto-Skalimit â zgjedhim AWSServiceRoleForApplicationAutoScaling_ECSService.
Politikat e automatizuara tĂ« skalimit tĂ« detyrave â rregullat pĂ«r skalimin. Ka 2 lloje:
- Ndjekja e objektivave â ndjekja e metrikĂ«s sĂ« synuar (pĂ«rdorimi i CPU/RAM ose numri i kĂ«rkesave pĂ«r secilĂ«n detyrĂ«). PĂ«r shembull, ne duam qĂ« ngarkesa mesatare e procesorit tĂ« jetĂ« 85%, kur ajo tĂ« kalojĂ«, detyrat e reja do tĂ« shtohen derisa tĂ« arrijĂ« nĂ« vlerĂ«n e synuar. NĂ«se ngarkesa Ă«shtĂ« mĂ« poshtĂ«, atĂ«herĂ« detyrat do tĂ« hiqen, nĂ«se nuk Ă«shtĂ« aktivizuar mbrojtja nga zvogĂ«limi (Ăaktivizo zvogĂ«limin).
- Skalimi me hapa â reagimi ndaj ndodhisĂ« sĂ« rastĂ«sishme. KĂ«tu mund tĂ« pĂ«rcaktoni reagimin ndaj çdo ngjarjeje (Alarmi i CloudWatch), kur ajo ndodh, mund tĂ« shtoni ose hiqni numrin e caktuar tĂ« detyrave, ose tĂ« pĂ«rcaktoni saktĂ«sisht numrin e detyrave.
Shërbimi mund të ketë disa rregulla skalmimi, kjo mund të jetë e dobishme, por është thelbësore të siguroheni që ato të mos bien në konflikt me njëra-tjetrën.
PĂ«rfundimi
Nëse keni ndjekur udhëzimet dhe keni përdorur të njëjtën imazh Docker, shërbimi juaj duhet të kthejë një faqe të tillë.
- Kemi krijuar një model sipas të cilit aktivizohen të gjitha makinat në shërbim. Po ashtu, kemi mësuar të përditësojmë makinat kur modelit i bëhen ndryshime.
- Kemi konfiguruar përpunimin e sinjalit të ndalimit të instancës së tillë, kështu që brenda një minute pas marrjes së tij, të gjitha detyrat aktive hiqen nga makina, duke siguruar që asgjë të mos humbasë apo të ndërpritet.
- Kemi ngritur një balancues, për të shpërndarë ngarkesën në mënyrë të barabartë mbi makinat.
- Kemi krijuar një shërbim që funksionon në instancat e pikave, duke arritur kështu të reduktojmë shpenzimet për makinat afërsisht në 3 herë.
- Ne kemi konfiguruan auto-skalimin në të dyja drejtimet për të trajtuar rritjen e ngarkesave, por në të njëjtën kohë për të mos paguar për shkallëzim të tepruar.
- Ne përdorim Capacity Provider, që aplikacioni të menaxhojë infrastrukturën (makinat), dhe jo anasjelltas.
- Jemi të mrekullueshëm.
Nëse keni shpërthime të parashikueshme në ngarkesë, për shembull, nëse bëni reklamim në një listë të madhe të postës elektronike, mund të konfiguroni skalimin sipas .
Po ashtu, është e mundur të bëni skalim në bazë të të dhënave nga pjesë të ndryshme të sistemit tuaj. Për shembull, kemi funksionalitetin përdoruesve të aplikacionit mobil. Ndonjëherë, një fushatë dërgohet për 1M+ njerëz. Pas një dërgese të tillë, gjithmonë vërehet një rritje e madhe e kërkesave në API, pasi shumë përdorues hyjnë në aplikacion në të njëjtën kohë. Kështu që, nëse shohim se në radhën për dërgimin e njoftimeve promovuese ka shumë më tepër se sa indikatorët standardë, ne mund të aktivizojmë menjëherë disa makina dhe detyra shtesë për të qenë të gatshëm për ngarkesën.
Do të isha i lumtur nëse në komentet do të ndani raste interesante të përdorimit të instancave të spoteve dhe ECS apo diçka mbi skalimin.
Së shpejti do të publikojmë artikuj për mënyrën se si përpunojmë mijëra ngjarje analitike në sekondë në një stack kryesisht pa serverë (me para) dhe si organizohet deploy i shërbimeve me ndihmën e GitLab CI dhe Terraform Cloud.
Na ndiqni, do të jetë interesante!
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutemi.
A përdorni instanca spot në prodhim?
22,2%Po
66,7%Jo18
11,1%Mësoj për ta nga një artikull, planifikoj të përdor.
27 përdorues votuan. 5 përdorues abstenuan.
Burimi: habr.com
