Cloud & IT Cert Prep · บทเรียน

เสาหลักความน่าเชื่อถือและประสิทธิภาพ

ออกแบบให้กู้คืนได้โดยอัตโนมัติ ปรับขนาดในแนวนอน และจัดการความจุ เลือกประเภททรัพยากรที่เหมาะสม และตรวจสอบเพื่อรักษาประสิทธิภาพในระยะยาว

เสาหลักความน่าเชื่อถือและประสิทธิภาพ เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

ภาพรวมเสาหลัก Reliability

เสาหลัก Reliability ของเฟรมเวิร์ก Well-Architected ช่วยให้เวิร์กโหลดทำหน้าที่ตามที่ตั้งใจไว้อย่างถูกต้องและสม่ำเสมอเมื่อจำเป็นต้องใช้งาน Reliability ครอบคลุมสามด้าน ได้แก่ พื้นฐาน (โควตาบริการ โครงสร้างเครือข่าย) สถาปัตยกรรมเวิร์กโหลด (ระบบแบบกระจาย การหลีกเลี่ยงจุดล้มเหลวเพียงจุดเดียว) และ การจัดการการเปลี่ยนแปลงและการจัดการความล้มเหลว (การตรวจสอบ การปรับขนาด และการกู้คืนจากความล้มเหลว) เป้าหมายคือการสร้างระบบที่กู้คืนจากการหยุดชะงักของโครงสร้างพื้นฐานหรือบริการได้โดยอัตโนมัติ

# Reliability design principles:
# 1. Automatically recover from failure
# 2. Test recovery procedures
# 3. Scale horizontally to increase availability
# 4. Stop guessing capacity (use auto scaling)
# 5. Manage change in automation (IaC + CI/CD)

# Key AWS services for reliability:
# - Auto Scaling Groups
# - Elastic Load Balancing
# - Route 53 health checks
# - AWS Backup

ขีดจำกัดบริการและโควตา

AWS บังคับใช้ โควตาบริการ (เดิมเรียกว่าขีดจำกัด) กับทรัพยากรเพื่อปกป้องลูกค้าทุกราย ตัวอย่างเช่น ขีดจำกัดเริ่มต้นของอินสแตนซ์ EC2 ในแต่ละรีเจียน ขีดจำกัดของ VPC และการเรียกใช้ Lambda พร้อมกัน หากเวิร์กโหลดของคุณใช้โควตาจนถึงขีดจำกัดโดยไม่คาดคิด คำขอจะถูกจำกัดอัตราหรือปฏิเสธ ส่งผลให้เกิดความล้มเหลวด้าน Reliability ใช้คอนโซล Service Quotas หรือ CLI เพื่อดูขีดจำกัดปัจจุบันและขอเพิ่มล่วงหน้าก่อนที่จะจำเป็น ตรวจสอบเมตริกการใช้งานเพื่อค้นหาว่ากำลังเข้าใกล้ขีดจำกัด ก่อนที่จะส่งผลต่อความพร้อมใช้งาน

# List service quotas for EC2
aws service-quotas list-service-quotas \
  --service-code ec2 \
  --query 'Quotas[?QuotaName==`Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances`]'

# Request quota increase
aws service-quotas request-service-quota-increase \
  --service-code ec2 \
  --quota-code L-1216C47A \
  --desired-value 500

การกู้คืนจากความล้มเหลวโดยอัตโนมัติ

เสาหลัก Reliability เน้น การกู้คืนโดยอัตโนมัติ โดยไม่ต้องมีมนุษย์ดำเนินการ AWS มีกลไกซ่อมแซมตนเองอัตโนมัติหลายรูปแบบ ได้แก่ การกู้คืนอัตโนมัติของ EC2 ซึ่งกู้คืนอินสแตนซ์บนฮาร์ดแวร์เดิมโดยอัตโนมัติ หรือย้ายไปยังฮาร์ดแวร์ที่ทำงานปกติเมื่ออินสแตนซ์ไม่ผ่านการตรวจสอบพื้นฐาน การตรวจสอบสถานะของ ASG จะยุติอินสแตนซ์ที่ไม่สมบูรณ์และเปิดใช้อินสแตนซ์ทดแทน RDS Multi-AZ จะสลับไปใช้ระบบสำรองโดยอัตโนมัติ ออกแบบสถาปัตยกรรมให้สถานการณ์ความล้มเหลวส่วนใหญ่เรียกใช้การกู้คืนโดยอัตโนมัติ ซึ่งบันทึกไว้ในการแจ้งเตือนของ CloudWatch

# CloudWatch alarm to auto-recover a specific EC2 instance
aws cloudwatch put-metric-alarm \
  --alarm-name EC2-auto-recover \
  --metrics '[{"Id":"m1","MetricStat":{"Metric":{"Namespace":"AWS/EC2","MetricName":"StatusCheckFailed_System","Dimensions":[{"Name":"InstanceId","Value":"i-12345"}]},"Period":60,"Stat":"Maximum"}}]' \
  --comparison-operator GreaterThanThreshold \
  --threshold 0 \
  --evaluation-periods 2 \
  --alarm-actions 'arn:aws:automate:us-east-1:ec2:recover'

การปรับขนาดในแนวนอนเพื่อ Reliability

เสาหลัก Reliability แนะนำให้ ปรับขนาดในแนวนอน (เพิ่มอินสแตนซ์ขนาดเล็กหลายตัว) แทนการปรับขนาดในแนวตั้ง (เพิ่มขนาดอินสแตนซ์ให้ใหญ่ขึ้น) เพื่อให้มี Reliability ที่ดียิ่งขึ้น อินสแตนซ์ขนาดใหญ่เพียงตัวเดียวเป็นจุดล้มเหลวเพียงจุดเดียว การมีอินสแตนซ์ขนาดเล็กหลายตัวอยู่เบื้องหลังตัวกระจายโหลดทำให้ความล้มเหลวของอินสแตนซ์ใดอินสแตนซ์หนึ่งส่งผลกระทบน้อยที่สุด AWS Auto Scaling จะปรับขนาดกลุ่มทรัพยากรโดยอัตโนมัติให้สอดคล้องกับความต้องการ เพื่อให้คุณมีความจุเพียงพอและไม่ต้องจ่ายเงินให้ทรัพยากรที่ไม่ได้ใช้งานในช่วงที่มีการใช้งานน้อย

# Horizontal scaling: 10 t3.medium vs 1 r5.4xlarge
# 10 t3.medium:
#   - Failure of 1 = loss of 10% capacity
#   - ASG launches replacement automatically
#   - 9 instances absorb load during replacement

# 1 r5.4xlarge:
#   - Failure = 100% downtime until instance recovered
#   - Much higher RTO (new instance launch: 1-3 min)

# Prefer horizontal scaling for stateless tiers

การทดสอบเพื่อ Reliability

เสาหลัก Reliability กำหนดให้ ทดสอบขั้นตอนการกู้คืน — ไม่ใช่เพียงสมมติว่าขั้นตอนเหล่านั้นใช้ได้ ใช้ AWS Fault Injection Simulator (FIS) เพื่อจำลองความล้มเหลวในระบบอย่างมีการควบคุม เช่น ยุติอินสแตนซ์ EC2 แบบสุ่ม จำกัดอัตราการเรียก API และจำลองเวลาแฝงของเครือข่าย ดำเนินการทดลองเหล่านี้ในระบบจริง (โดยมีมาตรการป้องกัน) เพื่อตรวจสอบว่าการตรวจสอบของคุณตรวจพบความล้มเหลว การปรับขนาดอัตโนมัติตอบสนอง และการกู้คืนเสร็จสิ้นภายใน RTO ขั้นตอนการกู้คืนที่ไม่เคยทดสอบมักล้มเหลวเมื่อเผชิญกับแรงกดดันจากเหตุการณ์จริง

# AWS FIS experiment: terminate random instance
aws fis create-experiment-template \
  --description 'Chaos: terminate 1 of 5 instances' \
  --targets '{"instanceTargets":{"resourceType":"aws:ec2:instance","selectionMode":"COUNT(1)","resourceTags":{"Env":"production"}}}' \
  --actions '{"terminateInstance":{"actionId":"aws:ec2:terminate-instances","targets":{"Instances":"instanceTargets"}}}' \
  --stop-conditions '[{"source":"aws:cloudwatch:alarm","value":"arn:aws:cloudwatch::123:alarm:high-error-rate"}]'

ภาพรวมเสาหลัก Performance Efficiency

เสาหลัก Performance Efficiency มุ่งเน้นการใช้ทรัพยากรการประมวลผลอย่างมีประสิทธิภาพเพื่อให้เป็นไปตามข้อกำหนดของระบบ และรักษาประสิทธิภาพดังกล่าวเมื่อความต้องการเปลี่ยนแปลงและเทคโนโลยีพัฒนาไป หลักการสำคัญในการออกแบบมีดังนี้: ทำให้เทคโนโลยีขั้นสูงเข้าถึงได้ง่าย — ใช้บริการที่มีการจัดการ (RDS, SageMaker) แทนการสร้างทุกอย่างตั้งแต่ต้น ขยายการใช้งานไปทั่วโลกภายในไม่กี่นาที — ใช้งานในหลายรีเจียนด้วย CloudFormation ใช้สถาปัตยกรรมแบบไร้เซิร์ฟเวอร์ — ลดภาระการจัดการโครงสร้างพื้นฐาน ทดลองให้บ่อยขึ้น — ทดสอบประเภทและการกำหนดค่าของอินสแตนซ์ที่แตกต่างกัน

# Performance Efficiency areas:
# Selection:   Right compute, storage, database, network
# Review:      Continuously evaluate new services
# Monitoring:  CloudWatch metrics guide decisions
# Trade-offs:  Consistency vs performance, latency vs cost

# Example: choosing between services
# RDS vs DynamoDB vs Aurora vs ElastiCache
# → depends on access patterns, consistency needs, scale

การเลือกการประมวลผลที่เหมาะสม

Performance Efficiency เริ่มต้นจาก การเลือกประเภทการประมวลผลที่เหมาะสมกับเวิร์กโหลดของคุณ EC2 มีตระกูลอินสแตนซ์หลายสิบแบบที่ปรับให้เหมาะกับกรณีใช้งานต่างกัน ได้แก่ ตระกูล c-series สำหรับงานที่ใช้การประมวลผลสูง (การเข้ารหัสวิดีโอ การประมวลผลแบบกลุ่ม) ตระกูล r-series สำหรับงานที่ใช้หน่วยความจำสูง (ฐานข้อมูลในหน่วยความจำ การทำแคช) ตระกูล i-series สำหรับงานที่ใช้พื้นที่จัดเก็บสูง (NoSQL คลังข้อมูล) และ ตระกูล p/g-series สำหรับเวิร์กโหลด GPU (การฝึกโมเดล ML) การใช้ประเภทอินสแตนซ์ที่ไม่เหมาะสมหมายถึงการจ่ายเงินให้ความจุที่คุณใช้ไม่ได้ หรือทำให้ประสิทธิภาพลดลง

# AWS Compute Optimizer: get right-size recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123:instance/i-12345

# Output shows:
# - Current instance utilisation (CPU, memory, network)
# - Recommended instance type
# - Estimated monthly savings
# - Performance risk of changing

# Lambda: match memory to actual usage
# Use Lambda Power Tuning tool for memory optimisation

การทำแคชเพื่อ Performance Efficiency

การทำแคชเป็นเทคนิคพื้นฐานด้าน Performance Efficiency ที่ช่วยลดเวลาแฝงและภาระของฐานข้อมูล ElastiCache (Redis/Memcached) เก็บผลลัพธ์การสืบค้นฐานข้อมูลไว้ในหน่วยความจำเพื่อเข้าถึงได้ภายในระดับมิลลิวินาที CloudFront เก็บการตอบกลับ HTTP ไว้ที่ตำแหน่ง Edge ซึ่งอยู่ใกล้ผู้ใช้ การทำแคชของ API Gateway ลดการเรียกใช้ Lambda ด้วยการเก็บการตอบกลับของ API ไว้ในแคช DAX (DynamoDB Accelerator) เพิ่มแคชในหน่วยความจำระดับไมโครวินาทีไว้ด้านหน้า DynamoDB เลือกชั้นแคชที่เหมาะสมตามตำแหน่งของคอขวด — ฐานข้อมูล API หรือการส่งมอบที่ Edge

# DAX cluster for DynamoDB microsecond latency
aws dax create-cluster \
  --cluster-name my-dax \
  --node-type dax.r6g.large \
  --replication-factor 3 \
  --iam-role-arn arn:aws:iam::123:role/DAXRole \
  --subnet-group my-dax-subnet-group

# Application connects to DAX endpoint
# Cache hits: microseconds
# Cache misses: fetches from DynamoDB and caches result

พื้นที่จัดเก็บที่เหมาะสมเพื่อประสิทธิภาพ

การเลือกพื้นที่จัดเก็บส่งผลต่อประสิทธิภาพอย่างมาก io2 Block Express EBS ให้ค่าได้สูงสุดถึง 256,000 IOPS สำหรับฐานข้อมูลประสิทธิภาพสูง gp3 เป็นค่าเริ่มต้นสำหรับเวิร์กโหลดส่วนใหญ่และมีต้นทุนต่ำกว่า พื้นที่จัดเก็บของอินสแตนซ์ ให้ค่า IOPS สูงสุด (NVMe) สำหรับข้อมูลชั่วคราว S3 รองรับการขยายไปถึงคำขอหลายพันรายการต่อวินาทีสำหรับการจัดเก็บออบเจ็กต์ EFS ให้การเข้าถึงไฟล์แบบ POSIX ที่ใช้ร่วมกัน เลือกพื้นที่จัดเก็บให้ตรงกับรูปแบบ I/O: การอ่านแบบต่อเนื่องได้ประโยชน์จาก st1 (HDD ที่ปรับให้เหมาะกับ Throughput) ส่วน I/O แบบสุ่มต้องใช้โวลุม SSD

# EBS volume performance characteristics:
# gp3: 3,000-16,000 IOPS, 125-1,000 MB/s
# io2: 100-64,000 IOPS (up to 256k with Block Express)
# st1: 40-500 MB/s sequential throughput (HDD)
# sc1: 12-250 MB/s (cheapest, cold workloads)

# Create high-performance io2 volume
aws ec2 create-volume \
  --availability-zone us-east-1a \
  --volume-type io2 \
  --size 500 \
  --iops 50000

การตรวจสอบประสิทธิภาพและการปรับปรุงอย่างต่อเนื่อง

Performance Efficiency ไม่ใช่การตัดสินใจที่ทำเพียงครั้งเดียว — คุณต้องตรวจสอบเมตริกประสิทธิภาพอย่างต่อเนื่องและประเมินตัวเลือกของคุณใหม่เมื่อ AWS เปิดตัวบริการใหม่ ใช้ แดชบอร์ด CloudWatch เพื่อติดตามเปอร์เซ็นไทล์เวลาแฝง p50, p90 และ p99 (ไม่ใช่ดูเฉพาะค่าเฉลี่ย ซึ่งอาจซ่อนเวลาแฝงส่วนหาง) ใช้ การติดตามของ X-Ray เพื่อระบุส่วนที่ช้าที่สุดของลำดับคำขอ ตั้งค่า การตรวจจับความผิดปกติของ CloudWatch เพื่อสร้างค่าพื้นฐานและแจ้งเตือนเมื่อประสิทธิภาพเบี่ยงเบนผิดปกติโดยอัตโนมัติ ตรวจสอบประกาศของ AWS เป็นประจำ — ประเภทอินสแตนซ์รุ่นใหม่มักให้ประสิทธิภาพดีกว่าในต้นทุนที่ต่ำลง

# CloudWatch: track API response latency percentiles
aws cloudwatch put-metric-alarm \
  --alarm-name 'API-P99-Latency' \
  --metric-name TargetResponseTime \
  --namespace AWS/ApplicationELB \
  --extended-statistic p99 \
  --dimensions Name=LoadBalancer,Value=app/my-alb/xxx \
  --period 60 \
  --evaluation-periods 5 \
  --threshold 2.0 \
  --comparison-operator GreaterThanThreshold

ข้อแลกเปลี่ยนด้าน Performance Efficiency

บางครั้ง Performance Efficiency จำเป็นต้องแลกกับเสาหลักอื่น การเพิ่มแคช (ElastiCache) ช่วยปรับปรุงประสิทธิภาพ แต่เพิ่มความซับซ้อนในการปฏิบัติการ (ข้อแลกเปลี่ยนกับความเป็นเลิศด้านการปฏิบัติการ) และต้นทุน (ข้อแลกเปลี่ยนกับ Cost Optimisation) การใช้ DynamoDB แทน RDS ช่วยเพิ่มประสิทธิภาพเมื่อขยายขนาด แต่จำเป็นต้องออกแบบโมเดลข้อมูลใหม่ (ความพยายามด้านความเป็นเลิศในการปฏิบัติการ) เฟรมเวิร์ก Well-Architected ยอมรับข้อแลกเปลี่ยนเหล่านี้และขอให้คุณตัดสินใจอย่างรอบคอบพร้อมบันทึกเหตุผลไว้ ในข้อสอบ ให้มองหาตัวเลือกที่บรรลุเป้าหมายด้านประสิทธิภาพโดยมีภาระด้านการปฏิบัติการน้อยที่สุด

# Common performance vs cost trade-offs:
# Cache:         +Performance, +Cost, +Complexity
# Read Replicas: +Read performance, +Cost
# SSD vs HDD:    +IOPS, +Cost
# Multi-region:  -Latency for users, +Cost, +Complexity

# Common performance vs consistency trade-offs:
# DynamoDB eventually consistent reads: +Throughput, -Consistency
# Aurora Reader endpoint: +Read scale, potential replication lag

ตรวจสอบความเข้าใจอย่างรวดเร็ว

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

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า Reliability จำเป็นต้องมีการกู้คืนโดยอัตโนมัติ การปรับขนาดในแนวนอน และการทดสอบความล้มเหลวเป็นประจำ Performance Efficiency จำเป็นต้องเลือกประเภทการประมวลผล พื้นที่จัดเก็บ และฐานข้อมูลที่เหมาะสมกับแต่ละเวิร์กโหลด และ การทำแคชในหลายชั้นช่วยลดเวลาแฝงและภาระของฐานข้อมูล เสาหลักทั้งสองจำเป็นต้องมีการตรวจสอบอย่างต่อเนื่องและความพร้อมที่จะทบทวนการตัดสินใจด้านสถาปัตยกรรม บทถัดไปเราจะศึกษาเสาหลัก Cost Optimisation และความยั่งยืน

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

บทเรียน “เสาหลักความน่าเชื่อถือและประสิทธิภาพ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เสาหลักความน่าเชื่อถือและประสิทธิภาพ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เสาหลักความน่าเชื่อถือและประสิทธิภาพ”

ออกแบบให้กู้คืนได้โดยอัตโนมัติ ปรับขนาดในแนวนอน และจัดการความจุ เลือกประเภททรัพยากรที่เหมาะสม และตรวจสอบเพื่อรักษาประสิทธิภาพในระยะยาว คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่

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

บทเรียน “เสาหลักความน่าเชื่อถือและประสิทธิภาพ” ใช้เวลานานแค่ไหน

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

ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม

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

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

เสาหลักความเป็นเลิศด้านการดำเนินงานและความปลอดภัย
เสาหลักความน่าเชื่อถือและประสิทธิภาพ
เสาหลักการเพิ่มประสิทธิภาพต้นทุนและความยั่งยืน
เครื่องมือ Well-Architected และกระบวนการทบทวน

← กลับไปที่ Cloud & IT Cert Prep