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

โพรบตรวจสอบสถานะและการลดระดับอย่างราบรื่น

กำหนดค่าโพรบตรวจสอบสถานะของตัวกระจายภาระงานและ Traffic Manager เพื่อให้ตรวจพบความล้มเหลวได้อย่างรวดเร็ว และออกแบบรูปแบบตัวตัดวงจรกับการลดระดับอย่างราบรื่นสำหรับชั้นแอปพลิเคชัน

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

เหตุใดโพรบตรวจสอบสถานะจึงมีความสำคัญ

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

โพรบตรวจสอบสถานะของ Azure Load Balancer

Azure Load Balancer รองรับโพรบตรวจสอบสถานะสองประเภท:

  • โพรบ TCP — ตรวจสอบว่าแบ็กเอนด์รับการเชื่อมต่อ TCP บนพอร์ตที่ระบุได้หรือไม่ เรียบง่าย แต่ไม่ตรวจสอบตรรกะของแอปพลิเคชัน
  • โพรบ HTTP/HTTPS — ส่งคำขอ GET ไปยังเส้นทางที่ระบุ และคาดหวังการตอบกลับ 200 OK แม่นยำกว่า เนื่องจากทดสอบปลายทางของแอปพลิเคชันโดยตรง

แบ็กเอนด์จะถูกระบุว่าไม่สมบูรณ์ หากโพรบล้มเหลวติดต่อกันตามจำนวนครั้งที่กำหนดค่าไว้

# Create an HTTP health probe for an Azure Load Balancer:
az network lb probe create \
  --resource-group myRG \
  --lb-name myLoadBalancer \
  --name httpHealthProbe \
  --protocol Http \
  --port 80 \
  --path /health \
  --interval 15 \
  --threshold 2

การออกแบบปลายทางตรวจสอบสถานะที่เชื่อถือได้

ปลายทางตรวจสอบสถานะที่ออกแบบมาอย่างดี (/health) ทำได้มากกว่าการส่งคืน 200 OK — โดยตรวจสอบว่าการพึ่งพาที่สำคัญของแอปพลิเคชันยังเข้าถึงได้ การตรวจสอบสถานะที่ครอบคลุมอาจทดสอบการเชื่อมต่อกับฐานข้อมูล แคช และ API ปลายทางใด ๆ หากการพึ่งพารายการใดไม่พร้อมใช้งาน ปลายทางจะส่งคืน รหัสสถานะ 5xx เพื่อแจ้งให้ตัวกระจายโหลดนำอินสแตนซ์นี้ออกจากการหมุนเวียน

# Example health endpoint response (JSON):
# GET /health
# {
#   'status': 'healthy',
#   'checks': {
#     'database': 'ok',
#     'cache': 'ok',
#     'externalApi': 'ok'
#   }
# }
# If database check fails, return HTTP 503 instead of 200

โพรบตรวจสอบสถานะของ Traffic Manager

Azure Traffic Manager ใช้โพรบตรวจสอบสถานะเช่นกัน แต่ทำงานในระดับภูมิภาค โดยส่งคำขอ GET ผ่าน HTTP หรือ HTTPS ไปยัง URL ปลายทางที่กำหนดค่าไว้ในแต่ละภูมิภาคเป็นระยะ หากปลายทางไม่ตอบกลับภายใน ช่วงเวลาหมดเวลาตามจำนวนช่วงเวลาติดต่อกันที่กำหนด Traffic Manager จะระบุว่าปลายทางนั้นมีประสิทธิภาพลดลง และหยุดกำหนดเส้นทางคำขอ DNS ไปยังปลายทางดังกล่าว พร้อมเปลี่ยนเส้นทางผู้ใช้ไปยังภูมิภาคที่มีสถานะปกติ

# Configure Traffic Manager health probe settings:
az network traffic-manager profile update \
  --resource-group myRG \
  --name myTMProfile \
  --monitor-protocol HTTPS \
  --monitor-port 443 \
  --monitor-path /health \
  --monitor-interval 30 \
  --monitor-timeout 10 \
  --monitor-tolerated-failures 3

โพรบตรวจสอบสถานะของ Application Gateway

Azure Application Gateway มีความสามารถด้านโพรบตรวจสอบสถานะที่ซับซ้อนกว่า Load Balancer มาตรฐาน รองรับ โพรบแบบกำหนดเองที่ระบุส่วนหัวโฮสต์ ช่วงรหัสสถานะที่คาดหวัง เช่น 200-399 และสตริงสำหรับจับคู่ในเนื้อหา นอกจากนี้ Application Gateway ยังรองรับ การกำหนดเส้นทางแยกตามเส้นทาง ทำให้กลุ่มแบ็กเอนด์ต่าง ๆ มีการกำหนดค่าโพรบตรวจสอบสถานะที่แตกต่างกันสำหรับเส้นทาง URL ที่แตกต่างกันได้

# Create a custom probe for Application Gateway:
az network application-gateway probe create \
  --gateway-name myAppGateway \
  --resource-group myRG \
  --name customProbe \
  --protocol Http \
  --host-name-from-http-settings true \
  --path /api/health \
  --interval 20 \
  --timeout 10 \
  --threshold 3

Graceful Degradation คืออะไร

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

รูปแบบ Circuit Breaker

รูปแบบ circuit breaker ช่วยป้องกันไม่ให้แอปพลิเคชันเรียกใช้บริการปลายทางที่ขัดข้องซ้ำแล้วซ้ำเล่า เมื่อบริการเริ่มขัดข้อง circuit breaker จะ เปิด และส่งคืนข้อผิดพลาดหรือการตอบกลับสำรองทันทีโดยไม่เรียกเครือข่าย หลังจากช่วงพัก circuit breaker จะเข้าสู่สถานะ half-open และอนุญาตให้ส่งคำขอทดลองหนึ่งครั้ง หากสำเร็จ วงจรจะปิดและกลับมาทำงานตามปกติ

# Circuit breaker states:
# CLOSED: normal operation, calls pass through
# OPEN:   service failing, calls immediately return error/fallback
# HALF-OPEN: cool-down expired, try one request:
#           success -> CLOSED
#           failure -> OPEN (reset timer)

# Libraries: Polly (.NET), Resilience4j (Java), polly-js (JS)

ลองใหม่ด้วยการหน่วงเวลาแบบ Exponential

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

# Exponential backoff with jitter (pseudocode):
# attempt 1: wait 1s  + random(0-500ms)
# attempt 2: wait 2s  + random(0-500ms)
# attempt 3: wait 4s  + random(0-500ms)
# attempt 4: wait 8s  + random(0-500ms)
# max retries: 4
# max wait: 30s (cap)
# After max retries: return error to caller

รูปแบบ Bulkhead

รูปแบบ bulkhead แยกส่วนต่าง ๆ ของแอปพลิเคชันออกเป็นกลุ่มทรัพยากร เพื่อให้ความล้มเหลวในส่วนหนึ่งไม่ใช้ทรัพยากรทั้งหมดและทำให้ทั้งระบบหยุดทำงาน ชื่อนี้มาจากผนังกั้นห้องในเรือ ซึ่งป้องกันไม่ให้น้ำที่ท่วมช่องหนึ่งทำให้เรือทั้งลำจม ใน Azure แนวทางนี้อาจหมายถึงการใช้ กลุ่มเธรด แยกกัน หรือใช้ แผน App Service แยกกันสำหรับบริการแต่ละรายการเพื่อจำกัดขอบเขตของความล้มเหลว

การตอบกลับสำรองและข้อมูลที่แคชไว้

เทคนิคทั่วไปสำหรับการลดความสามารถของระบบอย่างเหมาะสมคือให้บริการ ข้อมูลที่แคชไว้หรือข้อมูลเก่า เมื่อแหล่งข้อมูลปัจจุบันไม่พร้อมใช้งาน ตัวอย่างเช่น หน้าแค็ตตาล็อกสินค้าอาจแสดงราคาของเมื่อวานที่แคชไว้จาก Azure Cache for Redis แทนการแสดงข้อผิดพลาด หากไม่สามารถเชื่อมต่อฐานข้อมูลได้ชั่วคราว ผู้ใช้จะพบความไม่สะดวกเล็กน้อย (ราคาล้าสมัยเล็กน้อย) แทนที่จะพบความล้มเหลวทั้งหมด

การตรวจสอบและการแจ้งเตือนเมื่อความสามารถลดลง

การลดความสามารถของระบบอย่างเหมาะสมควร มองเห็นได้และวัดผลได้ ใช้ Application Insights เพื่อติดตามอัตราการเปิด circuit breaker การตอบกลับสำรอง และความพยายามลองใหม่ในรูปเมตริกแบบกำหนดเอง ตั้งค่า การแจ้งเตือน เมื่อเมตริกเหล่านี้เกินค่าเกณฑ์ เพื่อให้ทีมผู้รับผิดชอบเมื่อเกิดเหตุได้รับแจ้งว่าแอปพลิเคชันกำลังทำงานในสถานะที่ความสามารถลดลง แม้ว่าประสบการณ์ที่ผู้ใช้เห็นจะยังดูยอมรับได้

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

ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า โพรบตรวจสอบสถานะ ช่วยให้ตัวจัดสรรโหลดตรวจพบแบ็กเอนด์ที่ล้มเหลวและเปลี่ยนเส้นทางการรับส่งข้อมูลโดยอัตโนมัติ การลดความสามารถของระบบอย่างเหมาะสม ช่วยให้แอปพลิเคชันยังทำงานได้บางส่วนเมื่อการพึ่งพาล้มเหลว และรูปแบบต่าง ๆ เช่น circuit breaker, การลองใหม่พร้อมการหน่วงเวลา และ bulkhead ช่วยสร้างความทนทานในระดับแอปพลิเคชัน ต่อไป เราจะสำรวจแนวคิดการกู้คืนจากภัยพิบัติ — การกำหนด RTO, RPO และระดับการกู้คืน

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

บทเรียน “โพรบตรวจสอบสถานะและการลดระดับอย่างราบรื่น” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “โพรบตรวจสอบสถานะและการลดระดับอย่างราบรื่น”

กำหนดค่าโพรบตรวจสอบสถานะของตัวกระจายภาระงานและ Traffic Manager เพื่อให้ตรวจพบความล้มเหลวได้อย่างรวดเร็ว และออกแบบรูปแบบตัวตัดวงจรกับการลดระดับอย่างราบรื่นสำหรับชั้นแอปพลิเคชัน คุณปฏิบัติ 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. SLA ของ Azure และ SLA แบบประกอบ
  2. ชุดความพร้อมใช้งานและโซนความพร้อมใช้งาน
  3. สถาปัตยกรรมแอ็กทีฟ-แอ็กทีฟหลายภูมิภาค
  4. โพรบตรวจสอบสถานะและการลดระดับอย่างราบรื่น
← กลับไปที่ Cloud & IT Cert Prep