AWS Solutions Architect · درس

فحوصات الصحة وقواطع الدائرة ومنطق إعادة المحاولة

استخدم فحوصات صحة ELB وفحوصات نقاط النهاية في Route 53 وقواطع الدائرة على مستوى التطبيق لاكتشاف الأعطال وإعادة توجيه حركة المرور تلقائيًا

فحوصات الصحة وقواطع الدائرة ومنطق إعادة المحاولة درس مجاني في AWS Solutions Architect على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في AWS Solutions Architect، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة AWS Solutions Architect 4 دروس في المجموع.

أهمية اكتشاف الأعطال تلقائيًا

في الأنظمة الموزعة، تتعطل المكونات باستمرار — فقد تتعطل المثيلات، أو تحدث انقسامات في الشبكة، أو تتعرض الخدمات التابعة لحمل زائد. ومن دون اكتشاف الأعطال تلقائيًا، تستمر حركة المرور في التدفق إلى المكونات المعطلة، مما يسبب أعطالًا متسلسلة. توفر AWS طبقات متعددة لفحص الحالة: إذ تكتشف فحوصات حالة ELB المثيلات غير السليمة، وتكتشف فحوصات حالة Route 53 نقاط النهاية غير السليمة، ويستبدل 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. توجد ثلاثة أنواع: تفحص فحوصات نقاط النهاية عنوان 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

نمط قاطع الدائرة

يُعد قاطع الدائرة نمطًا على مستوى التطبيق يمنع الأعطال المتسلسلة، وذلك من خلال مراقبة الاستدعاءات إلى خدمة تابعة وإيقافها مؤقتًا عندما يتجاوز عدد الأعطال حدًا معينًا. ويتكون هذا القاطع من ثلاث حالات: مغلق (التشغيل الطبيعي)، ومفتوح (تجاوز عدد الأعطال الحد، فتُحظر الاستدعاءات فورًا)، وشبه مفتوح (بعد انتهاء مهلة، يُسمح بعدد صغير من الاستدعاءات الاختبارية للتحقق مما إذا كانت الخدمة قد تعافت). يطبّق 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 لتطبيق قاطع الدائرة

إن AWS App Mesh عبارة عن شبكة خدمات تطبّق سياسات قاطع الدائرة وإعادة المحاولة والمهلة على مستوى البنية التحتية، من دون إجراء تغييرات على التعليمات البرمجية. وتُعرّفون سياسات قاطع الدائرة في إعدادات العقدة الافتراضية أو الموجّه الافتراضي. وعندما تصبح خدمة upstream غير سليمة، يفتح وكيل 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 (60 ثانية افتراضيًا)، ومهلة تنفيذ Lambda (بحد أقصى 15 دقيقة)، ومهلة تكامل API Gateway (بحد أقصى 29 ثانية). وتؤدي المهلات إلى تشغيل منطق إعادة المحاولة أو منطق قاطع الدائرة لديكم.

# 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

تتطلب فحوصات الصحة الفعالة وقواطع الدائرة مراقبة لفهم أنماط الأعطال. يُعد CloudWatch طبقة قابلية المراقبة؛ فأنشئوا إنذارات بشأن ELB UnHealthyHostCount (المثيلات التي تفشل في فحوصات الصحة)، ومعدل Lambda Errors، وSQS NumberOfMessagesSentToDLQ (الرسائل التي تصل إلى DLQ)، وTarget group 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 تؤتمت اكتشاف الأعطال على مستوى البنية التحتية، وأن قواطع الدائرة تمنع الأعطال المتسلسلة بإيقاف الاستدعاءات إلى الخدمات غير السليمة، وأن التراجع الأُسّي مع التنويع العشوائي يجعل إعادة المحاولات آمنة تحت الحمل. وتلتقط قوائم انتظار الرسائل غير القابلة للتسليم الرسائل الفاشلة لفحصها. بعد ذلك، سنستكشف RTO وRPO وطبقات التعافي من الكوارث.

الأسئلة الشائعة

هل درس «فحوصات الصحة وقواطع الدائرة ومنطق إعادة المحاولة» مجاني؟

نعم — نص درس «فحوصات الصحة وقواطع الدائرة ومنطق إعادة المحاولة» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة AWS Solutions Architect، انتقل إلى CoddyKit PRO. تتضمن دورة AWS Solutions Architect 4 دروس في المجموع.

ماذا ستتعلم في «فحوصات الصحة وقواطع الدائرة ومنطق إعادة المحاولة»؟

استخدم فحوصات صحة ELB وفحوصات نقاط النهاية في Route 53 وقواطع الدائرة على مستوى التطبيق لاكتشاف الأعطال وإعادة توجيه حركة المرور تلقائيًا تتمرن على AWS Solutions Architect مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ AWS Solutions Architect؟

لا تُشترط خبرة سابقة. AWS Solutions Architect على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «فحوصات الصحة وقواطع الدائرة ومنطق إعادة المحاولة»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس AWS Solutions Architect هذا؟

نعم. كل درس في AWS Solutions Architect يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

التوافر العالي في مقابل تحمّل الأعطال: التعريفات والمفاضلات
أنماط Multi-AZ للخدمات ذات الحالة
النشط-النشط والنشط-الخامل متعدد المناطق
فحوصات الصحة وقواطع الدائرة ومنطق إعادة المحاولة

← العودة إلى AWS Solutions Architect