Saluton al ĉiuj! Mi nomiĝas Kirill, mi estas CTO ĉe Adapty. Plejparto de nia arkitekturo estas sur AWS, kaj hodiaŭ mi parolos pri kiel ni reduktis servilkostojn je 3 fojojn uzante punktojn en produktadmedio, kaj ankaŭ kiel agordi ilian aŭtomatan skalon. Unue estos superrigardo pri kiel ĝi funkcias, kaj poste detalaj instrukcioj por komenci.
Kio estas Spot-Instancoj?
petskriboj estas serviloj de aliaj AWS-uzantoj, kiuj nuntempe estas neaktivaj, kaj ili vendas ilin kun granda rabato (Amazono skribas ĝis 90%, laŭ nia sperto ~3x, varias depende de la regiono, AZ kaj instanco-tipo). Ilia ĉefa diferenco de regulaj estas, ke ili povas malŝalti iam ajn. Tial ni longe kredis, ke estas normale uzi ilin por virgaj medioj, aŭ por taskoj de kalkulo de io, kun mezaj rezultoj konservitaj en S3 aŭ en la datumbazo, sed ne por vendoj. Estas triaj solvoj, kiuj permesas vin uzi makulojn pri produktado, sed estas multaj lambastonoj por nia kazo, do ni ne efektivigis ilin. La aliro priskribita en la artikolo funkcias tute ene de la norma AWS-funkcio, sen pliaj skriptoj, kronoj ktp.
Malsupre estas kelkaj ekrankopioj, kiuj montras la prezhistorion por punktoj.
m5.granda en la regiono eu-west-1 (Irlando). Prezo estis plejparte stabila dum 3 monatoj, nuntempe ŝparante 2.9x.
m5.granda en la us-orient-1-regiono (N. Virginio). La prezo konstante ŝanĝas dum 3 monatoj, nuntempe ŝparante de 2.3x al 2.8x depende de la havebleca zono.
t3.malgranda en la us-orient-1-regiono (N. Virginio). Prezo estas stabila dum 3 monatoj, nuntempe ŝparante 3.4x.
Serva arkitekturo
La baza arkitekturo de la servo, pri kiu ni parolos en ĉi tiu artikolo, estas montrita en la suba diagramo.
Aplika Ŝarĝbalancilo → EC2 Celgrupo → Elasta Uja Servo
La Aplikaĵo-Ŝarĝbalancilo (ALB) estas uzata kiel ekvilibristo, kiu sendas petojn al la EC2 Celgrupo (TG). TG respondecas pri malfermado de havenoj sur petskriboj por ALBoj kaj ligado de ili al havenoj de Elastic Container Service (ECS) ujoj. ECS estas analogo de Kubernetes en AWS, kiu administras Docker-ujojn.
Unu okazo povas havi plurajn kurantajn ujojn kun la samaj havenoj, do ni ne povas fiksi ilin fikse. ECS diras al TG, ke ĝi lanĉas novan taskon (en Kubernetes-terminaro tio nomiĝas pod), ĝi kontrolas pri liberaj pordoj sur la petskribo kaj asignas unu el ili al la lanĉita tasko. TG ankaŭ regule kontrolas ĉu la petskribo kaj la API laboras pri ĝi uzante sankontrolon, kaj se ĝi vidas problemojn, ĝi ĉesas sendi petojn tie.
EC2 Aŭtomata Skalado-Grupoj + ECS-Kapacaj Provizantoj
La supra diagramo ne montras la servon EC2 Auto Scaling Groups (ASG). De la nomo vi povas kompreni, ke ĝi respondecas pri skalo de okazoj. Tamen, ĝis antaŭ nelonge, AWS ne havis enkonstruitan kapablon administri la nombron da kurantaj maŝinoj de ECS. ECS ebligis skali la nombron da taskoj, ekzemple, per CPU-uzo, RAM aŭ nombro da petoj. Sed se taskoj okupis ĉiujn senpagajn okazojn, tiam novaj maŝinoj ne estis aŭtomate kreitaj.
Ĉi tio ŝanĝiĝis kun la apero de ECS Capacity Providers (ECS CP). Nun ĉiu servo en ECS povas esti asociita kun ASG, kaj se la taskoj ne konvenas al la kurantaj petskriboj, tiam novaj estos levitaj (sed ene de la establitaj ASG-limoj). Ĉi tio ankaŭ funkcias en la kontraŭa direkto, se ECS CP vidas neaktivajn okazojn sen taskoj, tiam ĝi donos la ASG-komandon por fermi ilin. ECS CP havas la kapablon specifi celprocenton de ekzempla ŝarĝo, tiel ke certa nombro da maŝinoj ĉiam estas liberaj por rapide grimpi taskojn; pri tio mi iom poste parolos.
EC2 Lanĉaj Ŝablonoj
La lasta servo pri kiu mi parolos antaŭ ol eniri en detalojn pri kreado de ĉi tiu infrastrukturo estas EC2 Launch Templates. Ĝi ebligas al vi krei ŝablonon laŭ kiu ĉiuj maŝinoj komenciĝos, por ne ripeti ĉi tion de nulo ĉiufoje. Ĉi tie vi povas elekti la tipon de maŝino por komenci, sekurecan grupon, diskbildon kaj multajn aliajn parametrojn. Vi ankaŭ povas specifi uzantajn datumojn, kiuj estos alŝutitaj al ĉiuj lanĉitaj okazoj. Vi povas ruli skriptojn en uzantdatumoj, ekzemple, vi povas redakti la enhavon de dosiero .
Unu el la plej gravaj agordaj parametroj por ĉi tiu artikolo estas =vero. Se ĉi tiu parametro estas ebligita, tiam tuj kiam ECS ricevas signalon, ke punkto-instanco estas forprenita, ĝi transdonas ĉiujn taskojn, kiuj funkcias pri ĝi, al la stato de Drenado. Neniuj novaj taskoj estos asignitaj al ĉi tiu kazo; se estas taskoj kiuj volas esti lanĉitaj al ĝi nun, ili estos nuligitaj. Petoj de la ekvilibristo ankaŭ ĉesas veni. Sciigo pri forigo de ekzemplo venas 2 minutojn antaŭ la reala evento. Tial, se via servo ne plenumas taskojn pli longajn ol 2 minutojn kaj ne konservas ion ajn sur disko, tiam vi povas uzi punktojn sen perdi datumojn.
Koncerne diskon - AWS lastatempe Eblas uzi la Elastan Dosiersistemon (EFS) kune kun ECS; kun ĉi tiu skemo, eĉ la disko ne estas malhelpo, sed ni ne provis tion, ĉar principe ni ne bezonas la diskon por konservi la staton. Defaŭlte, post ricevo de SIGINT (sendita kiam tasko estas translokigita al la stato de Drenado), ĉiuj kurantaj taskoj estos ĉesigitaj post 30 sekundoj, eĉ se ili ankoraŭ ne finiĝis; vi povas ŝanĝi ĉi tiun fojon uzante la parametron. . La ĉefa afero estas ne agordi ĝin dum pli ol 2 minutoj por spotaj maŝinoj.
Kreante servon
Ni daŭrigu krei la priskribitan servon. En la procezo, mi aldone priskribos plurajn utilajn punktojn, kiuj ne estis menciitaj supre. Ĝenerale, ĉi tio estas paŝo post paŝo, sed mi ne konsideros iujn tre bazajn aŭ, male, tre specifajn kazojn. Ĉiuj agoj estas faritaj en la AWS-vida konzolo, sed povas esti reproduktitaj programe per CloudFormation aŭ Terraform. Ĉe Adapty ni uzas Terraform.
EC2 Lanĉa Ŝablono
Ĉi tiu servo kreas agordon de maŝinoj, kiuj estos uzataj. Ŝablonoj estas administritaj en la sekcio EC2 -> Instancoj -> Lanĉi ŝablonojn.
Amazona maŝinbildo (AMI) — specifu la diskobildon per kiu ĉiuj okazoj estos lanĉitaj. Por ECS, plejofte indas uzi la optimumigitan bildon de Amazon. Ĝi estas regule ĝisdatigita kaj enhavas ĉion necesan por ke ECS funkciu. Por ekscii la nunan bildan ID, iru al la paĝo , elektu la regionon, kiun vi uzas kaj kopiu la AMI-ID por ĝi. Ekzemple, por la us-orienta-1-regiono, la nuna ID en la momento de skribado estas ami-00c7c1cf5bdc913ed. Ĉi tiu identigilo devas esti enmetita en la Specifi propran valoran objekton.
Speco de kazo — indiku la instantan tipon. Elektu tiun, kiu plej taŭgas por via tasko.
Ŝlosilparo (ensaluto) — specifu atestilon kun kiu vi povas konekti al la petskribo per SSH, se necese.
Retaj agordoj — specifu la retajn parametrojn. Interliga platformo plejofte devus ekzisti Virtuala Privata Nubo (VPC). Sekurecaj grupoj — sekurecaj grupoj por viaj okazoj. Ĉar ni uzos ekvilibron antaŭ la petskriboj, mi rekomendas specifi grupon ĉi tie, kiu permesas envenajn konektojn nur de la balancilo. Tio estas, vi havos 2 sekurecajn grupojn, unu por la ekvilibristo, kiu ebligas enirkonektojn de ie ajn sur la havenoj 80 (http) kaj 443 (https), kaj la dua por maŝinoj, kiu ebligas envenantajn konektojn sur iuj havenoj de la ekvilibra grupo. . Elirkonektoj en ambaŭ grupoj devas esti malfermitaj uzante la TCP-protokolon al ĉiuj havenoj al ĉiuj adresoj. Vi povas limigi havenojn kaj adresojn por elirantaj konektoj, sed tiam vi devas konstante kontroli, ke vi ne provas aliri ion sur fermita haveno.
Stokado (volumoj) — specifu la disko-parametrojn por la maŝinoj. La diskgrandeco ne povas esti malpli ol tiu specifita en la AMI; por ECS Optimized ĝi estas 30 GiB.
Altnivelaj detaloj — specifi pliajn parametrojn.
Aĉeta opcio — ĉu ni volas aĉeti spotokazojn. Ni volas, sed ni ne markos ĉi tiun skatolon ĉi tie; ni agordos ĝin en la Aŭtomata Skala Grupo, ekzistas pli da ebloj tie.
IAM-instanca profilo — indiku la rolon kun kiu la instancoj estos lanĉitaj. Por ke instancoj ruliĝu en ECS, ili bezonas permesojn, kiuj kutime troviĝas en la rolo ecsInstanceRole. En kelkaj kazoj ĝi povas esti kreita, se ne, tiam ĉi tie pri kiel fari tion. Post kreado, ni indikas ĝin en la ŝablono.
Poste estas multaj parametroj, esence vi povas lasi defaŭltajn valorojn ĉie, sed ĉiu el ili havas klaran priskribon. Mi ĉiam ebligas la EBS-optimumigitan ekzemplon kaj T2/T3 Senlimajn eblojn se uzataj ekzemploj.
Datumoj de uzantoj — indiku uzantajn datumojn. Ni redaktos la dosieron /etc/ecs/ecs.config, kiu enhavas la ECS-agentagordon.
Ekzemplo de kiaj uzantdatenoj povus aspekti:
#!/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 — la parametro indikas, ke la petskribo apartenas al aro kun la persona nomo, tio estas, ĉi tiu aro povos meti siajn taskojn sur ĉi tiun servilon. Ni ankoraŭ ne kreis areton, sed ni uzos ĉi tiun nomon dum kreado de ĝi.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — la parametro specifas, ke kiam signalo estas ricevita por malŝalti makulinstancon, ĉiuj taskoj pri ĝi devas esti transdonitaj al la Drenado-statuso.
ECS_CONTAINER_STOP_TIMEOUT=1m - la parametro specifas, ke post ricevo de SIGINT-signalo, ĉiuj taskoj havas 1 minuton antaŭ ol esti mortigitaj.
ECS_ENGINE_AUTH_TYPE=docker — la parametro indikas, ke la Docker-skemo estas uzata kiel la rajtiga mekanismo
ECS_ENGINE_AUTH_DATA=... — konekto-parametroj al la privata ujo-registro, kie viaj Docker-bildoj estas konservitaj. Se ĝi estas publika, tiam vi ne bezonas specifi ion ajn.
Por la celoj de ĉi tiu artikolo, mi uzos publikan bildon de Docker Hub, do specifu la parametrojn ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA ne necesas.
Bone scii: Oni rekomendas ĝisdatigi la AMI regule, ĉar novaj versioj ĝisdatigas versiojn de Docker, Linukso, ECS-agento ktp. Por ne forgesi pri tio, vi povas pri la eldono de novaj versioj. Vi povas ricevi sciigojn retpoŝte kaj ĝisdatigi permane, aŭ vi povas skribi Lambda-funkcion, kiu aŭtomate kreos novan version de Lanĉa Ŝablono kun ĝisdatigita AMI.
EC2 Aŭtomata Skala Grupo
Auto Scaling Group respondecas pri lanĉo kaj skalo de okazoj. Grupoj estas administritaj en la sekcio EC2 -> Aŭtomata Skalado -> Aŭtomata Skalado-Grupoj.
Lanĉi ŝablonon — elektu la ŝablonon kreitan en la antaŭa paŝo. Ni lasas la defaŭltan version.
Aĉetaj ebloj kaj petskriboj — specifu la specojn de okazoj por la areto. Aliĝi al lanĉo-ŝablono uzas la instantan tipon de la Lanĉa Ŝablono. Kombini aĉetopciojn kaj ekzemplertipojn ebligas al vi flekseble agordi ekzemplertipojn. Ni uzos ĝin.
Laŭvola bazo por postulo — la nombro da regulaj, ne-punktaj okazoj, kiuj ĉiam funkcios.
Laŭpostula procento super bazo — procenta proporcio de regulaj kaj punktaj okazoj, 50-50 estos distribuita egale, 20-80 por ĉiu regula okazo 4 punktoj estos altigitaj. Por la celoj de ĉi tiu ekzemplo, mi indikos 50-50, sed fakte ni plej ofte faras 20-80, en iuj kazoj 0-100.
Instancaj tipoj — ĉi tie vi povas specifi pliajn specojn de okazoj, kiuj estos uzataj en la areto. Ni neniam uzis ĝin ĉar mi ne vere komprenas la signifon de la rakonto. Eble ĉi tio estas pro la limoj de specifaj specoj de kazoj, sed ili povas esti facile pliigitaj per subteno. Se vi konas la aplikaĵon, mi ĝojos legi ĝin en la komentoj)
reto — retaj agordoj, elektu VPC kaj subretojn por maŝinoj, plejofte vi devus elekti ĉiujn disponeblajn subretojn.
Balancado de ŝarĝo - agordoj de balancilo, sed ni faros tion aparte, ni tuŝos nenion ĉi tie. Sankontroloj ankaŭ estos agordita poste.
Grupo grandeco — ni indikas la limojn pri la nombro da maŝinoj en la areto kaj la deziratan nombron da maŝinoj ĉe la komenco. La nombro da maŝinoj en la areto neniam estos malpli ol la minimumo specifita kaj pli ol la maksimumo, eĉ se skalo devus okazi laŭ la metrikoj.
Skalaj politikoj — skali parametrojn, sed ni skalos surbaze de la kurantaj ECS taskoj, do ni agordos la skalon poste.
Okaza skalo-enprotekto — protekto de okazoj kontraŭ forigo dum malgrandiĝo. Ni ebligas ĝin por ke ASG ne forigu la maŝinon, kiu havas kurantajn taskojn. ECS Capacity Provider malŝaltos protekton por okazoj, kiuj ne havas taskojn.
Aldoni etikedojn — vi povas specifi etikedojn por ekzemploj (por tio, la markobutono Etikedi novajn okazojn devas esti markita). Mi rekomendas specifi la Nomo-etikedon, tiam ĉiuj okazoj, kiuj estas lanĉitaj ene de la grupo, havos la saman nomon, kaj estas oportune vidi ilin en la konzolo.
Post kreado de la grupo, malfermu ĝin kaj iru al la sekcio Altnivelaj agordoj.Kial ne ĉiuj opcioj estas videblaj en la konzolo ĉe la krea etapo.
Finpolitikoj — reguloj, kiuj estas konsiderataj dum forigo de okazoj. Ili estas aplikataj en ordo. Ni kutime uzas tiujn en la suba bildo. Unue, okazoj kun la plej malnova Lanĉa Ŝablono estas forigitaj (ekzemple, se ni ĝisdatigis la AMI, ni kreis novan version, sed ĉiuj okazoj sukcesis ŝanĝi al ĝi). Tiam la okazoj kiuj estas plej proksimaj al la sekva faktura horo estas elektitaj. Kaj tiam la plej malnovaj estas elektitaj laŭ la dato de lanĉo.
Bone scii: ĝisdatigi ĉiujn maŝinojn en areto, oportune uzi . Se vi kombinas ĉi tion kun la Lambda funkcio de la antaŭa paŝo, vi havos plene aŭtomatigitan instancan ĝisdatigsistemon. Antaŭ ĝisdatigi ĉiujn maŝinojn, vi devas malŝalti instanc-en-en-protekton por ĉiuj instancoj en la grupo. Ne agordo en la grupo, sed protekto de la maŝinoj mem, ĉi tio estas farita en la langeto Administrado de petskriboj.
Aplikaĵo Load Balancer kaj EC2 Celgrupo
La balancilo estas kreita en la sekcio EC2 → Ŝarĝbalancado → Ŝarĝbalanciloj. Ni uzos Aplikaĵon Load Balancer; komparo de malsamaj specoj de balanciloj legeblas ĉe .
Aŭskultantoj - havas sencon fari pordojn 80 kaj 443 kaj alidirekti de 80 al 443 uzante ekvilibrajn regulojn poste.
Haveblecaj Zonoj — plejofte ni elektas alireblajn zonojn por ĉiuj.
Agordi Sekurecajn Agordojn — la SSL-atestilo por la ekvilibristo estas indikita ĉi tie, la plej oportuna opcio estas en ACM. Pri la diferencoj Sekureca Politiko legeblas en , vi povas lasi ĝin elektita defaŭlte ELBSecurityPolicy-2016-08. Post kreado de la balancilo, vi vidos ĝin DNS-nomo, kiun vi bezonas agordi la CNAME por via domajno. Ekzemple, jen kiel ĝi aspektas en Cloudflare.
Sekureca Grupo — kreu aŭ elektu sekurecan grupon por la ekvilibristo, mi skribis pli pri tio ĝuste supre en la sekcio de EC2 Lanĉa Ŝablono → Retaj agordoj.
Celo-grupo — ni kreas grupon, kiu respondecas pri direktado de petoj de la ekvilibristo al maŝinoj kaj kontroli ilian haveblecon por anstataŭigi ilin en kazo de problemoj. Celtipo devas esti Instanco, protokolon и haveno ajna, se vi uzas HTTPS por komunikado inter la ekvilibristo kaj instancoj, tiam vi devas alŝuti atestilon al ili. Por la celoj de ĉi tiu ekzemplo, ni ne faros tion, ni simple forlasos la havenon 80.
Sankontroloj — parametroj por kontroli la funkciadon de la servo. En reala servo, ĉi tio devus esti aparta peto, kiu efektivigas gravajn partojn de la komerca logiko; por la celoj de ĉi tiu ekzemplo, mi lasos la defaŭltajn agordojn. Tuj poste, vi povas elekti la peto-intervalo, tempoforigo, sukcesaj kodoj, ktp. En nia ekzemplo, ni indikos Sukceskodojn 200-399, ĉar la Docker-bildo, kiu estos uzata, redonas 304-kodon.
Registri Celojn — ĉi tie la aŭtoj por la grupo estas elektitaj, sed en nia kazo tio estos farita de ECS, do ni simple preterlasas ĉi tiun paŝon.
Bone scii: ĉe la ekvilibra nivelo vi povas ebligi protokolojn kiuj estos konservitaj en S3 en certa . De tie ili povas esti eksportitaj al triaj servoj por analizo, aŭ vi povas fari SQL-demandojn rekte sur la datumoj en S3 per . Ĝi estas oportuna kaj funkcias sen aldona kodo. Mi ankaŭ rekomendas agordi la forigon de ŝtipoj de la S3 sitelo post difinita tempodaŭro.
ECS-Tasko-Difino
En la antaŭaj paŝoj, ni kreis ĉion rilate al la serva infrastrukturo; nun ni pluiras al priskribi la ujojn, kiujn ni lanĉos. Ĉi tio estas farita en la sekcio ECS → Taskdifinoj.
Lanĉo tipo kongruo - elektu EC2.
Taskekzekuto IAM-rolo - elektu ecsTaskExecutionRole. Uzante ĝin, protokoloj estas skribitaj, aliro al sekretaj variabloj estas donita, ktp.
En la sekcio Difinoj de Ujo, alklaku Aldoni Ujon.
bildo — ligu al la bildo kun la projektkodo; por ĉi tiu ekzemplo mi uzos publikan bildon de Docker Hub .
Memorlimoj — memorlimoj por la ujo. Malmola Limo — malmola limo, se la ujo superas la specifitan valoron, la docker kill komando estos efektivigita, la ujo tuj mortos. Mola Limo — mola limo, la ujo povas iri preter la specifita valoro, sed ĉi tiu parametro estos konsiderata kiam oni metas taskojn sur maŝinoj. Ekzemple, se maŝino havas 4 GiB da RAM, kaj la mola limo de ujo estas 2048 MiB, tiam ĉi tiu maŝino povas havi maksimume 2 kurantajn taskojn kun ĉi tiu ujo. En realeco, 4 GiB da RAM estas iomete malpli ol 4096 MiB, ĉi tio povas esti vidita sur la langeto ECS-Instancoj en la areto. Mola limo ne povas esti pli granda ol malmola limo. Gravas kompreni, ke se estas pluraj ujoj en unu tasko, tiam iliaj limoj estas resumitaj.
Portmapoj - en Gastiga haveno Ni indikas 0, tio signifas, ke la haveno estos asignita dinamike kaj estos monitorita de la Celgrupo. Uja Haveno — la haveno, sur kiu funkcias via aplikaĵo, estas ofte specifita en la ekzekuta komando, aŭ asignita en via aplika kodo, Dockerfile, ktp. Por nia ekzemplo ni uzos 3000 ĉar ĝi estas listigita en la bildo uzata.
Sankontrolo — parametroj de sano-kontrolo de ujoj, ne konfuzeblaj kun tiu agordita en la Celgrupo.
medio - medio-agordoj. CPU-unuoj - simila al Memorlimoj, nur pri la procesoro. Ĉiu procesoro-kerno estas 1024 unuoj, do se la servilo havas du-kernan procesoron kaj la ujo estas agordita al 512, tiam 4 taskoj kun ĉi tiu ujo povas esti lanĉitaj sur unu servilo. CPU-unuoj ĉiam respondas al la nombro da kernoj; ne povas esti iom malpli da ili, kiel estas la kazo kun memoro.
komando — komando por lanĉi servon ene de ujo, ĉiuj parametroj estas specifitaj apartigitaj per komoj. Ĉi tio povus esti gunicorn, npm, ktp. Se ne specifita, la valoro de la CMD-direktivo de la Dockerfile estos uzata. Ni indikas npm,start.
Mediaj variabloj — ujo medio-variabloj. Ĉi tio povas esti aŭ simplaj tekstaj datumoj aŭ sekretaj variabloj de aŭ .
Stokado kaj Registrado — ĉi tie ni starigos ensalutadon en CloudWatch Logs (servo por protokoloj de AWS). Por fari tion, simple ebligu la markobutonon Aŭtomate agordi CloudWatch Logs. Post kreado de la Tasko-Difino, grupo de protokoloj estos aŭtomate kreita en CloudWatch. Defaŭlte, protokoloj estas konservitaj en ĝi senfine; mi rekomendas ŝanĝi la Retenan periodon de Neniam Eksvalidiĝo al la bezonata periodo. Ĉi tio estas farita en CloudWatch Log-grupoj, vi devas alklaki la nunan periodon kaj elekti novan.
ECS Cluster kaj ECS Kapacita Provizanto
Iru al la sekcio ECS → Aretoj por krei areton. Ni elektas EC2 Linux + Networking kiel ŝablonon.
Aretonomo - tre grave, ni faras ĉi tie la saman nomon kiel specifita en la parametro Lanĉa Ŝablono ECS_CLUSTER, en nia kazo - DemoApiClusterProd. Marku la markobutonon Krei malplenan areton. Laŭvole, vi povas ebligi Container Insights por vidi metrikojn por servoj en CloudWatch. Se vi faris ĉion ĝuste, tiam en la sekcio de ECS-Instancoj vi vidos maŝinojn, kiuj estis kreitaj en la grupo Aŭtomata Skalado.
Iru al langeto Kapacaj Provizantoj kaj kreu novan. Mi memorigu al vi, ke necesas kontroli la kreadon kaj malŝalton de maŝinoj depende de la nombro da kurantaj ECS taskoj. Gravas noti, ke provizanto nur povas esti asignita al unu grupo.
Aŭtomata Skala grupo — elektu la antaŭe kreitan grupon.
Administrita skalado — ebligu ĝin por ke la provizanto povu grimpi la servon.
Cel-kapacito % — kian procenton de maŝinoj ŝarĝitaj kun taskoj ni bezonas. Se vi specifas 100%, tiam ĉiuj maŝinoj ĉiam estos okupataj pri funkciado de taskoj. Se vi specifas 50%, tiam duono de la aŭtoj ĉiam estos senpaga. En ĉi tiu kazo, se estas akra salto en ŝarĝo, novaj taksioj tuj atingos liberajn aŭtojn, sen devi atendi ke instancoj estos deplojitaj.
Administrita finprotekto — ebligu, ĉi tiu parametro permesas al la provizanto forigi la protekton de okazoj kontraŭ forigo. Ĉi tio okazas kiam ne estas aktivaj taskoj sur la maŝino kaj permesas Celon-kapaciton%.
ECS-servo kaj skalo-aranĝo
Lasta paŝo :) Por krei servon, vi devas iri al la antaŭe kreita areto en la langeto Servoj.
Lanĉa tipo — vi devas alklaki Ŝalti al kapablo provizanto strategio kaj elekti la antaŭe kreitajn provizantojn.
Taska Difino — elektu la antaŭe kreitan Taskan Difinon kaj ĝian revizion.
Serva nomo — por eviti konfuzon, ni ĉiam indikas la samon kiel Tasko-Difino.
Serva tipo - ĉiam Repliko.
Nombro de taskoj — la dezirata nombro da aktivaj taskoj en la servo. Ĉi tiu parametro estas kontrolata per skalo, sed ankoraŭ devas esti specifita.
Minimuma sana procento и Maksimuma procento — determini la konduton de taskoj dum deplojo. La defaŭltaj valoroj estas 100 kaj 200, indikante, ke en la momento de deplojo la nombro da taskoj pliiĝos plurfoje, kaj poste revenos al la dezirata valoro. Se vi havas 1 taskon funkcianta, min=0, kaj max=100, tiam dum deplojo ĝi estos mortigita, kaj post tio nova estos levita, tio estas, ĝi estos malfunkcio. Se 1 tasko funkcias, min=50, max=150, tiam disfaldido tute ne okazos, ĉar 1 tasko ne povas esti dividita en duono aŭ pliigita je unu fojo kaj duono.
Tipo de deplojo — lasu Rolling-ĝisdatigon.
Lokigo Ŝablonoj — reguloj por meti taskojn sur maŝinojn. La defaŭlta estas AZ Balanced Spread - tio signifas, ke ĉiu nova tasko estos metita sur novan kazon ĝis maŝinoj en ĉiuj haveblecaj zonoj leviĝos. Ni kutime faras BinPack - CPU kaj Spread - AZ; kun ĉi tiu politiko, taskoj estas metitaj kiel eble plej dense sur unu maŝino per CPU. Se necesas krei novan maŝinon, ĝi estas kreita en nova havebleca zono.
Ŝarĝbalancilo tipo — elektu Aplikan Ŝarĝbalancilon.
Serva IAM-rolo - elektu ecsServiceRole.
Ŝarĝbalancilo nomo — elektu la antaŭe kreitan ekvilibron.
Sankontrolo gracia periodo — paŭzu antaŭ ol fari sankontrolojn post lanĉo de nova tasko, ni kutime fiksas ĝin al 60 sekundoj.
Ujo por ŝarĝi ekvilibron — en la nomo de Celgrupo, elektu la antaŭe kreitan grupon, kaj ĉio estos aŭtomate plenigita.
Servo Aŭtomata Skalado — servo-skalaj parametroj. Elektu Agordu Servan Aŭtomatan Skaladon por ĝustigi la deziratan nombron de via servo. Ni fiksas la minimuman kaj maksimuman nombron da taskoj dum grimpado.
IAM-rolo por Service Auto Scaling - elektu AWSServiceRoleForApplicationAutoScaling_ECSService.
Aŭtomataj taskaj skalaj politikoj — reguloj por grimpi. Estas 2 tipoj:
- Celspurado - spuri celajn metrikojn (uzado de CPU/RAM aŭ nombro da petoj por ĉiu tasko). Ekzemple, ni volas, ke la averaĝa procesoro-ŝarĝo estu 85%, kiam ĝi iĝas pli alta, novaj taskoj estos aldonitaj ĝis ĝi atingos la celvaloron. Se la ŝarĝo estas pli malalta, tiam taskoj estos forigitaj, male, krom se protekto kontraŭ malpliigo estas ebligita (Malebligu skalon-enen).
- Ŝtupo skalado - reago al arbitra evento. Ĉi tie vi povas agordi reagon al iu ajn evento (CloudWatch Alarm), kiam ĝi okazas, vi povas aldoni aŭ forigi la specifitan nombron da taskoj, aŭ specifi la ĝustan nombron da taskoj.
Servo povas havi plurajn skalajn regulojn, ĉi tio povas esti utila, la ĉefa afero estas certigi, ke ili ne konfliktas unu kun la alia.
konkludo
Se vi sekvis la instrukciojn kaj uzis la saman Docker-bildon, via servo devus resendi paĝon kiel ĉi tion.
- Ni kreis ŝablonon laŭ kiu ĉiuj maŝinoj en la servo estas lanĉitaj. Ni ankaŭ lernis kiel ĝisdatigi maŝinojn kiam la ŝablono ŝanĝiĝas.
- Ni agordis la prilaboradon de la spot-instanca haltsignalo, do ene de minuto post ricevi ĝin, ĉiuj kurantaj taskoj estas forigitaj de la maŝino, do nenio estas perdita aŭ interrompita.
- Ni levis la ekvilibron por distribui la ŝarĝon egale tra la maŝinoj.
- Ni kreis servon, kiu funkcias sur punktoj, kiu reduktas maŝinajn kostojn ĉirkaŭ 3 fojojn.
- Ni agordis aŭtomatan skalon en ambaŭ direktoj por trakti pliigitajn laborŝarĝojn sen enspezi malfunkciajn kostojn.
- Ni uzas Capacity Provider por ke la aplikaĵo administru la infrastrukturon (maŝinojn) kaj ne inverse.
- Ni estas bonegaj.
Se vi havas antaŭvideblajn pikilojn en ŝarĝo, ekzemple vi reklamas en granda retpoŝta kampanjo, vi povas agordi skalon per .
Vi ankaŭ povas grimpi surbaze de datumoj de malsamaj partoj de via sistemo. Ekzemple, ni havas la funkciojn uzantoj de la movebla aplikaĵo. Foje kampanjo estas sendita al 1M+ homoj. Post tia distribuo, ĉiam estas granda kresko de petoj al la API, ĉar multaj uzantoj ensalutas en la aplikaĵo samtempe. Do se ni vidas, ke estas signife pli normaj indikiloj en la atendovico por sendi reklamajn puŝajn sciigojn, ni povas tuj lanĉi plurajn pliajn maŝinojn kaj taskojn por esti pretaj por la ŝarĝo.
Mi ĝojos, se vi rakontos al mi en la komentoj interesajn kazojn de uzado de punktoj kaj ECS aŭ ion pri skalo.
Baldaŭ estos artikoloj pri kiel ni prilaboras milojn da analizaj eventoj je sekundo sur ĉefe senservila stako (kun mono) kaj kiel la disfaldiĝo de servoj funkcias uzante GitLab CI kaj Terraform Cloud.
Abonu al ni, ĝi estos interese!
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Ĉu vi uzas punktojn en produktado?
-
22,2%Jes6
-
66,7%No18
-
11,1%Mi eksciis pri ili el artikolo kaj planas uzi ilin3
27 uzantoj voĉdonis. 5 uzantoj sindetenis.
fonto: www.habr.com