0Pricing
AWS Solutions Architect · درس

سيناريوهات البنى المرنة وعالية التوافر

عالج سيناريوهات تجاوز الفشل لقواعد البيانات متعددة المناطق، والتوسّع التلقائي تحت حركة المرور المفاجئة، وتجاوز الفشل القائم على فحوصات الصحة في Route 53 لترسيخ مفاهيم الموثوقية

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

السيناريو 1: تطبيق ويب متعدد مناطق التوافر

السيناريو: تدير شركة تطبيق ويب مؤلفًا من طبقتين (ALB → EC2 → RDS)، وتريد إزالة أي نقطة فشل منفردة ضمن منطقة AWS. الحل: انشر مثيلات EC2 في مجموعة Auto Scaling تمتد عبر منطقتي توافر على الأقل خلف ALB (وهو متعدد مناطق التوافر بطبيعته). فعّل RDS Multi-AZ للنسخ المتماثل المتزامن إلى مثيل احتياطي. اضبط فحوصات السلامة على ALB لتوجيه الطلبات تلقائيًا بعيدًا عن المثيلات غير السليمة. باستخدام هذه البنية، يؤدي فقدان أي منطقة توافر واحدة إلى تجاوز فشل تلقائي في كل طبقة.

# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
  --db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --engine mysql \
  --multi-az \
  --master-username admin \
  --master-user-password Pass123! \
  --allocated-storage 100

# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --availability-zones us-east-1a us-east-1b us-east-1c \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abc

السيناريو 2: توسيع نطاق القراءة في RDS تحت الحمل

السيناريو: يبلغ مثيل RDS الخاص بتطبيق للتجارة الإلكترونية حدود وحدة المعالجة المركزية خلال ساعات الذروة بسبب استعلامات التحليلات كثيفة القراءة التي يجريها فريق ذكاء الأعمال. الحل: أنشئ RDS Read Replicas ووجّه استعلامات ذكاء الأعمال إلى نقطة نهاية النسخة المتماثلة. تستخدم Read Replicas النسخ المتماثل غير المتزامن، ويُعد التأخر الطفيف مقبولًا في التحليلات. يؤدي ذلك إلى تخفيف حركة القراءة عن مثيل RDS الأساسي، الذي يُخصص لعمليات الكتابة وقراءات التطبيق. وبالنسبة إلى أحمال العمل كثيفة القراءة للغاية، أضف طبقة ElastiCache أمام RDS للبيانات التي يكثر الوصول إليها.

# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-replica \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --availability-zone us-east-1b

# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)

السيناريو 3: التوسعة التلقائية عند ارتفاع استخدام وحدة المعالجة المركزية

السيناريو: تعمل واجهة API عديمة الحالة على EC2 خلف ALB. يرتفع استخدام وحدة المعالجة المركزية إلى 90% خلال ساعات العمل وينخفض إلى ما يقارب الصفر ليلًا. تريد الشركة أن تتوسع مجموعة المثيلات تلقائيًا. الحل: اضبط مجموعة Auto Scaling باستخدام سياسة التوسعة بتتبع الهدف لاستهداف متوسط استخدام لوحدة المعالجة المركزية يبلغ 60%. ستضيف ASG مثيلات تلقائيًا عندما يتجاوز الاستخدام 60%، وتزيلها عندما ينخفض عن الهدف. أضف إجراء توسعة مجدولًا لتهيئة الحد الأدنى من السعة مسبقًا قبل بدء ساعات العمل، مما يمنع التأخر عند زيادة حركة المرور صباحًا.

# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 60.0,
    "DisableScaleIn": false
  }'

# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name api-asg \
  --scheduled-action-name morning-scale-out \
  --recurrence '0 8 * * MON-FRI' \
  --min-size 5

السيناريو 4: تجاوز الفشل باستخدام Route 53 إلى موقع التعافي من الكوارث

السيناريو: تدير شركة تطبيق ويب أساسيًا في us-east-1، وتريد تجاوز الفشل إلى صفحة صيانة ثابتة مستضافة على S3 في us-west-2 إذا أصبح التطبيق الأساسي غير سليم. الحل: أنشئ فحص سلامة في Route 53 لمراقبة نقطة نهاية ALB الأساسية. أنشئ سجلين في Route 53 باستخدام سياسة توجيه تجاوز الفشل: سجل أساسي يشير إلى ALB (ومرتبط بفحص السلامة)، وسجل ثانوي يشير إلى موقع S3 الثابت. إذا فشل فحص السلامة، تعرض Route 53 تلقائيًا استجابة DNS الخاصة بالسجل الثانوي.

# Create Route 53 health check for primary ALB
aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "app.example.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check fails

السيناريو 5: فك الاقتران باستخدام SQS لتحقيق المرونة

السيناريو: تكتب خدمة خلفية لمعالجة الطلبات في قاعدة بيانات، لكن قاعدة البيانات تصبح غير متاحة أحيانًا أثناء نوافذ الصيانة، مما يؤدي إلى فقدان الطلبات. الحل: ضع قائمة انتظار SQS بين الواجهة الأمامية (التي تقبل الطلبات) والخدمة الخلفية (التي تعالجها). توضع الطلبات في قائمة الانتظار فورًا، مما يمنح العميل تأكيدًا فوريًا. تسحب عمليات الخلفية الطلبات من قائمة الانتظار وتعالجها عند توفر قاعدة البيانات. أثناء الصيانة، تتراكم الطلبات في قائمة الانتظار بدلًا من إسقاطها، مما يوفر المرونة من خلال فك الاقتران غير المتزامن.

# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --message-body '{"orderId": "ORD-123", "items": [...]}'

# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --max-number-of-messages 10

# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)

السيناريو 6: استراتيجية Pilot Light للتعافي من الكوارث

السيناريو: تحتاج شركة إلى حل للتعافي من الكوارث يحقق RPO مدته ساعة واحدة وRTO مدته 4 ساعات، ضمن ميزانية متوسطة. الحل: طبّق استراتيجية Pilot Light للتعافي من الكوارث. احتفظ بنسخة متماثلة من قاعدة البيانات الأساسية في منطقة التعافي من الكوارث باستخدام RDS Cross-Region Read Replica. لا تعمل خوادم التطبيق في منطقة التعافي من الكوارث أثناء التشغيل العادي؛ بل يُحافَظ فقط على الحد الأدنى من المكوّن «الأساسي» (قاعدة البيانات) في حالة جاهزية. عند وقوع كارثة، رقِّ النسخة المتماثلة للقراءة إلى مثيل مستقل، وشغّل خوادم التطبيق من AMIs مُنشأة مسبقًا باستخدام CloudFormation. يبلغ RTO ساعات لا دقائق، لأن تشغيل الخوادم يستغرق وقتًا.

# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --source-region us-east-1 \
  --destination-region us-west-2

# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2

السيناريو 7: قائمة انتظار SQS للرسائل الميتة للرسائل الفاشلة

السيناريو: تفشل معالجة الرسائل الموجودة في قائمة انتظار SQS مرارًا بسبب خطأ في Lambda المستهلكة. وتستمر الرسائل في الظهور مجددًا وتمنع معالجة بقية القائمة. الحل: اضبط قائمة انتظار للرسائل الميتة (DLQ) على قائمة الانتظار الرئيسية. بعد فشل معالجة الرسالة عددًا قابلًا للضبط من المرات (maxReceiveCount)، تنقلها SQS تلقائيًا إلى DLQ بدلًا من إعادة تسليمها إلى ما لا نهاية. يؤدي ذلك إلى إتاحة قائمة الانتظار الرئيسية للرسائل السليمة. اضبط تنبيهًا في CloudWatch على مقياس DLQ ‏ApproximateNumberOfMessagesVisible لتنبيه فريق الهندسة عند تراكم الرسائل في DLQ.

# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
  }'

# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
  --alarm-name orders-dlq-depth \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --dimensions Name=QueueName,Value=orders-dlq \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 --period 60 --statistic Sum

السيناريو 8: قاعدة بيانات Aurora العالمية

السيناريو: تعمل شركة في الولايات المتحدة وأوروبا. يواجه المستخدمون في أوروبا زمن استجابة مرتفعًا لقراءة قاعدة البيانات لأن RDS موجودة في us-east-1. الحل: استخدم Amazon Aurora Global Database. توجد المجموعة الأساسية في us-east-1، وتُضاف مجموعة ثانوية للقراءة فقط في eu-west-1. تنسخ Aurora البيانات إلى المنطقة الثانوية بزمن استجابة اعتيادي أقل من ثانية واحدة باستخدام النسخ المتماثل على مستوى التخزين. يقرأ المستخدمون الأوروبيون من المجموعة الثانوية في eu-west-1. عند وقوع كارثة إقليمية، يمكن ترقية المجموعة الثانوية إلى أساسية خلال أقل من دقيقة، وهو أفضل RTO بين خيارات قواعد البيانات متعددة المناطق في AWS.

# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
  --global-cluster-identifier prod-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora

# Add secondary Region cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-aurora-eu \
  --engine aurora-postgresql \
  --global-cluster-identifier prod-global \
  --region eu-west-1

السيناريو 9: خدمة ECS مع ALB وAuto Scaling

السيناريو: تحتاج خدمة API قائمة على الحاويات وتعمل على ECS Fargate إلى التوسع استنادًا إلى استخدام وحدة المعالجة المركزية، وإلى الاستمرار عند تعطل مناطق التوافر. الحل: سجّل خدمة ECS في مجموعة أهداف Application Load Balancer لتوزيع حركة المرور عبر المهام قيد التشغيل. ضع المهام عبر مناطق توافر متعددة من خلال تحديد شبكات فرعية متعددة في إعداد الخدمة. اضبط ECS Service Auto Scaling باستخدام سياسة تتبع هدف لاستخدام وحدة المعالجة المركزية في خدمة ECS، لتوسيع عدد المهام وتقليصه تلقائيًا. إذا تعطلت إحدى مناطق التوافر، تعيد ECS تشغيل المهام الفاشلة في مناطق التوافر السليمة.

# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
  --cluster prod-cluster \
  --service-name api-service \
  --task-definition api-task:5 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
      "securityGroups": ["sg-app"],
      "assignPublicIp": "DISABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:...:targetgroup/api-tg/abc",
    "containerName": "api",
    "containerPort": 8080
  }]'

السيناريو 10: تجاوز الفشل بفحص السلامة باستخدام Route 53

السيناريو: تدير شركة مثيلين من EC2 في منطقتي توافر مختلفتين، ويقدمان النطاق نفسه. وتريد الشركة أن تتوقف Route 53 تلقائيًا عن إرسال حركة المرور إلى المثيل غير السليم. الحل: استخدم التوجيه الموزون في Route 53 بأوزان متساوية (50/50)، واربط فحص سلامة نقطة النهاية بكل سجل. عندما تكتشف Route 53 أن نقطة نهاية غير سليمة، تزيل ذلك السجل من استجابات DNS وترسل 100% من حركة المرور إلى نقطة النهاية السليمة. وعند استعادة المثيل ونجاح فحوصات السلامة مجددًا، تعيد Route 53 موازنة حركة المرور تلقائيًا، دون الحاجة إلى تغييرات يدوية في DNS.

# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "instance-1a",
        "Weight": 50,
        "HealthCheckId": "hc-abc123",
        "TTL": 30,
        "ResourceRecords": [{"Value": "10.0.1.10"}]
      }
    }]
  }'

السيناريو 11: DynamoDB Global Tables لتحقيق التوافر العالي متعدد المناطق

السيناريو: يحتاج تطبيق ألعاب للهواتف المحمولة إلى قراءة بيانات اللاعبين وكتابتها بزمن استجابة منخفض من كل من us-east-1 وap-southeast-1. يؤدي جدول DynamoDB في منطقة واحدة إلى زمن استجابة مرتفع للمستخدمين الآسيويين. الحل: فعّل DynamoDB Global Tables. تنسخ Global Tables البيانات تلقائيًا عبر المناطق المحددة باستخدام النسخ المتماثل متعدد المصادر الرئيسية، إذ يمكن لأي منطقة قبول عمليات الكتابة. يكتب المستخدمون الآسيويون البيانات ويقرؤونها من النسخة المتماثلة في ap-southeast-1 بزمن استجابة محلي (نحو 5 مللي ثانية). تتولى Global Tables حل التعارضات باستخدام استراتيجية «آخر كاتب يفوز» المستندة إلى الطوابع الزمنية. يقترب RTO من الصفر عند حدوث فشل إقليمي كامل، إذ تُوجَّه حركة المرور ببساطة إلى المنطقة الباقية.

# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
  --global-table-name PlayerData \
  --replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'

# Add another Region to an existing Global Table
aws dynamodb update-global-table \
  --global-table-name PlayerData \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

تحقق سريع

اختبر مدى فهمكم لمفاهيم AWS Solutions Architect (SAA-C03) الواردة في هذا الدرس.

مراجعة الدرس

استعرضتم في هذا الدرس سيناريوهات تتناول: ASG وRDS متعددَي مناطق التوافر لتحقيق التوافر العالي داخل المنطقة، وتوجيه تجاوز الفشل في Route 53 للتعافي من الكوارث عبر المناطق، وSQS DLQ لعزل الرسائل الفاشلة دون منع قوائم الانتظار، وAurora Global Database لتوسيع نطاق القراءة عبر المناطق وتجاوز الفشل مع RTO أقل من دقيقة. ننتقل بعد ذلك إلى سيناريوهات البنى عالية الأداء والمُحسّنة من حيث التكلفة.

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

هل درس «سيناريوهات البنى المرنة وعالية التوافر» مجاني؟

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

ماذا ستتعلم في «سيناريوهات البنى المرنة وعالية التوافر»؟

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

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

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

كم من الوقت يستغرق درس «سيناريوهات البنى المرنة وعالية التوافر»؟

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

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

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

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

  1. سيناريوهات البنية الآمنة
  2. سيناريوهات البنى المرنة وعالية التوافر
  3. سيناريوهات الأداء العالي وتحسين التكلفة
  4. اختبار مصغّر شامل بطول كامل للمجالات المختلطة
← العودة إلى AWS Solutions Architect