Բարեւ բոլորին! Ես Կիրիլն եմ, ես Ադապտիում CTO եմ: Մեր ճարտարապետության մեծ մասը AWS-ի վրա է, և այսօր ես կխոսեմ այն մասին, թե ինչպես մենք կրճատեցինք սերվերի ծախսերը 3 անգամ՝ օգտագործելով spot օրինակները արտադրական միջավայրում, ինչպես նաև ինչպես կարգավորել դրանց ավտոմատ մասշտաբը: Սկզբում կլինի ակնարկ, թե ինչպես է այն աշխատում, ապա մանրամասն հրահանգներ սկսելու համար:
Որոնք են Spot դեպքերը:
Օրինակները AWS-ի այլ օգտատերերի սերվերներ են, որոնք ներկայումս անգործության են մատնված, և նրանք դրանք վաճառում են մեծ զեղչով (Amazon-ը գրում է մինչև 90%, մեր փորձից ~ 3x, տատանվում է կախված տարածաշրջանից, AZ և օրինակի տեսակից): Նրանց հիմնական տարբերությունը սովորականներից այն է, որ նրանք կարող են ցանկացած պահի անջատվել: Հետևաբար, երկար ժամանակ մենք հավատում էինք, որ նորմալ է դրանք օգտագործել կուսական միջավայրերի կամ ինչ-որ բան հաշվարկելու առաջադրանքների համար, S3-ում կամ տվյալների բազայում պահպանված միջանկյալ արդյունքներով, բայց ոչ վաճառքի համար: Կան երրորդ կողմի լուծումներ, որոնք թույլ են տալիս օգտագործել բծեր արտադրության վրա, բայց մեր գործի համար կան բազմաթիվ հենակներ, ուստի մենք դրանք չենք իրականացրել: Հոդվածում նկարագրված մոտեցումն ամբողջությամբ աշխատում է ստանդարտ AWS ֆունկցիոնալության շրջանակներում՝ առանց լրացուցիչ սցենարների, պսակների և այլն։
Ստորև բերված են մի քանի սքրինշոթներ, որոնք ցույց են տալիս գների պատմությունը տեղում օրինակների համար:
m5.մեծ է eu-west-1 (Իռլանդիա) տարածաշրջանում: Գինը հիմնականում կայուն է եղել 3 ամիս, ներկայումս խնայում է 2.9 անգամ:
m5.մեծ է ԱՄՆ-արևելք-1 տարածաշրջանում (Ն. Վիրջինիա): Գինը անընդհատ փոխվում է 3 ամսվա ընթացքում՝ ներկայումս խնայելով 2.3x-ից մինչև 2.8x՝ կախված առկայության գոտուց:
t3.փոքր ԱՄՆ-արևելք-1 տարածաշրջանում (Ն. Վիրջինիա): Գինը կայուն է 3 ամիս, ներկայումս խնայում է 3.4 անգամ։
Ծառայությունների ճարտարապետություն
Ծառայության հիմնական ճարտարապետությունը, որի մասին մենք կխոսենք այս հոդվածում, ներկայացված է ստորև ներկայացված դիագրամում:
Application Load Balancer → EC2 Target Group → Elastic Container Service
Application Load Balancer (ALB) օգտագործվում է որպես հավասարակշռող, որը հարցումներ է ուղարկում EC2 թիրախային խմբին (TG): TG-ն պատասխանատու է ALB-երի ատյանների վրա նավահանգիստների բացման և դրանք Elastic Container Service (ECS) բեռնարկղերի նավահանգիստներին միացնելու համար: ECS-ը Kubernetes-ի անալոգն է AWS-ում, որը կառավարում է Docker կոնտեյներները:
Մեկ օրինակը կարող է ունենալ մի քանի գործող կոնտեյներ՝ նույն նավահանգիստներով, այնպես որ մենք չենք կարող դրանք ֆիքսել: ECS-ն ասում է TG-ին, որ այն գործարկում է նոր առաջադրանք (Kubernetes տերմինաբանության մեջ սա կոչվում է pod), այն ստուգում է օրինակի անվճար պորտերը և դրանցից մեկին վերագրում է գործարկված առաջադրանքը: TG-ն նաև պարբերաբար ստուգում է, թե արդյոք օրինակը և API-ն աշխատում են դրա վրա՝ օգտագործելով առողջության ստուգումը, և եթե որևէ խնդիր է տեսնում, դադարում է հարցումներ ուղարկել այնտեղ։
EC2 Auto Scaling Groups + ECS Capacity Providers
Վերոնշյալ դիագրամը ցույց չի տալիս EC2 Auto Scaling Groups (ASG) ծառայությունը: Անվանումից կարելի է հասկանալ, որ այն պատասխանատու է ատյանների մասշտաբավորման համար։ Այնուամենայնիվ, մինչև վերջերս AWS-ը չուներ ECS-ից աշխատող մեքենաների քանակը կառավարելու ներկառուցված հնարավորություն: ECS-ը հնարավորություն տվեց մեծացնել առաջադրանքների քանակը, օրինակ՝ ըստ պրոցեսորի օգտագործման, RAM-ի կամ հարցումների քանակի: Բայց եթե առաջադրանքները զբաղեցրին բոլոր ազատ օրինակները, ապա նոր մեքենաներ ինքնաբերաբար չէին ստեղծվում:
Սա փոխվել է ECS Capacity Providers-ի (ECS CP) հայտնվելով: Այժմ ECS-ում յուրաքանչյուր ծառայություն կարող է կապված լինել ASG-ի հետ, և եթե առաջադրանքները չեն տեղավորվում գործող ատյաններում, ապա նորերը կբարձրացվեն (բայց սահմանված ASG սահմաններում): Սա նաև աշխատում է հակառակ ուղղությամբ, եթե ECS CP-ն տեսնում է անգործուն օրինակներ՝ առանց առաջադրանքների, ապա ASG հրամանը կտա դրանք անջատելու համար։ ECS CP-ն հնարավորություն ունի նշելու օրինակի բեռնվածության թիրախային տոկոսը, որպեսզի որոշակի թվով մեքենաներ միշտ ազատ լինեն արագ մասշտաբային առաջադրանքների համար, ես այս մասին կխոսեմ մի փոքր ուշ:
EC2 գործարկման ձևանմուշներ
Վերջին ծառայությունը, որի մասին կխոսեմ նախքան այս ենթակառուցվածքի ստեղծման մասին մանրամասն խոսելը, EC2 Launch Templates-ն է: Այն թույլ է տալիս ստեղծել կաղապար, ըստ որի բոլոր մեքենաները կսկսեն, որպեսզի ամեն անգամ դա չկրկնվի զրոյից։ Այստեղ կարող եք ընտրել գործարկվող մեքենայի տեսակը, անվտանգության խումբը, սկավառակի պատկերը և շատ այլ պարամետրեր: Կարող եք նաև նշել օգտվողի տվյալները, որոնք կվերբեռնվեն գործարկված բոլոր օրինակներում: Դուք կարող եք սկրիպտներ գործարկել օգտվողի տվյալների մեջ, օրինակ՝ կարող եք խմբագրել ֆայլի բովանդակությունը .
Այս հոդվածի կազմաձևման ամենակարևոր պարամետրերից մեկն է =ճշմարիտ. Եթե այս պարամետրը միացված է, ապա հենց որ ECS-ն ազդանշան է ստանում, որ կետային օրինակը հանվում է, այն փոխանցում է դրա վրա աշխատող բոլոր առաջադրանքները «Draining» կարգավիճակին: Այս օրինակին ոչ մի նոր առաջադրանք չի վերագրվի, եթե կան առաջադրանքներ, որոնք ցանկանում են առաջադրվել հենց հիմա, դրանք կչեղարկվեն: Հավասարակշռողի խնդրանքները նույնպես դադարում են գալ: Օրինակի ջնջման մասին ծանուցումը գալիս է բուն իրադարձությունից 2 րոպե առաջ: Հետևաբար, եթե ձեր ծառայությունը 2 րոպեից ավելի առաջադրանքներ չի կատարում և ոչինչ չի պահում սկավառակի վրա, ապա դուք կարող եք օգտագործել տեղում օրինակներ՝ առանց տվյալների կորստի:
Ինչ վերաբերում է սկավառակին - AWS վերջերս Հնարավոր է ECS-ի հետ միասին օգտագործել Elastic File System (EFS), այս սխեմայով նույնիսկ սկավառակը խոչընդոտ չէ, բայց մենք դա չփորձեցինք, քանի որ սկզբունքորեն մեզ պետք չէ սկավառակը վիճակը պահելու համար: Լռելյայնորեն, SIGINT ստանալուց հետո (ուղարկվում է, երբ առաջադրանքը փոխանցվում է «Draining» կարգավիճակին), բոլոր ընթացիկ առաջադրանքները կդադարեցվեն 30 վայրկյան հետո, նույնիսկ եթե դրանք դեռ չեն ավարտվել: Դուք կարող եք փոխել այս ժամանակը՝ օգտագործելով պարամետրը: . Հիմնական բանը տեղում մեքենաների համար 2 րոպեից ավելի չդնելն է։
Ծառայության ստեղծում
Անցնենք նկարագրված ծառայության ստեղծմանը։ Ընթացքում ես լրացուցիչ նկարագրելու եմ մի քանի օգտակար կետեր, որոնք վերը նշված չեն: Ընդհանրապես, սա քայլ առ քայլ հրահանգ է, բայց ես չեմ դիտարկի որոշ շատ տարրական կամ, ընդհակառակը, շատ կոնկրետ դեպքեր։ Բոլոր գործողությունները կատարվում են AWS տեսողական վահանակում, սակայն կարող են վերարտադրվել ծրագրային եղանակով՝ օգտագործելով CloudFormation կամ Terraform: Adapty-ում մենք օգտագործում ենք Terraform-ը:
EC2 գործարկման ձևանմուշ
Այս ծառայությունը ստեղծում է մեքենաների կոնֆիգուրացիա, որոնք կօգտագործվեն: Կաղապարները կառավարվում են EC2 -> Instances -> Launch templates բաժնում:
Amazon մեքենայի պատկեր (AMI) — նշեք սկավառակի պատկերը, որով կգործարկվեն բոլոր օրինակները: ECS-ի համար շատ դեպքերում արժե օգտագործել Amazon-ի օպտիմիզացված պատկերը: Այն պարբերաբար թարմացվում է և պարունակում է այն ամենը, ինչ անհրաժեշտ է ECS-ի աշխատանքի համար: Ներկայիս պատկերի ID-ն պարզելու համար անցեք էջ , ընտրեք այն տարածաշրջանը, որն օգտագործում եք և պատճենեք դրա համար AMI ID-ն: Օրինակ, us-east-1 տարածաշրջանի համար գրելու պահին գործող ID-ն է ami-00c7c1cf5bdc913ed. Այս ID-ն պետք է տեղադրվի «Նշեք հատուկ արժեք» տարրի մեջ:
Օրինակի տեսակը - նշեք օրինակի տեսակը: Ընտրեք մեկը, որը լավագույնս համապատասխանում է ձեր առաջադրանքին:
Բանալիների զույգ (մուտք) — նշեք վկայագիր, որով անհրաժեշտության դեպքում կարող եք միանալ օրինակին SSH-ի միջոցով:
Ցանցի կարգավորումները - նշեք ցանցի պարամետրերը: Ցանցային հարթակ Շատ դեպքերում պետք է լինի վիրտուալ մասնավոր ամպ (VPC): Անվտանգության խմբեր — անվտանգության խմբեր ձեր օրինակների համար: Քանի որ ատյանների դիմաց մենք կօգտագործենք հավասարակշռող, խորհուրդ եմ տալիս այստեղ նշել մի խումբ, որը թույլ է տալիս մուտքային կապեր միայն հավասարակշռողից: Այսինքն, դուք կունենաք անվտանգության 2 խումբ, մեկը հավասարակշռողի համար, որը թույլ է տալիս ներգնա միացումներ 80 (http) և 443 (https) նավահանգիստների ցանկացած կետից, իսկ երկրորդը մեքենաների համար, որը թույլ է տալիս մուտքային կապեր հավասարակշռող խմբի ցանկացած պորտի վրա: . Երկու խմբերի ելքային կապերը պետք է բացվեն TCP արձանագրության միջոցով բոլոր հասցեների բոլոր նավահանգիստներին: Դուք կարող եք սահմանափակել նավահանգիստները և հասցեները ելքային կապերի համար, բայց հետո դուք պետք է անընդհատ հետևեք, որ չեք փորձում որևէ բան մուտք գործել փակ նավահանգստում:
Պահպանում (ծավալներ) - նշեք սկավառակի պարամետրերը մեքենաների համար: Սկավառակի չափը չի կարող պակաս լինել AMI-ում նշվածից, ECS Optimized-ի համար այն 30 ԳԲ է:
Ընդլայնված մանրամասներ - նշեք լրացուցիչ պարամետրեր:
Գնման տարբերակ — արդյո՞ք մենք ցանկանում ենք գնել տեղում օրինակներ: Մենք ուզում ենք, բայց այստեղ չենք նշի այս վանդակը, մենք այն կկարգավորենք Auto Scaling Group-ում, այնտեղ ավելի շատ տարբերակներ կան:
IAM օրինակի պրոֆիլը — նշեք այն դերը, որով գործարկվելու են ատյանները: Որպեսզի օրինակները աշխատեն ECS-ում, նրանց անհրաժեշտ են թույլտվություններ, որոնք սովորաբար հանդիպում են դերում ecsInstanceRole. Որոշ դեպքերում այն կարող է ստեղծվել, եթե ոչ, ապա այստեղ այն մասին, թե ինչպես դա անել: Ստեղծվելուց հետո մենք այն նշում ենք կաղապարում։
Հաջորդը կան բազմաթիվ պարամետրեր, հիմնականում դուք կարող եք լռելյայն արժեքներ թողնել ամենուր, բայց դրանցից յուրաքանչյուրն ունի հստակ նկարագրություն: Ես միշտ միացնում եմ EBS-ով օպտիմիզացված օրինակը և T2/T3 անսահմանափակ տարբերակները, եթե օգտագործվում են դեպքեր.
Օգտագործողի տվյալներ - նշեք օգտվողի տվյալները: Մենք կխմբագրենք ֆայլը /etc/ecs/ecs.config, որը պարունակում է ECS գործակալի կոնֆիգուրացիան:
Օրինակ, թե ինչպիսին կարող են լինել օգտվողի տվյալները.
#!/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 — պարամետրը ցույց է տալիս, որ օրինակը պատկանում է տվյալ անունով կլաստերին, այսինքն՝ այս կլաստերը կկարողանա իր առաջադրանքները տեղադրել այս սերվերի վրա։ Մենք դեռ չենք ստեղծել կլաստեր, բայց այն ստեղծելիս կօգտագործենք այս անունը։
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — պարամետրը սահմանում է, որ երբ ազդանշան է ստացվում՝ անջատելու կետային օրինակը, դրա վրա դրված բոլոր առաջադրանքները պետք է փոխանցվեն «Draining» կարգավիճակին:
ECS_CONTAINER_STOP_TIMEOUT=1m - պարամետրը նշում է, որ SIGINT ազդանշան ստանալուց հետո բոլոր առաջադրանքները սպանվելուց 1 րոպե ունեն:
ECS_ENGINE_AUTH_TYPE=docker — պարամետրը ցույց է տալիս, որ Docker սխեման օգտագործվում է որպես թույլտվության մեխանիզմ
ECS_ENGINE_AUTH_DATA=... — կապի պարամետրերը մասնավոր կոնտեյների ռեգիստրին, որտեղ պահվում են ձեր Docker պատկերները: Եթե հրապարակային է, ուրեմն պետք չէ որևէ բան նշել։
Այս հոդվածի նպատակների համար ես կօգտագործեմ հանրային պատկեր Docker Hub-ից, ուստի նշեք պարամետրերը ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA կարիք չկա.
Լավ է իմանալ, թեԽորհուրդ է տրվում պարբերաբար թարմացնել AMI-ն, քանի որ նոր տարբերակները թարմացնում են Docker-ի, Linux-ի, ECS գործակալի և այլնի տարբերակները: Այս մասին չմոռանալու համար կարող եք նոր տարբերակների թողարկման մասին։ Դուք կարող եք ստանալ ծանուցումներ էլ.
EC2 Auto Scaling Group
Auto Scaling Group-ը պատասխանատու է օրինակների գործարկման և մասշտաբավորման համար: Խմբերը կառավարվում են EC2 -> Auto Scaling -> Auto Scaling Groups բաժնում:
Գործարկել ձևանմուշը — ընտրեք նախորդ քայլում ստեղծված ձևանմուշը: Մենք թողնում ենք լռելյայն տարբերակը:
Գնման տարբերակները և օրինակների տեսակները — նշեք կլաստերի տիպերի տեսակները: Հավատարիմ գործարկելու կաղապարը օգտագործում է գործարկման կաղապարի օրինակի տեսակը: Գնման տարբերակների և օրինակների տեսակների համադրումը թույլ է տալիս ճկուն կերպով կարգավորել օրինակների տեսակները: Մենք կօգտագործենք այն։
Ընտրովի On-Demand բազա — կանոնավոր, ոչ կետային օրինակների քանակը, որոնք միշտ կաշխատեն:
Ըստ պահանջի տոկոսը բազայից բարձր — Հերթական և կետային ատյանների տոկոսային հարաբերակցությունը 50-50 կբաշխվի հավասարապես, 20-80 յուրաքանչյուր կանոնավոր ատյանի համար կբարձրացվի 4 տեղում: Այս օրինակի նպատակների համար ես կնշեմ 50-50, բայց իրականում մենք ամենից հաճախ անում ենք 20-80, որոշ դեպքերում 0-100:
Օրինակների տեսակները — այստեղ դուք կարող եք նշել օրինակների լրացուցիչ տեսակներ, որոնք կօգտագործվեն կլաստերում: Մենք երբեք չենք օգտագործել այն, քանի որ ես իրականում չեմ հասկանում պատմության իմաստը: Միգուցե դա պայմանավորված է կոնկրետ տեսակի օրինակների սահմանափակումներով, բայց դրանք հեշտությամբ կարելի է մեծացնել աջակցության միջոցով: Եթե գիտեք հավելվածը, ուրախ կլինեմ կարդալ այն մեկնաբանություններում)
Ցանց — ցանցի կարգավորումներ, ընտրեք VPC և ենթացանցեր մեքենաների համար, շատ դեպքերում դուք պետք է ընտրեք բոլոր հասանելի ենթացանցերը:
Բեռի հավասարակշռում - հավասարակշռողի կարգավորումներ, բայց մենք դա կանենք առանձին, այստեղ ոչինչ չենք դիպչի: Առողջության ստուգումներ նույնպես կկարգավորվի ավելի ուշ:
Խմբի չափը — մենք նշում ենք կլաստերի մեքենաների քանակի սահմանափակումները և սկզբում մեքենաների ցանկալի քանակը: Կլաստերում մեքենաների թիվը երբեք չի լինի սահմանված նվազագույնից պակաս և առավելագույնից ավելի, նույնիսկ եթե մասշտաբը պետք է իրականացվի ըստ չափումների:
Սանդղակի քաղաքականություն — մասշտաբավորման պարամետրերը, բայց մենք մասշտաբավորելու ենք ECS-ի գործող առաջադրանքների հիման վրա, այնպես որ մենք ավելի ուշ կկարգավորենք մասշտաբը:
Օրինակի սանդղակի պաշտպանություն — ատյանների պաշտպանություն ջնջումից, երբ նվազեցնում են: Մենք միացնում ենք այն, որպեսզի ASG-ն չջնջի այն մեքենան, որն ունի գործող առաջադրանքներ: ECS Capacity Provider-ը կանջատի պաշտպանությունը այն դեպքերի համար, որոնք առաջադրանքներ չունեն:
Ավելացնել պիտակները — Դուք կարող եք նշել պիտակներ օրինակների համար (դրա համար պետք է նշվի Tag new instances վանդակը): Ես խորհուրդ եմ տալիս նշել Name tag-ը, այնուհետև խմբի ներսում գործարկված բոլոր օրինակները կունենան նույն անունը, և հարմար է դրանք դիտել վահանակում:
Խումբը ստեղծելուց հետո բացեք այն և անցեք Ընդլայնված կոնֆիգուրացիաներ բաժին:Ինչու ստեղծման փուլում բոլոր տարբերակները տեսանելի չեն վահանակում:
Դադարեցման քաղաքականություն — կանոններ, որոնք հաշվի են առնվում դեպքերը ջնջելիս: Դրանք կիրառվում են հերթականությամբ։ Մենք սովորաբար օգտագործում ենք ստորև նկարում պատկերվածները: Նախ, ամենահին Launch Template-ով օրինակները ջնջվում են (օրինակ, եթե մենք թարմացրել ենք AMI-ն, մենք ստեղծել ենք նոր տարբերակ, բայց բոլոր օրինակներին հաջողվել է անցնել դրան): Այնուհետև ընտրվում են այն դեպքերը, որոնք ամենամոտ են հաջորդ հաշվարկային ժամին: Եվ հետո ամենահիններն ընտրվում են ըստ գործարկման ամսաթվի:
Լավ է իմանալ, թե: թարմացնել բոլոր մեքենաները կլաստերի մեջ, հարմար օգտագործման համար . Եթե սա համատեղեք նախորդ քայլի Lambda ֆունկցիայի հետ, դուք կունենաք օրինակների թարմացման լիովին ավտոմատացված համակարգ: Նախքան բոլոր մեքենաները թարմացնելը, դուք պետք է անջատեք օրինակների մասշտաբի պաշտպանությունը խմբի բոլոր օրինակների համար: Ոչ թե կոնֆիգուրացիա խմբում, այլ պաշտպանություն հենց մեքենաներից, դա արվում է «Instance management» ներդիրում:
Application Load Balancer և EC2 Target Group
Հավասարակշռիչը ստեղծվում է EC2 → Load Balancing → Load Balancers բաժնում: Մենք կօգտագործենք Application Load Balancer, տարբեր տեսակի հավասարակշռողների համեմատությունը կարելի է կարդալ այստեղ .
Լսողներ - իմաստ ունի ստեղծել 80 և 443 նավահանգիստները և վերահղել 80-ից 443՝ օգտագործելով հավասարակշռող կանոնները ավելի ուշ:
Հասանելիության գոտիներ — Շատ դեպքերում մենք ընտրում ենք հասանելիության գոտիներ բոլորի համար:
Կարգավորել անվտանգության կարգավորումները — այստեղ նշված է SSL վկայագիրը հավասարակշռողի համար, ամենահարմար տարբերակն է ACM-ում։ Տարբերությունների մասին Անվտանգության քաղաքականություն կարելի է կարդալ , կարող եք այն թողնել լռելյայն ընտրված ELBSecurityPolicy-2016-08. Հավասարակշռիչը ստեղծելուց հետո դուք կտեսնեք այն DNS անուն, որը դուք պետք է կարգավորեք CNAME-ը ձեր տիրույթի համար: Օրինակ, Cloudflare-ում այսպիսի տեսք ունի:
Անվտանգության խումբ — ստեղծեք կամ ընտրեք անվտանգության խումբ հավասարակշռողի համար, ես այս մասին ավելին գրել եմ հենց վերևում՝ EC2 Launch Template → Network settings բաժնում:
Թիրախային խումբ — մենք ստեղծում ենք խումբ, որը պատասխանատու է հավասարակշռողից դեպի մեքենաներ ուղղորդելու հարցումները և ստուգելու դրանց առկայությունը՝ խնդիրների դեպքում դրանք փոխարինելու համար: Թիրախի տեսակը պետք է լինի օրինակ, Արձանագրություն и Նավահանգիստ ցանկացած, եթե դուք օգտագործում եք HTTPS հավասարակշռողի և ատյանների միջև հաղորդակցության համար, ապա ձեզ հարկավոր է վկայագիր վերբեռնել նրանց վրա: Այս օրինակի նպատակների համար մենք դա չենք անի, մենք պարզապես կթողնենք նավահանգիստ 80-ը:
Առողջության ստուգումներ — ծառայության ֆունկցիոնալությունը ստուգելու պարամետրեր: Իրական ծառայության մեջ սա պետք է լինի առանձին հարցում, որն իրականացնում է բիզնեսի տրամաբանության կարևոր մասերը, այս օրինակի նպատակների համար ես կթողնեմ լռելյայն կարգավորումները: Հաջորդը, կարող եք ընտրել հարցումների միջակայքը, ժամանակի վերջը, հաջողության կոդերն ու այլն: Մեր օրինակում մենք կնշենք Հաջողության կոդերը 200-399, քանի որ օգտագործվող Docker պատկերը վերադարձնում է 304 կոդ:
Գրանցեք թիրախները — այստեղ ընտրվում են խմբի մեքենաները, բայց մեր դեպքում դա արվելու է ECS-ի կողմից, ուստի մենք պարզապես բաց ենք թողնում այս քայլը:
Լավ է իմանալ, թեՀավասարակշռողի մակարդակում դուք կարող եք միացնել տեղեկամատյանները, որոնք որոշակիորեն կպահվեն S3-ում . Այնտեղից դրանք կարող են արտահանվել երրորդ կողմի ծառայություններ՝ վերլուծության համար, կամ կարող եք SQL հարցումներ կատարել անմիջապես S3-ի տվյալների վրա՝ օգտագործելով . Այն հարմար է և աշխատում է առանց որևէ լրացուցիչ կոդի: Ես նաև խորհուրդ եմ տալիս կարգավորել S3 դույլից տեղեկամատյանների հեռացումը սահմանված ժամկետից հետո:
ECS առաջադրանքի սահմանում
Նախորդ քայլերում մենք ստեղծել ենք այն ամենը, ինչ կապված է սպասարկման ենթակառուցվածքի հետ, այժմ մենք անցնում ենք այն բեռնարկղերի նկարագրությանը, որոնք մենք կգործարկենք: Դա արվում է ECS → Task Definitions բաժնում:
Գործարկման տեսակի համատեղելիություն - ընտրեք EC2:
Առաջադրանքի կատարում IAM դերը - ընտրել ecsTaskExecutionRole. Օգտագործելով այն՝ գրվում են տեղեկամատյաններ, տրվում է մուտք դեպի գաղտնի փոփոխականներ և այլն։
Բեռնարկղերի սահմանումներ բաժնում սեղմեք Ավելացնել կոնտեյներ:
պատկեր — նկարին հղում նախագծի կոդով; այս օրինակի համար ես կօգտագործեմ հանրային պատկեր Docker Hub-ից .
Հիշողության սահմանափակումներ — կոնտեյների հիշողության սահմանաչափերը: Կոշտ սահման — կոշտ սահմանաչափ, եթե բեռնարկղը դուրս է գալիս նշված արժեքից, կկատարվի docker kill հրամանը, կոնտեյները անմիջապես կմեռնի: Փափուկ սահմանաչափ — փափուկ սահմանը, բեռնարկղը կարող է գերազանցել նշված արժեքը, բայց այս պարամետրը հաշվի կառնվի մեքենաների վրա առաջադրանքները դնելիս: Օրինակ, եթե մեքենան ունի 4 ԳԲ օպերատիվ հիշողություն, իսկ կոնտեյների փափուկ սահմանաչափը 2048 ՄԲ է, ապա այս սարքը կարող է ունենալ առավելագույնը 2 առաջադրանք այս կոնտեյներով: Իրականում, 4 ԳԲ օպերատիվ հիշողությունը մի փոքր պակաս է 4096 ՄԲ-ից, սա կարելի է դիտել կլաստերի ECS Instances ներդիրում: Փափուկ սահմանաչափը չի կարող ավելի մեծ լինել, քան կոշտ սահմանը: Կարևոր է հասկանալ, որ եթե մեկ առաջադրանքում կան մի քանի կոնտեյներ, ապա դրանց սահմաններն ամփոփված են:
Նավահանգիստների քարտեզագրումներ - ին Հյուրընկալող նավահանգիստ Մենք նշում ենք 0, սա նշանակում է, որ նավահանգիստը նշանակվելու է դինամիկ և վերահսկվելու է Թիրախային խմբի կողմից: Կոնտեյներային նավահանգիստ — այն նավահանգիստը, որի վրա աշխատում է ձեր հավելվածը, հաճախ նշված է կատարման հրամանում կամ նշանակվում է ձեր հավելվածի կոդում, Dockerfile-ում և այլն: Մեր օրինակի համար մենք կօգտագործենք 3000, քանի որ այն նշված է օգտագործվող պատկերը.
Առողջության ստուգում — կոնտեյների առողջության ստուգման պարամետրերը, որոնք չպետք է շփոթվեն թիրախային խմբում կազմաձևվածի հետ:
միջավայր - շրջակա միջավայրի կարգավորումներ: CPU միավորներ - Հիշողության սահմանափակումների նման, միայն պրոցեսորի մասին: Յուրաքանչյուր պրոցեսորի միջուկը 1024 միավոր է, հետևաբար, եթե սերվերն ունի երկմիջուկ պրոցեսոր, և կոնտեյները դրված է 512-ի վրա, ապա այս կոնտեյների հետ 4 առաջադրանք կարող է գործարկվել մեկ սերվերի վրա: Պրոցեսորի միավորները միշտ համապատասխանում են միջուկների քանակին, դրանցից մի փոքր պակաս լինել չի կարող, ինչպես դա հիշողության դեպքում է:
Հրաման — հրաման՝ կոնտեյների ներսում ծառայություն սկսելու համար, բոլոր պարամետրերը նշված են՝ բաժանված ստորակետերով: Սա կարող է լինել հրաձիգ, npm և այլն: Եթե նշված չէ, ապա կօգտագործվի Dockerfile-ից CMD հրահանգի արժեքը: Մենք նշում ենք npm,start.
Շրջակա միջավայրի փոփոխականներ — կոնտեյների միջավայրի փոփոխականներ: Սա կարող է լինել կամ պարզ տեքստային տվյալներ կամ գաղտնի փոփոխականներ կամ .
Պահպանում և անտառահատում — այստեղ մենք կկարգավորենք մուտքը CloudWatch Logs (ծառայություն AWS-ի տեղեկամատյանների համար): Դա անելու համար պարզապես միացրեք CloudWatch Logs-ի ավտոմատ կազմաձևման վանդակը: Առաջադրանքի սահմանումը ստեղծելուց հետո CloudWatch-ում ավտոմատ կերպով կստեղծվի տեղեկամատյանների խումբ: Լռելյայնորեն, տեղեկամատյանները պահվում են դրանում անորոշ ժամանակով: Ես խորհուրդ եմ տալիս փոխել պահպանման ժամկետը Never Expire-ից մինչև պահանջվող ժամկետ: Դա արվում է CloudWatch Log խմբերում, պետք է սեղմել ընթացիկ ժամանակաշրջանի վրա և ընտրել նորը։
ECS Cluster և ECS Capacity Provider
Գնացեք ECS → Կլաստերներ բաժին՝ կլաստեր ստեղծելու համար: Որպես ձևանմուշ մենք ընտրում ենք EC2 Linux + Networking:
Կլաստերի անվանումը - շատ կարևոր է, մենք այստեղ դարձնում ենք նույն անունը, ինչպես նշված է Launch Template պարամետրում ECS_CLUSTER, մեր դեպքում - DemoApiClusterProd. Նշեք «Ստեղծել դատարկ կլաստեր» վանդակը: Ընտրովի, դուք կարող եք միացնել Container Insights-ը՝ CloudWatch-ում ծառայությունների չափումները դիտելու համար: Եթե ամեն ինչ ճիշտ եք արել, ապա ECS Instances բաժնում կտեսնեք մեքենաներ, որոնք ստեղծվել են Auto Scaling խմբում:
Գնացեք ներդիր Կարողությունների մատակարարներ և ստեղծել նորը: Հիշեցնեմ, որ դա անհրաժեշտ է մեքենաների ստեղծումն ու անջատումը վերահսկելու համար՝ կախված գործող ECS առաջադրանքների քանակից: Կարևոր է նշել, որ մատակարարը կարող է նշանակվել միայն մեկ խմբի:
Auto Scaling խումբ — ընտրել նախկինում ստեղծված խումբը:
Կառավարվող մասշտաբավորում — միացրեք այն, որպեսզի մատակարարը կարողանա ընդլայնել ծառայությունը:
Նպատակային հզորություն % — առաջադրանքներով բեռնված մեքենաների քանի տոկոսն է մեզ անհրաժեշտ: Եթե դուք նշեք 100%, ապա բոլոր մեքենաները միշտ զբաղված կլինեն առաջադրանքներով: Եթե նշեք 50%, ապա մեքենաների կեսը միշտ անվճար կլինի։ Այս դեպքում, եթե ծանրաբեռնվածության կտրուկ թռիչք լինի, նոր տաքսիները անմիջապես կհասնեն անվճար մեքենաների, առանց սպասելու դեպքերի տեղակայմանը:
Կառավարվող դադարեցման պաշտպանություն — միացնել, այս պարամետրը թույլ է տալիս մատակարարին հեռացնել օրինակների պաշտպանությունը ջնջումից: Դա տեղի է ունենում, երբ մեքենայի վրա ակտիվ առաջադրանքներ չկան և թույլ է տալիս թիրախային հզորություն:
ECS ծառայության և մասշտաբի կարգավորում
Վերջին քայլը :) Ծառայություն ստեղծելու համար պետք է Ծառայություններ ներդիրում գնալ նախկինում ստեղծված կլաստերին:
Գործարկման տեսակը — դուք պետք է սեղմեք «Անցնել հզորությունների մատակարարի ռազմավարությանը» և ընտրեք նախկինում ստեղծված մատակարարներին:
Առաջադրանքի սահմանում — ընտրեք նախկինում ստեղծված Առաջադրանքի սահմանումը և դրա վերանայումը:
Ծառայության անվանումը — շփոթությունից խուսափելու համար մենք միշտ նշում ենք նույնը, ինչ առաջադրանքի սահմանումը:
Ծառայության տեսակը - միշտ կրկնօրինակ:
Առաջադրանքների քանակը — ծառայության մեջ ակտիվ առաջադրանքների ցանկալի թիվը: Այս պարամետրը վերահսկվում է մասշտաբով, բայց դեռ պետք է նշվի:
Առողջ նվազագույն տոկոս и Առավելագույն տոկոս — որոշել առաջադրանքների վարքագիծը տեղակայման ժամանակ: Լռելյայն արժեքներն են 100 և 200, ինչը ցույց է տալիս, որ տեղակայման պահին առաջադրանքների թիվը մի քանի անգամ կավելանա, այնուհետև կվերադառնա ցանկալի արժեքին: Եթե դուք ունեք 1 առաջադրանք առաջադրված՝ min=0, և max=100, ապա տեղակայման ժամանակ այն կսպանվի, իսկ դրանից հետո նորը կբարձրացվի, այսինքն՝ կլինի downtime։ Եթե 1 առաջադրանք է աշխատում, min=50, max=150, ապա տեղակայումն ընդհանրապես տեղի չի ունենա, քանի որ 1 առաջադրանքը չի կարելի կիսով չափ բաժանել կամ ավելացնել մեկուկես անգամ:
Տեղակայման տեսակը — հեռանալ Rolling թարմացումից:
Տեղադրման ձևանմուշներ - մեքենաների վրա առաջադրանքների տեղադրման կանոններ: Լռելյայն AZ Balanced Spread-ն է. սա նշանակում է, որ յուրաքանչյուր նոր առաջադրանք կտեղադրվի նոր օրինակի վրա, մինչև բոլոր հասանելիության գոտիների մեքենաները բարձրանան: Մենք սովորաբար կատարում ենք BinPack - CPU և Spread - AZ; այս քաղաքականության դեպքում առաջադրանքները հնարավորինս խիտ տեղադրվում են մեկ մեքենայի վրա յուրաքանչյուր պրոցեսորի վրա: Եթե անհրաժեշտ է ստեղծել նոր մեքենա, այն ստեղծվում է նոր հասանելիության գոտում։
Բեռի հավասարակշռիչի տեսակը — ընտրել Application Load Balancer:
Ծառայության IAM դերը - ընտրել ecsServiceRole.
Բեռնվածքի հավասարակշռիչի անվանումը — ընտրեք նախկինում ստեղծված հավասարակշռիչը:
Առողջության ստուգման արտոնյալ ժամանակահատված — Առողջական ստուգումներ կատարելուց առաջ դադար տալ նոր առաջադրանքը ներկայացնելուց հետո, մենք սովորաբար այն դնում ենք 60 վայրկյանի վրա:
Կոնտեյներ բեռնման հաշվեկշռի համար — Թիրախային խմբի անուն տարրում ընտրեք նախկինում ստեղծված խումբը, և ամեն ինչ ինքնաբերաբար կլրացվի։
Ծառայության ավտոմատ մասշտաբավորում — ծառայության մասշտաբի պարամետրեր: Ընտրեք «Կարգավորել ծառայության ավտոմատ մասշտաբը»՝ ձեր ծառայության ցանկալի թիվը կարգավորելու համար: Մենք սահմանում ենք առաջադրանքների նվազագույն և առավելագույն քանակը, երբ չափում ենք:
IAM դերը ծառայության ավտոմատ մասշտաբի համար - ընտրել AWSServiceRoleForApplicationAutoScaling_ECSService.
Առաջադրանքների մասշտաբի ավտոմատ քաղաքականություն - մասշտաբի կանոններ. Կան 2 տեսակ.
- Թիրախային հետևում — հետևել թիրախային չափորոշիչներին (CPU/RAM-ի օգտագործումը կամ յուրաքանչյուր առաջադրանքի համար հարցումների քանակը): Օրինակ, մենք ցանկանում ենք, որ պրոցեսորի միջին ծանրաբեռնվածությունը լինի 85%, երբ այն ավելի բարձրանա, նոր առաջադրանքներ կավելացվեն, մինչև այն հասնի նպատակային արժեքին: Եթե ծանրաբեռնվածությունն ավելի ցածր է, ապա առաջադրանքները կհեռացվեն, ընդհակառակը, եթե միացված չէ պաշտպանությունը նվազման դեմ (Անջատել մասշտաբը).
- Քայլի մասշտաբավորում - արձագանքը կամայական իրադարձության. Այստեղ դուք կարող եք կարգավորել արձագանքը ցանկացած իրադարձության (CloudWatch Alarm), երբ այն տեղի ունենա, կարող եք ավելացնել կամ հեռացնել առաջադրանքների նշված քանակությունը կամ նշել առաջադրանքների ճշգրիտ թիվը:
Ծառայությունը կարող է ունենալ մի քանի մասշտաբային կանոններ, դա կարող է օգտակար լինել, գլխավորն այն է, որ դրանք չհակասեն միմյանց:
Ամփոփում
Եթե հետևել եք հրահանգներին և օգտագործել եք նույն Docker պատկերը, ձեր ծառայությունը պետք է վերադարձնի նման էջ:
- Մենք ստեղծել ենք ձևանմուշ, որի համաձայն գործարկվում են ծառայության բոլոր մեքենաները: Մենք նաև սովորեցինք, թե ինչպես թարմացնել մեքենաները, երբ կաղապարը փոխվում է:
- Մենք կազմաձևել ենք կետային օրինակի կանգառի ազդանշանի մշակումը, ուստի այն ստանալուց հետո մեկ րոպեի ընթացքում բոլոր գործող առաջադրանքները հանվում են մեքենայից, այնպես որ ոչինչ չի կորչում կամ ընդհատվում:
- Մենք բարձրացրեցինք հավասարակշռիչը, որպեսզի բեռը հավասարաչափ բաշխվի մեքենաների վրա:
- Մենք ստեղծել ենք ծառայություն, որն աշխատում է տեղում, ինչը նվազեցնում է մեքենայի ծախսերը մոտ 3 անգամ:
- Մենք կարգավորել ենք ավտոմատ մասշտաբավորումը երկու ուղղություններով, որպեսզի կարողանանք կարգավորել ավելացած աշխատանքային բեռները՝ առանց պարապուրդի ծախսերի:
- Մենք օգտագործում ենք Capacity Provider-ը, որպեսզի հավելվածը կառավարի ենթակառուցվածքը (մեքենաները) և ոչ թե հակառակը:
- Մենք հիանալի ենք:
Եթե դուք ունեք կանխատեսելի բարձրացումներ բեռի մեջ, օրինակ՝ գովազդում եք մեծ էլփոստի արշավում, կարող եք կարգավորել մասշտաբը ըստ .
Դուք կարող եք նաև մասշտաբել՝ հիմնվելով ձեր համակարգի տարբեր մասերի տվյալների վրա: Օրինակ, մենք ունենք ֆունկցիոնալությունը բջջային հավելվածի օգտվողներ. Երբեմն արշավ է ուղարկվում 1 միլիոն+ մարդկանց: Նման բաշխումից հետո միշտ կա API-ին ուղղված հարցումների մեծ աճ, քանի որ շատ օգտվողներ միաժամանակ մուտք են գործում հավելված: Այսպիսով, եթե տեսնենք, որ գովազդային ծանուցումներ ուղարկելու հերթում զգալիորեն ավելի ստանդարտ ցուցանիշներ կան, մենք կարող ենք անմիջապես գործարկել մի քանի լրացուցիչ մեքենաներ և առաջադրանքներ՝ պատրաստ լինելու համար ծանրաբեռնվածությանը:
Ուրախ կլինեմ, եթե մեկնաբանություններում ինձ ասեք spot instance-ների և ECS-ի օգտագործման հետաքրքիր դեպքեր կամ ինչ-որ բան մասշտաբի մասին:
Շուտով հոդվածներ կլինեն այն մասին, թե ինչպես ենք մենք վայրկյանում մշակում հազարավոր վերլուծական իրադարձություններ հիմնականում առանց սերվերի կույտում (փողով) և ինչպես է աշխատում ծառայությունների տեղակայումը GitLab CI-ի և Terraform Cloud-ի միջոցով:
Բաժանորդագրվեք մեզ, հետաքրքիր կլինի:
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ , խնդրում եմ:
Արտադրության մեջ կիրառու՞մ եք տեղում օրինակներ:
-
22,2%Այո 6
-
66,7%No18
-
11,1%Ես դրանց մասին իմացա մի հոդվածից և նախատեսում եմ օգտագործել դրանք3
Քվեարկել է 27 օգտատեր։ 5 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com