ข้ามไปที่เนื้อหา

AWS Cloud Quest · แลป 4

Auto-Healing and Scaling Applications — EC2 Auto Scaling

เป้าหมายของแล็บ

ตั้งค่าแอปพลิเคชันบน EC2 ให้รักษาจำนวน instance ที่ต้องการ ทดแทน instance ที่เสีย และเพิ่ม/ลดจำนวน instance ตาม workload โดยลดการจัดการด้วยมือ

คำศัพท์หลัก

  • Amazon EC2: virtual server สำหรับรันแอปพลิเคชัน
  • Amazon Machine Image (AMI): image/template ที่ใช้เปิด EC2 instance
  • Launch template: กำหนดค่าที่ใช้เปิด instance เช่น AMI, instance type, security group, IAM instance profile และ storage
  • Auto Scaling group (ASG): กลุ่ม EC2 ที่ Amazon EC2 Auto Scaling จัดการร่วมกัน
  • Minimum capacity: จำนวน instance ต่ำสุดที่ ASG รักษาไว้
  • Desired capacity: จำนวน instance เป้าหมายที่ ASG พยายามรักษา
  • Maximum capacity: จำนวน instance สูงสุดที่ ASG สามารถขยายได้
  • Health check: การตรวจสถานะว่า instance ยังพร้อมใช้งานหรือไม่
  • Scaling policy: กฎเพิ่ม/ลด capacity ตามตัวชี้วัดหรือกำหนดเวลา

Auto-healing กับ Auto Scaling ไม่เหมือนกัน

  • Auto-healing: เมื่อ instance ที่อยู่ใน ASG ไม่ healthy หรือถูก terminate ระบบจะเปิด instance ใหม่เพื่อทดแทนและรักษา desired capacity
  • Auto Scaling: เปลี่ยนจำนวน instance ตามความต้องการ เช่น เพิ่มเมื่อ CPU หรือ request load สูง และลดเมื่อความต้องการลดลง โดยไม่ต่ำกว่า minimum หรือสูงกว่า maximum

ดังนั้น การมี ASG ช่วยทดแทนเครื่องเสียได้ แม้ยังไม่ได้ตั้ง scaling policy เพื่อเพิ่ม/ลดตามโหลด ส่วนการ scale ตามโหลดต้องมี policy หรือการตั้งค่าที่เกี่ยวข้อง

แนวทางทำแล็บ

  1. ตรวจสอบ EC2 instance, AMI, VPC, subnet และ security group ที่โจทย์เตรียมไว้
  2. สร้างหรือเลือก launch template ตามที่โจทย์กำหนด
  3. สร้าง Auto Scaling group และเลือก VPC/subnets ที่เหมาะสม
  4. ตั้งค่า minimum, desired และ maximum capacity ตามโจทย์
  5. กำหนด health check ที่เหมาะสม หากเชื่อมกับ load balancer ให้ตรวจ health check type และ grace period ตามสถานการณ์
  6. ตั้ง scaling policy ตามโจทย์ เช่น target tracking จาก average CPU utilization หรือ request count per target
  7. ตรวจ Activity history, instance health และ CloudWatch metrics
  8. ทดสอบ auto-healing โดยจำลองเหตุการณ์ที่โจทย์อนุญาต เช่น terminate instance ใน ASG แล้วสังเกตการสร้าง instance ทดแทน
  9. หากเป็นการทดสอบ scaling ให้สร้างโหลดตามคำแนะนำของแล็บและสังเกตจำนวน instance
  10. ตรวจว่าจำนวน instance อยู่ภายใน min/max และกลับไปให้ Cloud Quest ตรวจภารกิจ

วิธีคิดเรื่อง scaling

ตัวอย่างเชิงแนวคิด: หากตั้ง minimum = 2, desired = 2 และ maximum = 4 ระบบควรเริ่มจากจำนวนเป้าหมาย 2 เครื่อง หากเครื่องหนึ่งเสีย ASG จะพยายามทดแทนเพื่อรักษา desired capacity หากมี scaling policy และ workload สูงขึ้น ระบบอาจเพิ่มได้ถึง 4 เครื่อง เมื่อโหลดลดลงก็ลดจำนวนได้ แต่ไม่ต่ำกว่า minimum

ตัวเลขนี้เป็นตัวอย่างประกอบ ไม่ใช่ค่าที่ต้องใช้ในแล็บทุกครั้ง

CloudWatch มีบทบาทอย่างไร

CloudWatch ใช้ดู metrics เช่น CPU utilization, สร้าง dashboard, logs และ alarms โดย scaling policy สามารถใช้ metrics ที่เหมาะสมเพื่อเปลี่ยน capacity ได้ ตัวอย่างเช่น Target tracking scaling ตั้งเป้าค่า metric แล้วให้ระบบปรับจำนวน instance เพื่อพยายามรักษาค่าเป้าหมาย

อย่าจำว่า CPU เป็น metric เดียวที่ใช้ได้ ต้องเลือก metric ให้สัมพันธ์กับ workload และการเพิ่ม capacity จริง

จุดที่มักผิด

  • ตั้ง desired capacity สูงกว่า maximum หรือ minimum สูงกว่า desired โดยไม่สอดคล้องกัน
  • สร้าง launch template ผิด AMI, security group หรือ subnet
  • คิดว่า scaling จะเกิดขึ้นเองทุกกรณีเพียงเพราะสร้าง ASG: ต้องมี scaling policy หรือ scheduled action หากต้องการให้ปรับตามโหลด/เวลา
  • คิดว่า health check ผ่านหมายความว่าแอปพลิเคชันทำงานถูกต้องทุกฟังก์ชัน: health check มีขอบเขตตามวิธีตรวจที่กำหนด
  • ลบ instance นอก ASG แล้วสรุปว่าเป็นการทดสอบ auto-healing ที่ถูกต้อง: ควรตรวจว่า instance เป็นสมาชิก ASG และดู Activity history
  • ไม่กระจาย ASG ไปหลาย Availability Zones ทำให้ความทนทานต่อความขัดข้องของ AZ ลดลง

จำก่อนสอบ

  • ASG รักษา desired capacity และแทนที่ instance ที่ unhealthy
  • Scaling policy ปรับ capacity ตามโหลด/เงื่อนไข
  • Launch template เป็นแม่แบบการสร้าง EC2
  • CloudWatch ใช้ติดตาม metrics และ alarms
  • ใช้หลาย AZ เพื่อเพิ่มความทนทาน ไม่ใช่แค่เพิ่มจำนวน instance ใน AZ เดียว