0Pricing
AWS Solutions Architect · درس

سيناريوهات الأداء العالي وتحسين التكلفة

أجب عن أسئلة سيناريوهات حول استراتيجيات التخزين المؤقت وتحسين استعلامات بحيرات البيانات والمفاضلة بين Reserved وSpot وبنى النسخ المتماثلة للقراءة

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

السيناريو 1: التخزين المؤقت لتقليل حمل قاعدة البيانات

السيناريو: تخدم قاعدة بيانات RDS MySQL لموقع إخباري 90% من حركة القراءة لمحتوى المقالات الذي يتغير مرة واحدة في الساعة كحد أقصى. يبلغ متوسط استخدام وحدة المعالجة المركزية لقاعدة البيانات 80%، وترتفع التكاليف، ويبلغ زمن الاستجابة 200 مللي ثانية لكل استعلام. الحل: أضف مجموعة ElastiCache Redis أمام RDS باستخدام نمط التحميل الكسول (التخزين المؤقت الجانبي). يفحص التطبيق ذاكرة التخزين المؤقت أولًا؛ وعند وجود العنصر فيها، يعيد المقال المخزن مؤقتًا خلال أقل من 1 مللي ثانية. وعند عدم وجوده، يستعلم التطبيق من RDS، ويعيد النتيجة، ويكتبها في ذاكرة التخزين المؤقت مع TTL مدته ساعة واحدة. النتيجة المتوقعة: معدل وصول إلى ذاكرة التخزين المؤقت يبلغ 90%، وانخفاض استخدام وحدة المعالجة المركزية في RDS إلى أقل من 20%، وانخفاض زمن الاستجابة إلى أقل من 5 مللي ثوانٍ للاستجابات المخزنة مؤقتًا.

import boto3, json

elasticache = boto3.client('elasticache')
redis_client = None  # assume redis-py client connected to ElastiCache endpoint

def get_article(article_id):
    cache_key = 'article:' + str(article_id)
    # Check cache first
    cached = redis_client.get(cache_key)
    if cached:
        return json.loads(cached)  # cache hit: <1ms
    # Cache miss: query RDS
    article = rds_query('SELECT * FROM articles WHERE id = %s', article_id)
    # Write to cache with 1-hour TTL
    redis_client.setex(cache_key, 3600, json.dumps(article))
    return article

السيناريو 2: CloudFront لتوصيل الأصول الثابتة

السيناريو: يواجه المستخدمون في آسيا والمحيط الهادئ أزمنة تحميل تتراوح بين 2 و4 ثوانٍ لتطبيق ويب مستضاف على EC2 في us-east-1. ويقدم التطبيق أصولًا ثابتة كبيرة (صورًا وJS وCSS). الحل: ضع توزيعة CloudFront أمام ALB. اضبط سلوك تخزين مؤقت للمسار /static/* مع TTL طويل (مثلًا أسبوع واحد)، بحيث تُخزَّن الملفات الثابتة مؤقتًا في مواقع CloudFront الطرفية القريبة من المستخدمين في آسيا. تتجاوز طلبات API الديناميكية التخزين المؤقت باستخدام TTL=0. يحمّل المستخدمون الآسيويون الأصول الثابتة من موقع طرفي في سنغافورة أو طوكيو خلال أقل من 100 مللي ثانية، بدلًا من انتظار رحلات ذهاب وإياب إلى us-east-1.

# CloudFront origin for ALB + separate behaviour for static assets
aws cloudfront create-distribution --distribution-config '{
  'Origins': {
    'Quantity': 1,
    'Items': [{
      'Id': 'alb-origin',
      'DomainName': 'my-alb.us-east-1.elb.amazonaws.com',
      'CustomOriginConfig': {"HTTPSPort": 443, "OriginProtocolPolicy": "https-only"}
    }]
  },
  'CacheBehaviors': {
    'Quantity': 1,
    'Items': [{
      'PathPattern': '/static/*',
      'DefaultTTL': 604800,
      'MaxTTL': 604800
    }]
  },
  'DefaultCacheBehavior': {"DefaultTTL": 0}
}'

السيناريو 3: ضبط حجم الموارد باستخدام Compute Optimizer

السيناريو: لدى شركة 500 مثيل من EC2، وقد جرى توفير كثير منها قبل 3 سنوات باستخدام أنواع مثيلات كبيرة. فاتورة AWS مرتفعة، لكن الشركة لا تعرف أي المثيلات مفرط في توفير مواردها. الحل: فعّل AWS Compute Optimizer (وهو مجاني ويستخدم مقاييس CloudWatch لمدة 14 يومًا). يحلل Compute Optimizer الاستخدام الفعلي لوحدة المعالجة المركزية والذاكرة والشبكة والقرص لكل مثيل، ويقدم توصيات لضبط الحجم. قد يُوصى بتقليص حجم t3.xlarge الذي يبلغ متوسط استخدام وحدة المعالجة المركزية فيه 8% إلى t3.small. يؤدي تطبيق التوصيات على 500 مثيل عادةً إلى خفض تكاليف EC2 بنسبة تتراوح بين 20 و40%.

# Enable Compute Optimizer at account level
aws compute-optimizer update-enrollment-status \
  --status Active

# Get EC2 instance recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --filters Name=Finding,Values=OVER_PROVISIONED \
  --query 'instanceRecommendations[*].{Instance: instanceArn, Current: currentInstanceType, Recommended: recommendationOptions[0].instanceType}' \
  --output table

السيناريو 4: مثيلات Spot لمعالجة الدفعات

السيناريو: تدير شركة متخصصة في علم الجينوم مهام معالجة دفعات ليلية تستغرق 8 ساعات ويمكن إعادة تشغيلها إذا انقطعت. وتبلغ تكلفة EC2 On-Demand لهذه المهام 10,000 دولار شهريًا. الحل: استخدم مثيلات EC2 Spot لمجموعة معالجة الدفعات. مثيلات Spot هي سعة EC2 غير مستخدمة، ومتاحة بخصم يصل إلى 90%. بالنسبة إلى مهام الدفعات التي تتحمل الانقطاع، استخدم AWS Batch، الذي يعيد تلقائيًا وضع مهام Spot الفاشلة في قائمة الانتظار، ويستخدم مجموعة مختلطة (Spot مع حد أدنى من موارد On-Demand الاحتياطية). التوفير المتوقع: خفض تكاليف الحوسبة بنسبة تتراوح بين 70 و90%، من 10,000 دولار إلى 1,000–3,000 دولار شهريًا.

# AWS Batch compute environment with Spot instances
aws batch create-compute-environment \
  --compute-environment-name spot-genomics \
  --type MANAGED \
  --state ENABLED \
  --compute-resources '{
    "type": "SPOT",
    "bidPercentage": 60,
    "minvCpus": 0,
    "maxvCpus": 256,
    "instanceTypes": ["optimal"],
    "subnets": ["subnet-1a", "subnet-1b"],
    "securityGroupIds": ["sg-batch"],
    "instanceRole": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
    "spotIamFleetRole": "arn:aws:iam::123456789012:role/AmazonEC2SpotFleetRole"
  }' \
  --service-role arn:aws:iam::123456789012:role/AWSBatchServiceRole

السيناريو 5: سعة DynamoDB عند الطلب لحركة المرور المتغيرة

السيناريو: تستخدم لوحة ترتيب للعبة DynamoDB مع معدل نقل مُوفَّر. عند إطلاق الألعاب، ترتفع حركة المرور 50 ضعفًا ويبدأ الجدول في تقييد الطلبات. وخارج فترات الإطلاق، يقترب معدل النقل من الصفر، فتُهدَر السعة المُوفَّرة. الحل: بدّل DynamoDB إلى وضع السعة عند الطلب. تتوسع السعة عند الطلب فورًا لتلبية أي معدل نقل دون تخطيط يدوي للسعة، وتُفرض الرسوم لكل طلب بدلًا من كل وحدة سعة مُوفَّرة. تدفعون فقط مقابل الطلبات التي تنفذونها، دون تكلفة سعة خاملة بين عمليات الإطلاق. ويبادل الوضع عند الطلب ارتفاعًا طفيفًا في تكلفة الطلب الواحد مقابل ضمان عدم تقييد الطلبات وإلغاء إدارة السعة.

# Switch existing DynamoDB table to On-Demand mode
aws dynamodb update-table \
  --table-name Leaderboard \
  --billing-mode PAY_PER_REQUEST

# Verify the change
aws dynamodb describe-table \
  --table-name Leaderboard \
  --query 'Table.BillingModeSummary.BillingMode'

السيناريو 6: S3 Intelligent-Tiering للوصول غير المتوقع

السيناريو: تخزّن شركة ملايين الصور التي ينشئها المستخدمون في S3 Standard. وتختلف أنماط الوصول بصورة غير متوقعة؛ إذ يُ accessed إلى بعض الصور يوميًا، بينما لا يُ accessed إلى صور أخرى لعدة أشهر. وترغب الشركة في خفض تكاليف التخزين من دون إدارة سياسات دورة الحياة يدويًا. الحل: استخدام S3 Intelligent-Tiering. إذ ينقل الكائنات تلقائيًا بين الطبقات استنادًا إلى أنماط الوصول: الوصول المتكرر (Standard)، والوصول غير المتكرر (لم يتم الوصول إليها لمدة 30 يومًا أو أكثر)، والوصول الفوري إلى الأرشيف (90 يومًا أو أكثر)، والوصول إلى الأرشيف (90 يومًا أو أكثر، مع تفعيل اختياري). لا توجد رسوم استرجاع ضمن Intelligent-Tiering. وتبلغ رسوم المراقبة 0.0025 دولار لكل 1,000 كائن شهريًا، وهي تكلفة ضئيلة بالنسبة إلى مجموعات البيانات الكبيرة.

# Move objects to Intelligent-Tiering via lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
  --bucket user-images-bucket \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "AutoTier",
      "Status": "Enabled",
      "Filter": {},
      "Transitions": [{
        "Days": 0,
        "StorageClass": "INTELLIGENT_TIERING"
      }]
    }]
  }'

السيناريو 7: المفاضلة بين Athena وRedshift

السيناريو: ترغب شركة ناشئة في الاستعلام عن جداول بحيرة بيانات موجودة في S3. وتُجري نحو 10 استعلامات مخصصة أسبوعيًا. ويقترح أحد الموردين استخدام Amazon Redshift مع مجموعة dc2.large. الحل للشركة الناشئة: البدء باستخدام Amazon Athena؛ فلا توجد تكلفة للبنية التحتية، وتُدفع الرسوم فقط مقابل البيانات التي يتم فحصها (نحو 5 دولارات لكل TB). وقد تكلّف 10 استعلامات أسبوعيًا على بيانات Parquet مقسّمة جيدًا أقل من 5 دولارات شهريًا. بينما تكلّف مجموعة Redshift dc2.large نحو 180 دولارًا شهريًا عند تشغيلها باستمرار. يصبح Redshift فعالًا من حيث التكلفة فقط عندما يكون تزامن الاستعلامات مرتفعًا (50 استعلامًا أو أكثر يوميًا) أو تكون الاستجابة في أقل من ثانية مطلوبة. وتشير العبارة المفتاحية «مخصص، غير متكرر» بوضوح إلى Athena.

# Athena cost estimate for 10 queries/week:
# Assume each query scans 5 GB of Parquet data
# 10 queries x 5 GB = 50 GB / week = 200 GB / month
# Athena cost: 200 GB x $0.005/GB = $1.00 / month
#
# Redshift dc2.large cost: $0.25/hr x 24hr x 30days = $180/month
#
# For 10 queries/week -> Athena saves $179/month
# Breakeven: when queries scan >36 TB/month or concurrency >50/day -> use Redshift

السيناريو 8: اختيار نوع وحدة تخزين EBS

السيناريو: يتطلب خادم قاعدة بيانات علائقية 64,000 عملية إدخال وإخراج في الثانية (IOPS) مع زمن استجابة منخفض وثابت. وقد اقتربت وحدة تخزين gp3 الحالية في EBS من الحد الأقصى لعدد IOPS. الحل: الترقية إلى io2 Block Express (وهو نوع وحدة تخزين في EBS مصمم لقواعد البيانات كثيفة عمليات الإدخال والإخراج). يدعم io2 Block Express ما يصل إلى 256,000 IOPS لكل وحدة تخزين، مع زمن استجابة أقل من ميلي ثانية. وهو أغلى من gp3 (0.125 دولار/GB + ‏0.065 دولار/IOPS مخصّص/شهريًا)، لكنه خيار EBS الوحيد الذي يستوفي متطلبات 64,000 IOPS أو أكثر. وبالنسبة إلى أحمال قواعد البيانات الحساسة لزمن الاستجابة، عندما لا يكون سقف gp3 البالغ 16,000 IOPS كافيًا، فإن io2 هو خيار EBS العملي الوحيد.

# Create io2 Block Express volume with 64,000 IOPS
aws ec2 create-volume \
  --volume-type io2 \
  --size 500 \
  --iops 64000 \
  --availability-zone us-east-1a \
  --encrypted

# EBS volume type IOPS limits summary:
# gp3: up to 16,000 IOPS (default 3,000, configurable)
# io1: up to 64,000 IOPS (on Nitro instances)
# io2 Block Express: up to 256,000 IOPS
# st1 (throughput HDD): no IOPS focus, max 500 MB/s throughput
# sc1 (cold HDD): lowest cost, 250 MB/s max, rarely accessed data

السيناريو 9: المثيلات المحجوزة لأحمال العمل المستقرة

السيناريو: تشغّل شركة 20 مثيلًا من نوع r6i.4xlarge في EC2 باستمرار لتطبيق إنتاجي، ولا تتوقع أي تغيير في المتطلبات لمدة 3 سنوات. وتبلغ نفقاتها الحالية عند الطلب 80,000 دولار سنويًا لهذه المثيلات. الحل: شراء مثيلات محجوزة قياسية لمدة 3 سنوات (أو خطط Compute Savings Plans) مع الدفع الكامل مقدمًا للحصول على أكبر خصم. توفّر المثيلات المحجوزة القياسية خصمًا يصل إلى 72% مقارنةً بالتسعير عند الطلب. تعمل المثيلات على مدار الساعة طوال أيام الأسبوع مع حمل عمل متوقع، وهذا هو النموذج التقليدي المناسب للمثيلات المحجوزة. خفض التكلفة المتوقع: ‏80,000 × 0.72 = ‏22,400 دولار سنويًا، مقارنةً بـ 80,000 دولار سنويًا عند الطلب، أي توفير قدره 57,600 دولار سنويًا.

# Reserved Instance purchase decision matrix:
# On-Demand:          No commitment, highest price, any workload
# 1-yr RI (All Up):   40% discount, 1-yr commitment, specific instance type
# 3-yr RI (All Up):   60-72% discount, 3-yr commitment, best for stable workloads
# Compute Savings Plan: 66% max discount, flexible instance family/size/Region
# EC2 Spot:           90% discount, interruptible, batch/stateless only
#
# Rule: if usage > 70% of the time for >1 year -> buy RI or Savings Plan
# Rule: if usage < 50% -> stick with On-Demand
# Rule: if usage pattern is steady 3yr -> 3yr RI All Upfront maximises savings

السيناريو 10: مقارنة تكلفة Lambda وEC2 مع حركة مرور متغيرة

السيناريو: تشغّل شركة واجهة REST API على مثيل t3.micro في EC2 بتكلفة تبلغ 8 دولارات شهريًا. وتستقبل الواجهة مليون طلب شهريًا، ويستغرق تنفيذ كل طلب 100 مللي ثانية. ويتساءل الفريق عما إذا كان Lambda سيكون أقل تكلفة. التحليل: تسعير Lambda: ‏1,000,000 طلب × ‏0.0000002 دولار = ‏0.20 دولار (تكلفة الطلبات) + ‏1,000,000 × ‏0.1 ثانية × ذاكرة 128MB × المعدل = نحو 1.67 دولار (تكلفة الحوسبة)، بإجمالي نحو 1.87 دولار شهريًا. وبذلك يكون Lambda أرخص من EC2 لواجهة API منخفضة الحركة هذه. ومع ارتفاع عدد الطلبات إلى أكثر من نحو 40 مليون طلب شهريًا، يصبح EC2 أرخص. استخدم Lambda Cost Calculator لتحديد نقطة التعادل لكل حمل عمل.

# Lambda vs EC2 cost rough break-even calculation:
# Lambda costs: $0.20 per 1M requests + $0.0000166667 per GB-second
# At 128 MB memory, 100ms duration:
#   GB-seconds per request = 0.128 GB x 0.1s = 0.0128 GB-s
#   Cost per request = $0.0000166667 x 0.0128 = $0.000000213 compute
#   + $0.0000002 request fee = $0.000000413 total per request
#
# EC2 t3.micro: $0.0104/hr x 720 hrs = $7.49/month
# Break-even: $7.49 / $0.000000413 = ~18 million requests/month
# Below 18M requests/month -> Lambda cheaper
# Above 18M requests/month -> EC2 cheaper (if utilisation is high)

السيناريو 11: Global Accelerator لواجهات API الديناميكية

السيناريو: تعاني واجهة API عالمية تخدم مستخدمين في أوروبا والولايات المتحدة وآسيا من تفاوت في زمن الاستجابة، لأن حركة المرور تمر عبر مسارات غير متوقعة على الإنترنت. وقد جرت دراسة CloudFront، لكن استجابات واجهة API ديناميكية (ولا يمكن تخزينها مؤقتًا). الحل: استخدام AWS Global Accelerator. إذ يوفر عنواني IP ثابتين من نوع anycast على مستوى العالم. تدخل حركة مرور المستخدم إلى العمود الفقري العالمي لـ AWS عبر أقرب موقع طرفي لـ AWS، ثم تنتقل عبر شبكة AWS الخاصة إلى المصدر في Region المستهدفة، متجنبةً الجزء الأوسط المزدحم من الإنترنت العام. ويحسّن Global Accelerator زمن استجابة واجهات API الديناميكية بنسبة تتراوح بين 20% و60%، كما يوفر تحويلًا فوريًا عند تعطل نقطة نهاية إحدى Regions.

# Create a Global Accelerator for an ALB
aws globalaccelerator create-accelerator \
  --name my-api-accelerator \
  --ip-address-type IPV4 \
  --enabled

# Add a listener and endpoint group pointing to ALB
aws globalaccelerator create-listener \
  --accelerator-arn arn:aws:globalaccelerator::123:accelerator/abc \
  --protocol TCP \
  --port-ranges '[{"FromPort": 443, "ToPort": 443}]'

# Endpoint group in us-east-1 with ALB
aws globalaccelerator create-endpoint-group \
  --listener-arn arn:aws:globalaccelerator::123:listener/xyz \
  --endpoint-group-region us-east-1 \
  --endpoint-configurations '[{"EndpointId": "arn:aws:elasticloadbalancing:...", "Weight": 100}]'

اختبار سريع

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

مراجعة الدرس

خلال هذا الدرس، تعاملت مع سيناريوهات تشمل: التحميل الكسول في ElastiCache لخفض استخدام CPU في RDS من 80% إلى 20%، وSpot Instances وAWS Batch لتوفير 70-90% من تكاليف مهام المعالجة الدفعية، وAthena للاستعلامات المخصصة غير المتكررة مقارنةً بـ Redshift للتحليلات عالية التزامن، وS3 Intelligent-Tiering لأنماط الوصول غير المتوقعة من دون رسوم استرجاع. والآن ننتقل إلى المشروع الختامي الأخير: اختبار مصغر مؤقت ومتعدد المجالات لقياس مدى استعدادك.

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

هل درس «سيناريوهات الأداء العالي وتحسين التكلفة» مجاني؟

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

ماذا ستتعلم في «سيناريوهات الأداء العالي وتحسين التكلفة»؟

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

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

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

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

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

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

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

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

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