การสร้าง API ที่ปรับขนาดได้บนอินสแตนซ์ AWS Spot

สวัสดีทุกคน! ฉันชื่อคิริลล์ เป็น CTO ของ Adapty สถาปัตยกรรมส่วนใหญ่ของเราอยู่บน AWS และวันนี้ผมจะพูดถึงวิธีที่เราลดต้นทุนเซิร์ฟเวอร์ลง 3 เท่าโดยใช้อินสแตนซ์สปอตในสภาพแวดล้อมการใช้งานจริง รวมถึงวิธีตั้งค่าการปรับขนาดอัตโนมัติ ขั้นแรกจะมีภาพรวมของวิธีการทำงาน และจากนั้นจะมีคำแนะนำโดยละเอียดสำหรับการเริ่มต้นใช้งาน

อินสแตนซ์ Spot คืออะไร

จุด อินสแตนซ์คือเซิร์ฟเวอร์ของผู้ใช้ AWS อื่นๆ ที่ไม่ได้ใช้งานในปัจจุบัน และขายได้ในราคาลดพิเศษ (Amazon เขียนสูงถึง 90% จากประสบการณ์ของเรา ประมาณ 3 เท่า แตกต่างกันไปขึ้นอยู่กับภูมิภาค AZ และประเภทอินสแตนซ์) ความแตกต่างหลักจากปกติคือสามารถปิดได้ตลอดเวลา ดังนั้น เราเชื่อมานานแล้วว่าเป็นเรื่องปกติที่จะใช้สิ่งเหล่านี้สำหรับสภาพแวดล้อมใหม่ หรือสำหรับงานคำนวณบางอย่าง โดยบันทึกผลลัพธ์ระดับกลางไว้ใน S3 หรือในฐานข้อมูล แต่ไม่ใช่เพื่อการขาย มีโซลูชันของบริษัทอื่นที่อนุญาตให้คุณใช้สปอตในการผลิตได้ แต่มีไม้ค้ำยันมากมายสำหรับกรณีของเรา ดังนั้นเราจึงไม่ได้นำไปใช้ แนวทางที่อธิบายไว้ในบทความทำงานได้อย่างสมบูรณ์ภายในฟังก์ชันการทำงานของ AWS มาตรฐาน โดยไม่ต้องใช้สคริปต์เพิ่มเติม Crowns ฯลฯ

ด้านล่างนี้คือภาพหน้าจอบางส่วนที่แสดงประวัติราคาสำหรับอินสแตนซ์สปอต

m5.large ในภูมิภาค eu-west-1 (ไอร์แลนด์) ราคาทรงตัวเป็นส่วนใหญ่เป็นเวลา 3 เดือน โดยปัจจุบันประหยัดได้ 2.9 เท่า

m5.large ในภูมิภาค us-east-1 (เวอร์จิเนียเหนือ) ราคามีการเปลี่ยนแปลงตลอดเวลาในช่วง 3 เดือน ปัจจุบันประหยัดจาก 2.3 เท่าเป็น 2.8 เท่า ขึ้นอยู่กับโซนที่มีจำหน่าย

t3.small ในภูมิภาค us-east-1 (เวอร์จิเนียเหนือ) ราคาทรงตัวมา 3 เดือน ปัจจุบันประหยัดได้ 3.4 เท่า

สถาปัตยกรรมการบริการ

สถาปัตยกรรมพื้นฐานของบริการที่เราจะพูดถึงในบทความนี้แสดงอยู่ในแผนภาพด้านล่าง

Application Load Balancer → กลุ่มเป้าหมาย EC2 → Elastic Container Service

Application Load Balancer (ALB) ถูกใช้เป็นตัวปรับสมดุล ซึ่งจะส่งคำขอไปยังกลุ่มเป้าหมาย EC2 (TG) TG รับผิดชอบในการเปิดพอร์ตบนอินสแตนซ์สำหรับ ALB และเชื่อมต่อกับพอร์ตของคอนเทนเนอร์ Elastic Container Service (ECS) ECS เป็นอะนาล็อกของ Kubernetes ใน AWS ซึ่งจัดการคอนเทนเนอร์ Docker

อินสแตนซ์หนึ่งสามารถมีคอนเทนเนอร์ที่ทำงานอยู่ได้หลายคอนเทนเนอร์ด้วยพอร์ตเดียวกัน ดังนั้นเราจึงไม่สามารถตั้งค่าคงที่ได้ ECS แจ้ง TG ว่ากำลังเปิดตัวงานใหม่ (ในคำศัพท์เฉพาะของ Kubernetes เรียกว่าพ็อด) โดยจะตรวจสอบพอร์ตที่ว่างบนอินสแตนซ์ และมอบหมายพอร์ตใดพอร์ตหนึ่งให้กับงานที่เปิดตัว TG ยังตรวจสอบเป็นประจำว่าอินสแตนซ์และ API ทำงานอยู่หรือไม่โดยใช้การตรวจสุขภาพ และหากพบปัญหาใดๆ ก็จะหยุดส่งคำขอที่นั่น

EC2 Auto Scaling Groups + ผู้ให้บริการความจุ ECS

แผนภาพด้านบนไม่แสดงบริการ 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 ช่วยให้คุณสร้างเทมเพลตตามที่เครื่องทั้งหมดจะเริ่มทำงานเพื่อไม่ให้ทำซ้ำตั้งแต่ต้นทุกครั้ง ที่นี่คุณสามารถเลือกประเภทของเครื่องที่จะสตาร์ท กลุ่มความปลอดภัย ดิสก์อิมเมจ และพารามิเตอร์อื่นๆ อีกมากมาย คุณยังสามารถระบุข้อมูลผู้ใช้ที่จะอัปโหลดไปยังอินสแตนซ์ที่เปิดใช้งานทั้งหมดได้ คุณสามารถรันสคริปต์ในข้อมูลผู้ใช้ได้ เช่น คุณสามารถแก้ไขเนื้อหาของไฟล์ได้ การกำหนดค่าเอเจนต์ ECS.

หนึ่งในพารามิเตอร์การกำหนดค่าที่สำคัญที่สุดสำหรับบทความนี้คือ ECS_ENABLE_SPOT_INSTANCE_DRAINING=จริง หากเปิดใช้งานพารามิเตอร์นี้ ทันทีที่ ECS รับสัญญาณว่าอินสแตนซ์สปอตกำลังถูกลบออกไป อินสแตนซ์จะถ่ายโอนงานทั้งหมดที่ทำงานบนอินสแตนซ์นั้นไปยังสถานะการระบาย จะไม่มีการมอบหมายงานใหม่ให้กับอินสแตนซ์นี้ หากมีงานที่ต้องการเปิดตัวในตอนนี้ งานเหล่านั้นจะถูกยกเลิก คำขอจากบาลานเซอร์ก็หยุดมาเช่นกัน การแจ้งเตือนการลบอินสแตนซ์จะมา 2 นาทีก่อนเหตุการณ์จริง ดังนั้น หากบริการของคุณไม่ได้ทำงานนานกว่า 2 นาทีและไม่ได้บันทึกสิ่งใดลงดิสก์ คุณสามารถใช้อินสแตนซ์สปอตได้โดยไม่สูญเสียข้อมูล

เกี่ยวกับดิสก์ - AWS เมื่อเร็ว ๆ นี้ ฉันมี เป็นไปได้ที่จะใช้ Elastic File System (EFS) ร่วมกับ ECS ด้วยรูปแบบนี้แม้แต่ดิสก์ก็ไม่ใช่อุปสรรค แต่เราไม่ได้ลองเพราะโดยหลักการแล้วเราไม่ต้องใช้ดิสก์เพื่อจัดเก็บสถานะ ตามค่าเริ่มต้น หลังจากได้รับ SIGINT (ส่งเมื่องานถูกโอนไปยังสถานะ Draining) งานที่กำลังทำงานอยู่ทั้งหมดจะหยุดลงหลังจาก 30 วินาที แม้ว่าจะยังไม่เสร็จสิ้นก็ตาม คุณสามารถเปลี่ยนเวลานี้ได้โดยใช้พารามิเตอร์ ECS_CONTAINER_STOP_TIMEOUT. สิ่งสำคัญคืออย่าตั้งค่าไว้นานกว่า 2 นาทีสำหรับเครื่องเฉพาะจุด

การสร้างบริการ

มาดูการสร้างบริการที่อธิบายไว้กันดีกว่า ในกระบวนการนี้ ฉันจะอธิบายเพิ่มเติมถึงประเด็นที่เป็นประโยชน์หลายประการที่ไม่ได้กล่าวถึงข้างต้น โดยทั่วไปนี่เป็นคำแนะนำทีละขั้นตอน แต่ฉันจะไม่พิจารณาบางกรณีพื้นฐานหรือในทางกลับกันกรณีที่เฉพาะเจาะจงมาก การดำเนินการทั้งหมดจะดำเนินการใน Visual Console ของ AWS แต่สามารถทำซ้ำโดยทางโปรแกรมได้โดยใช้ CloudFormation หรือ Terraform ที่ Adapty เราใช้ Terraform

เทมเพลตการเปิดตัว EC2

บริการนี้สร้างการกำหนดค่าของเครื่องที่จะใช้ เทมเพลตได้รับการจัดการในส่วน EC2 -> อินสแตนซ์ -> เรียกใช้เทมเพลต

อิมเมจเครื่องของ Amazon (AMI) — ระบุดิสก์อิมเมจที่จะเปิดใช้อินสแตนซ์ทั้งหมด สำหรับ ECS ในกรณีส่วนใหญ่ การใช้อิมเมจที่ปรับให้เหมาะสมจาก Amazon ถือว่าคุ้มค่า มีการอัปเดตเป็นประจำและมีทุกสิ่งที่จำเป็นสำหรับการทำงานของ ECS หากต้องการทราบรหัสรูปภาพปัจจุบัน ให้ไปที่หน้านั้น AMI ที่ปรับให้เหมาะสมกับ Amazon ECSเลือกภูมิภาคที่คุณใช้และคัดลอก AMI ID ตัวอย่างเช่น สำหรับภูมิภาค us-east-1 รหัสปัจจุบัน ณ เวลาที่เขียนคือ ami-00c7c1cf5bdc913ed. ต้องแทรก ID นี้ลงในรายการระบุค่าที่กำหนดเอง

ประเภทอินสแตนซ์ — ระบุประเภทอินสแตนซ์ เลือกอันที่เหมาะกับงานของคุณมากที่สุด

คู่กุญแจ (เข้าสู่ระบบ) — ระบุใบรับรองที่คุณสามารถเชื่อมต่อกับอินสแตนซ์ผ่าน SSH ได้ หากจำเป็น

ตั้งค่าเครือข่าย — ระบุพารามิเตอร์เครือข่าย แพลตฟอร์มเครือข่าย โดยส่วนใหญ่แล้วควรมี Virtual Private Cloud (VPC) กลุ่มความปลอดภัย — กลุ่มความปลอดภัยสำหรับอินสแตนซ์ของคุณ เนื่องจากเราจะใช้บาลานเซอร์หน้าอินสแตนซ์ ฉันขอแนะนำให้ระบุกลุ่มที่นี่ที่อนุญาตการเชื่อมต่อขาเข้าจากบาลานเซอร์เท่านั้น นั่นคือคุณจะมีกลุ่มความปลอดภัย 2 กลุ่ม กลุ่มหนึ่งสำหรับบาลานเซอร์ซึ่งอนุญาตการเชื่อมต่อขาเข้าจากทุกที่บนพอร์ต 80 (http) และ 443 (https) และกลุ่มที่สองสำหรับเครื่องซึ่งอนุญาตการเชื่อมต่อขาเข้าบนพอร์ตใดๆ จากกลุ่มบาลานเซอร์ . การเชื่อมต่อขาออกในทั้งสองกลุ่มจะต้องเปิดโดยใช้โปรโตคอล TCP ไปยังพอร์ตทั้งหมดไปยังที่อยู่ทั้งหมด คุณสามารถจำกัดพอร์ตและที่อยู่สำหรับการเชื่อมต่อขาออกได้ แต่คุณจะต้องตรวจสอบอย่างต่อเนื่องว่าคุณไม่ได้พยายามเข้าถึงบางสิ่งบนพอร์ตที่ปิด

พื้นที่เก็บข้อมูล (เล่ม) — ระบุพารามิเตอร์ดิสก์สำหรับเครื่อง ขนาดดิสก์ต้องไม่เล็กกว่าที่ระบุใน AMI สำหรับ ECS Optimized คือ 30 GiB

รายละเอียดขั้นสูง — ระบุพารามิเตอร์เพิ่มเติม

ตัวเลือกการซื้อ — ไม่ว่าเราต้องการซื้ออินสแตนซ์แบบสปอตหรือไม่ เราต้องการ แต่เราจะไม่ทำเครื่องหมายที่ช่องนี้ที่นี่ เราจะกำหนดค่าในกลุ่ม Auto Scaling ซึ่งมีตัวเลือกเพิ่มเติมอยู่ที่นั่น

โปรไฟล์อินสแตนซ์ IAM — ระบุบทบาทที่จะเปิดตัวอินสแตนซ์ เพื่อให้อินสแตนซ์ทำงานใน ECS ได้ อินสแตนซ์จะต้องมีสิทธิ์ซึ่งมักจะพบได้ในบทบาท ecsInstanceRole. ในบางกรณีก็สามารถสร้างได้ ถ้าไม่ก็นี่ การแนะนำ เกี่ยวกับวิธีการทำเช่นนี้ หลังจากสร้างแล้ว เราจะระบุไว้ในเทมเพลต
ถัดไปมีพารามิเตอร์มากมาย โดยทั่วไปคุณสามารถทิ้งค่าเริ่มต้นไว้ได้ทุกที่ แต่แต่ละรายการมีคำอธิบายที่ชัดเจน ฉันเปิดใช้งานอินสแตนซ์ที่ปรับให้เหมาะสม EBS และตัวเลือก T2/T3 Unlimited เสมอหากใช้ ระเบิดได้ ตัวอย่าง.

เวลาที่ผู้ใช้ – ระบุข้อมูลผู้ใช้ เราจะแก้ไขไฟล์ /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.config

ECS_CLUSTER=DemoApiClusterProd — พารามิเตอร์บ่งชี้ว่าอินสแตนซ์เป็นของคลัสเตอร์ที่มีชื่อที่กำหนด นั่นคือคลัสเตอร์นี้จะสามารถวางงานบนเซิร์ฟเวอร์นี้ได้ เรายังไม่ได้สร้างคลัสเตอร์ แต่เราจะใช้ชื่อนี้เมื่อสร้างคลัสเตอร์

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — พารามิเตอร์ระบุว่าเมื่อได้รับสัญญาณให้ปิดอินสแตนซ์สปอต งานทั้งหมดบนอินสแตนซ์ควรถูกถ่ายโอนไปยังสถานะ Draining

ECS_CONTAINER_STOP_TIMEOUT=1m - พารามิเตอร์ระบุว่าหลังจากได้รับสัญญาณ SIGINT แล้ว งานทั้งหมดจะมีเวลา 1 นาทีก่อนที่จะถูกฆ่า

ECS_ENGINE_AUTH_TYPE=docker — พารามิเตอร์บ่งชี้ว่ารูปแบบนักเทียบท่าถูกใช้เป็นกลไกการอนุญาต

ECS_ENGINE_AUTH_DATA=... — พารามิเตอร์การเชื่อมต่อกับรีจิสตรีคอนเทนเนอร์ส่วนตัว ซึ่งเป็นที่เก็บอิมเมจ Docker ของคุณ หากเป็นแบบสาธารณะ คุณไม่จำเป็นต้องระบุอะไร

สำหรับวัตถุประสงค์ของบทความนี้ ฉันจะใช้รูปภาพสาธารณะจาก Docker Hub ดังนั้นให้ระบุพารามิเตอร์ ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA ไม่ต้องการ

น่ารู้: ขอแนะนำให้อัปเดต AMI เป็นประจำ เนื่องจากเวอร์ชันใหม่จะอัปเดตเวอร์ชันของ Docker, Linux, ECS agent ฯลฯ หากต้องการอย่าลืมสิ่งนี้ คุณสามารถทำได้ ตั้งค่าการแจ้งเตือน เกี่ยวกับการเปิดตัวเวอร์ชันใหม่ คุณสามารถรับการแจ้งเตือนทางอีเมลและอัปเดตด้วยตนเอง หรือคุณสามารถเขียนฟังก์ชัน Lambda ซึ่งจะสร้างเทมเพลต Launch เวอร์ชันใหม่โดยอัตโนมัติด้วย AMI ที่อัปเดตแล้ว

กลุ่มปรับขนาดอัตโนมัติ EC2

Auto Scaling Group มีหน้าที่รับผิดชอบในการเปิดใช้และปรับขนาดอินสแตนซ์ กลุ่มจะได้รับการจัดการในส่วน EC2 -> Auto Scaling -> Auto Scaling Groups

เปิดตัวเทมเพลต — เลือกเทมเพลตที่สร้างในขั้นตอนก่อนหน้า เราคงเวอร์ชันเริ่มต้นไว้

ซื้อตัวเลือกและประเภทอินสแตนซ์ — ระบุประเภทของอินสแตนซ์สำหรับคลัสเตอร์ ปฏิบัติตามเทมเพลตการเปิดใช้งานโดยใช้ประเภทอินสแตนซ์จากเทมเพลตการเปิดใช้งาน รวมตัวเลือกการซื้อและประเภทอินสแตนซ์เข้าด้วยกันทำให้คุณสามารถกำหนดค่าประเภทอินสแตนซ์ได้อย่างยืดหยุ่น เราจะใช้มัน

ฐานตามความต้องการเพิ่มเติม — จำนวนอินสแตนซ์ปกติที่ไม่ใช่สปอตที่จะทำงานตลอดเวลา

เปอร์เซ็นต์ตามความต้องการที่สูงกว่าฐาน — เปอร์เซ็นต์อัตราส่วนของอินสแตนซ์ปกติและอินสแตนซ์สปอต 50-50 จะถูกกระจายเท่า ๆ กัน 20-80 สำหรับแต่ละอินสแตนซ์ปกติ 4 สปอตจะเพิ่มขึ้น สำหรับวัตถุประสงค์ของตัวอย่างนี้ ฉันจะระบุ 50-50 แต่ในความเป็นจริงแล้ว เรามักจะทำ 20-80 ในบางกรณี 0-100

ประเภทอินสแตนซ์ — ที่นี่คุณสามารถระบุประเภทเพิ่มเติมของอินสแตนซ์ที่จะใช้ในคลัสเตอร์ได้ เราไม่เคยใช้เพราะว่าไม่เข้าใจความหมายของเรื่องจริงๆ บางทีนี่อาจเป็นเพราะข้อจำกัดของอินสแตนซ์บางประเภท แต่สามารถเพิ่มได้อย่างง่ายดายผ่านการสนับสนุน หากทราบใบสมัครแล้วยินดีอ่านในคอมเม้นท์ครับ)

เครือข่าย — การตั้งค่าเครือข่าย เลือก VPC และซับเน็ตสำหรับเครื่อง ในกรณีส่วนใหญ่ คุณควรเลือกซับเน็ตที่มีอยู่ทั้งหมด

โหลดบาลานซ์ - การตั้งค่าบาลานเซอร์ แต่เราจะทำแยกกัน เราจะไม่แตะต้องสิ่งใดที่นี่ ตรวจสุขภาพ จะได้รับการกำหนดค่าในภายหลังด้วย

ขนาดกลุ่ม — เราระบุขีดจำกัดเกี่ยวกับจำนวนเครื่องในคลัสเตอร์และจำนวนเครื่องที่ต้องการเมื่อเริ่มต้น จำนวนเครื่องในคลัสเตอร์จะไม่น้อยกว่าค่าต่ำสุดที่ระบุและมากกว่าจำนวนสูงสุด แม้ว่าการปรับขนาดควรเกิดขึ้นตามเมตริกก็ตาม

นโยบายการปรับขนาด — พารามิเตอร์การปรับขนาด แต่เราจะปรับขนาดตามงาน ECS ที่ทำงานอยู่ ดังนั้นเราจะกำหนดค่าการปรับขนาดในภายหลัง

การป้องกันการขยายขนาดอินสแตนซ์ — การป้องกันอินสแตนซ์จากการถูกลบเมื่อลดขนาดลง เราเปิดใช้งานเพื่อให้ ASG ไม่ลบเครื่องที่กำลังทำงานอยู่ ECS Capacity Provider จะปิดใช้งานการป้องกันสำหรับอินสแตนซ์ที่ไม่มีงาน

เพิ่มแท็ก — คุณสามารถระบุแท็กสำหรับอินสแตนซ์ได้ (ในกรณีนี้ ต้องทำเครื่องหมายที่ช่องทำเครื่องหมายแท็กอินสแตนซ์ใหม่) ฉันแนะนำให้ระบุแท็กชื่อ จากนั้นอินสแตนซ์ทั้งหมดที่เปิดตัวภายในกลุ่มจะมีชื่อเดียวกัน และดูได้สะดวกในคอนโซล

หลังจากสร้างกลุ่มแล้ว ให้เปิดแล้วไปที่ส่วน การกำหนดค่าขั้นสูง เหตุใดจึงไม่เห็นตัวเลือกทั้งหมดในคอนโซลในขั้นตอนการสร้าง

นโยบายการสิ้นสุด — กฎที่นำมาพิจารณาเมื่อลบอินสแตนซ์ นำไปใช้ตามลำดับ เรามักจะใช้อันที่อยู่ในภาพด้านล่าง ขั้นแรก อินสแตนซ์ที่มีเทมเพลตการเปิดใช้งานเก่าที่สุดจะถูกลบ (เช่น หากเราอัปเดต AMI เราจะสร้างเวอร์ชันใหม่ แต่อินสแตนซ์ทั้งหมดสามารถสลับไปใช้เวอร์ชันนั้นได้) จากนั้นเลือกอินสแตนซ์ที่ใกล้กับชั่วโมงการเรียกเก็บเงินถัดไปมากที่สุด จากนั้นอันที่เก่าที่สุดจะถูกเลือกตามวันที่เปิดตัว

น่ารู้: เพื่ออัพเดททุกเครื่องในคลัสเตอร์ ใช้งานสะดวก รีเฟรชอินสแตนซ์. หากคุณรวมสิ่งนี้เข้ากับฟังก์ชัน Lambda จากขั้นตอนก่อนหน้า คุณจะมีระบบอัปเดตอินสแตนซ์อัตโนมัติเต็มรูปแบบ ก่อนที่จะอัปเดตเครื่องทั้งหมด คุณต้องปิดใช้งานการป้องกันการขยายอินสแตนซ์สำหรับอินสแตนซ์ทั้งหมดในกลุ่ม ไม่ใช่การกำหนดค่าในกลุ่ม แต่เป็นการป้องกันจากเครื่องเอง ซึ่งทำได้บนแท็บการจัดการอินสแตนซ์

Application Load Balancer และกลุ่มเป้าหมาย EC2

บาลานเซอร์ถูกสร้างขึ้นในส่วน EC2 → โหลดบาลานเซอร์ → โหลดบาลานเซอร์ เราจะใช้ Application Load Balancer โดยสามารถอ่านการเปรียบเทียบบาลานเซอร์ประเภทต่างๆ ได้ที่ หน้าบริการ.

ฟัง - สมเหตุสมผลที่จะสร้างพอร์ต 80 และ 443 และเปลี่ยนเส้นทางจาก 80 เป็น 443 โดยใช้กฎบาลานเซอร์ในภายหลัง

โซนความพร้อมใช้งาน — ในกรณีส่วนใหญ่ เราจะเลือกโซนการเข้าถึงสำหรับทุกคน

กำหนดการตั้งค่าความปลอดภัย — ใบรับรอง SSL สำหรับบาลานเซอร์ระบุไว้ที่นี่ ตัวเลือกที่สะดวกที่สุดคือ ทำใบรับรอง ในพลอากาศเอก เกี่ยวกับความแตกต่าง นโยบายความปลอดภัย สามารถอ่านได้ใน เอกสารคุณสามารถปล่อยให้เลือกไว้ตามค่าเริ่มต้นได้ ELBSecurityPolicy-2016-08. หลังจากสร้างบาลานเซอร์แล้ว คุณจะเห็นมัน ชื่อ DNSซึ่งคุณต้องกำหนดค่า CNAME สำหรับโดเมนของคุณ ตัวอย่างเช่น นี่คือลักษณะที่ปรากฏใน Cloudflare

กลุ่มรักษาความปลอดภัย — สร้างหรือเลือกกลุ่มความปลอดภัยสำหรับบาลานเซอร์ ฉันเขียนเพิ่มเติมเกี่ยวกับเรื่องนี้ไว้ด้านบนในส่วนเทมเพลตการเปิดใช้งาน EC2 → การตั้งค่าเครือข่าย

กลุ่มเป้าหมาย — เราสร้างกลุ่มที่รับผิดชอบในการกำหนดเส้นทางคำขอจากบาลานเซอร์ไปยังเครื่องจักร และตรวจสอบความพร้อมใช้งานเพื่อทดแทนในกรณีที่เกิดปัญหา ประเภทเป้าหมาย จะต้องเป็นอินสแตนซ์ โปรโตคอล и ท่าเรือ ใดๆ หากคุณใช้ HTTPS เพื่อการสื่อสารระหว่างบาลานเซอร์และอินสแตนซ์ คุณจะต้องอัปโหลดใบรับรองไปยังอินสแตนซ์เหล่านั้น สำหรับวัตถุประสงค์ของตัวอย่างนี้ เราจะไม่ทำเช่นนี้ เราจะออกจากพอร์ต 80 เพียงอย่างเดียว

ตรวจสุขภาพ — พารามิเตอร์สำหรับตรวจสอบการทำงานของบริการ ในการบริการจริง นี่ควรเป็นคำขอแยกต่างหากที่ใช้ส่วนสำคัญของตรรกะทางธุรกิจ เพื่อวัตถุประสงค์ของตัวอย่างนี้ ฉันจะคงการตั้งค่าเริ่มต้นไว้ ถัดไป คุณสามารถเลือกช่วงเวลาคำขอ หมดเวลา รหัสความสำเร็จ ฯลฯ ในตัวอย่างของเรา เราจะระบุรหัสความสำเร็จ 200-399 เนื่องจากอิมเมจ Docker ที่จะใช้ส่งคืนรหัส 304

ลงทะเบียนเป้าหมาย — ที่นี่เลือกรถยนต์สำหรับกลุ่มแล้ว แต่ในกรณีของเรา ECS จะเป็นผู้ดำเนินการ ดังนั้นเราจึงข้ามขั้นตอนนี้ไป

น่ารู้: ที่ระดับบาลานเซอร์ คุณสามารถเปิดใช้งานบันทึกที่จะถูกบันทึกไว้ใน S3 ในบางส่วนได้ รูปแบบ. จากนั้นสามารถส่งออกไปยังบริการของบริษัทอื่นเพื่อการวิเคราะห์ หรือคุณสามารถทำการสืบค้น SQL บนข้อมูลใน S3 ได้โดยตรงด้วย โดยใช้เอเธน่า. สะดวกและใช้งานได้โดยไม่ต้องใช้รหัสเพิ่มเติม ฉันยังแนะนำให้ตั้งค่าการลบบันทึกออกจากบัคเก็ต S3 หลังจากระยะเวลาที่กำหนด

คำจำกัดความของงาน ECS

ในขั้นตอนก่อนหน้านี้ เราได้สร้างทุกอย่างที่เกี่ยวข้องกับโครงสร้างพื้นฐานของบริการ ตอนนี้ เรามาอธิบายคอนเทนเนอร์ที่เราจะเปิดตัวกันต่อ ซึ่งทำได้ในส่วน ECS → คำจำกัดความของงาน

ความเข้ากันได้ของประเภทการเปิดตัว - เลือก EC2

บทบาท IAM การดำเนินการงาน - เลือก ecsTaskExecutionRole. เมื่อใช้จะมีการเขียนบันทึก ให้สิทธิ์การเข้าถึงตัวแปรลับ ฯลฯ

ในส่วนคำจำกัดความของคอนเทนเนอร์ คลิกเพิ่มคอนเทนเนอร์

ภาพ — ลิงก์ไปยังรูปภาพพร้อมรหัสโปรเจ็กต์ สำหรับตัวอย่างนี้ ฉันจะใช้รูปภาพสาธารณะจาก Docker Hub bitnami/โหนดตัวอย่าง:0.0.1.

ขีดจำกัดของหน่วยความจำ — ขีดจำกัดหน่วยความจำสำหรับคอนเทนเนอร์ ฮาร์ดลิมิต — ขีดจำกัดฮาร์ด หากคอนเทนเนอร์เกินค่าที่ระบุ คำสั่ง docker kill จะถูกดำเนินการ คอนเทนเนอร์จะตายทันที ซอฟท์ลิมิต — ขีดจำกัดซอฟต์ คอนเทนเนอร์สามารถเกินค่าที่ระบุได้ แต่พารามิเตอร์นี้จะถูกนำมาพิจารณาเมื่อวางงานบนเครื่องจักร ตัวอย่างเช่น หากเครื่องมี RAM 4 GiB และขีดจำกัดซอฟต์ของคอนเทนเนอร์คือ 2048 MiB เครื่องนี้สามารถมีงานที่ทำงานอยู่ได้สูงสุด 2 งานด้วยคอนเทนเนอร์นี้ ในความเป็นจริง RAM ขนาด 4 GiB นั้นน้อยกว่า 4096 MiB เล็กน้อย ซึ่งสามารถดูได้บนแท็บอินสแตนซ์ ECS ในคลัสเตอร์ ขีดจำกัดซอฟต์ต้องไม่มากกว่าขีดจำกัดฮาร์ด สิ่งสำคัญคือต้องเข้าใจว่าหากมีหลายคอนเทนเนอร์ในงานเดียว ขีดจำกัดจะถูกสรุป

การแมปพอร์ต - ใน พอร์ตโฮสต์ เราระบุ 0 ซึ่งหมายความว่าพอร์ตจะถูกกำหนดแบบไดนามิกและจะถูกตรวจสอบโดยกลุ่มเป้าหมาย พอร์ตคอนเทนเนอร์ — พอร์ตที่แอปพลิเคชันของคุณทำงานมักจะระบุไว้ในคำสั่งดำเนินการหรือกำหนดไว้ในรหัสแอปพลิเคชันของคุณ Dockerfile ฯลฯ สำหรับตัวอย่างของเรา เราจะใช้ 3000 เนื่องจากอยู่ในรายการ ไฟล์นักเทียบท่า รูปภาพที่ใช้งานอยู่

ตรวจสุขภาพ — พารามิเตอร์การตรวจสอบสภาพคอนเทนเนอร์ อย่าสับสนกับพารามิเตอร์ที่กำหนดค่าไว้ในกลุ่มเป้าหมาย

สิ่งแวดล้อม — การตั้งค่าสภาพแวดล้อม หน่วยซีพียู - คล้ายกับขีดจำกัดหน่วยความจำ เฉพาะเกี่ยวกับโปรเซสเซอร์เท่านั้น แกนประมวลผลแต่ละตัวมีขนาด 1024 หน่วย ดังนั้นหากเซิร์ฟเวอร์มีโปรเซสเซอร์แบบดูอัลคอร์และคอนเทนเนอร์ถูกตั้งค่าเป็น 512 ดังนั้น 4 งานที่มีคอนเทนเนอร์นี้สามารถเปิดใช้งานได้บนเซิร์ฟเวอร์เดียว หน่วย CPU จะสอดคล้องกับจำนวนคอร์เสมอ โดยจะต้องมีจำนวนคอร์น้อยกว่านั้นไม่น้อย เช่นเดียวกับหน่วยความจำ

คำสั่ง — คำสั่งเพื่อเริ่มบริการภายในคอนเทนเนอร์ โดยระบุพารามิเตอร์ทั้งหมดโดยคั่นด้วยเครื่องหมายจุลภาค นี่อาจเป็น gunicorn, npm ฯลฯ หากไม่ได้ระบุ ระบบจะใช้ค่าของคำสั่ง CMD จาก Dockerfile เราระบุ npm,start.

ตัวแปรสภาพแวดล้อม — ตัวแปรสภาพแวดล้อมของคอนเทนเนอร์ นี่อาจเป็นข้อมูลข้อความธรรมดาหรือตัวแปรลับก็ได้ ผู้จัดการความลับ หรือ ที่เก็บพารามิเตอร์.

การจัดเก็บและการบันทึก — ที่นี่เราจะตั้งค่าการบันทึกใน CloudWatch Logs (บริการสำหรับบันทึกจาก AWS) ในการดำเนินการนี้ เพียงเปิดใช้งานช่องทำเครื่องหมายกำหนดค่า CloudWatch Logs อัตโนมัติ หลังจากสร้างคำจำกัดความของงานแล้ว กลุ่มของบันทึกจะถูกสร้างขึ้นโดยอัตโนมัติใน CloudWatch ตามค่าเริ่มต้น บันทึกจะถูกจัดเก็บไว้โดยไม่มีกำหนด ฉันแนะนำให้เปลี่ยนระยะเวลาการเก็บรักษาจากไม่มีวันหมดอายุเป็นระยะเวลาที่ต้องการ ซึ่งดำเนินการในกลุ่ม CloudWatch Log คุณต้องคลิกช่วงเวลาปัจจุบันและเลือกช่วงเวลาใหม่

คลัสเตอร์ ECS และผู้ให้บริการความจุ ECS

ไปที่ส่วน ECS → คลัสเตอร์ เพื่อสร้างคลัสเตอร์ เราเลือก EC2 Linux + Networking เป็นเทมเพลต

ชื่อคลัสเตอร์ - สำคัญมาก เราทำให้ที่นี่เป็นชื่อเดียวกับที่ระบุไว้ในพารามิเตอร์ Launch Template ECS_CLUSTERในกรณีของเรา - DemoApiClusterProd. เลือกช่องทำเครื่องหมายสร้างคลัสเตอร์ว่าง หรือคุณสามารถเปิดใช้งาน Container Insights เพื่อดูตัววัดสำหรับบริการใน CloudWatch ได้ หากคุณทำทุกอย่างถูกต้องแล้ว ในส่วนอินสแตนซ์ ECS คุณจะเห็นเครื่องที่สร้างขึ้นในกลุ่ม Auto Scaling

ไปที่แท็บ ผู้ให้บริการความจุ และสร้างอันใหม่ ฉันขอเตือนคุณว่าจำเป็นต้องควบคุมการสร้างและปิดเครื่องโดยขึ้นอยู่กับจำนวนงาน ECS ที่ทำงานอยู่ สิ่งสำคัญคือต้องทราบว่าสามารถกำหนดผู้ให้บริการให้กับกลุ่มเดียวเท่านั้น

กลุ่มปรับขนาดอัตโนมัติ — เลือกกลุ่มที่สร้างไว้ก่อนหน้านี้

การปรับขนาดที่มีการจัดการ — เปิดใช้งานเพื่อให้ผู้ให้บริการสามารถปรับขนาดบริการได้

กำลังการผลิตเป้าหมาย % — เราต้องการเครื่องจักรที่โหลดงานกี่เปอร์เซ็นต์ หากคุณระบุเป็น 100% เครื่องทั้งหมดจะยุ่งอยู่กับงานที่กำลังดำเนินอยู่ตลอดเวลา หากคุณระบุ 50% รถยนต์ครึ่งหนึ่งจะว่างเสมอ ในกรณีนี้ หากมีการบรรทุกเพิ่มขึ้นอย่างรวดเร็ว แท็กซี่ใหม่จะได้รับรถยนต์ฟรีทันที โดยไม่ต้องรอให้อินสแตนซ์ถูกใช้งาน

การป้องกันการยกเลิกที่มีการจัดการ — เปิดใช้งาน พารามิเตอร์นี้อนุญาตให้ผู้ให้บริการลบการป้องกันอินสแตนซ์ออกจากการลบ สิ่งนี้เกิดขึ้นเมื่อไม่มีงานที่ใช้งานอยู่ในเครื่องและอนุญาตให้ความจุเป้าหมาย%

บริการ ECS และการตั้งค่าการปรับขนาด

ขั้นตอนสุดท้าย :) หากต้องการสร้างบริการ คุณต้องไปที่คลัสเตอร์ที่สร้างไว้ก่อนหน้านี้บนแท็บบริการ

ประเภทการเปิดตัว — คุณต้องคลิกเปลี่ยนไปใช้กลยุทธ์ผู้ให้บริการความจุ และเลือกผู้ให้บริการที่สร้างไว้ก่อนหน้านี้

คำจำกัดความของงาน — เลือกคำจำกัดความของงานที่สร้างไว้ก่อนหน้านี้และการแก้ไข

ชื่อบริการ — เพื่อหลีกเลี่ยงความสับสน เราจะระบุให้เหมือนกับคำจำกัดความของงานเสมอ

ประเภทบริการ - จำลองเสมอ

จำนวนงาน — จำนวนงานที่ต้องการในบริการ พารามิเตอร์นี้ถูกควบคุมโดยการปรับขนาด แต่ยังคงต้องระบุอยู่

เปอร์เซ็นต์สุขภาพขั้นต่ำ и เปอร์เซ็นต์สูงสุด — กำหนดพฤติกรรมของงานระหว่างการใช้งาน ค่าเริ่มต้นคือ 100 และ 200 ซึ่งบ่งชี้ว่าในขณะที่ใช้งาน จำนวนงานจะเพิ่มขึ้นหลายครั้ง จากนั้นจึงกลับสู่ค่าที่ต้องการ หากคุณมี 1 งานที่รันอยู่ ค่าต่ำสุด=0 และสูงสุด=100 ในระหว่างการปรับใช้ งานนั้นจะถูกปิด และหลังจากนั้นงานใหม่จะถูกยกขึ้น กล่าวคือ จะเป็นช่วงหยุดทำงาน หาก 1 งานกำลังทำงานอยู่ ต่ำสุด=50 สูงสุด=150 การปรับใช้จะไม่เกิดขึ้นเลย เนื่องจาก 1 งานไม่สามารถแบ่งครึ่งหรือเพิ่มขึ้นหนึ่งเท่าครึ่งได้

ประเภทการปรับใช้ — ออกจากการอัปเดตแบบกลิ้ง

เทมเพลตตำแหน่ง — กฎสำหรับการวางงานบนเครื่องจักร ค่าเริ่มต้นคือ AZ Balanced Spread ซึ่งหมายความว่าแต่ละงานใหม่จะถูกวางไว้บนอินสแตนซ์ใหม่จนกว่าเครื่องใน Availability Zone ทั้งหมดจะเพิ่มขึ้น โดยปกติแล้วเราจะทำ BinPack - CPU และ Spread - AZ ด้วยนโยบายนี้ งานจะถูกจัดวางอย่างหนาแน่นที่สุดบนเครื่องหนึ่งเครื่องต่อ CPU หากจำเป็นต้องสร้างเครื่องใหม่ เครื่องจะถูกสร้างขึ้นในโซนความพร้อมใช้งานใหม่

ประเภทโหลดบาลานเซอร์ — เลือก Application Load Balancer

บทบาท IAM ของบริการ - เลือก ecsServiceRole.

ชื่อตัวจัดสรรภาระงาน — เลือกบาลานเซอร์ที่สร้างไว้ก่อนหน้านี้

ระยะเวลาผ่อนผันการตรวจสุขภาพ — หยุดชั่วคราวก่อนดำเนินการตรวจสุขภาพหลังจากเปิดตัวงานใหม่ โดยปกติเราตั้งค่าไว้ที่ 60 วินาที

คอนเทนเนอร์สำหรับโหลดบาลานซ์ — ในรายการชื่อกลุ่มเป้าหมาย ให้เลือกกลุ่มที่สร้างไว้ก่อนหน้า จากนั้นทุกอย่างจะถูกกรอกโดยอัตโนมัติ

บริการปรับขนาดอัตโนมัติ — พารามิเตอร์การปรับขนาดบริการ เลือกกำหนดค่า Service Auto Scaling เพื่อปรับจำนวนบริการที่คุณต้องการ เรากำหนดจำนวนงานขั้นต่ำและสูงสุดเมื่อปรับขนาด

บทบาท IAM สำหรับ Service Auto Scaling - เลือก AWSServiceRoleForApplicationAutoScaling_ECSService.

นโยบายการปรับขนาดงานอัตโนมัติ – กฎเกณฑ์สำหรับการปรับขนาด มี 2 ​​ประเภท:

1. การติดตามเป้าหมาย — การติดตามตัวชี้วัดเป้าหมาย (การใช้งาน CPU/RAM หรือจำนวนคำขอสำหรับแต่ละงาน) ตัวอย่างเช่น เราต้องการให้โหลดตัวประมวลผลโดยเฉลี่ยอยู่ที่ 85% เมื่อสูงขึ้น งานใหม่จะถูกเพิ่มจนกว่าจะถึงค่าเป้าหมาย หากโหลดลดลง งานจะถูกลบออก ในทางกลับกัน เว้นแต่จะเปิดใช้งานการป้องกันการลดขนาดลง (ปิดการใช้งานการขยายขนาด).
2. ปรับขนาดขั้นตอน - การตอบสนองต่อเหตุการณ์ตามอำเภอใจ ที่นี่คุณสามารถกำหนดค่าการตอบสนองต่อเหตุการณ์ใดๆ (CloudWatch Alarm) เมื่อเกิดขึ้น คุณสามารถเพิ่มหรือลบจำนวนงานที่ระบุ หรือระบุจำนวนงานที่แน่นอนได้

บริการอาจมีกฎการปรับขนาดหลายข้อซึ่งอาจมีประโยชน์สิ่งสำคัญคือต้องแน่ใจว่ากฎเหล่านั้นจะไม่ขัดแย้งกัน

ข้อสรุป

หากคุณทำตามคำแนะนำและใช้อิมเมจ Docker เดียวกัน บริการของคุณควรส่งคืนเพจในลักษณะนี้

1. เราได้สร้างเทมเพลตตามการเปิดตัวเครื่องทั้งหมดในบริการ นอกจากนี้เรายังได้เรียนรู้วิธีอัปเดตเครื่องเมื่อมีการเปลี่ยนแปลงเทมเพลต
2. เราได้กำหนดค่าการประมวลผลสัญญาณหยุดอินสแตนซ์สปอตแล้ว ดังนั้นภายในหนึ่งนาทีหลังจากได้รับสัญญาณ งานที่กำลังทำงานอยู่ทั้งหมดจะถูกลบออกจากเครื่อง ดังนั้นจึงไม่มีอะไรสูญหายหรือหยุดชะงัก
3. เรายกเครื่องถ่วงเพื่อกระจายโหลดอย่างสม่ำเสมอทั่วทั้งเครื่องจักร
4. เราได้สร้างบริการที่ทำงานบนอินสแตนซ์เฉพาะจุด ซึ่งช่วยลดต้นทุนเครื่องจักรได้ประมาณ 3 เท่า
5. เราได้กำหนดค่าการปรับขนาดอัตโนมัติในทั้งสองทิศทางเพื่อรองรับปริมาณงานที่เพิ่มขึ้นโดยไม่ทำให้เกิดต้นทุนการหยุดทำงาน
6. เราใช้ตัวให้บริการความจุเพื่อให้แอปพลิเคชันจัดการโครงสร้างพื้นฐาน (เครื่องจักร) ไม่ใช่วิธีอื่น
7. พวกเราเก่งมาก

หากคุณมีการโหลดที่เพิ่มขึ้นอย่างรวดเร็วที่คาดการณ์ได้ เช่น คุณกำลังโฆษณาในแคมเปญอีเมลขนาดใหญ่ คุณสามารถตั้งค่าการปรับขนาดได้โดย ตารางเวลา.

คุณยังสามารถปรับขนาดตามข้อมูลจากส่วนต่างๆ ของระบบของคุณได้ เช่น เรามีฟังก์ชันการทำงาน การส่งข้อเสนอส่งเสริมการขายแต่ละรายการ ผู้ใช้แอปพลิเคชันมือถือ บางครั้งแคมเปญอาจถูกส่งไปยังผู้คนมากกว่า 1 ล้านคน หลังจากการเผยแพร่ดังกล่าว จะมีคำขอไปยัง API เพิ่มขึ้นอย่างมากเสมอ เนื่องจากผู้ใช้จำนวนมากเข้าสู่ระบบแอปพลิเคชันในเวลาเดียวกัน ดังนั้นหากเราเห็นว่ามีตัวบ่งชี้มาตรฐานในคิวสำหรับส่งการแจ้งเตือนแบบพุชส่งเสริมการขายมากขึ้นอย่างเห็นได้ชัด เราก็สามารถเปิดใช้เครื่องจักรและงานเพิ่มเติมหลายรายการได้ทันทีเพื่อเตรียมพร้อมสำหรับการโหลด

ฉันจะดีใจถ้าคุณบอกฉันในความคิดเห็นกรณีที่น่าสนใจของการใช้อินสแตนซ์สปอตและ ECS หรือบางอย่างเกี่ยวกับการปรับขนาด

เร็วๆ นี้ จะมีบทความเกี่ยวกับวิธีที่เราประมวลผลเหตุการณ์การวิเคราะห์หลายพันรายการต่อวินาทีบนสแต็กแบบไร้เซิร์ฟเวอร์เป็นส่วนใหญ่ (ด้วยเงิน) และวิธีการปรับใช้บริการโดยใช้ GitLab CI และ Terraform Cloud

สมัครสมาชิกกับเรามันจะน่าสนใจ!

เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ เข้าสู่ระบบ, โปรด.

คุณใช้อินสแตนซ์สปอตในการผลิตหรือไม่

• ลด 22,2%ใช่6

• ลด 66,7%หมายเลข 18

• ลด 11,1%ฉันเรียนรู้เกี่ยวกับสิ่งเหล่านั้นจากบทความและวางแผนที่จะใช้มัน3

ผู้ใช้ 27 คนโหวต ผู้ใช้ 5 รายงดออกเสียง

ที่มา: will.com