Сайн уу! Намайг Кирилл гэдэг, би Adapty-ийн ерөнхий захирал. Манай архитектурын ихэнх хэсэг нь AWS дээр байдаг бөгөөд өнөөдөр би үйлдвэрлэлийн орчинд спот инстансуудыг ашигласнаар серверийн зардлыг хэрхэн 3 дахин бууруулсан тухай, мөн тэдгээрийн автомат масштабыг хэрхэн тохируулах талаар ярих болно. Эхлээд энэ нь хэрхэн ажилладаг талаар тойм, дараа нь эхлэх дэлгэрэнгүй заавар байх болно.
Spot Instance гэж юу вэ?
instances нь одоогоор идэвхгүй байгаа бусад AWS хэрэглэгчдийн серверүүд бөгөөд тэдгээрийг маш хямд үнээр зардаг (Амазон 90% хүртэл бичдэг, бидний туршлагаас харахад ~3x, бүс нутаг, AZ болон instance төрлөөс хамаарч өөр өөр байдаг). Тэдний ердийнхөөс гол ялгаа нь тэд хүссэн үедээ унтрааж болно. Тиймээс бид удаан хугацааны туршид тэдгээрийг онгон орчинд ашиглах, эсвэл ямар нэгэн зүйлийг тооцоолох даалгаварт ашиглах нь хэвийн зүйл гэж үзэж байсан бөгөөд завсрын үр дүнг S3 дээр эсвэл мэдээллийн санд хадгалсан боловч борлуулалтад ашигладаггүй. Үйлдвэрлэл дээр толбо ашиглах боломжийг олгодог гуравдагч этгээдийн шийдлүүд байдаг боловч манай тохиолдолд олон таяг байдаг тул бид хэрэгжүүлээгүй. Нийтлэлд дурдсан арга нь нэмэлт скрипт, титэм гэх мэт стандарт AWS функцийн хүрээнд бүхэлдээ ажилладаг.
Спот тохиолдлуудын үнийн түүхийг харуулсан цөөн хэдэн дэлгэцийн агшинг доор харуулав.
м5.eu-west-1 (Ирланд) бүсэд том. Үнэ 3 сарын турш тогтвортой байсан бөгөөд одоогоор 2.9 дахин хэмнэж байна.
м5.амс-зүүн-1 бүсэд том хэмжээтэй (Н.Виржиниа). Үнэ нь 3 сарын хугацаанд байнга өөрчлөгдөж байгаа бөгөөд одоогоор боломжийн бүсээс хамааран 2.3x-аас 2.8x хүртэл хэмнэж байна.
t3.us-зүүн-1 бүсэд жижиг (Н.Виржиниа). Үнэ 3 сарын турш тогтвортой байсан бөгөөд одоогоор 3.4 дахин хэмнэлттэй байна.
Үйлчилгээний архитектур
Энэ нийтлэлд бидний ярих үйлчилгээний үндсэн архитектурыг доорх диаграммд үзүүлэв.
Хэрэглээний ачааллыг тэнцвэржүүлэгч → EC2 Зорилтот бүлэг → Уян савны үйлчилгээ
Хэрэглээний ачааллыг тэнцвэржүүлэгч (ALB) нь EC2 зорилтот бүлэгт (TG) хүсэлт илгээдэг тэнцвэржүүлэгч болгон ашигладаг. TG нь ALB-ийн жишээн дээр портуудыг нээж, тэдгээрийг Elastic Container Service (ECS) контейнерийн портуудтай холбох үүрэгтэй. ECS нь Docker контейнеруудыг удирддаг AWS дахь Kubernetes-ийн аналог юм.
Нэг жишээ нь ижил порттой хэд хэдэн ажиллаж байгаа контейнертэй байж болох тул бид тэдгээрийг тогтмол тохируулах боломжгүй. ECS нь TG-д шинэ ажил эхлүүлж байгаагаа (Kubernetes-ийн нэр томъёогоор үүнийг pod гэж нэрлэдэг) хэлж, жишээн дээрх үнэгүй портуудыг шалгаж, тэдгээрийн аль нэгийг эхлүүлсэн даалгаварт хуваарилдаг. TG мөн эрүүл мэндийн шалгалтыг ашиглан инстанц болон API үүн дээр ажиллаж байгаа эсэхийг тогтмол шалгадаг бөгөөд хэрэв ямар нэгэн асуудал гарвал тэнд хүсэлт илгээхээ больдог.
EC2 Auto Scaling Groups + ECS Capacity Provayders
Дээрх диаграммд EC2 Auto Scaling Groups (ASG) үйлчилгээг харуулаагүй болно. Нэрнээс нь харахад энэ нь тохиолдлуудыг масштаблах үүрэгтэй гэдгийг ойлгож болно. Гэсэн хэдий ч саяхныг хүртэл AWS нь ECS-ээс ажиллаж байгаа машинуудын тоог удирдах чадваргүй байсан. ECS нь даалгаврын тоог, жишээлбэл, CPU-ийн хэрэглээ, RAM эсвэл хүсэлтийн тоогоор нэмэгдүүлэх боломжтой болгосон. Гэхдээ хэрэв даалгаврууд бүх чөлөөт тохиолдлуудыг эзэлдэг байсан бол шинэ машинууд автоматаар үүсгэгдээгүй болно.
Энэ нь ECS Capacity Providers (ECS CP) гарч ирснээр өөрчлөгдсөн. Одоо ECS дахь үйлчилгээ бүрийг ASG-тэй холбож болох бөгөөд хэрэв даалгаврууд нь ажиллаж байгаа тохиолдлуудад тохирохгүй бол шинийг өсгөх болно (гэхдээ тогтоосон ASG хязгаар дотор). Энэ нь мөн эсрэг чиглэлд ажилладаг, хэрэв ECS CP нь даалгаваргүй сул зогсолтуудыг харвал ASG-д тэдгээрийг унтраах команд өгнө. ECS CP нь жишээний ачааллын зорилтот хувийг тодорхойлох чадвартай бөгөөд ингэснээр тодорхой тооны машинууд ажлыг хурдан шуурхай гүйцэтгэхэд үнэ төлбөргүй байдаг; Би энэ талаар дараа нь ярих болно.
EC2 эхлүүлэх загварууд
Энэ дэд бүтцийг бий болгох талаар дэлгэрэнгүй ярихаас өмнө миний ярих сүүлчийн үйлчилгээ бол EC2 Launch Templates юм. Энэ нь бүх машиныг эхлүүлэх загвар үүсгэх боломжийг олгодог бөгөөд ингэснээр үүнийг эхнээс нь дахин давтахгүй байх болно. Эндээс та эхлүүлэх машин, хамгаалалтын бүлэг, дискний дүрс болон бусад олон параметрүүдийг сонгох боломжтой. Та мөн бүх эхлүүлсэн тохиолдлуудад байршуулах хэрэглэгчийн өгөгдлийг зааж өгч болно. Та хэрэглэгчийн өгөгдөлд скрипт ажиллуулж болно, жишээлбэл, та файлын агуулгыг засах боломжтой .
Энэ нийтлэлийн тохиргооны хамгийн чухал параметрүүдийн нэг бол = үнэн. Хэрэв энэ параметрийг идэвхжүүлсэн бол ECS нь спот инстанцыг устгаж байна гэсэн дохиог хүлээн авмагц үүн дээр ажилладаг бүх ажлыг ус зайлуулах төлөв рүү шилжүүлдэг. Энэ инстантад ямар ч шинэ даалгавар өгөхгүй; хэрэв яг одоо хийгдэх ажил байгаа бол тэдгээрийг цуцлах болно. Тэнцвэржүүлэгчийн хүсэлт ч ирэхээ больсон. Бодит үйл явдлаас 2 минутын өмнө жишээ устгасан тухай мэдэгдэл ирдэг. Тиймээс, хэрэв таны үйлчилгээ 2 минутаас илүү хугацаа шаардагдахгүй бөгөөд дискэнд юу ч хадгалахгүй бол та өгөгдөл алдалгүйгээр спот жишээг ашиглаж болно.
Дискний тухай - AWS саяхан ECS-тэй хамт уян хатан файлын системийг (EFS) ашиглах боломжтой; энэ схемийн хувьд диск хүртэл саад болохгүй, гэхдээ бид үүнийг оролдоогүй, учир нь зарчмын хувьд төлөвийг хадгалахад диск хэрэггүй. Анхдагч байдлаар, SIGINT-г хүлээн авсны дараа (даалгаврыг шавхах төлөв рүү шилжүүлэх үед илгээсэн) бүх ажиллаж байгаа ажлууд 30 секундын дараа зогсох бөгөөд тэд хараахан дуусаагүй байсан ч та энэ хугацааг параметрийг ашиглан өөрчилж болно. . Хамгийн гол нь спот машинуудад үүнийг 2 минутаас илүү хугацаагаар тохируулахгүй байх явдал юм.
Үйлчилгээг бий болгох
Тодорхойлсон үйлчилгээг бий болгох руу явцгаая. Энэ явцад би дээр дурдаагүй хэд хэдэн ашигтай цэгүүдийг нэмж тайлбарлах болно. Ерөнхийдөө энэ бол алхам алхмаар зааварчилгаа, гэхдээ би маш энгийн эсвэл эсрэгээрээ маш тодорхой тохиолдлуудыг авч үзэхгүй. Бүх үйлдлийг AWS визуал консол дээр гүйцэтгэдэг боловч CloudFormation эсвэл Terraform ашиглан программын дагуу хуулбарлах боломжтой. Adapty дээр бид Terraform ашигладаг.
EC2 эхлүүлэх загвар
Энэ үйлчилгээ нь ашиглах машинуудын тохиргоог бий болгодог. Загваруудыг EC2 -> Instances -> Launch templates хэсэгт удирддаг.
Амазоны машины зураг (AMI) — бүх тохиолдлуудыг эхлүүлэх дискний дүрсийг зааж өгнө үү. ECS-ийн хувьд ихэнх тохиолдолд Amazon-ийн оновчтой зургийг ашиглах нь зүйтэй. Энэ нь тогтмол шинэчлэгдэж байдаг бөгөөд ECS ажиллахад шаардлагатай бүх зүйлийг агуулдаг. Одоогийн зургийн ID-г мэдэхийн тулд хуудас руу очно уу , ашиглаж буй бүсээ сонгоод AMI ID-г хуулна уу. Жишээлбэл, us-east-1 бүсийн хувьд бичиж байх үеийн одоогийн ID байна ami-00c7c1cf5bdc913ed. Энэ ID-г "Захиалгат үнэ цэнийг зааж өгөх" зүйлд оруулах ёстой.
Жишээ төрөл - жишээний төрлийг заана. Таны даалгаварт хамгийн тохиромжтойг нь сонго.
Түлхүүр хос (нэвтрэх) — шаардлагатай бол SSH-ээр дамжуулан инстанцтай холбогдож болох сертификатыг зааж өгнө үү.
Сүлжээний тохиргоо — сүлжээний параметрүүдийг зааж өгнө. Сүлжээний платформ ихэнх тохиолдолд Virtual Private Cloud (VPC) байх ёстой. Аюулгүй байдлын бүлгүүд - таны жишээнүүдийн аюулгүй байдлын бүлгүүд. Бид жишээнүүдийн өмнө тэнцвэржүүлэгч ашиглах тул энд зөвхөн тэнцвэржүүлэгчээс ирж буй холболтыг зөвшөөрдөг бүлгийг зааж өгөхийг зөвлөж байна. Өөрөөр хэлбэл, та 2 (http) ба 80 (https) портууд дээр хаанаас ч дотогшоо холболт хийх боломжийг олгодог тэнцвэржүүлэгчийн нэг, хоёр дахь нь тэнцвэржүүлэгч бүлгийн дурын портууд дээр ирж буй холболтуудыг зөвшөөрдөг машинуудад зориулсан хамгаалалтын 443 бүлэгтэй байх болно. . Хоёр бүлгийн гадагшаа холболтыг TCP протокол ашиглан бүх хаягийн бүх порт руу нээх ёстой. Та гарч буй холболтын портууд болон хаягуудыг хязгаарлаж болох боловч хаалттай порт дээр ямар нэгэн зүйлд хандахыг оролдоогүй гэдгээ байнга хянаж байх хэрэгтэй.
Хадгалах (эзлэхүүн) — машинуудын дискний параметрүүдийг зааж өгнө. Дискний хэмжээ нь AMI-д заасан хэмжээнээс бага байж болохгүй; ECS Optimized-ийн хувьд 30 ГБ байна.
Нарийвчилсан дэлгэрэнгүй мэдээлэл - нэмэлт параметрүүдийг зааж өгөх.
Худалдан авах сонголт - бид спот жишээ худалдаж авахыг хүсч байгаа эсэх. Бид хүсч байна, гэхдээ бид энд энэ нүдийг шалгахгүй; бид үүнийг Автомат масштабын бүлэгт тохируулах болно, тэнд илүү олон сонголтууд байна.
IAM жишээний профайл — инстанцуудыг эхлүүлэх үүргийг заана. Тохиолдлуудыг ECS-д ажиллуулахын тулд тэдгээрт ихэвчлэн дүрд байдаг зөвшөөрөл шаардлагатай байдаг ecsInstanceRole. Зарим тохиолдолд үүнийг үүсгэж болно, хэрэв үгүй бол энд Үүнийг хэрхэн хийх талаар. Үүсгэсэний дараа бид үүнийг загварт зааж өгдөг.
Дараа нь олон параметрүүд байдаг, үндсэндээ та хаа сайгүй анхдагч утгыг үлдээж болно, гэхдээ тэдгээр нь тус бүрдээ тодорхой тайлбартай байдаг. Би үргэлж EBS-оновчлогдсон инстанц болон ашиглаж байгаа бол T2/T3 Хязгааргүй сонголтуудыг идэвхжүүлдэг тохиолдлууд.
Хэрэглэгчийн өгөгдөл — хэрэглэгчийн өгөгдлийг заана. Бид файлыг засах болно /etc/ecs/ecs.configECS агентын тохиргоог агуулсан .
Хэрэглэгчийн өгөгдөл ямар байж болох тухай жишээ:
#!/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 — Энэ параметр нь спот инстанцыг унтраах дохиог хүлээн авах үед түүн дээрх бүх ажлыг Ус зайлуулах төлөв рүү шилжүүлэхийг зааж өгдөг.
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 хэрэгцээгүй.
Мэдэхэд таатай байна: Шинэ хувилбарууд нь Docker, Linux, ECS agent гэх мэт хувилбаруудыг шинэчилдэг тул AMI-г тогтмол шинэчлэхийг зөвлөж байна. Үүнийг мартаж болохгүй. шинэ хувилбаруудыг гаргах тухай. Та имэйлээр мэдэгдэл хүлээн авч, гараар шинэчлэх боломжтой эсвэл шинэчлэгдсэн AMI-тай Launch Template-ийн шинэ хувилбарыг автоматаар үүсгэх Lambda функцийг бичиж болно.
EC2 Auto Scaling Group
Auto Scaling Group нь тохиолдлуудыг эхлүүлэх, масштаблах үүрэгтэй. Бүлгүүдийг EC2 -> Auto Scaling -> Auto Scaling Groups хэсэгт удирддаг.
Загварыг эхлүүлэх — өмнөх алхам дээр үүсгэсэн загварыг сонгоно уу. Бид өгөгдмөл хувилбарыг үлдээдэг.
Худалдан авах сонголтууд болон жишээний төрлүүд — кластерт зориулсан тохиолдлын төрлийг зааж өгнө. Adhere to launch template нь Launch Template дээрх жишээний төрлийг ашигладаг. Худалдан авалтын сонголтууд болон жишээний төрлүүдийг хослуулах нь инстанцийн төрлийг уян хатан тохируулах боломжийг танд олгоно. Бид үүнийг ашиглах болно.
Нэмэлт эрэлт хэрэгцээний суурь - Үргэлж ажиллах байнгын, спот бус тохиолдлын тоо.
Хүсэлтийн үндсэн дээр хувь — энгийн болон спот инстанцуудын хувийн харьцаа, 50-50-ийг тэнцүү хуваарилж, энгийн тохиолдол бүрт 20-80-ыг 4 спотыг өсгөнө. Энэ жишээний зорилгын үүднээс би 50-50-ийг зааж өгөх болно, гэхдээ бодит байдал дээр бид ихэнхдээ 20-80, зарим тохиолдолд 0-100-ийг хийдэг.
Инстанцийн төрлүүд — энд та кластерт хэрэглэгдэх нэмэлт төрлүүдийг зааж өгч болно. Би түүхийн утгыг сайн ойлгохгүй байгаа болохоор бид үүнийг хэзээ ч ашиглаж байгаагүй. Магадгүй энэ нь тодорхой төрлийн тохиолдлын хязгаарлалттай холбоотой байж болох ч дэмжлэг үзүүлэх замаар тэдгээрийг хялбархан нэмэгдүүлэх боломжтой. Хэрэв та програмыг мэддэг бол би үүнийг сэтгэгдэл дээр уншихдаа баяртай байх болно)
Сүлжээний — сүлжээний тохиргоо, VPC болон машинуудын дэд сүлжээг сонгох, ихэнх тохиолдолд боломжтой бүх дэд сүлжээг сонгох хэрэгтэй.
Ачааллыг тэнцвэржүүлэх - тэнцвэржүүлэгчийн тохиргоо, гэхдээ бид үүнийг тусад нь хийх болно, бид энд юу ч хүрэхгүй. Эрүүл мэндийн үзлэг мөн дараа нь тохируулах болно.
Бүлгийн хэмжээ - бид кластер дахь машинуудын тоо болон эхлэх үед хүссэн тооны машинуудын хязгаарлалтыг зааж өгдөг. Хэмжилтийн дагуу масштаб хийх шаардлагатай байсан ч кластер дахь машинуудын тоо хэзээ ч заасан хамгийн бага хэмжээнээс бага, дээд хэмжээнээс их байх ёсгүй.
Томруулах бодлого - масштабын параметрүүд, гэхдээ бид ажиллаж байгаа ECS даалгаврууд дээр үндэслэн масштаблах тул дараа нь масштабыг тохируулах болно.
Instance-ийн хамгаалалт - масштабыг багасгах үед тохиолдлуудыг устгахаас хамгаалах. ASG нь ажиллаж байгаа ажилтай машиныг устгахгүйн тулд бид үүнийг идэвхжүүлдэг. ECS Capacity Provider нь даалгаваргүй тохиолдолд хамгаалалтыг идэвхгүй болгоно.
Шошго нэмэх — та жишээнүүдэд шошго зааж өгч болно (үүнд шинэ тохиолдлуудыг тэмдэглэх нүдийг шалгах шаардлагатай). Би Нэрийн шошгыг зааж өгөхийг зөвлөж байна, тэгвэл бүлэг дотор эхлүүлсэн бүх тохиолдлууд ижил нэртэй байх бөгөөд тэдгээрийг консол дээр үзэхэд тохиромжтой.
Бүлэг үүсгэсний дараа үүнийг нээгээд Advanced configurations хэсэгт очно уу.Яагаад бүх сонголтууд үүсгэх үе шатанд консол дээр харагдахгүй байна.
Дуусгах бодлого - тохиолдлуудыг устгахдаа харгалзан үздэг дүрмүүд. Тэдгээрийг дарааллаар нь хэрэглэнэ. Бид ихэвчлэн доорх зурган дээрхийг ашигладаг. Нэгдүгээрт, хамгийн хуучин Launch Template-тай тохиолдлууд устгагдана (жишээлбэл, хэрэв бид AMI-г шинэчилсэн бол бид шинэ хувилбарыг үүсгэсэн боловч бүх тохиолдол түүн рүү шилжиж чадсан). Дараа нь дараагийн тооцооны цагт хамгийн ойр байгаа тохиолдлуудыг сонгоно. Тэгээд хамгийн эртнийх нь нээлтийн огноогоор сонгогддог.
Мэдэхэд таатай байна: ашиглахад тохиромжтой кластерт байгаа бүх машиныг шинэчлэх . Хэрэв та үүнийг өмнөх алхам дахь Lambda функцтэй хослуулбал бүрэн автоматжуулсан инстанцийн шинэчлэлтийн системтэй болно. Бүх машиныг шинэчлэхийн өмнө та бүлгийн бүх тохиолдлуудад жишээний масштабын хамгаалалтыг идэвхгүй болгох ёстой. Бүлэг дэх тохиргоо биш, харин машинуудаас өөрсдөө хамгаалах, үүнийг Instance management tab дээр хийдэг.
Хэрэглээний ачаалал тэнцвэржүүлэгч ба EC2 зорилтот бүлэг
Тэнцвэржүүлэгчийг EC2 → Ачаалал тэнцвэржүүлэх → Ачаалал тэнцвэржүүлэгч хэсэгт үүсгэсэн. Бид Хэрэглээний ачааллыг тэнцвэржүүлэгчийг ашиглах болно, янз бүрийн төрлийн тэнцвэржүүлэгчдийн харьцуулалтыг эндээс уншиж болно .
Сонсогчид - Дараа нь тэнцвэржүүлэгч дүрмийг ашиглан 80 ба 443 портуудыг хийж, 80-аас 443 руу дахин чиглүүлэх нь утга учиртай.
Бэлэн байдлын бүс - ихэнх тохиолдолд бид хүн бүрт хүртээмжтэй бүсийг сонгодог.
Аюулгүй байдлын тохиргоог хийнэ үү - тэнцвэржүүлэгчийн SSL сертификатыг энд зааж өгсөн бөгөөд хамгийн тохиромжтой сонголт бол ACM-д. Ялгаатай байдлын талаар Аюулгүй байдлын бодлого дотор уншиж болно , та үүнийг анхдагчаар сонгон үлдээж болно ELBSecurityPolicy-2016-08. Тэнцвэржүүлэгчийг үүсгэсний дараа та үүнийг харах болно DNS нэр, та өөрийн домэйны CNAME-г тохируулах хэрэгтэй. Жишээлбэл, Cloudflare дээр иймэрхүү харагдаж байна.
Аюулгүй байдлын бүлэг — тэнцвэржүүлэгчийн аюулгүй байдлын бүлгийг үүсгэх эсвэл сонгох, би энэ талаар EC2 эхлүүлэх загвар → Сүлжээний тохиргоо хэсэгт дээр дурдсан.
Зорилтот бүлэг - Бид тэнцвэржүүлэгчээс ирсэн хүсэлтийг машин руу чиглүүлэх, асуудал гарсан тохиолдолд солихын тулд тэдгээрийн бэлэн байдлыг шалгах үүрэгтэй бүлгийг бий болгодог. Зорилтот төрөл байх ёстой, Протокол и порт Хэрэв та тэнцвэржүүлэгч болон тохиолдлуудын хооронд холболт хийхдээ HTTPS ашигладаг бол тэдэнд гэрчилгээ байршуулах хэрэгтэй. Энэ жишээний зорилгоор бид үүнийг хийхгүй, зүгээр л 80-р портыг орхих болно.
Эрүүл мэндийн үзлэг - үйлчилгээний ажиллагааг шалгах параметрүүд. Бодит үйлчилгээнд энэ нь бизнесийн логикийн чухал хэсгүүдийг хэрэгжүүлэх тусдаа хүсэлт байх ёстой; энэ жишээний зорилгоор би анхдагч тохиргоог орхих болно. Дараа нь та хүсэлтийн интервал, завсарлага, амжилтын код гэх мэтийг сонгож болно. Бидний жишээн дээр ашиглах Docker дүрс нь 200 кодыг буцаадаг тул Амжилтын код 399-304-ийг зааж өгөх болно.
Зорилтотуудыг бүртгэх - Энд бүлгийн машинуудыг сонгосон боловч манай тохиолдолд үүнийг ECS хийх тул бид энэ алхамыг алгасах болно.
Мэдэхэд таатай байна: тэнцвэржүүлэгчийн түвшинд та S3-д тодорхой хугацаанд хадгалагдах логуудыг идэвхжүүлж болно . Тэндээс тэдгээрийг аналитик хийхэд зориулж гуравдагч талын үйлчилгээнд экспортлох боломжтой, эсвэл S3 дээрх өгөгдөл дээр шууд SQL асуулга хийх боломжтой. . Энэ нь тохиромжтой бөгөөд нэмэлт кодгүйгээр ажилладаг. Би мөн тодорхой хугацааны дараа S3 хувингаас лог устгах тохиргоог хийхийг зөвлөж байна.
ECS даалгаврын тодорхойлолт
Өмнөх алхмуудад бид үйлчилгээний дэд бүтэцтэй холбоотой бүх зүйлийг бий болгосон бол одоо бид эхлүүлэх чингэлэгүүдийг тайлбарлах болно. Үүнийг ECS → Task Definitions хэсэгт хийнэ.
Эхлэх төрлийн нийцтэй байдал - EC2-г сонгоно уу.
Даалгаврын гүйцэтгэлийн IAM үүрэг - сонгох ecsTaskExecutionRole. Үүнийг ашиглан лог бичиж, нууц хувьсагчдад хандах эрх өгдөг гэх мэт.
Container Definitions хэсэгт "Container Add" дээр дарна уу.
Image — төслийн кодтой зураг руу холбоно уу; энэ жишээнд би Docker Hub-ийн нийтийн зургийг ашиглах болно .
Санах ойн хязгаарлалт - савны санах ойн хязгаарлалт. Хатуу хязгаар - хатуу хязгаар, хэрэв контейнер заасан утгаас хэтэрвэл docker kill командыг гүйцэтгэх бөгөөд контейнер тэр даруй үхэх болно. Зөөлөн хязгаарлалт - зөөлөн хязгаар, сав нь заасан хэмжээнээс давж гарах боломжтой боловч машин дээр ажил байрлуулахдаа энэ параметрийг харгалзан үзнэ. Жишээлбэл, хэрэв машин нь 4 ГБ RAM-тай бөгөөд контейнерын зөөлөн хязгаар нь 2048 МБ бол энэ машин нь энэ контейнертэй хамгийн ихдээ 2 ажиллах боломжтой. Бодит байдал дээр 4 ГБ RAM нь 4096 МБ-аас арай бага бөгөөд үүнийг кластер дахь ECS Instances таб дээрээс харж болно. Зөөлөн хязгаар хатуу хязгаараас их байж болохгүй. Хэрэв нэг даалгаварт хэд хэдэн сав байгаа бол тэдгээрийн хязгаарыг нэгтгэн дүгнэхийг ойлгох нь чухал юм.
Портын зураглал - үед Хост порт Бид 0-ийг зааж байгаа бөгөөд энэ нь портыг динамикаар хуваарилж, Зорилтот бүлэгт хяналт тавих болно гэсэн үг юм. Контейнер порт — Таны аппликешн ажиллаж буй портыг ихэвчлэн гүйцэтгэх тушаалд зааж өгсөн эсвэл таны програмын код, Dockerfile гэх мэтээр зааж өгдөг. Бидний жишээнд бид 3000-ыг ашиглах болно, учир нь энэ нь жагсаалтад орсон байдаг ашиглаж байгаа зураг.
Эрүүл мэндийн үзлэг - Зорилтот бүлэгт тохируулсантай андуурч болохгүй савны эрүүл мэндийн хяналтын параметрүүд.
Байгаль орчны - орчны тохиргоо. CPU нэгжүүд - Санах ойн хязгаарлалттай төстэй, зөвхөн процессорын тухай. Процессорын цөм бүр нь 1024 нэгж тул сервер нь хоёр цөмт процессортой бөгөөд контейнерыг 512 гэж тохируулсан бол энэ контейнертэй 4 ажлыг нэг сервер дээр ажиллуулж болно. CPU-ийн нэгжүүд нь цөмүүдийн тоотой үргэлж тохирдог бөгөөд санах ойтой адил цөөхөн байж болохгүй.
тушаал — чингэлэг доторх үйлчилгээг эхлүүлэх команд, бүх параметрүүдийг таслалаар заана. Энэ нь gunicorn, npm гэх мэт байж болно. Хэрэв заагаагүй бол Dockerfile-ийн CMD зааврын утгыг ашиглана. Бид харуулж байна npm,start.
Хүрээлэн буй орчны хувьсагчид - контейнер орчны хувьсагч. Энэ нь энгийн текст өгөгдөл эсвэл нууц хувьсагч байж болно буюу .
Хадгалалт ба бүртгэл — энд бид CloudWatch Logs (AWS-ийн бүртгэлд зориулсан үйлчилгээ)-д нэвтрэх тохиргоог хийнэ. Үүнийг хийхийн тулд CloudWatch бүртгэлийг автоматаар тохируулах нүдийг идэвхжүүлнэ үү. Даалгаврын тодорхойлолтыг үүсгэсний дараа CloudWatch дээр логуудын бүлэг автоматаар үүсгэгдэнэ. Анхдагч байдлаар, бүртгэлүүд нь тодорхойгүй хугацаагаар хадгалагддаг; Хадгалах хугацааг Хэзээ ч дуусахгүй байхаас шаардлагатай хугацаа болгон өөрчлөхийг би зөвлөж байна. Энэ нь CloudWatch Log-ийн бүлгүүдэд хийгддэг тул та одоогийн үе дээр товшоод шинийг сонгох хэрэгтэй.
ECS кластер ба ECS чадавхи хангагч
Кластер үүсгэхийн тулд ECS → Clusters хэсэгт очно уу. Бид загвар болгон EC2 Linux + Networking-г сонгодог.
Кластерын нэр - маш чухал, бид энд Launch Template параметрт заасантай ижил нэртэй байна ECS_CLUSTER, бидний тохиолдолд - DemoApiClusterProd. Хоосон кластер үүсгэх нүдийг чагтална уу. Сонголтоор та CloudWatch дээрх үйлчилгээний хэмжүүрүүдийг харахын тулд Container Insights-ийг идэвхжүүлж болно. Хэрэв та бүх зүйлийг зөв хийсэн бол ECS Instances хэсэгт Auto Scaling бүлэгт үүсгэсэн машинуудыг харах болно.
Таб руу оч Хүчин чадал хангагчид мөн шинээр бий болгох. Ажиллаж буй ECS даалгаврын тооноос хамааран машин үүсгэх, унтраахыг хянах шаардлагатай гэдгийг танд сануулъя. Үйлчилгээ үзүүлэгчийг зөвхөн нэг бүлэгт хуваарилж болно гэдгийг анхаарах нь чухал юм.
Автомат масштабын бүлэг — өмнө нь үүсгэсэн бүлгийг сонгох.
Удирдах масштаб — үйлчилгээ үзүүлэгч үйлчилгээгээ өргөжүүлэхийн тулд үүнийг идэвхжүүлнэ.
Зорилтот хүчин чадал % - Бидэнд даалгавраар ачаалагдсан машинуудын хэдэн хувь нь хэрэгтэй вэ. Хэрэв та 100% гэж зааж өгвөл бүх машинууд үргэлж ажил хийх завгүй байх болно. Хэрэв та 50% -ийг зааж өгвөл машины тал хувь нь үргэлж үнэ төлбөргүй байх болно. Энэ тохиолдолд ачаалал огцом нэмэгдсэн тохиолдолд шинэ таксинууд шууд машинуудыг үнэгүй хүргэж өгөх болно.
Удирдлагатай дуусгавар болох хамгаалалт — идэвхжүүлнэ үү, энэ параметр нь үйлчилгээ үзүүлэгчийг устгалаас хамгаалалтыг арилгах боломжийг олгодог. Энэ нь машин дээр идэвхтэй ажил байхгүй үед тохиолддог бөгөөд Зорилтот багтаамж% -ийг зөвшөөрдөг.
ECS үйлчилгээ ба масштабын тохиргоо
Сүүлийн алхам :) Үйлчилгээ үүсгэхийн тулд та Үйлчилгээний таб дээрх өмнө нь үүсгэсэн кластер руу очих хэрэгтэй.
Эхлүүлэх төрөл — Та чадавхи нийлүүлэгчийн стратегид шилжих дээр товшоод өмнө нь үүсгэсэн үйлчилгээ үзүүлэгчдийг сонгох хэрэгтэй.
Даалгаврын тодорхойлолт — өмнө нь үүсгэсэн даалгаврын тодорхойлолт болон түүний засварыг сонгоно уу.
Үйлчилгээний нэр - төөрөгдөл гаргахгүйн тулд бид үргэлж Даалгаврын тодорхойлолттой ижил зүйлийг заадаг.
Үйлчилгээний төрөл - үргэлж хуулбар.
Даалгаврын тоо - үйлчилгээнд идэвхтэй даалгавруудын хүссэн тоо. Энэ параметрийг масштабаар хянадаг боловч тодорхой зааж өгөх ёстой.
Хамгийн бага эрүүл хувь и Хамгийн их хувь - байршуулах явцад даалгаврын зан төлөвийг тодорхойлох. Өгөгдмөл утгууд нь 100 ба 200 бөгөөд энэ нь байршуулах үед даалгаврын тоо хэд хэдэн удаа нэмэгдэж, дараа нь хүссэн утга руугаа буцах болно гэдгийг харуулж байна. Хэрэв танд min=1, max=0 гэсэн 100 даалгавар ажиллаж байгаа бол байршуулах явцад энэ нь устгагдах бөгөөд үүний дараа шинийг босгох болно, өөрөөр хэлбэл энэ нь зогсолт болно. Хэрэв 1 даалгавар ажиллаж байгаа бол min=50, max=150 бол байршуулалт огт болохгүй, учир нь 1 ажлыг хагас болгон хувааж эсвэл нэг хагас дахин нэмэгдүүлэх боломжгүй.
Байршуулах төрөл - Rolling шинэчлэлтийг орхи.
Байршлын загварууд - машин дээр даалгавар байрлуулах дүрэм. Өгөгдмөл нь AZ Balanced Spread - энэ нь бүх боломжит бүсийн машинууд нэмэгдэх хүртэл шинэ ажил бүрийг шинэ жишээн дээр байрлуулна гэсэн үг юм. Бид ихэвчлэн BinPack - CPU болон Spread - AZ-ийг хийдэг; энэ бодлогын дагуу даалгавруудыг CPU тутамд нэг машин дээр аль болох нягт байрлуулдаг. Хэрэв шинэ машин үүсгэх шаардлагатай бол түүнийг шинэ боломжийн бүсэд үүсгэнэ.
Ачаалал тэнцвэржүүлэгчийн төрөл — Програмын ачаалал тэнцвэржүүлэгчийг сонгоно уу.
Үйлчилгээний IAM үүрэг - сонгох ecsServiceRole.
Ачаалал тэнцвэржүүлэгчийн нэр — өмнө нь үүсгэсэн тэнцвэржүүлэгчийг сонгоно уу.
Эрүүл мэндийн үзлэгт хамрагдах хугацаа - Шинэ ажил гаргасны дараа эрүүл мэндийн үзлэг хийхээсээ өмнө түр зогсоо, бид үүнийг ихэвчлэн 60 секундээр тохируулдаг.
Ачаалах савны үлдэгдэл — Зорилтот бүлгийн нэр хэсэгт өмнө нь үүсгэсэн бүлгийг сонгоход бүх зүйл автоматаар бөглөгдөнө.
Үйлчилгээний автомат масштаб — үйлчилгээний масштабын параметрүүд. Үйлчилгээнийхээ хүссэн тоог тохируулахын тулд "Үйлчилгээний автомат масштабыг тохируулах" гэснийг сонгоно уу. Бид масштаблахдаа хамгийн бага ба хамгийн их даалгаврын тоог тогтоодог.
Үйлчилгээний автомат масштабын IAM үүрэг - сонгох AWSServiceRoleForApplicationAutoScaling_ECSService.
Автомат ажлын масштабын бодлого - масштаблах дүрэм. 2 төрөл байдаг:
- Зорилтот хяналт - зорилтот хэмжигдэхүүнийг хянах (CPU/RAM хэрэглээ эсвэл даалгавар тус бүрийн хүсэлтийн тоо). Жишээлбэл, бид процессорын дундаж ачааллыг 85% байлгахыг хүсч байгаа бөгөөд энэ нь нэмэгдэхэд зорилтот түвшинд хүрэх хүртэл шинэ ажлууд нэмэгдэх болно. Хэрэв ачаалал бага байвал масштабыг багасгахаас хамгаалах хамгаалалтыг идэвхжүүлээгүй тохиолдолд даалгавруудыг арилгах болно (Хэмжээг идэвхгүй болгох).
- Алхам масштаб - дур зоргоороо үйл явдалд үзүүлэх хариу үйлдэл. Энд та аливаа үйл явдалд үзүүлэх хариу үйлдлийг (CloudWatch дохиолол) тохируулах боломжтой бөгөөд энэ нь тохиолдоход заасан тооны даалгаврыг нэмэх, хасах, эсвэл яг хэдэн даалгаврыг зааж өгөх боломжтой.
Үйлчилгээ нь хэд хэдэн масштабын дүрэмтэй байж болно, энэ нь ашигтай байж болох бөгөөд гол зүйл бол тэдгээр нь хоорондоо зөрчилдөхгүй байх явдал юм.
дүгнэлт
Хэрэв та зааврыг дагаж, ижил Docker дүрсийг ашигласан бол таны үйлчилгээ иймэрхүү хуудсыг буцаана.
- Бид үйлчилгээнд байгаа бүх машинуудыг ажиллуулдаг загварыг бий болгосон. Мөн загвар өөрчлөгдөх үед машинуудыг хэрхэн шинэчлэх талаар сурсан.
- Бид цэгийн жишээг зогсоох дохионы боловсруулалтыг тохируулсан тул хүлээн авснаас хойш нэг минутын дотор ажиллаж байгаа бүх ажлыг машинаас устгаж, юу ч алдагдахгүй, тасалдахгүй.
- Бид ачааллыг машинуудад жигд хуваарилахын тулд тэнцвэржүүлэгчийг босгосон.
- Бид спот жишээн дээр ажилладаг үйлчилгээг бий болгосон бөгөөд энэ нь машины зардлыг ойролцоогоор 3 дахин бууруулдаг.
- Сул зогсолтын зардал гаргахгүйгээр ажлын ачааллыг нэмэгдүүлэхийн тулд бид хоёр чиглэлд автомат масштабыг тохируулсан.
- Бид Capacity Provider-ийг ашигладаг бөгөөд ингэснээр програм нь дэд бүтцийг (машин) удирддаг бөгөөд эсрэгээр нь биш юм.
- Бид мундаг.
Хэрэв таны ачаалал урьдчилан таамаглах боломжтой бол, жишээлбэл, та том и-мэйл кампанит ажилд сурталчилгаа хийж байгаа бол масштабыг дараах байдлаар тохируулж болно. .
Та мөн өөрийн системийн өөр өөр хэсгүүдийн өгөгдөлд тулгуурлан масштаблах боломжтой. Жишээлбэл, бидэнд функц бий гар утасны програмын хэрэглэгчид. Заримдаа кампанит ажлыг 1 сая гаруй хүнд илгээдэг. Ийм түгээлтийн дараа олон хэрэглэгчид нэгэн зэрэг програм руу нэвтэрдэг тул API-д хандах хүсэлт байнга нэмэгддэг. Хэрэв бид сурталчилгааны мэдэгдлийг илгээх дараалалд илүү олон стандарт үзүүлэлт байгааг олж харвал бид ачаалахад бэлэн байх хэд хэдэн нэмэлт машин, даалгавруудыг нэн даруй эхлүүлэх боломжтой.
Хэрэв та спот инстанц, ECS ашиглах сонирхолтой тохиолдлууд эсвэл масштабын талаар ямар нэг зүйлийг сэтгэгдэл дээр хэлвэл би баяртай байх болно.
Удалгүй бид ихэвчлэн сервергүй стек дээр (мөнгөтэй) секундэд олон мянган аналитик үйл явдлуудыг хэрхэн боловсруулдаг, GitLab CI болон Terraform Cloud ашиглан үйлчилгээг хэрхэн байршуулдаг тухай нийтлэлүүд гарах болно.
Бидэнд бүртгүүлээрэй, энэ нь сонирхолтой байх болно!
Зөвхөн бүртгэлтэй хэрэглэгчид санал асуулгад оролцох боломжтой. , гуйя.
Та үйлдвэрлэлд спот жишээ ашигладаг уу?
-
22,2%Тийм 6
-
66,7%Үгүй 18
-
11,1%Би тэдний талаар нийтлэлээс олж мэдсэн бөгөөд тэдгээрийг ашиглахаар төлөвлөж байна3
27 хэрэглэгч санал өгсөн. 5 хэрэглэгч түдгэлзсэн.
Эх сурвалж: www.habr.com