AWS Solutions Architect · บทเรียน

การปรับขนาดอัตโนมัติและการทำโหลดบาลานซ์บริการ ECS

เชื่อม ALB เข้ากับบริการ ECS เพื่อกำหนดเส้นทางตามพาธ และกำหนดค่าการปรับขนาดบริการอัตโนมัติให้ตอบสนองต่อ CPU หรือเมตริก CloudWatch แบบกำหนดเอง

การปรับขนาดอัตโนมัติและการทำโหลดบาลานซ์บริการ ECS เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

เหตุผลที่ต้องใช้การปรับขนาดบริการ ECS อัตโนมัติ

การกำหนด จำนวนที่ต้องการ ของบริการ ECS ไว้คงที่ไม่สามารถตอบสนองต่อความผันผวนของปริมาณการรับส่งข้อมูลได้ คุณจึงต้องเลือกว่าจะจัดสรรทรัพยากรมากเกินไป (ทำให้สิ้นเปลืองค่าใช้จ่าย) หรือจัดสรรน้อยเกินไป (ทำให้ประสิทธิภาพลดลง) การปรับขนาดบริการ ECS อัตโนมัติจะปรับจำนวนงานที่ต้องการโดยอัตโนมัติตามเมทริกซ์ของ CloudWatch โดยทำงานเบื้องหลังผ่านบริการ Application Auto Scaling ซึ่งเป็นเฟรมเวิร์กเดียวกับที่ DynamoDB, Aurora และ ElastiCache ใช้ การปรับขนาดบริการ ECS อัตโนมัติรองรับนโยบายการติดตามเป้าหมาย การปรับขนาดแบบเป็นขั้น และการปรับขนาดตามกำหนดเวลา

การลงทะเบียน ECS เป็นเป้าหมายที่ปรับขนาดได้

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

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id 'service/MyAppCluster/MyAppService' \
  --min-capacity 2 \
  --max-capacity 20

การติดตามเป้าหมายสำหรับบริการ ECS

การติดตามเป้าหมายเป็นนโยบายการปรับขนาดอัตโนมัติที่แนะนำสำหรับบริการ ECS ส่วนใหญ่ เมทริกซ์เป้าหมายที่ใช้กันมากที่สุดคือ ECSServiceAverageCPUUtilization โดยกำหนดเป้าหมายไว้ที่ 50–70% แล้ว ECS จะเพิ่มหรือลดจำนวนงานเพื่อรักษาระดับการใช้ CPU ดังกล่าว อีกเมทริกซ์ที่มีประโยชน์มากคือ จำนวนคำขอ ALB ต่อเป้าหมาย ซึ่งใช้ติดตามจำนวนคำขอ ALB ต่องานหนึ่งงาน และปรับขนาดเพื่อรักษาอัตราคำขอเป้าหมายต่ออินสแตนซ์ AWS จะจัดการการเพิ่มและลดขนาดโดยอัตโนมัติ พร้อมช่วงพักที่เหมาะสม

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id 'service/MyAppCluster/MyAppService' \
  --policy-name 'ECSTargetTracking' \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "TargetValue": 60.0,
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

การกำหนดเส้นทาง ALB ไปยังบริการ ECS

การแนบ Application Load Balancer (ALB) เข้ากับบริการ ECS จะกระจายการรับส่งข้อมูล HTTP/HTTPS ไปยังงานที่กำลังทำงานอยู่ทั้งหมด กลุ่มเป้าหมายของ ALB จะลงทะเบียน IP ของแต่ละงาน (สำหรับ Fargate/awsvpc) หรือพอร์ตของคอนเทนเนอร์ (สำหรับโหมด bridge) ECS จะลงทะเบียนงานใหม่กับกลุ่มเป้าหมายโดยอัตโนมัติเมื่อเริ่มทำงาน และยกเลิกการลงทะเบียนเมื่องานหยุดทำงาน ALB จะตรวจสอบสถานะการทำงานของแต่ละงาน งานที่ไม่ผ่านการตรวจสอบจะถูกระบายออก (ปิดการเชื่อมต่ออย่างเรียบร้อย) ก่อนที่บริการจะยุติงานดังกล่าว

การกำหนดเส้นทางตามพาธสำหรับหลายบริการ

รูปแบบการใช้งานที่มีประสิทธิภาพรูปแบบหนึ่งคือการกำหนดเส้นทางของพาธ URL ที่แตกต่างกันไปยังบริการ ECS ที่แตกต่างกันโดยใช้ การกำหนดเส้นทางตามพาธของ ALB ALB เดียวที่มีตัวรับฟัง HTTPS หนึ่งตัวสามารถกำหนดเส้นทางดังนี้: /api/orders/* ไปยังบริการ ECS ของคำสั่งซื้อ, /api/users/* ไปยังบริการ ECS ของผู้ใช้ และ /api/products/* ไปยังบริการ ECS ของสินค้า โดยแต่ละบริการมีบริการ ECS ของตนเองและปรับขนาดได้อย่างอิสระ วิธีนี้ไม่จำเป็นต้องใช้ตัวจัดสรรโหลดแยกสำหรับแต่ละไมโครเซอร์วิส ช่วยลดค่าใช้จ่ายและทำให้การจัดการ DNS ง่ายขึ้น

# ALB listener rule for ECS microservice routing
aws elbv2 create-rule \
  --listener-arn 'arn:aws:elasticloadbalancing:...' \
  --priority 10 \
  --conditions '[{"Field": "path-pattern", "Values": ["/api/orders/*"]}]' \
  --actions '[{"Type": "forward", "TargetGroupArn": "arn:...OrdersTargetGroup"}]'

การระบายการเชื่อมต่อและความล่าช้าในการยกเลิกการลงทะเบียน

เมื่อกำลังยุติงาน ECS (ระหว่างการลดขนาดหรือการนำไปใช้งาน) ALB จะทำเครื่องหมายงานนั้นว่า กำลังระบายการเชื่อมต่อ และหยุดกำหนดเส้นทางคำขอใหม่ไปยังงานดังกล่าว ขณะเดียวกันก็ปล่อยให้คำขอที่กำลังดำเนินการเสร็จสิ้น ความล่าช้าในการยกเลิกการลงทะเบียน (ค่าเริ่มต้น 300 วินาที และกำหนดได้ตั้งแต่ 0–3600 วินาที) คือระยะเวลาที่ ALB รอก่อนปิดการเชื่อมต่อโดยบังคับ สำหรับ ECS ที่มีระยะเวลาประมวลผลคำขอสั้น ให้ตั้งค่าความล่าช้าในการยกเลิกการลงทะเบียนให้ต่ำลง (30–60 วินาที) เพื่อเร่งการนำไปใช้งานและการลดขนาด สำหรับการเชื่อมต่อที่ใช้เวลานาน (WebSocket, การอัปโหลดไฟล์) ให้ใช้ค่าความล่าช้าที่สูงกว่า

# Set deregistration delay on target group to 60 seconds
aws elbv2 modify-target-group-attributes \
  --target-group-arn 'arn:aws:elasticloadbalancing:...' \
  --attributes 'Key=deregistration_delay.timeout_seconds,Value=60'

เมทริกซ์แบบกำหนดเองสำหรับการปรับขนาด ECS

นอกเหนือจาก CPU และหน่วยความจำแล้ว ให้เผยแพร่ เมทริกซ์ CloudWatch แบบกำหนดเองจากแอปพลิเคชันของคุณ (ความลึกของคิว เซสชันที่ใช้งานอยู่ ตัวชี้วัดประสิทธิภาพทางธุรกิจ) แล้วใช้เมทริกซ์เหล่านี้ควบคุมการปรับขนาด ตัวอย่างเช่น หากงาน ECS แต่ละงานรองรับข้อความในคิวพร้อมกันได้ 50 ข้อความ ให้เผยแพร่ความลึกของคิว SQS เป็นเมทริกซ์แบบกำหนดเอง และสร้างนโยบายการติดตามเป้าหมายโดยกำหนดเป้าหมายไว้ที่ 50 ข้อความต่องาน วิธีนี้ทำให้การปรับขนาดขับเคลื่อนโดยตรรกะทางธุรกิจโดยตรง แทนการพึ่งพาเมทริกซ์โครงสร้างพื้นฐานที่อาจไม่สัมพันธ์กับภาระงานของแอปพลิเคชัน

aws application-autoscaling put-scaling-policy \
  --policy-name 'QueueDepthScaling' \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "CustomizedMetricSpecification": {
      "MetricName": "QueueDepth",
      "Namespace": "MyApp",
      "Statistic": "Average"
    },
    "TargetValue": 50.0
  }' \
  --resource-id 'service/MyCluster/WorkerService' \
  --scalable-dimension ecs:service:DesiredCount \
  --service-namespace ecs

การป้องกันงานจากการลดขนาด

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

# From inside the ECS task container
curl -X PUT 'http://169.254.170.2/v3/tasks/scale-in-protection' \
  -H 'Content-Type: application/json' \
  -d '{"ProtectionEnabled": true, "ExpiresInMinutes": 60}'

เมทริกซ์การปรับขนาด: CPU เทียบกับหน่วยความจำและ ALB

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

ตัวตัดวงจรการนำไปใช้งานของ ECS

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

aws ecs create-service \
  --cluster 'MyAppCluster' \
  --service-name 'MyAppService' \
  --task-definition 'myapp-task:5' \
  --desired-count 3 \
  --deployment-configuration '{
    "deploymentCircuitBreaker": {
      "enable": true,
      "rollback": true
    },
    "minimumHealthyPercent": 100,
    "maximumPercent": 200
  }'

สถาปัตยกรรมตั้งแต่ต้นจนจบ: ECS + ALB + การปรับขนาดอัตโนมัติ

สถาปัตยกรรมเว็บ API ที่ใช้คอนเทนเนอร์และพร้อมสำหรับการใช้งานจริง: Route 53 แปลงชื่อโดเมนไปเป็นชื่อ DNS ของ ALB จากนั้น ALB จะสิ้นสุดการเชื่อมต่อ HTTPS (ใบรับรอง ACM) ใช้กฎ WAF และกำหนดเส้นทางคำขอไปยัง กลุ่มเป้าหมายของบริการ ECS งาน Fargate ในซับเน็ตส่วนตัวที่กระจายอยู่ใน 3 AZ จะจัดการคำขอ การปรับขนาดบริการ ECS อัตโนมัติโดยใช้การติดตามเป้าหมายของจำนวนคำขอ ALB ต่อเป้าหมาย จะปรับจำนวนงานตั้งแต่ 2 ถึง 50 งานจะเชื่อมต่อกับ RDS Aurora และ ElastiCache ในซับเน็ตส่วนตัว บันทึกทั้งหมดจะส่งไปยังบันทึกของ CloudWatch ส่วนเมทริกซ์จะขับเคลื่อนแดชบอร์ดและการแจ้งเตือนของ CloudWatch

ตรวจสอบความเข้าใจ

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

ทบทวนบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า การปรับขนาดบริการ ECS อัตโนมัติใช้ Application Auto Scaling ร่วมกับการติดตามเป้าหมาย (CPU, คำขอ ALB หรือเมทริกซ์แบบกำหนดเอง) เพื่อปรับจำนวนงานให้อยู่ระหว่างขอบเขตขั้นต่ำและสูงสุดที่กำหนดไว้ การกำหนดเส้นทางตามพาธของ ALBช่วยให้ตัวจัดสรรโหลดหนึ่งตัวให้บริการไมโครเซอร์วิส ECS หลายรายการได้ โดยกำหนดเส้นทางพาธ URL ไปยังกลุ่มเป้าหมายที่แตกต่างกัน และ ตัวตัดวงจรการนำไปใช้งานจะย้อนกลับการนำไปใช้งานที่ล้มเหลวโดยอัตโนมัติก่อนที่จะทำให้บริการเสื่อมประสิทธิภาพเป็นเวลานาน เนื้อหานี้เป็นบทสรุปของโมดูล ECS และคอนเทนเนอร์ ต่อไปเราจะสำรวจ Amazon EKS สำหรับ Kubernetes บน AWS

คำถามที่พบบ่อย

บทเรียน “การปรับขนาดอัตโนมัติและการทำโหลดบาลานซ์บริการ ECS” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การปรับขนาดอัตโนมัติและการทำโหลดบาลานซ์บริการ ECS” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การปรับขนาดอัตโนมัติและการทำโหลดบาลานซ์บริการ ECS”

เชื่อม ALB เข้ากับบริการ ECS เพื่อกำหนดเส้นทางตามพาธ และกำหนดค่าการปรับขนาดบริการอัตโนมัติให้ตอบสนองต่อ CPU หรือเมตริก CloudWatch แบบกำหนดเอง คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่

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

บทเรียน “การปรับขนาดอัตโนมัติและการทำโหลดบาลานซ์บริการ ECS” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม

ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

คลัสเตอร์ ECS คำจำกัดความงาน และบริการ
ประเภทการเปิดใช้งาน EC2 เทียบกับ Fargate
ECR: การจัดเก็บและดึงอิมเมจคอนเทนเนอร์
การปรับขนาดอัตโนมัติและการทำโหลดบาลานซ์บริการ ECS

← กลับไปที่ AWS Solutions Architect