ركيزتا الموثوقية وكفاءة الأداء
صمّم للتعافي التلقائي والتوسّع الأفقي وإدارة السعة، واختر أنواع الموارد المناسبة وراقبها للحفاظ على الأداء بمرور الوقت
ركيزتا الموثوقية وكفاءة الأداء درس مجاني في Cloud & IT Cert Prep على CoddyKit. هذا هو الدرس 2 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Cloud & IT Cert Prep، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Cloud & IT Cert Prep 4 دروس في المجموع.
نظرة عامة على ركيزة الموثوقية
تضمن ركيزة الموثوقية في إطار العمل Well-Architected أن ينفّذ حمل العمل وظيفته المقصودة بشكل صحيح ومتسق عند الحاجة إليه. وتشمل الموثوقية ثلاثة مجالات: الأسس (حدود الخدمة وطوبولوجيا الشبكة)، ومعمارية حمل العمل (الأنظمة الموزعة وتجنّب نقاط التعطل الفردية SPOFs)، وإدارة التغييرات وإدارة حالات الفشل (المراقبة والتوسّع والتعافي من الفشل). والهدف هو بناء أنظمة تتعافى تلقائيًا من انقطاعات البنية التحتية أو الخدمات.
# Reliability design principles:
# 1. Automatically recover from failure
# 2. Test recovery procedures
# 3. Scale horizontally to increase availability
# 4. Stop guessing capacity (use auto scaling)
# 5. Manage change in automation (IaC + CI/CD)
# Key AWS services for reliability:
# - Auto Scaling Groups
# - Elastic Load Balancing
# - Route 53 health checks
# - AWS Backupحدود الخدمة والحصص
تفرض AWS حصص الخدمة (المعروفة سابقًا باسم الحدود) على الموارد لحماية جميع العملاء. ومن أمثلتها الحدود الافتراضية لمثيلات EC2 في كل منطقة، وحدود VPC، والتنفيذات المتزامنة لـ Lambda. إذا بلغ حمل العمل حصةً ما بشكل غير متوقع، فسيتم تقييد الطلبات أو رفضها، مما يؤدي إلى إخفاقات في الموثوقية. استخدم وحدة تحكم Service Quotas أو CLI لعرض الحدود الحالية وطلب زيادتها قبل الحاجة إليها. راقب مقاييس الاستخدام لاكتشاف اقترابك من الحدود قبل أن يؤثر ذلك في التوافر.
# List service quotas for EC2
aws service-quotas list-service-quotas \
--service-code ec2 \
--query 'Quotas[?QuotaName==`Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances`]'
# Request quota increase
aws service-quotas request-service-quota-increase \
--service-code ec2 \
--quota-code L-1216C47A \
--desired-value 500التعافي التلقائي من الفشل
تؤكد ركيزة الموثوقية على التعافي التلقائي دون تدخل بشري. توفّر AWS آليات متعددة للمعالجة الذاتية: يعمل EC2 Auto Recovery تلقائيًا على استعادة المثيل على العتاد نفسه أو نقله إلى عتاد سليم عند فشله في الفحوص الأساسية. وتنهي فحوصات سلامة ASG المثيلات غير السليمة وتطلق بدائل لها. ويجري RDS Multi-AZ تحويلاً تلقائيًا إلى المثيل الاحتياطي. صمّم بنيتك بحيث تؤدي معظم سيناريوهات الفشل إلى تشغيل إجراءات تعافٍ تلقائية تلتقطها تنبيهات CloudWatch.
# CloudWatch alarm to auto-recover a specific EC2 instance
aws cloudwatch put-metric-alarm \
--alarm-name EC2-auto-recover \
--metrics '[{"Id":"m1","MetricStat":{"Metric":{"Namespace":"AWS/EC2","MetricName":"StatusCheckFailed_System","Dimensions":[{"Name":"InstanceId","Value":"i-12345"}]},"Period":60,"Stat":"Maximum"}}]' \
--comparison-operator GreaterThanThreshold \
--threshold 0 \
--evaluation-periods 2 \
--alarm-actions 'arn:aws:automate:us-east-1:ec2:recover'التوسّع الأفقي لتحقيق الموثوقية
توصي ركيزة الموثوقية بالتوسّع أفقيًا (إضافة مزيد من المثيلات الأصغر) بدلًا من التوسّع رأسيًا (الانتقال إلى مثيلات أكبر) لتحقيق موثوقية أفضل. فالمثيل الكبير الواحد يمثل نقطة تعطل فردية. أما استخدام مثيلات أصغر متعددة خلف موزّع حمل، فيعني أن فشل أي مثيل منفرد سيكون تأثيره محدودًا. يعمل AWS Auto Scaling على ضبط حجم الأسطول تلقائيًا لتلبية الطلب، مما يضمن امتلاك سعة كافية، وعدم الدفع مقابل الموارد الخاملة خلال فترات انخفاض النشاط.
# Horizontal scaling: 10 t3.medium vs 1 r5.4xlarge
# 10 t3.medium:
# - Failure of 1 = loss of 10% capacity
# - ASG launches replacement automatically
# - 9 instances absorb load during replacement
# 1 r5.4xlarge:
# - Failure = 100% downtime until instance recovered
# - Much higher RTO (new instance launch: 1-3 min)
# Prefer horizontal scaling for stateless tiersاختبار الموثوقية
تتطلب ركيزة الموثوقية اختبار إجراءات التعافي — لا افتراض نجاحها. استخدم AWS Fault Injection Simulator (FIS) لإدخال حالات فشل في نظامك بطريقة محكومة: أنهِ مثيلات EC2 عشوائية، وخنّق استدعاءات API، وأدخل زمن استجابة للشبكة. أجرِ هذه التجارب في بيئة الإنتاج (مع وضع وسائل حماية) للتحقق من أن المراقبة تكتشف حالات الفشل، وأن التوسّع التلقائي يستجيب، وأن التعافي يكتمل ضمن RTO الخاص بك. غالبًا ما تفشل إجراءات التعافي غير المختبرة تحت ضغط حادث حقيقي.
# AWS FIS experiment: terminate random instance
aws fis create-experiment-template \
--description 'Chaos: terminate 1 of 5 instances' \
--targets '{"instanceTargets":{"resourceType":"aws:ec2:instance","selectionMode":"COUNT(1)","resourceTags":{"Env":"production"}}}' \
--actions '{"terminateInstance":{"actionId":"aws:ec2:terminate-instances","targets":{"Instances":"instanceTargets"}}}' \
--stop-conditions '[{"source":"aws:cloudwatch:alarm","value":"arn:aws:cloudwatch::123:alarm:high-error-rate"}]'نظرة عامة على ركيزة كفاءة الأداء
تركّز ركيزة كفاءة الأداء على استخدام موارد الحوسبة بكفاءة لتلبية متطلبات النظام، والحفاظ على هذه الكفاءة مع تغيّر الطلب وتطوّر التقنيات. مبادئ التصميم الأساسية: إتاحة التقنيات المتقدمة للجميع — استخدام الخدمات المُدارة (RDS وSageMaker) بدلًا من بنائها من الصفر. الانتقال إلى النطاق العالمي خلال دقائق — النشر في مناطق متعددة باستخدام CloudFormation. استخدام المعماريات عديمة الخوادم — التخلّص من إدارة البنية التحتية. إجراء التجارب بوتيرة أكبر — اختبار أنواع المثيلات والتكوينات المختلفة.
# Performance Efficiency areas:
# Selection: Right compute, storage, database, network
# Review: Continuously evaluate new services
# Monitoring: CloudWatch metrics guide decisions
# Trade-offs: Consistency vs performance, latency vs cost
# Example: choosing between services
# RDS vs DynamoDB vs Aurora vs ElastiCache
# → depends on access patterns, consistency needs, scaleاختيار الحوسبة المناسبة
تبدأ كفاءة الأداء باختيار نوع الحوسبة المناسب لحمل العمل. يضم EC2 عشرات عائلات المثيلات المحسّنة لحالات استخدام مختلفة: c-series للأحمال كثيفة الحوسبة (ترميز الفيديو ومعالجة الدُفعات)، وr-series للأحمال كثيفة الذاكرة (قواعد البيانات الموجودة في الذاكرة والتخزين المؤقت)، وi-series للأحمال كثيفة التخزين (NoSQL ومستودعات البيانات)، وp/g-series لأحمال GPU (تدريب ML). ويعني استخدام نوع المثيل الخاطئ الدفع مقابل سعة لا يمكنك استخدامها أو تراجع الأداء.
# AWS Compute Optimizer: get right-size recommendations
aws compute-optimizer get-ec2-instance-recommendations \
--instance-arns arn:aws:ec2:us-east-1:123:instance/i-12345
# Output shows:
# - Current instance utilisation (CPU, memory, network)
# - Recommended instance type
# - Estimated monthly savings
# - Performance risk of changing
# Lambda: match memory to actual usage
# Use Lambda Power Tuning tool for memory optimisationالتخزين المؤقت لتحقيق كفاءة الأداء
يُعد التخزين المؤقت أسلوبًا أساسيًا لكفاءة الأداء، إذ يقلل زمن الاستجابة وحمل قاعدة البيانات. يخزّن ElastiCache (Redis/Memcached) نتائج استعلامات قاعدة البيانات في الذاكرة للوصول إليها خلال أجزاء من الألف من الثانية. ويخزّن CloudFront استجابات HTTP مؤقتًا في مواقع الحافة القريبة من المستخدمين. ويقلل التخزين المؤقت في API Gateway استدعاءات Lambda عبر تخزين استجابات API مؤقتًا. ويضيف DAX (DynamoDB Accelerator) ذاكرة تخزين مؤقت داخل الذاكرة بزمن وصول مقداره ميكروثانية أمام DynamoDB. اختر طبقة التخزين المؤقت المناسبة بناءً على موضع عنق الزجاجة — قاعدة البيانات أو API أو التوصيل عبر الحافة.
# DAX cluster for DynamoDB microsecond latency
aws dax create-cluster \
--cluster-name my-dax \
--node-type dax.r6g.large \
--replication-factor 3 \
--iam-role-arn arn:aws:iam::123:role/DAXRole \
--subnet-group my-dax-subnet-group
# Application connects to DAX endpoint
# Cache hits: microseconds
# Cache misses: fetches from DynamoDB and caches resultالتخزين المناسب لتحقيق الأداء
يؤثر اختيار التخزين تأثيرًا كبيرًا في الأداء. يوفّر io2 Block Express EBS ما يصل إلى 256,000 عملية إدخال/إخراج في الثانية IOPS لقواعد البيانات عالية الأداء. ويُعد gp3 الخيار الافتراضي لمعظم أحمال العمل بتكلفة أقل. ويوفّر Instance store أعلى معدل IOPS (NVMe) للبيانات المؤقتة. ويتوسع S3 إلى آلاف الطلبات في الثانية لتخزين الكائنات. ويوفّر EFS وصولًا مشتركًا إلى الملفات وفق POSIX. طابق التخزين مع نمط الإدخال/الإخراج: تستفيد عمليات القراءة التسلسلية من st1 (Throughput Optimised HDD)، بينما تتطلب عمليات الإدخال/الإخراج العشوائية وحدات تخزين SSD.
# EBS volume performance characteristics:
# gp3: 3,000-16,000 IOPS, 125-1,000 MB/s
# io2: 100-64,000 IOPS (up to 256k with Block Express)
# st1: 40-500 MB/s sequential throughput (HDD)
# sc1: 12-250 MB/s (cheapest, cold workloads)
# Create high-performance io2 volume
aws ec2 create-volume \
--availability-zone us-east-1a \
--volume-type io2 \
--size 500 \
--iops 50000مراقبة الأداء والتحسين المستمر
كفاءة الأداء ليست قرارًا يُتخذ مرة واحدة — بل يجب عليك مراقبة مقاييس الأداء باستمرار وإعادة تقييم اختياراتك مع إصدار AWS خدمات جديدة. استخدم لوحات معلومات CloudWatch لتتبّع المئينات p50 وp90 وp99 لزمن الاستجابة (وليس المتوسطات فقط، لأنها تخفي زمن الاستجابة في الذيل). استخدم تتبعات X-Ray لتحديد الأجزاء الأبطأ في سلسلة الطلب. اضبط اكتشاف الحالات الشاذة في CloudWatch لإنشاء خط أساس تلقائيًا وإطلاق تنبيهات عند الانحرافات غير الطبيعية في الأداء. راجع إعلانات AWS بانتظام — فغالبًا ما توفّر أنواع المثيلات الأحدث أداءً أفضل بتكلفة أقل.
# CloudWatch: track API response latency percentiles
aws cloudwatch put-metric-alarm \
--alarm-name 'API-P99-Latency' \
--metric-name TargetResponseTime \
--namespace AWS/ApplicationELB \
--extended-statistic p99 \
--dimensions Name=LoadBalancer,Value=app/my-alb/xxx \
--period 60 \
--evaluation-periods 5 \
--threshold 2.0 \
--comparison-operator GreaterThanThresholdالمفاضلات في كفاءة الأداء
تتطلب كفاءة الأداء أحيانًا إجراء مفاضلات مع الركائز الأخرى. تؤدي إضافة ذاكرة تخزين مؤقت (ElastiCache) إلى تحسين الأداء، لكنها تضيف تعقيدًا تشغيليًا (مفاضلة مع التميّز التشغيلي) وتكلفة (مفاضلة مع تحسين التكلفة). ويؤدي استخدام DynamoDB بدلًا من RDS إلى تحسين الأداء على نطاق واسع، لكنه يتطلب إعادة تصميم نموذج البيانات (جهد من التميّز التشغيلي). يقر إطار العمل Well-Architected بهذه المفاضلات، ويطلب منك إجراؤها بوعي وتوثيق أسبابها. في أسئلة الاختبار، ابحث عن الخيار الذي يحقق أهداف الأداء بأقل عبء تشغيلي.
# Common performance vs cost trade-offs:
# Cache: +Performance, +Cost, +Complexity
# Read Replicas: +Read performance, +Cost
# SSD vs HDD: +IOPS, +Cost
# Multi-region: -Latency for users, +Cost, +Complexity
# Common performance vs consistency trade-offs:
# DynamoDB eventually consistent reads: +Throughput, -Consistency
# Aurora Reader endpoint: +Read scale, potential replication lagتحقق سريع
اختبر مدى فهمك لمفاهيم AWS Solutions Architect (SAA-C03) الواردة في هذا الدرس.
مراجعة الدرس
تعلّمت في هذا الدرس أن الموثوقية تتطلب التعافي التلقائي والتوسّع الأفقي والاختبار المنتظم لحالات الفشل، وأن كفاءة الأداء تتطلب اختيار نوع الحوسبة والتخزين وقاعدة البيانات المناسب لكل حمل عمل، وأن التخزين المؤقت على طبقات متعددة يقلل زمن الاستجابة وحمل قاعدة البيانات. وتتطلب كلتا الركيزتين مراقبة مستمرة واستعدادًا لإعادة النظر في القرارات المعمارية. سنستكشف بعد ذلك ركيزتي تحسين التكلفة والاستدامة.
الأسئلة الشائعة
هل درس «ركيزتا الموثوقية وكفاءة الأداء» مجاني؟
نعم — نص درس «ركيزتا الموثوقية وكفاءة الأداء» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Cloud & IT Cert Prep، انتقل إلى CoddyKit PRO. تتضمن دورة Cloud & IT Cert Prep 4 دروس في المجموع.
ماذا ستتعلم في «ركيزتا الموثوقية وكفاءة الأداء»؟
صمّم للتعافي التلقائي والتوسّع الأفقي وإدارة السعة، واختر أنواع الموارد المناسبة وراقبها للحفاظ على الأداء بمرور الوقت تتمرن على Cloud & IT Cert Prep مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ Cloud & IT Cert Prep؟
لا تُشترط خبرة سابقة. Cloud & IT Cert Prep على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 2 من أصل 4.
كم من الوقت يستغرق درس «ركيزتا الموثوقية وكفاءة الأداء»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس Cloud & IT Cert Prep هذا؟
نعم. كل درس في Cloud & IT Cert Prep يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- ركيزتا التميّز التشغيلي والأمان
- ركيزتا الموثوقية وكفاءة الأداء
- ركيزتا تحسين التكلفة والاستدامة
- أداة Well-Architected وعملية المراجعة