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

การตรวจสอบสุขภาพ เซอร์กิตเบรกเกอร์ และตรรกะการลองใหม่

ใช้การตรวจสอบสุขภาพของ ELB การตรวจสอบปลายทางของ Route 53 และเซอร์กิตเบรกเกอร์ระดับแอปพลิเคชันเพื่อตรวจจับข้อขัดข้องและเปลี่ยนเส้นทางการรับส่งข้อมูลโดยอัตโนมัติ

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

เหตุใดการตรวจจับความล้มเหลวโดยอัตโนมัติจึงสำคัญ

ในระบบแบบกระจาย องค์ประกอบต่าง ๆ ล้มเหลวอยู่เสมอ อินสแตนซ์หยุดทำงาน การแบ่งแยกของเครือข่ายเกิดขึ้น และบริการปลายทางมีภาระงานมากเกินไป หากไม่มี การตรวจจับความล้มเหลวโดยอัตโนมัติ ทราฟฟิกจะยังคงไหลไปยังองค์ประกอบที่ล้มเหลว ทำให้เกิดความล้มเหลวต่อเนื่องเป็นลูกโซ่ AWS มีการตรวจสอบสถานะหลายชั้น ได้แก่ การตรวจสอบสถานะของ ELB เพื่อตรวจจับอินสแตนซ์ที่ไม่พร้อมใช้งาน การตรวจสอบสถานะของ Route 53 เพื่อตรวจจับ Endpoint ที่ไม่พร้อมใช้งาน และ Auto Scaling เพื่อแทนที่อินสแตนซ์ที่ล้มเหลว รูปแบบในระดับแอปพลิเคชัน เช่น ตัวตัดวงจรและการลองใหม่ ช่วยเติมเต็มภาพรวมด้านความทนทาน

การตรวจสอบสถานะ ELB

การตรวจสอบสถานะของ Elastic Load Balancer จะส่งคำขอไปยังเป้าหมายที่ลงทะเบียนไว้เป็นระยะ เพื่อพิจารณาว่าเป้าหมายเหล่านั้นยังทำงานเป็นปกติหรือไม่ คุณสามารถกำหนด เส้นทางตรวจสอบสถานะ (เช่น /health) โพรโทคอล พอร์ต ช่วงเวลา (ค่าเริ่มต้น 30 วินาที) และ เกณฑ์สถานะปกติ/ผิดปกติ (จำนวนครั้งสำเร็จ/ล้มเหลวติดต่อกัน) เมื่อเป้าหมายไม่ผ่านการตรวจสอบสถานะ ELB จะหยุดส่งทราฟฟิกไปยังเป้าหมายนั้น ระบบจะประเมินเป้าหมายอย่างต่อเนื่อง และเพิ่มเป้าหมายกลับเข้ามาอีกครั้งเมื่อผ่านเกณฑ์สถานะปกติ

# Configure ALB target group health check
aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing::123:targetgroup/my-tg/abc \
  --health-check-protocol HTTPS \
  --health-check-port 443 \
  --health-check-path /health \
  --health-check-interval-seconds 15 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --matcher HttpCode=200

การตรวจสอบสถานะ Route 53

การตรวจสอบสถานะของ Route 53 จะตรวจสอบปลายทางจากหลายตำแหน่งทั่วโลก และทำงานร่วมกับการกำหนดเส้นทาง DNS แบบ failover โดยมีอยู่สามประเภท ได้แก่ การตรวจสอบปลายทาง ซึ่งส่งคำขอไปยัง URL ของแอปพลิเคชันโดยตรง การตรวจสอบแบบคำนวณ ซึ่งรวมการตรวจสอบสถานะย่อยหลายรายการด้วยตรรกะ AND/OR (มีประโยชน์สำหรับการตรวจสอบที่ซับซ้อน) และ การตรวจสอบการแจ้งเตือน CloudWatch ซึ่งมอบหมายให้ CloudWatch เป็นผู้ตัดสินสถานะ เหมาะเมื่อคุณไม่สามารถเปิดเผยปลายทางตรวจสอบสถานะแบบสาธารณะ หรือต้องการตัดสินสถานะจากเมตริก

# Create endpoint health check
aws route53 create-health-check \
  --caller-reference ref-$(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "api.example.com",
    "Port": 443,
    "ResourcePath": "/health",
    "RequestInterval": 10,
    "FailureThreshold": 2,
    "EnableSNI": true
  }'

การตรวจสอบสถานะ Auto Scaling

Auto Scaling Groups สามารถใช้การตรวจสอบสถานะได้สองประเภท ได้แก่ การตรวจสอบสถานะ EC2 ซึ่งตรวจจับความล้มเหลวของอินสแตนซ์ในระดับไฮเปอร์ไวเซอร์ (กรณีการตรวจสอบสถานะอินสแตนซ์ล้มเหลว) และ การตรวจสอบสถานะ ELB ซึ่งรับรู้สถานะของแอปพลิเคชันได้มากกว่า อินสแตนซ์อาจยังทำงานอยู่แต่ให้บริการด้วยข้อผิดพลาด และการตรวจสอบสถานะ ELB จะตรวจพบกรณีนี้ คุณสามารถกำหนดค่า ASG ให้ใช้การตรวจสอบสถานะ ELB เพื่อให้ความล้มเหลวในระดับแอปพลิเคชันเรียกให้เปลี่ยนอินสแตนซ์ใหม่ ไม่ใช่เฉพาะความล้มเหลวของ EC2 ที่อยู่เบื้องหลังเท่านั้น

# Configure ASG to use ELB health checks
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --health-check-type ELB \
  --health-check-grace-period 300

# Grace period: time after launch before health checks start
# Prevents premature termination during startup

รูปแบบ Circuit Breaker

Circuit breaker เป็นรูปแบบในระดับแอปพลิเคชันที่ป้องกันความล้มเหลวแบบต่อเนื่องเป็นลูกโซ่ โดยตรวจสอบการเรียกใช้บริการปลายทาง และหยุดการเรียกใช้ชั่วคราวเมื่อความล้มเหลวเกินเกณฑ์ วงจรนี้มีสามสถานะ ได้แก่ Closed (การทำงานปกติ) Open (ความล้มเหลวเกินเกณฑ์ จึงบล็อกการเรียกใช้ทันที) และ Half-Open (หลังหมดเวลา จะอนุญาตให้เรียกทดสอบจำนวนเล็กน้อยเพื่อตรวจสอบว่าบริการฟื้นตัวแล้วหรือไม่) AWS App Mesh และ SDK ของแอปพลิเคชัน เช่น Resilience4j รองรับการนำรูปแบบนี้ไปใช้

# Circuit breaker states
# CLOSED: All calls pass through
#   failureCount < threshold -> stay CLOSED
#   failureCount >= threshold -> open circuit

# OPEN: All calls fail immediately
#   After timeout -> enter HALF-OPEN

# HALF-OPEN: Allow limited test calls
#   Success -> return to CLOSED
#   Failure -> return to OPEN

# Example threshold: 5 failures in 10 seconds -> OPEN

AWS App Mesh สำหรับ Circuit Breaking

AWS App Mesh เป็น service mesh ที่รองรับ circuit breaking การลองใหม่ และนโยบายหมดเวลาในระดับโครงสร้างพื้นฐาน โดยไม่ต้องแก้ไขโค้ด คุณกำหนด นโยบาย circuit breaker ในการกำหนดค่าของโหนดเสมือนหรือเราเตอร์เสมือน เมื่อบริการต้นทางมีสถานะผิดปกติ พร็อกซี Envoy ของ App Mesh จะเปิดวงจรโดยอัตโนมัติ และส่งคืนข้อผิดพลาดทันทีแทนที่จะรอจนหมดเวลา ความสามารถนี้มีประโยชน์อย่างยิ่งในสถาปัตยกรรมไมโครเซอร์วิสที่ทำงานบน ECS หรือ EKS

# App Mesh virtual node with circuit breaker
# (JSON configuration)
{
  'spec': {
    'listeners': [{
      'outlierDetection': {
        'consecutiveErrors': 5,
        'interval': {'unit': 'ms', 'value': 10000},
        'baseEjectionDuration': {'unit': 's', 'value': 30},
        'maxEjectionPercent': 50
      }
    }]
  }
}

ตรรกะการลองใหม่และการหน่วงเวลาแบบทวีคูณ

ตรรกะการลองใหม่ จะพยายามดำเนินการที่ล้มเหลวอีกครั้งโดยอัตโนมัติ แต่ตรรกะการลองใหม่แบบไร้การควบคุม (ลองใหม่ทันทีในลูปถี่ ๆ) อาจทำให้สถานการณ์โหลดเกินรุนแรงขึ้น การหน่วงเวลาแบบทวีคูณ จะเพิ่มเวลารอระหว่างการลองใหม่แบบทวีคูณ: 1s, 2s, 4s, 8s... วิธีนี้ช่วยลดโหลดของบริการที่กำลังมีปัญหา และเปิดเวลาให้บริการฟื้นตัว การเพิ่มความแปรผันแบบสุ่ม (สุ่มช่วงเวลาการลองใหม่) จะป้องกัน ปัญหาฝูงชนแห่กันเข้ามา ซึ่งเกิดขึ้นเมื่อไคลเอ็นต์ทั้งหมดลองใหม่พร้อมกันหลังจากระบบหยุดให้บริการช่วงสั้น ๆ AWS SDK จะใช้การหน่วงเวลาแบบทวีคูณร่วมกับการเพิ่มความแปรผันแบบสุ่มโดยอัตโนมัติ

# AWS SDK retries with exponential backoff automatically
# Default retry config for most AWS services:
# Max retries: 3-5 (varies by service)
# Base delay: 100ms
# Max delay: ~20 seconds

# Python boto3 custom retry configuration
import boto3
from botocore.config import Config

config = Config(
    retries={'max_attempts': 5, 'mode': 'adaptive'}
)
client = boto3.client('s3', config=config)

Idempotency เพื่อการลองใหม่อย่างปลอดภัย

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

# SQS message deduplication ID for FIFO queues
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders.fifo \
  --message-body '{"orderId":"ord-123","items":[...]}' \
  --message-group-id 'customer-456' \
  --message-deduplication-id 'ord-123-attempt-1'

# SQS deduplicates messages with same ID for 5 minutes

การกำหนดค่าการหมดเวลา

หากไม่มีการกำหนด การหมดเวลา อย่างชัดเจน บริการปลายทางที่ทำงานช้าจะทำให้เธรดรอค้างอย่างไม่มีกำหนด ใช้พูลการเชื่อมต่อจนหมด และก่อให้เกิดความล้มเหลวแบบต่อเนื่องเป็นลูกโซ่ ควรกำหนดการหมดเวลาในทุกชั้น ได้แก่ การหมดเวลาการเชื่อมต่อ (เวลาที่ใช้สร้างการเชื่อมต่อ TCP) การหมดเวลาการอ่าน (เวลาที่ใช้รับคำตอบ) และ การหมดเวลาของคำขอทั้งหมด ใน AWS ให้กำหนดการหมดเวลาเมื่อไม่มีการใช้งานของ ELB (ค่าเริ่มต้น 60s) การหมดเวลาการทำงานของ Lambda (สูงสุด 15 min) และการหมดเวลาการเชื่อมต่อของ API Gateway (สูงสุด 29s) การหมดเวลาจะเรียกใช้ตรรกะการลองใหม่หรือ circuit breaker ของคุณ

# Lambda: set execution timeout
aws lambda update-function-configuration \
  --function-name my-function \
  --timeout 30

# ALB: configure idle timeout
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <ALB-ARN> \
  --attributes Key=idle_timeout.timeout_seconds,Value=60

# API Gateway: integration timeout max 29000ms

คิวจดหมายตีกลับสำหรับการประมวลผลที่ล้มเหลว

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

# Configure DLQ on SQS queue
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/main-queue \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123:dlq\",\"maxReceiveCount\":3}"
  }'

# After 3 failed processing attempts, message goes to DLQ

การสังเกตความล้มเหลวด้วย CloudWatch

การตรวจสอบสถานะและ circuit breaker ที่มีประสิทธิภาพจำเป็นต้องมีการตรวจสอบระบบ เพื่อทำความเข้าใจรูปแบบความล้มเหลว CloudWatch เป็นชั้นการสังเกตการณ์ระบบ ให้สร้างการแจ้งเตือนสำหรับ ELB UnHealthyHostCount (อินสแตนซ์ที่ไม่ผ่านการตรวจสอบสถานะ) อัตรา Lambda Errors จำนวน SQS NumberOfMessagesSentToDLQ (ข้อความที่ไปถึง DLQ) และ RequestCountPerTarget ของกลุ่มเป้าหมาย ตั้งค่าการแจ้งเตือน SNS เพื่อให้ทีมเวรรับแจ้งเตือนทันทีเมื่อการตรวจสอบสถานะอัตโนมัติตรวจพบการเสื่อมประสิทธิภาพ

# CloudWatch alarm for unhealthy hosts
aws cloudwatch put-metric-alarm \
  --alarm-name 'ALB-UnhealthyHosts' \
  --alarm-description 'Alert when targets fail health checks' \
  --metric-name UnHealthyHostCount \
  --namespace AWS/ApplicationELB \
  --period 60 \
  --evaluation-periods 2 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123:ops-team

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

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

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

ในบทเรียนนี้ คุณได้เรียนรู้ว่า การตรวจสอบสถานะของ ELB และ Route 53 ช่วยตรวจจับความล้มเหลวในระดับโครงสร้างพื้นฐานโดยอัตโนมัติ circuit breaker ป้องกันความล้มเหลวแบบต่อเนื่องเป็นลูกโซ่ด้วยการหยุดการเรียกใช้บริการที่มีสถานะผิดปกติ และ การหน่วงเวลาแบบทวีคูณร่วมกับการเพิ่มความแปรผันแบบสุ่มช่วยให้การลองใหม่ปลอดภัยภายใต้โหลดสูง คิวจดหมายตีกลับจะเก็บข้อความที่ล้มเหลวไว้เพื่อตรวจสอบ ต่อไปเราจะศึกษา RTO, RPO และระดับการกู้คืนจากภัยพิบัติ

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

บทเรียน “การตรวจสอบสุขภาพ เซอร์กิตเบรกเกอร์ และตรรกะการลองใหม่” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “การตรวจสอบสุขภาพ เซอร์กิตเบรกเกอร์ และตรรกะการลองใหม่”

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

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

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

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

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

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

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

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

  1. HA เทียบกับความทนทานต่อข้อขัดข้อง: นิยามและข้อแลกเปลี่ยน
  2. รูปแบบ Multi-AZ สำหรับบริการที่มีสถานะ
  3. Active-Active และ Active-Passive แบบหลายรีเจียน
  4. การตรวจสอบสุขภาพ เซอร์กิตเบรกเกอร์ และตรรกะการลองใหม่
← กลับไปที่ Cloud & IT Cert Prep