HA, Scalability, Elasticity & Agility
แนวคิดสำคัญที่เกี่ยวข้องกับการออกแบบระบบบน Cloud — ต้องแยกความหมายให้ชัด เพราะข้อสอบ CLF-C02 ชอบเอามาสลับเพื่อหลอก:
Vertical Scaling (Scale Up / Down)
เพิ่ม/ลด spec ของเครื่องเดิม เช่น t2.micro → t2.large (Scale Up) หรือ t2.large → t2.micro (Scale Down) มี hardware limit เหมาะกับ database ที่กระจายยาก เช่น RDS
Horizontal Scaling (Scale Out / In) = Elasticity
เพิ่ม/ลดจำนวนเครื่อง — Scale Out = เพิ่มเครื่อง, Scale In = ลดเครื่อง ไม่มี hardware limit เหมาะกับ distributed system เช่น web server หลัง ASG + ELB
High Availability (HA)
ระบบยังทำงานได้แม้ส่วนใดส่วนหนึ่งล้มเหลว (disaster) — กระจาย instance ไว้อย่างน้อย 2 AZ เพื่อไม่มี single point of failure เช่น AZ-A ล่ม AZ-B ยังทำงานต่อได้
Elasticity
ระบบ scale อัตโนมัติตาม load จริง เพิ่มเมื่อ traffic สูง ลดเมื่อ traffic ต่ำ จ่ายตามใช้จริง (Pay-as-you-go) = Horizontal Scaling + Auto
Agility (ระวัง! เป็นตัวหลอกในข้อสอบ)
ความรวดเร็วในการสร้าง resource ใหม่ใน Cloud — แค่คลิกก็ได้ environment ใหม่ใน 1 นาที ไม่ต้องสั่งซื้อ hardware Agility ไม่เกี่ยวกับ Scaling — แต่ข้อสอบมักใส่มาเป็นตัวเลือกหลอก
Elastic Load Balancing (ELB) Overview
Load Balancer คือ server ที่รับ traffic จาก user แล้วกระจายไปยัง EC2 instances หลายตัวด้านหลัง ทำให้ไม่มีเครื่องไหนรับ load หนักเกินไป เป็น Managed Service ที่ AWS ดูแล upgrade และ maintenance ให้
- กระจาย load ข้าม instance / AZ
- มี single DNS endpoint ให้ user เชื่อมต่อ
- Health check — หยุดส่ง traffic ไปเครื่องที่ล้มเหลว
- รองรับ SSL/TLS termination
- High availability ข้าม AZ
- AWS ดูแล upgrade, maintenance และรับประกัน availability ให้
ALB — Application Load Balancer (Layer 7)
HTTP / HTTPS / WebSocket — routing ตาม URL path, header, query string เหมาะกับ microservices, web apps
NLB — Network Load Balancer (Layer 4)
TCP / UDP / TLS — ultra-low latency, รองรับล้าน request/วินาที, มี Static IP ต่อ AZ
GWLB — Gateway Load Balancer (Layer 3)
ส่ง traffic ผ่าน virtual appliances (firewall, IDS/IPS, deep packet inspection) ก่อนถึง application
CLB — Classic Load Balancer (deprecated)
Layer 4 + 7 รุ่นเดิม — AWS แนะนำย้ายไปใช้ ALB หรือ NLB แทน
Application Load Balancer (ALB)
ALB ทำงานที่ Layer 7 (HTTP/HTTPS) — สามารถ routing traffic ตาม content ของ request ได้ละเอียด ไม่ใช่แค่ IP/Port
- Path-based routing: /users → Target Group A, /payments → Target Group B
- Host-based routing: app.example.com → TG A, api.example.com → TG B
- Query string routing: ?platform=mobile → Target Group Mobile
ALB ส่ง traffic ไปยัง Target Group ซึ่งประกอบด้วย EC2 Instances (จัดการโดย ASG ได้), ECS Tasks (Container-based), หรือ Lambda Functions (Serverless)
Auto Scaling Groups (ASG) Overview
ASG คือกลุ่มของ EC2 instances ที่ถูก scale out (เพิ่ม) หรือ scale in (ลด) อัตโนมัติตาม load — ทำให้ระบบรองรับ traffic ที่เปลี่ยนแปลงได้โดยไม่ต้องทำเอง
Min Capacity
จำนวน instance ขั้นต่ำ ห้ามต่ำกว่านี้ เช่น min=1
Desired Capacity
จำนวนที่ต้องการ — ASG พยายามรักษาไว้ที่จำนวนนี้ เช่น desired=2
Max Capacity
จำนวน instance สูงสุด ห้ามเกินนี้ เช่น max=5
- Scale out เมื่อ load เพิ่ม / Scale in เมื่อ load ลด — ใช้ CloudWatch alarms เป็น trigger
- Replace instance ที่ unhealthy อัตโนมัติ — รับ health check จาก ELB แล้ว terminate และสร้างใหม่แทน
- Register instance ใหม่กับ ELB อัตโนมัติ — instance ใหม่จะถูก add เข้า Target Group ให้เลย
- ASG ฟรี — จ่ายแค่ค่า EC2 instances ที่รัน
Launch Template — Blueprint ของ ASG
Launch Template คือ blueprint หรือพิมพ์เขียวที่บอก ASG ว่า 'เวลาสร้าง EC2 instance ใหม่ ให้สร้างแบบไหน' — ASG จะอ่านค่าจาก template ทุกครั้งที่ scale out หรือ replace instance
- AMI (Amazon Machine Image) — OS และ software ที่ติดตั้งมาแล้ว
- Instance Type — ขนาดเครื่อง เช่น t2.micro, m5.large
- Key Pair — สำหรับ SSH เข้าเครื่อง
- Security Groups — กฎ firewall เข้า/ออก
- EBS Volumes — disk ที่ติดมากับ instance
- IAM Role / Instance Profile — สิทธิ์ที่ instance จะใช้เรียก AWS API
- User Data — script ที่รันตอน boot ครั้งแรก เช่น install software, config service
- Network / Subnet settings
ASG Scaling Strategies
Manual Scaling
ปรับตัวเลข desired capacity ด้วยมือ — ง่ายที่สุด เหมาะกับ testing หรือ one-time adjustment
Simple / Step Scaling
กำหนด rule ตาม CloudWatch alarm เช่น 'ถ้า CPU > 70% → เพิ่ม 2 instances' หรือ 'ถ้า CPU < 30% → ลด 1 instance' กำหนดหลาย step ได้
Target Tracking Scaling (แนะนำ)
ง่ายที่สุด — ระบุ metric target แล้ว ASG จัดการให้เอง เช่น 'รักษา Average CPU ไว้ที่ 40%' ASG จะ scale out/in อัตโนมัติเพื่อให้ถึง target
Scheduled Scaling
Scale ตามเวลาที่กำหนดไว้ล่วงหน้า เช่น เช้าจันทร์ 9:00 → min=10, เย็นศุกร์ 18:00 → min=2 เหมาะกับ traffic pattern ที่รู้แล้ว
Predictive Scaling (ML)
AWS วิเคราะห์ historical data ด้วย Machine Learning แล้วคาดการณ์ load ล่วงหน้า pre-scale ก่อน traffic มาถึง ดีกว่า Scheduled เพราะไม่ต้องกำหนดเวลาเอง
ELB & ASG Summary
ELB และ ASG เป็นคู่หูที่ทำให้ระบบ scale ได้ และ tolerant ต่อ failure — ELB กระจาย traffic, ASG ปรับจำนวน instance ตาม load
ALB
Layer 7 (HTTP/HTTPS) — routing ตาม path, host, header เหมาะกับ microservices
NLB
Layer 4 (TCP/UDP) — ultra-low latency พร้อม Static IP ต่อ AZ
GWLB
Layer 3 — ส่ง traffic ผ่าน security appliances (firewall, IDS/IPS)
Health Check
ELB ตรวจ instance เป็นระยะ และหยุดส่ง traffic ไปเครื่องที่ล้มเหลว
ASG Capacity
Min ≤ Desired ≤ Max — ASG รักษาจำนวน instance ให้อยู่ใน range
Launch Template
Blueprint ของ ASG — AMI, instance type, SG, IAM role, user data
- ELB เป็น managed service — AWS ดูแล HA และ upgrade ให้
- ASG ฟรี — จ่ายแค่ค่า EC2 instance ที่รันจริง
- Target Tracking เป็น scaling strategy ที่ง่ายและแนะนำที่สุด
- HA = กระจาย instance ข้ามหลาย AZ ผ่าน ASG + ELB
- Scale Up (vertical) = spec ใหญ่ขึ้น ส่วน Scale Out (horizontal) = จำนวนเครื่องมากขึ้น